Do you have break-glass admin credentials accessible during an incident (sealed in a vault, separate from the affected identity provider)?
Demonstrate that emergency administrative credentials exist, are stored securely offline in a manner independent of production identity providers, and are accessible to authorized responders during incidents affecting authentication systems.
Description
What this control does
Break-glass (emergency) administrative credentials are pre-provisioned, highly privileged accounts stored offline and physically secured (e.g., in a tamper-evident envelope within a locked safe) to enable recovery when primary identity providers or authentication systems fail or are compromised. These credentials must be independent of the affected IdP, typically local admin accounts or root credentials, and must not rely on federated authentication, MFA apps, or cloud-hosted secret stores that may be inaccessible during an incident. This control ensures business continuity and incident response capability when normal access paths are severed by ransomware, misconfigurations, or supply-chain attacks targeting authentication infrastructure.
Control objective
What auditing this proves
Demonstrate that emergency administrative credentials exist, are stored securely offline in a manner independent of production identity providers, and are accessible to authorized responders during incidents affecting authentication systems.
Associated risks
Risks this control addresses
- Complete lockout from critical systems during an identity provider outage, preventing incident response and recovery operations
- Inability to remediate a compromised identity provider or federation service due to dependency on that same system for administrative access
- Prolonged downtime or data loss when ransomware encrypts or deletes cloud-hosted credential vaults and MFA enforcement blocks all access paths
- Unauthorized escalation if break-glass credentials are stored digitally in systems accessible to attackers who have already compromised the environment
- Delayed incident containment when emergency credentials are lost, outdated, or their storage location is unknown to on-call responders
- Regulatory non-compliance and audit findings when no documented emergency access procedure exists independent of primary authentication mechanisms
- Insider threat or social engineering exploitation if break-glass credentials lack audit trails, tamper-evidence, or dual-custody controls
Testing procedure
How an auditor verifies this control
- Request the organization's break-glass access policy and incident response plan sections describing emergency credential storage and retrieval procedures.
- Obtain an inventory of all break-glass accounts, including system scope (e.g., domain controllers, hypervisors, cloud tenants, network devices), account names, and last password rotation dates.
- Verify that break-glass credentials are stored in physical, offline containers (e.g., sealed envelopes in safes) by inspecting storage locations and photographing tamper-evident seals without opening.
- Confirm independence from the primary identity provider by reviewing account provisioning records to ensure local authentication (not federated SSO, LDAP, or cloud IdP dependency).
- Interview the custodians responsible for physical key or safe access and verify their names match documented authorization lists in the break-glass policy.
- Examine access logs or sign-out ledgers for the storage location to confirm the last audit or test retrieval date and ensure periodic validation occurs.
- Review change management records for the most recent break-glass credential rotation to verify passwords are updated at defined intervals and not stale.
- Test a simulated retrieval scenario by requesting the custodian demonstrate the retrieval process (without unsealing) and confirm response time aligns with incident response SLAs.