In Microsoft Entra ID, formerly Azure AD, emergency-access accounts (also called break-glass accounts) reduce administrator lockout risk. Their authentication and recovery arrangements must remain independent of normal administrator access. Create at least 2 cloud-only accounts with permanent Global Administrator permissions and phishing-resistant MFA. Conditional Access exclusions do not remove Microsoft’s mandatory MFA requirement.
A password stored in a safe is no longer a complete recovery plan. The account must also have a working authentication method, accessible credentials and tested monitoring. Start by separating those requirements.
Key takeaways for emergency access
Use these controls as the configuration baseline.
| Control | Required configuration |
|---|---|
| Identity | At least 2 cloud-only accounts using the tenant’s .onmicrosoft.com domain |
| Permissions | Permanent active Global Administrator, not PIM-eligible |
| Authentication | FIDO2 passkeys or certificate-based authentication configured for MFA |
| Credential custody | Separate secure storage, documented custodians and accessible recovery instructions |
| Monitoring | Alerts for successful sign-ins, failed attempts and associated audit events |
| Testing | Each account at least every 90 days |
These accounts provide a controlled Break-Glass capability and should remain unused outside authorised testing and genuine recovery.
Understand mandatory MFA and Conditional Access exclusions
Why excluded accounts still receive MFA prompts
Microsoft’s mandatory MFA enforcement explicitly includes emergency-access accounts. Excluding an account from every tenant Conditional Access policy does not exempt it from this separate enforcement.
Microsoft’s mandatory MFA documentation describes the gradual rollout: Phase 1 began in October 2024 for the Azure, Entra and Intune administration portals. Microsoft 365 admin centre enforcement began gradually in February 2025.
Phase 2 began on 1 October 2025 for management clients and API operations that create, update or delete resources. Read operations are outside that phase. These dates mark rollout starts, not simultaneous enforcement across every tenant.
What sign-in logs can establish
Open the sign-in event and review the application, authentication details and Conditional Access results together. Policies marked “Not Applied” establish that those policies did not apply; they do not prove that MFA was unnecessary.
Mandatory MFA can explain a prompt despite those exclusions. Other authentication and registration mechanisms can also interrupt access.
Device-compliance requirements used for Microsoft 365 access on personal devices can obstruct recovery if emergency accounts depend on the same managed-device infrastructure. Design exclusions around identified lockout risks rather than assuming an MFA exclusion is sufficient.
Create 2 cloud-only emergency accounts
Microsoft’s emergency-access account guidance recommends cloud-only identities and permanent active Global Administrator assignments. This keeps recovery independent of on-premises synchronisation, federation and privileged-role activation.
- Create 2 separate users directly in Microsoft Entra ID using the tenant’s
.onmicrosoft.comdomain. Keep each identity individually controlled, and don’t synchronise accounts from Active Directory or associate them with individual employees. - Record each account’s user principal name and immutable object ID. Use the object IDs in monitoring rules so display-name changes don’t break detection.
- Assign Global Administrator as permanent active. Don’t make the assignment eligible through Privileged Identity Management (PIM), because activation adds another dependency during recovery.
- Review Conditional Access coverage and document the exclusions needed to prevent lockout. Keep both accounts enabled and available for their intended purpose.
Update legacy Azure AD recovery runbooks to use the current Microsoft Entra ID terminology and process.
Don’t use these identities for email, browsing, automation or routine administration, or as shared accounts for everyday administration. Normal administrators should retain separate, appropriately restricted administrative accounts.
A Microsoft 365 security assessment should distinguish these documented emergency privileges from unnecessary standing permissions elsewhere.
Register authentication and protect credential custody
Prefer device-bound hardware credentials
Use a FIDO2 hardware security key where practical, or certificate-based authentication configured to satisfy MFA. A certificate doesn’t automatically provide multifactor authentication merely because it’s installed.
For hardware keys, enable the relevant passkey authentication method for the emergency accounts in Entra authentication-method policies. Complete registration through the account’s security information page using an approved bootstrap method, then test a fresh administrative authentication.
Microsoft’s Entra passkey documentation explains the supported authentication model. A hardware key keeps its credential device-bound; a synced passkey introduces dependencies on its syncing provider and recovery process.
Register and securely store spare keys. If using certificates, document certificate expiry, trust configuration and revocation dependencies. A recovery credential that expires unnoticed can leave an apparently prepared account unusable.
Separate storage without making recovery impractical
Generate a long, random, complex password for each account. Password material can be split between sealed envelopes, separate safes or disaster-recovery kits. This protects custody; it doesn’t replace MFA.
Keep duplicate recovery material in separate sealed envelopes with authorised custodians. Record who can retrieve each password component, key and PIN. Don’t store every recovery item in a password vault accessible only through the tenant being recovered.
Maintain a custody register covering storage location, authorised holders and access history. When a custodian leaves, review these arrangements alongside the Microsoft 365 leaver access checklist, without deleting the organisation-owned emergency identity.
Remove unexpected registration dependencies
A successful passkey authentication doesn’t establish that every security-information registration requirement has been satisfied. Combined registration can interrupt access because of Conditional Access, per-user MFA, Identity Protection, self-service password reset (SSPR) or other MFA policies.
Administrator SSPR uses a predefined 2-gate policy. It can request Microsoft Authenticator plus another method, even where a FIDO2 credential already satisfies the account’s authentication requirements.
Microsoft’s emergency-account registration discussion addresses this distinction. Administrators can disable administrator SSPR tenant-wide using Microsoft Graph PowerShell:
Update-MgPolicyAuthorizationPolicy -AllowedToUseSspr:$false
This affects administrator SSPR across the tenant, not just the emergency accounts, and can take up to 60 minutes. It doesn’t disable mandatory MFA or remove unrelated registration requirements.
Treat that command as a policy decision, not a standard preparation step. First identify which policy or process is triggering combined registration. Test that registration path in a fresh browser session before changing tenant-wide recovery settings, rather than relying on an existing authenticated session.
Monitor every sign-in and audit event
Monitoring must cover sign-in attempts, including successful and failed access, not merely successful recovery. A failed attempt can indicate a guessed username, exposed password or deliberate targeting of a highly privileged account.
Send identity logs to Log Analytics
Configure Entra diagnostic settings to stream identity and audit logs into a Log Analytics workspace. In Azure Monitor, create a scheduled-query Alert Rule against SigninLogs, filtering UserId for each emergency-account object ID. Review the sign-in logs for successful and failed activity.
Set the condition to trigger when returned records exceed 0. Don’t add a success-only filter: failed activity must remain eligible to trigger the alert.
Run the rule every 5 minutes with a suitable lookback window. Allow for ingestion delay; a 5-minute evaluation schedule doesn’t guarantee notification within 5 minutes of an attempt.
Create corresponding audit monitoring for events where either emergency account is the initiating identity or an affected target. Microsoft’s privileged-access security benchmark supports monitoring both identity sign-ins and audit activity.
Route notifications to people who can respond
Use a shared Azure Monitor Action Group across the account-specific rules. Responders should verify the shared Action Group’s email and SMS routes. Set emergency-account alerts to Critical, and document the investigation owner.
Test the Action Group’s delivery outside the normal Microsoft 365 administration workflow. An alert sent only to an inaccessible tenant mailbox provides limited help during lockout.
Log ingestion, retention and alert evaluation can incur Azure charges. Existing Sentinel or security-monitoring services may already provide the required coverage, but only when these identities and events are explicitly included.
Test recovery and restore control after use
Exercise each account at least every 90 days
Test every emergency account at least every 90 days, and after relevant authentication, policy, role or custody changes. Use a fresh session so cached tokens do not conceal a broken recovery route.
Confirm that authorised staff can retrieve credentials, complete MFA, reach the required administration portal and perform an appropriate administrative action. Confirm that authentication and audit alerts reach the designated responders.
Record the tester, date, outcome, notifications received and corrective actions. Testing should also expose practical failures: an unavailable custodian, incompatible workstation, missing key PIN or instructions stored behind the affected tenant.
Close the recovery activity without removing the fallback
After genuine use, document the incident, administrative changes and reason emergency access was required. Review sign-in and audit activity for actions outside the authorised recovery work.
Revoke sessions and rotate any exposed password or compromised authentication credential. Password resets do not remove registered passkeys or other authentication methods automatically.
If compromise is suspected, use a structured credential exposure response that also examines persistence and unauthorised permissions. Keep another tested emergency route available whilst repairing the affected account.
Return credentials to controlled storage and retest the restored configuration. Do not disable every emergency account once normal access returns.
Frequently asked questions
Can emergency accounts recover access during a Microsoft outage?
They can bypass some local dependencies, including broken federation, synchronisation or tenant Conditional Access configuration. They cannot guarantee access when Microsoft’s underlying authentication or administration services are unavailable. Maintain a separate outage communications process and offline recovery instructions.
Does an existing SOC alert prove these accounts are covered?
No. Coverage depends on the data sources, account filters, detection logic and notification route. Require evidence that successful attempts, failed attempts and relevant audit events are captured. A controlled test should establish delivery and response ownership, rather than merely showing that a rule exists.
Make emergency access an operational control
Emergency-access accounts depend on more than privileged access. Authentication, credential custody, monitoring and testing must remain usable when normal administration fails.
Keep the recovery route independent without leaving an unmonitored administrative shortcut. Record exceptions, ownership, credential custody and recovery procedures in your business continuity and disaster recovery (BCDR) documentation. Assign responsibility for maintaining them.
Speak to our team about reviewing your Microsoft 365 administrator access, Azure identity controls and security monitoring.
