Microsoft SC-500: Securing Break-Glass Accounts

Emergency access accounts—often called break-glass accounts—exist for the rare situation where normal Microsoft Entra administration is unavailable. Microsoft currently recommends maintaining at least two cloud-only emergency access accounts with permanently active Global Administrator role assignments so the organization can recover from federation outage, Conditional Access lockout, MFA failure, administrator turnover, or another identity-control failure.

The security challenge is obvious: the accounts must be usable when normal controls fail, but they also carry some of the highest privilege in the tenant. They need a different security model from ordinary administrators, with separate authentication methods, physical or procedural protection, monitoring, and regular validation.

Break-glass security is therefore a resilience control inside Microsoft Identity & Security.

Maintain at least two accounts

Microsoft recommends two or more emergency access accounts for redundancy.

The accounts should be cloud-only and use the tenant’s .onmicrosoft.com domain so they do not depend on a federated identity provider that might be unavailable during the emergency.

Do not use one executive’s normal account as the only recovery path.

Keep Global Administrator permanently active

Emergency access accounts are one of the few scenarios where Microsoft recommends a permanently active Global Administrator assignment rather than eligible PIM activation.

Privileged access normally reduces standing privilege, but an emergency account must remain usable when PIM approvers or activation flows are unavailable.

The exception should remain limited to the dedicated emergency identities.

Use phishing-resistant authentication

Microsoft recommends phishing-resistant methods such as FIDO2 security keys or certificate-based authentication, using methods distinct from the normal administrator path.

Passkeys can provide phishing-resistant authentication, but the recovery design should avoid depending on the same devices and services used by everyday admins.

Store backup authenticators in separate secure locations.

Exclude emergency accounts from blocking Conditional Access

Microsoft recommends excluding emergency access accounts from Conditional Access policies that could block or restrict sign-in.

Conditional Access is powerful enough to lock out every administrator if a policy is misconfigured.

Report-only policies do not block access and generally do not require the same exclusion.

Use dedicated secure workstations

Emergency credentials should not be typed into arbitrary user devices.

Microsoft recommends a designated secure or privileged-access workstation for emergency account use.

Keep that device available, patched, and independent enough that the same incident affecting normal administrator endpoints does not make recovery impossible.

Store credentials securely and separately

Credential material and backup authenticators should be accessible only to authorized people and stored in separate secure locations.

A fireproof safe, documented custody process, and dual-control procedure can reduce both theft risk and single-person dependency.

Do not keep the only key inside the same office or password manager whose failure would trigger the emergency.

Alert on every use

Emergency accounts should have essentially no normal activity.

Microsoft recommends high-priority monitoring for sign-ins and audit changes involving the accounts.

Identity risk and Microsoft security incident response should treat unexpected emergency-account use as a serious investigation trigger.

Validate at least every 90 days

Microsoft’s current guidance recommends validating emergency access account functionality at least every 90 days.

The test should confirm the account can sign in, the authentication method works, the Global Administrator assignment remains active, and current Conditional Access does not block recovery.

Document the test and repair problems immediately instead of discovering them during a tenant outage.

Keep emergency access rare

The existence of break-glass accounts should not become an excuse to bypass normal privileged-access design.

For Microsoft Entra resilience, the durable pattern is two cloud-only emergency identities, permanent Global Administrator role, independent phishing-resistant authentication, Conditional Access exclusion from blocking policies, secure storage, alerting on every use, and recurring validation. The accounts are most secure when everyone knows they exist but almost nobody ever needs them.

Emergency accounts should be excluded only from policies that could prevent recovery, not from every security control in the tenant. Monitoring, sign-in logging, admin-role auditing, and incident alerting should remain as strong as possible because any unexpected use of the account is inherently high risk.

The authentication method should avoid shared dependencies with normal administration. If every regular admin uses Microsoft Authenticator on corporate phones, the break-glass path might use separately stored FIDO2 security keys or certificates so one device-management or mobile-network failure does not disable both normal and emergency access.

