Break-glass accounts in Entra ID: a lockout-proof Conditional Access setup

To avoid locking yourself out of a Microsoft Entra tenant, create at least two cloud-only emergency access (break-glass) accounts on the .onmicrosoft.com domain, assign them Global Administrator as a permanently active role, protect them with FIDO2 passkeys that differ from your normal admin methods, and exclude them, through one dedicated group, from every Conditional Access policy that blocks or restricts sign-in. Then stream sign-in logs to Log Analytics and fire a critical alert whenever either account signs in, and test both accounts at least every 90 days.

Who this is for and what you will have at the end

This guide is for identity and security administrators who manage Conditional Access in Microsoft Entra ID, and for anyone about to deploy a block policy, a location restriction or a phishing-resistant MFA requirement for admins. Those are exactly the changes that lock tenants out.

At the end you will have:

• Two emergency access accounts that don't depend on federation, on-premises Active Directory, or any one person's phone.
• Phishing-resistant credentials on those accounts that satisfy mandatory MFA.
• A single exclusion group applied consistently to Conditional Access, and a script to find policies that miss it.
• An Azure Monitor alert that notifies administrators on every use.
• A documented 90-day validation drill.

Break-glass accounts are one part of a resilient identity design. The broader access model, with device trust and policy enforcement points, is covered in the Zero Trust remote access architecture.

Why tenants get locked out

Microsoft lists the situations emergency access accounts exist for:

• Federation is down, for example because the on-premises identity provider host is unavailable, so users redirected to it can't sign in.
• Administrators' MFA devices or the MFA service are unavailable, such as a cell network outage that stops phone calls and text messages.
• The last person with Global Administrator access leaves. Microsoft Entra ID won't let you delete the last Global Administrator, but the account can still be deleted or disabled on-premises.
• All Global Administrator and Privileged Role Administrator assignments are eligible, activation needs approval, and no approver is available.
• A natural disaster or other emergency takes networks out.

Add the most common self-inflicted case: a new Conditional Access policy targeting all users and all resources with a grant control nobody can satisfy.

Design requirements

Prerequisites

• Licensing: Conditional Access needs Microsoft Entra ID P1 or P2. Passkeys (FIDO2) are available in every edition, including Microsoft Entra ID Free.
• Roles: Privileged Role Administrator or Global Administrator to assign Global Administrator; Authentication Policy Administrator for authentication method policies; Privileged Authentication Administrator to create a Temporary Access Pass for an admin account; Conditional Access Administrator for policies; Security Administrator for diagnostic settings; Monitoring Contributor for the Azure Monitor alert.
• Hardware: FIDO2 security keys for each account, from a model that meets Microsoft Entra attestation requirements, plus safe storage in separate locations.
• Monitoring: an Azure subscription and a Log Analytics workspace. Sending logs to Log Analytics costs money; Microsoft estimates sign-in events at around 11.5 KB each and audit events at about 2 KB.

Step 1: Create the accounts

1. In the Microsoft Entra admin center, browse to Entra ID > Users and create two new cloud-only users on your contoso.onmicrosoft.com domain, for example bg-admin-01@contoso.onmicrosoft.com and bg-admin-02@contoso.onmicrosoft.com.
2. Don't add a phone number, personal email or any MFA method tied to an employee's device. Microsoft's validation checklist explicitly checks that emergency accounts haven't registered MFA or self-service password reset to anyone's personal device or details.
3. Open each account and copy its Object ID. You need them for monitoring in Step 7.

Hold off on assigning Global Administrator until the passkeys are registered in Step 4. That way an Authentication Administrator, rather than a Privileged Authentication Administrator, can issue the bootstrap pass, and the accounts are never privileged without a strong credential.

Step 2: Create the exclusion group

Create a security group named, for example, EmergencyAccess, and add both accounts. Microsoft recommends a dedicated group so you exclude one object from each policy instead of individual users.

Treat membership of this group as privileged: anyone added to it is outside your Conditional Access controls. Keep the membership to the two emergency accounts, restrict who can manage the group, and review its membership in every validation drill.

