# Design break-glass access for a SaaS control plane > Build independent emergency access with narrow powers, short expiry, immediate alerts, immutable evidence, and regular recovery drills. Canonical URL: https://www.devobs.io/articles/break-glass-access-for-saas-control-planes/ By: Claire Dubois Published: 2024-03-27T12:38:23.054Z Updated: 2026-09-06T08:31:04.426Z Section: Architecture Break-glass access should be an independently authenticated, narrowly privileged, time-limited recovery path used only when normal identity or authorization is unavailable. It must work during the outage it is meant to solve, and every use should create immediate alerts and reviewable evidence. ## Define the emergencies before the account Write specific trigger conditions: the primary identity provider is unavailable; federation configuration blocks every administrator; the authorization service denies all control-plane access; or a compromise response requires isolation from the normal trust path. “It is convenient” is not a trigger. For each condition, state which emergency actions restore normal administration and which actions remain prohibited. NIST [SP 800-53 Rev. 5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) provides a broad control catalog covering access control, identification and authentication, audit, contingency planning, and incident response. Use those families together: emergency access is not merely a privileged account; it is a controlled contingency procedure with authentication, logging, response, and review. Keep emergency authentication independent from the primary failure domain. If normal access depends on corporate SSO and the same SSO authenticates the break-glass account, the path is not independent. Use phishing-resistant credentials where supported, separate devices or custody, and recovery material protected by more than one person. Do not create a shared password known to an entire team. ## Minimize standing power The emergency identity should be excluded from ordinary daily use and automation. Grant only recovery capabilities: inspect control-plane health, repair identity-provider configuration, restore [authorization policy](https://www.devobs.io/articles/centralized-versus-embedded-authorization/), revoke compromised administrators, or activate a known recovery configuration. Customer data export, billing changes, and application-level impersonation should remain unavailable unless an explicit emergency scenario requires them. Microsoft's guidance for [emergency access accounts](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access) recommends multiple emergency accounts, authentication methods independent from ordinary administrator methods, monitoring, and regular validation. Its implementation details are specific to Microsoft Entra ID, but the resilience principles transfer to a SaaS control plane. Where possible, keep the standing identity low privilege and issue an expiring elevation after a second custodian confirms the incident. Bind elevation to an incident ID, scope, and maximum duration. Automatically revoke it and terminate sessions at expiry. Recovery must not depend on the affected policy engine being healthy, so test the entire enforcement chain. ## Alert and preserve evidence Alert security and incident responders on every authentication attempt, successful or failed, and on every privilege activation. Record actor or custodian identities, reason, incident, commands or API actions, resource effects, start and end times, and revocation. Send logs to a system the emergency identity cannot alter. Never place raw credentials in the incident record. After use, rotate or replace exposed recovery material, verify normal administration, review actions, and close any temporary network path. Treat unexplained use as a security incident. A successful emergency login during a drill should still generate the same alerts as a real one. ## Prove it quarterly and after changes Run a controlled exercise that disables the normal identity path, retrieves credentials through the documented custody process, performs a harmless recovery action, observes alerts, and revokes access. Include an expired credential, unavailable custodian, and logging failure in separate drills. The next step is to name the exact outage your current emergency account survives. Trace every dependency from credential retrieval to control-plane enforcement; any dependency shared with the simulated outage becomes a concrete redesign task. ## Test compromise as well as outage An identity outage and an administrator compromise demand different recovery moves. Exercise a case where the normal provider still works but cannot be trusted. The emergency path must let responders [revoke sessions](https://www.devobs.io/articles/session-revocation-distributed-systems/) and isolate integrations without accepting assertions from the compromised system. Confirm recovery notifications travel through an independent channel and evidence lands outside the affected control plane. Then rotate every credential exposed during the exercise and verify old sessions fail. Reviewed September 2026. ## Source references - -