Physical custody should be documented. Know who can retrieve each emergency authenticator, whether dual authorization is required, how custody changes are logged, and what happens if one location becomes inaccessible. Security and availability are both part of the account design.

Emergency accounts should not be used for routine maintenance, testing permissions, or bypassing PIM approval because doing so normalizes their use and makes alerts less meaningful. If administrators repeatedly need the break-glass account, the normal privileged-access design is broken and should be repaired.

Quarterly validation should be a real sign-in test, not a spreadsheet checkbox. Confirm cloud-only authentication, phishing-resistant method, Global Administrator rights, Conditional Access exclusions, workstation readiness, and alert generation. Capture the evidence and remediate any failure immediately.

Break-glass testing should also include an outage scenario. Ask whether the account still works if federation, PIM approvers, mobile networks, device compliance, or the normal admin laptop are unavailable. The recovery path is valuable only if it survives the dependencies it was created to bypass.

After every emergency use, rotate or replace credentials where appropriate, review the audit log, document why the account was needed, and close the architectural gap that caused normal administration to fail. Emergency access should produce a post-incident improvement, not become a recurring operational shortcut.

The account names and storage locations should be known to the limited authorized team but not broadly advertised. Security through obscurity is not the control, yet unnecessary visibility can increase targeting. Pair limited knowledge with strong monitoring and documented governance.

The mature design treats emergency access as a resilience capability with its own lifecycle: creation, secure custody, monitoring, quarterly validation, controlled use, post-use review, and periodic reassessment. That discipline is what keeps the highest-privilege accounts usable without making them the weakest accounts in the tenant.

Account creation should avoid dependencies on normal employee lifecycle where possible. An emergency account should not be disabled automatically because an individual employee changed department or left the organization.

Use a dedicated security group for emergency accounts so Conditional Access exclusions and monitoring can be managed consistently. Keep membership extremely small and alert on group changes as well as account sign-ins.

Credentials and hardware should have documented replacement procedures. FIDO2 keys can fail, certificates can expire, and secure storage can be relocated. Test that replacement does not accidentally remove the last functioning recovery path.

Emergency access should be included in identity disaster-recovery exercises. Simulate a tenant lockout and require the response team to retrieve, authenticate, verify alerts, and restore normal admin access using the documented process.

Review every policy change that targets all users or all administrators against the emergency group. Automation should prevent new Conditional Access policies from accidentally omitting the required exclusion.

Emergency-account passwords, if retained as part of the design, should be long, unique, and not shared with any other tenant or environment. If phishing-resistant authenticators are the primary path, password knowledge should still follow the secure custody process.

Monitoring should alert not only on successful sign-in but also on failed attempts, credential changes, role changes, authentication-method registration, and group membership changes involving the emergency accounts.

Break-glass accounts should be excluded from automation that disables stale users, expires credentials, removes inactive administrators, or enforces ordinary lifecycle cleanup. Their unusual inactivity is intentional.

Document which senior responders are authorized to approve use and which operational team executes the recovery. During a real outage, that separation prevents confusion about whether someone is allowed to retrieve and use the emergency credential.

After a test or real emergency, confirm the account returned to its protected dormant state: no active browser sessions, no unexpected role changes, no new authentication methods, and monitoring still enabled.

The objective is resilience without normalization. Emergency access should remain available, monitored, independently authenticated, and almost never used.

Emergency-account design should also survive staff turnover. Update authorized custodians, secure-storage records, and escalation contacts whenever responsibility changes so the recovery process does not depend on departed employees.

Keep the quarterly validation calendar owned by a named team and include failed tests in security-operations follow-up until the recovery path works again.

Alert ownership should remain explicit so every emergency-account event reaches a responder who can investigate immediately.

Keep emergency access dormant, monitored, and independently recoverable.

Test quarterly.