A change window disables a weak cipher on the city's API gateway and an old payment integration breaks. Leadership asks how to proceed securely. What is the best approach?
Select an answer to reveal the explanation.
Short Explanation
Hardening broke the old payment client—upgrade it if you can, or park a short, written risk exception while you finish the migration. Putting weak crypto back forever, or dropping TLS, is the wrong kind of fix.
Full Explanation
When a change window disables a weak cipher on the city's API gateway and an old payment integration breaks, leadership asking how to proceed securely should roll forward by upgrading the integration to supported clients, or use a time-bound exception with documented risk acceptance. Secure municipal posture prefers upgrading weak crypto, with exceptions only as temporary, owned risk. Re-enabling every weak cipher permanently across all gateways undoes hardening for all consumers. Ignoring the break and hoping citizens stop using the payment path abandons a critical civic function. Removing TLS entirely so both sides communicate in cleartext is unacceptable for payment data. Exam caveat: temporary exceptions need expiry dates, compensating controls, and executive acknowledgment—not silent permanent rollback of TLS baselines. Operational check: inventory broken payment clients, schedule upgrades, if needed apply a narrowly scoped temporary cipher exception with an end date, monitor for progress, and confirm the gateway returns to the hardened baseline when the exception expires. In municipal cloud operations, record the chosen control and the rejected alternatives in the change or incident ticket so future on-call staff understand which failure modes were avoided for city services. Re-validate after the next maintenance window that the same decision still holds under current provider limits, identity bindings, and application versions used by the civic platform team.