A new resident-services portal grants guest access to all modules whenever the identity provider is unreachable. What secure-design change should the architect require?
Select an answer to reveal the explanation.
Short Explanation
When the badge reader dies, you don’t prop the vault open for “guest mode.” Fail securely means no verified identity, no access—even if that means a temporary outage message instead of a free-for-all.
Full Explanation
A resident-services portal that grants guest access to all modules whenever the identity provider is unreachable fails open—trading availability messaging for uncontrolled confidentiality and integrity exposure across citizen data and municipal workflows. Secure design requires failing closed to authenticated sessions only: when identity cannot be verified, access is denied by default, with clear outage communication and break-glass procedures for truly emergency operations that remain tightly scoped and audited. Keeping fail-open so residents never see an error page prioritizes optics over authorization integrity. Caching every resident password in browser local storage to survive IdP outages creates a durable credential-theft target and bypasses central revocation. Disabling logging during outages removes the evidence trail needed to detect abuse precisely when controls are weakest. Exam caveat: “fail securely” / secure defaults mean deny access when security-relevant checks cannot complete; availability concerns are handled with redundancy and staged degradation, not universal guest mode. Operational check: simulate IdP unreachability in staging and confirm the portal refuses sensitive modules, serves a controlled error page, retains security logging, and that any emergency override uses separate privileged credentials with time limits and full audit—not a blanket anonymous grant.