Step 3: Enable passkeys and a bootstrap Temporary Access Pass

A new account has no MFA method, and users must complete MFA within the past five minutes before they can register a passkey. A Temporary Access Pass (TAP) solves this: it's a time-limited passcode that lets a user sign in and register passwordless methods.

Passkey (FIDO2) policy

1. Sign in as at least an Authentication Policy Administrator and open Authentication methods > Policies under Entra ID.
2. Select Passkey (FIDO2). On Configure, make sure Allow self-service set up is Yes; if it's No, users can't register a passkey in Security info even when the method is enabled.
3. If you use passkey profiles, create one for the EmergencyAccess group with Passkey types set to device-bound and Enforce attestation set to Yes, which matches Microsoft's example profile for IT admins and other high-privileged users. Optionally use Enforce key restrictions with the AAGUID of your security key model. Opting in to passkey profiles can't be undone, existing settings move into a Default passkey profile, and up to three profiles are currently supported, so plan this as a tenant-wide change.
4. On Enable and Target, include the EmergencyAccess group and assign the profile. Make sure the group isn't in an excluded group for this method: exclusion blocks passkey registration and sign-in entirely and overrides any inclusion.

Temporary Access Pass policy

1. In Authentication methods > Policies, select Temporary Access Pass, select Enable, and include the EmergencyAccess group.
2. Under Configure, consider One-time use. Defaults are a one-hour lifetime and an eight-character passcode.

Step 4: Register the security keys

For each account:

1. In Entra ID > Users, open the account, select Authentication methods > Add authentication method > Temporary Access Pass, and select Add. Note the passcode; you can't view it again after you select OK.
2. On the secure workstation, go to https://mysignins.microsoft.com/security-info, enter the account's UPN and the TAP.
3. Register the first security key. With a one-time TAP, finish within 10 minutes of signing in.
4. If you want a spare key for the same account, register it in the same session, or sign in later with the first key and add the second one from Security info. Label every key with the account it belongs to.
5. Delete the TAP from the account's Authentication methods once registration is done.

Then assign the Global Administrator role to both accounts. If you use Privileged Identity Management, make the assignment active and permanent, not eligible; PIM has its own licensing requirements, so check them before relying on it.

If the account was in scope for the self-service password reset registration policy or the Microsoft Entra ID Protection MFA registration policy, the TAP sign-in is redirected to the interrupt mode of combined registration, which doesn't support FIDO2 registration. Exclude the emergency accounts from those registration policies.

Certificate-based authentication is the alternative when you already run a PKI. Either method satisfies mandatory MFA.

Step 5: Exclude the group from Conditional Access

Exclude EmergencyAccess under Users > Exclude in every Conditional Access policy that blocks or restricts sign-in: MFA requirements, authentication strength requirements, compliant or hybrid-joined device requirements, location-based blocks, legacy authentication blocks and sign-in risk policies. Microsoft calls out country and region block policies specifically. Report-only policies don't block access, so they don't need the exclusion.

Two things the exclusion doesn't change:

• Mandatory MFA. Sign-in to the Azure portal, Microsoft Entra admin center and Intune admin center requires MFA, and so does the Microsoft 365 admin center. This applies to break-glass accounts and to any user exclusions. Azure CLI, Azure PowerShell and other Azure Resource Manager clients require MFA for create, update and delete operations. The passkey covers all of this.
• Combined policies. Microsoft advises testing exclusions, because another policy can still require MFA for an excluded user. Use the What If tool to check which policies apply to each emergency account.

Find policies that miss the exclusion

Run this regularly, and in any change process for Conditional Access:

Connect-MgGraph -Scopes 'Policy.Read.All'
 
$emergencyGroupId = '00aa00aa-bb11-cc22-dd33-44ee44ee44ee'   # Object ID of EmergencyAccess
 
Get-MgIdentityConditionalAccessPolicy -All |
    Where-Object {
        $_.State -eq 'enabled' -and
        $_.Conditions.Users.ExcludeGroups -notcontains $emergencyGroupId
    } |
    Select-Object DisplayName, State

