When the identity provider is down, MFA is broken or administrators are locked out, someone still needs to get in. Break-glass (emergency access) accounts provide that route. They are also some of the most dangerous accounts an organisation owns: highly privileged, often excluded from normal controls and rarely used, so misuse can go unnoticed. This guide explains how to design, protect, monitor and test break-glass access for cloud directories, cloud provider root accounts, on-premises systems, PAM platforms and critical applications. It is written for identity, infrastructure and security operations teams, and for the risk and audit functions that have to sign off the design.
Key takeaways
- Keep a small number, independent of what they recover. Microsoft recommends two or more cloud-only emergency accounts that are not federated or synchronised from on-premises.
- Use phishing-resistant, separate authentication. FIDO2 security keys or certificate-based authentication, held in secure physical storage, and different from the methods your normal administrators use.
- Exclude deliberately, then compensate. Exclude emergency accounts from policies that could block sign-in, and make strong authentication, monitoring and custody carry the protection instead.
- Alert on every use. A break-glass sign-in should wake someone up, through a channel that does not depend on the platform that just failed.
- Test regularly and after changes. Microsoft says to validate emergency accounts at least every 90 days; an emergency account that fails in an emergency is worse than none.
When break-glass is needed
Break-glass access exists for the moment when the normal path to administration has failed. Each scenario below fails in a different way, which is why the design has to remove dependencies rather than add them.
| Scenario | What fails | What the emergency route must avoid depending on |
|---|---|---|
| Identity provider or federation outage | Federated users cannot sign in to the cloud directory | The federation service and on-premises directory |
| MFA service outage or registration problem | Administrators cannot complete MFA or activate roles | Phones, SMS and the MFA method normal admins use |
| Conditional access or policy error | A new policy blocks every administrator | The policies being changed |
| Loss of the last administrators | Departure, deletion or disablement of the only admin accounts | Any single person or on-premises account state |
| Locked privileged role activation | All admin roles are eligible, activation needs approval and no approver is active | The privileged identity management workflow |
| PAM platform outage | Vaulted credentials cannot be retrieved | The vault itself |
| Cyber incident | Normal admin accounts may be compromised | Accounts and devices the attacker may control |
Microsoft lists most of these situations for Entra ID, including the case where every Global Administrator and Privileged Role Administrator assignment is eligible, activation requires approval and no approvers remain, leaving tenant administration "effectively locked". For wider planning, see the Business Continuity and Disaster Recovery Guide.
Designing break-glass accounts
- Independence: cloud-only accounts that do not depend on on-premises federation or synchronisation. Microsoft specifies accounts on the
*.onmicrosoft.comdomain and says to keep on-premises and cloud emergency access distinct, "with no dependency of one on the other". Use local accounts for critical on-premises systems. - Minimal number: two or more per platform, so one can be used while another is protected or recovered.
- Standing, not eligible: in Entra Privileged Identity Management, Microsoft says to make the Global Administrator assignment for emergency accounts active permanent rather than eligible, so activation workflows cannot block them.
- Clear naming that does not advertise purpose to attackers enumerating directories, while being documented internally.
- Exclusion design: exclude emergency accounts from conditional access policies that block or restrict sign-in, using a dedicated group; Microsoft notes report-only policies need no exclusion.
- Nothing personal attached: do not tie the accounts to an individual's phone, email or self-service password reset details, and make sure credentials and devices do not expire or fall into automated clean-up for lack of use.
- No day-to-day use: never use them for routine administration, email or browsing.
Shared accounts or named accounts?
Vendors differ, and the choice is a trade-off between availability and accountability.
| Model | Who recommends it | Strength | Weakness |
|---|---|---|---|
| Shared emergency accounts, credentials in a known secure location available to several administrators | Microsoft (default guidance for Entra ID) | Works when specific people are unavailable | Weaker attribution; custody and logging must compensate |
| Individual emergency accounts per administrator | Microsoft (alternative); Google advises more than one super admin, each managed by a separate individual | Clear accountability; usable remotely | More accounts to protect, monitor and test |
| Split custody (one group holds the password, another the MFA device) | AWS (root user, multi-person approval) | No single person can use the account alone | Needs two people available in an emergency |
Protecting credentials
- Use FIDO2 security keys or certificate-based authentication. CISA calls FIDO/WebAuthn "the only widely available phishing-resistant authentication", and Microsoft says both passkeys (FIDO2) and certificate-based authentication satisfy its mandatory MFA requirement.
- Use authentication methods different from your normal administrator accounts. Microsoft's example: if admins use the Authenticator app, use a FIDO2 key for emergency accounts.
- Store keys in secure, fireproof safes at separate locations, and change safe combinations regularly and whenever someone with access leaves.
- If passwords are also used, make them long and random, split between custodians (dual control) and stored offline. AWS suggests requiring two or more people to authorise access to where the root password is stored.
- Do not store break-glass credentials only in the PAM platform or password manager that might itself be unavailable. AWS makes the same point for root: do not store the root password in tools that depend on the account it unlocks.
- Use the accounts only from a designated secure workstation, such as a privileged access workstation. See the Tiered Administration Guide.
- Record custody: who holds what, where, and when it was last checked.
See the Phishing-Resistant MFA Guide.
Monitoring
Because break-glass accounts sit outside many preventive controls, detection carries more of the weight than for any other account.
- Every sign-in: alert immediately on any sign-in or attempted sign-in, to several people. Microsoft's guidance uses an Azure Monitor log alert on the accounts' object IDs with a threshold of greater than zero and severity "0 - Critical".
- Independent channels: send alerts by SMS, voice or a paging tool that does not rely on the identity platform or email tenant that may be down.
- Changes to the accounts: alert on changes to authentication methods, group membership, conditional access exclusions and role assignments. Watch for roles assigned outside PIM, which Entra PIM can raise as a security alert.
- Cloud root use: AWS recommends alerting on root user sign-in and usage, for example with an EventBridge or CloudWatch rule, or GuardDuty, and having a procedure for staff who receive the alert. Google recommends alerts when a
SetIamPolicy()call modifies an allow policy. - Every use investigated: including tests, recording the reason and the person.
Route these alerts into your identity detection rules. See the ITDR Guide.
Testing
Untested emergency access is an assumption. Microsoft asks for validation drills at least every 90 days and after key changes such as staff terminations or changes to subscriptions.
| Check | How | When |
|---|---|---|
| Sign-in works | Authenticate with each stored key or certificate from the designated workstation | At least every 90 days, and after identity platform or policy changes |
| Roles still assigned | Perform an administrative task and confirm standing assignment | Each drill |
| Alerts fire | Confirm the SOC received the alert through the independent channel; tell monitoring staff a check is under way | Each drill |
| Custodians are current | Review the authorised-user list and safe access | Each drill and after leavers or role changes |
| Procedure is current and people are trained | Walk through the documented break-glass process | Each drill, plus tabletop exercises |
| No personal methods registered | Check that nobody has added MFA or self-service reset tied to a personal device | Each drill |
Rotate secrets after each use or test where the method allows it.
After use
- Preserve the sign-in and audit logs from the directory and other affected workloads.
- Record who used the account, when, why and what was done, and decide whether the use was a planned drill, a genuine emergency, or misuse.
- Review every action taken during the session against the authorised purpose.
- Rotate credentials, re-register or replace physical tokens if they left custody, and re-seal storage.
- Remove any temporary emergency accounts or access created during the incident. NIST SP 800-53 AC-2(2) calls for automatically removing or disabling temporary and emergency accounts after a defined period.
- Fix the root cause that required emergency access, and update the procedure.
Fold these steps into your incident process. See the Identity Incident Response Playbook.
Break-glass beyond the directory
The directory is only one layer. Each platform that can lock you out needs its own route, and the guidance differs by provider.
| Platform | Emergency identity | Provider guidance |
|---|---|---|
| Microsoft Entra ID | Two or more cloud-only Global Administrator accounts | Passkey (FIDO2) or certificate-based authentication; excluded from blocking policies; validated at least every 90 days |
| AWS | Account root user | MFA on root (up to eight devices can be registered); no root access keys; alert on root use; in AWS Organizations, centralise root access and remove member account root credentials |
| Google Cloud and Workspace | Super administrator accounts | More than one super admin, each managed by a separate individual; security keys for 2-Step Verification; not used for daily work or the Organization Administrator group |
| PAM platform | Emergency procedure for vaulted credentials | Sealed offline copy of the few credentials needed to restore the vault itself |
| Critical applications and OT | Local emergency administrator | Same principles: independent authentication, custody, alerting and testing |
- PAM platforms: define how to retrieve the minimum set of credentials if the vault is unavailable. See the Privileged Access Management Guide and the PAM Buyer's Guide.
- Cloud root and organisation accounts: AWS also asks you to plan root credential recovery, with no single person holding both the root email inbox and the registered phone number. See the AWS Security Guide and the Google Cloud Security Guide.
- Directory recovery: plan forest and tenant recovery separately from account lockout. See the Active Directory and Entra ID Recovery Guide.
- Automation and AI agents: never give scripts, service accounts or AI agents access to break-glass credentials. Microsoft notes that workload identities are not affected by its mandatory MFA enforcement, but user identities used as service accounts are; a break-glass account wired into automation loses both its independence and its alerting value.
Common failure patterns
- Dependent on what it should bypass: break-glass accounts that rely on the same federation, MFA service or on-premises sync they are meant to bypass. In the Storm-0501 Hybrid Cloud Attacks 2024, one route into the cloud was a compromised Domain Admin whose matching Entra ID account held Global Administrator with MFA disabled.
- Excluded from MFA "for safety": an excluded account protected by a password alone is a backdoor. The Colonial Pipeline Ransomware Attack 2021 began with a legacy VPN account without MFA that was no longer used but still active.
- Privileged credentials stored for convenience: Verkada reported that a misconfigured support server exposed to the internet held admin-level credentials that attackers used to reach customer cameras. See the Verkada Camera Breach 2021. Break-glass secrets in scripts or shared drives fail the same way.
- Routine use: emergency accounts used for daily work because they are convenient, which destroys the signal value of every alert.
- No alerting, or alerting through the failed platform: misuse goes unnoticed, or the alert goes to a mailbox in the tenant that is locked.
- Never tested: accounts discovered not to work during an outage because a policy, licence or role changed.
- Single custodian: credentials held by one person who has left, or a safe combination nobody changed after they did.
- Swept up by clean-up: accounts or keys removed by dormant-account automation because they are, by design, rarely used. Exempt them explicitly and review the exemption.
Framework mapping
Control IDs were checked against NIST CSF 2.0, the NIST SP 800-53 Rev. 5 catalogue and the CIS Controls safeguard text. ISO/IEC 27001:2022 Annex A control names come from a published Annex A index. This is an indicative NHI Mgmt Group alignment, not an official crosswalk.
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 |
|---|---|---|---|---|
| Defined, minimal emergency accounts | PR.AA-01, PR.AA-05 | AC-2, AC-2(2) | 8.2 Privileged access rights | 5.4 |
| Phishing-resistant authentication for emergency accounts | PR.AA-03 | IA-2(1), IA-5 | 5.17 Authentication information, 8.5 Secure authentication | 6.5 |
| Resilience of administrative access during outages | PR.IR-03 | CP-2 | 5.29 Information security during disruption, 5.30 ICT readiness for business continuity | n/a |
| Monitoring and alerting on use | DE.CM-03 | AC-2(12), AC-6(9), AU-6 | 8.15 Logging, 8.16 Monitoring activities | 8.5, 8.11 |
| Post-use review and recovery | RC.RP-02 | IR-4 | 5.26 Response to information security incidents | 17.4 |
| Cloud root and default administrator accounts | PR.AA-05 | AC-6(5) | 8.2 Privileged access rights | 4.7 |
Metrics that show progress
| Metric | What it shows | Target direction |
|---|---|---|
| Critical platforms with documented, tested break-glass access | Coverage | Up, towards 100% |
| Days since last successful drill per account | Whether testing happens | Under 90 for every account |
| Emergency accounts using phishing-resistant methods only | Strength of the bypass route | 100% |
| Uses of break-glass accounts without a recorded reason | Misuse or routine use | Zero |
| Time from break-glass sign-in to acknowledgement by the SOC | Alerting works | Down |
| Break-glass accounts with a dependency on federation, sync or personal devices | Independence | Zero |
| Custodian list reviewed after each leaver with access | Custody hygiene | 100% |
| Temporary emergency access removed within the defined period | Clean-up after incidents | 100% |
Implementation roadmap
| Phase | Focus | Actions |
|---|---|---|
| First 30 days | Find and fix the obvious | Inventory existing emergency, root and super admin accounts; remove personal MFA and recovery details; confirm at least two independent accounts per critical platform; set alerts on every sign-in |
| Days 31 to 90 | Strengthen and document | Move to FIDO2 keys or certificate-based authentication; set up split, multi-site custody; document exclusions and the break-glass procedure; run the first drill |
| Days 91 to 180 | Extend beyond the directory | Cover cloud root accounts, PAM vault recovery, critical applications and OT; route alerts through independent channels; exempt accounts from dormant-account automation |
| Ongoing | Sustain | Drill at least every 90 days and after major changes; review custodians after leavers; post-incident reviews feed procedure updates |
To place emergency access in a wider privileged access programme, see the PAM Maturity Model and the JIT Access Guide: break-glass accounts are the documented exception to zero standing privilege.
Practitioner checklist
- Define break-glass accounts for each critical platform, independent of the systems they recover.
- Keep at least two per platform, cloud-only where the platform is a cloud directory.
- Protect them with phishing-resistant authentication that differs from normal admin methods.
- Hold credentials in split, multi-site physical custody and record who has access.
- Exclude them deliberately from policies that could block sign-in, and document why.
- Make privileged roles on emergency accounts standing, not eligible.
- Alert on every use and change through channels independent of the identity platform.
- Drill at least every 90 days and after significant changes; rotate after use.
- Review every use, remove temporary emergency access and fix root causes.
- Keep break-glass credentials away from scripts, service accounts and AI agents.
Standards and references
- Microsoft Learn: Manage emergency access accounts in Microsoft Entra ID
- Microsoft Learn: Create a resilient access control management strategy
- Microsoft Learn: Plan for mandatory Microsoft Entra multifactor authentication
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
- NIST: The NIST Cybersecurity Framework (CSF) 2.0
- CISA: Implementing Phishing-Resistant MFA
- AWS: Root user best practices for your AWS account
- Google Cloud: Super administrator account best practices
- Google Workspace Admin Help: Security best practices for administrator accounts
- CIS: CIS Critical Security Controls Version 8.1
- ISMS.online: ISO 27001:2022 Annex A Explained
- Verkada: Security Update, Incident Report
Related NHI Mgmt Group resources: Privileged Access Management Guide · Active Directory and Entra ID Hardening Guide · Identity Provider and SSO Security Guide · JIT Access Guide · Privileged Identity Management (PIM) Guide