Every enabled policy in the output needs a decision: add the exclusion, or record why that policy can't block or restrict the emergency accounts.

Prepare contingency policies

Microsoft also recommends disabled contingency policies you can turn on during an outage, named so they stand out, for example EM01 - ENABLE IN EMERGENCY: MFA Disruption [1/4]. Break-glass accounts give you a way in; contingency policies restore access for everyone else.

Step 6: Store the credentials

Keep each account's security keys in secure, fireproof safes in separate locations, accessible to the small group of authorized administrators. Microsoft also recommends that the credentials not be connected to any employee-supplied device, and that whoever uses them does so from a designated secure workstation such as a Privileged Access Workstation. Change safe combinations regularly and whenever someone with access leaves.

Step 7: Alert on every sign-in

Send sign-in logs to Log Analytics

1. In the Microsoft Entra admin center, as at least a Security Administrator, browse to Entra ID > Monitoring & health > Diagnostic settings.
2. Select + Add diagnostic setting, name it, and select the sign-in and audit log categories.
3. Under Destination Details, select Send to Log Analytics workspace, choose the subscription and workspace, and select Save.

Create the alert rule

1. In the Azure portal, as at least Monitoring Contributor, open Monitor > Alerts > + Create > Alert rule.
2. On Scope, select the Log Analytics workspace.
3. On Condition, choose Custom log search, set Query type to Aggregated logs, and use Microsoft's query with both Object IDs:

SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

4. Under Alert logic, set Threshold type to Static, Operator to Greater than, Threshold value to 0, and choose the evaluation frequency.
5. On Actions, select or create an action group with email, SMS, push or voice notifications to the security team.
6. On Details, set Severity to 0 - Critical, name the rule, and select Enable upon creation. Then Review + create.

The query doesn't filter on the result, so failed attempts raise the alert as well as successful sign-ins, and ResultType and ResultDescription tell you which it was. A failed attempt against a break-glass account deserves attention too.

Review every alert

When the alert fires, preserve the Microsoft Entra logs and decide whether the use was a planned drill, a real emergency, or misuse, then check what the account actually did against what was authorized.

Step 8: Validate every 90 days

Microsoft's minimum validation routine, performed at least every 90 days, after IT staff changes and when Microsoft Entra subscriptions change:

1. Tell the security monitoring team that a check is in progress.
2. Review the list of people authorized to use the credentials.
3. Confirm the break-glass procedure is documented and current, and that the people who would use it are trained.
4. Sign in with each account from the secure workstation and perform an administrative task.
5. Confirm the alert fired and reached the right people.
6. Confirm no MFA or self-service password reset method is registered to anyone's personal device or details.
7. Run the Conditional Access exclusion script and review the EmergencyAccess group membership.

Troubleshooting

Checklist

• Two cloud-only .onmicrosoft.com accounts, not tied to any person.
• Passkey (FIDO2) device-bound credentials registered with a TAP, TAP deleted afterwards.
• Global Administrator assigned as active and permanent in PIM.
• EmergencyAccess group excluded from every blocking or restricting Conditional Access policy, verified by script.
• Accounts excluded from SSPR and ID Protection MFA registration policies.
• Contingency Conditional Access policies created, disabled and clearly named.
• Keys stored in separate secure safes; use limited to a designated secure workstation.
• Sign-in logs in Log Analytics with a severity 0 alert and action group.
• Validation drill documented and run at least every 90 days.

References

• Manage emergency access admin accounts in Microsoft Entra ID
• Plan a Conditional Access deployment
• Plan for mandatory Microsoft Entra multifactor authentication
• How to enable passkeys (FIDO2) in Microsoft Entra ID
• Configure a Temporary Access Pass
• Integrate Microsoft Entra logs with Azure Monitor logs
• Microsoft Entra activity log integration options
• Get-MgIdentityConditionalAccessPolicy
• conditionalAccessUsers resource type