Break-glass accounts in Entra: passkeys, exclusions, alerts

What it is

An emergency access (break-glass) account is the way back in when normal admin access fails. Learn lists scenarios such as:

• a federation outage
• MFA devices or the MFA service being unavailable
• the last Global Administrator leaving
• all Global Administrator and Privileged Role Administrator assignments being eligible, with activation needing approval and no approvers selected

Learn’s resilience guidance recommends two cloud-only emergency access accounts, permanently assigned Global Administrator and not tied to individuals.

What good looks like

From the Learn emergency access page:

• Two or more accounts.
• Cloud-only, on the *.onmicrosoft.com domain, neither federated nor synchronised from on-premises.
• Assigned Global Administrator. In Privileged Identity Management, the assignment is active permanent rather than eligible.
• Not tied to an individual or to employee-supplied devices.
• Credentials and devices must not expire, or fall into scope of automated clean-up for lack of use.
• Credentials stored in secure, fireproof safes in separate locations.
• Used only from a designated secure workstation, such as a Privileged Access Workstation.
• A sign-in alert for every use, plus sign-in and audit logs captured for review, and a post-mortem after any use.

Who is affected

• Anyone who runs an Entra tenant. If you have one break-glass account, or one that is really a named admin’s spare, this is for you.
• Tenants with Conditional Access policies that block or restrict sign-in. Every one of those is a potential lockout for the emergency accounts.
• Tenants where break-glass accounts rely on a password with MFA excluded. Learn’s mandatory MFA page says break-glass accounts are required to sign in with MFA once enforcement begins, and that Conditional Access exclusions do not exempt them. Check where enforcement stands for your tenant in its Message Center and sign-in logs.

Why it matters

Mandatory MFA covers break-glass accounts. Learn’s mandatory MFA page says break-glass and emergency access accounts are also required to sign in with MFA once enforcement begins. It recommends passkey (FIDO2) or certificate-based authentication. The FAQ says system enforcement applies to all user accounts regardless of break-glass status, eligible or activated roles, or any user exclusions enabled for them.

So a Conditional Access exclusion protects you from your own policies. It does not protect you from Microsoft’s enforcement.

Learn gives these schedule details for mandatory MFA:

• Phase 1, from October 2024: the Azure portal, Entra admin center and Intune admin center.
• Phase 2, from 1 October 2025: Azure CLI, Azure PowerShell, the Azure mobile app, IaC tools and REST API endpoints, for create, update and delete operations.
• A postponement option for Phase 2 ran only to 1 July 2026, per Learn.

Learn points to aka.ms/postponePhase2MFA, to be checked as Global Administrator. Microsoft’s published material does not tell you where your tenant stands. Check its Message Center and your sign-in logs.

The 240-policy limit. Learn’s planning guide says Conditional Access has a limit of 240 policies per tenant, counting every state including report-only and off. It also advises using exclusions sparingly.

Decisions to make

Decision	Options from Learn	Trade-off
Authentication method	Passkey (FIDO2) (recommended), or certificate-based authentication where a PKI exists	CBA needs your own PKI. Microsoft does not provide one.
Which method	Different from your normal admin accounts	Learn’s example: admins on Microsoft Authenticator, emergency accounts on a FIDO2 key.
Passkey type	Synced passkey, or a device-bound key on a profile with attestation enforced	Synced passkeys do not support attestation. Learn says to treat them as phishing-resistant but with the same posture as other unattested authenticators. The device-bound key is the stricter option for break-glass.
Contingency Conditional Access policies	Disabled until needed, or report-only when not in use	Learn’s own pages differ. See the pitfalls.

Passkeys (FIDO2) need no extra licence and are available in all Entra ID editions, including Free, per Learn. CBA is also free and needs no paid edition, although MFA through Conditional Access needs a licensed edition.

If you choose CBA, note the limits Learn lists:

• Only one CRL distribution point per trusted CA is supported. It must be an HTTP URL. OCSP and LDAP URLs are not supported.
• CBA is not supported in the Web sign-in option on the Windows lock/sign-in screen.

Runbook

1. Create the accounts

   Create two or more accounts that are cloud-only, on the *.onmicrosoft.com domain, and not tied to a person. Learn’s emergency access page does not state a licence requirement for the accounts themselves, so check yours.

2. Assign Global Administrator as active permanent

   In Privileged Identity Management, make the Global Administrator assignment active permanent, not eligible, for each account. This is what Learn says to do for emergency access accounts.

3. Enable and register a phishing-resistant method

   For passkeys (FIDO2), enable the method first:

   1. Sign in to the Entra admin center as at least Authentication Policy Administrator.
   2. Go to Entra ID > Security > Authentication methods > Policies > Passkey (FIDO2).
   3. Enable the method and scope it so the break-glass accounts are included.

   Check these before you register:

   • Do not put break-glass accounts in an Excluded group on the Passkeys (FIDO2) policy. Learn says membership of an excluded group blocks FIDO2 registration and sign-in entirely, and overrides inclusion.
   • Self-service registration in Security info only works if Allow self-service set up is Yes on the Configure tab. That is a global setting, not per profile.

   Then register a passkey for each emergency access account. This step is a pointer to Learn rather than a full procedure. The points below are the conditions Learn states:

   1. Learn’s passkey page says self-service registration happens in Security info, and that it only works with Allow self-service set up set to Yes. Confirm in your tenant which account needs to be signed in to register each key.
   2. Learn says users must have completed MFA within the past five minutes before they can register a passkey (FIDO2). Complete MFA for the account first. Decide before you start which method the new emergency access account will use for that first MFA step.
   3. For the exact menu names and prompts in Security info, read the registration section of Enable passkeys (FIDO2), follow it, then check the result in your tenant.

   Learn says admin provisioning of security keys through Microsoft Graph is in preview. Treat self-service registration as the route to rely on.

   Confirm it worked before you move on:

   • Sign out, then sign in as the emergency access account using the passkey, from the designated secure workstation. Learn’s validation list says to confirm the accounts can sign in and perform admin tasks.
   • Check the account’s Authentication methods page in the Entra admin center for the registered passkey.
   • Repeat for each account. Do not close your own admin session until you have confirmed a passkey sign-in for at least one emergency account.

   If you restrict key types, note Learn’s warning: removing an AAGUID you previously allowed stops users who registered that key from signing in with it. For break-glass keys, that is a lockout.

4. Create the exclusion group

   Create a dedicated security group for the emergency accounts. Learn’s example name is EmergencyAccess. Use a group, not individual users: Learn says a limit applies to individual users added directly to a policy.

5. Exclude the group from Conditional Access policies that block or restrict sign-in

   Sign in as at least Conditional Access Administrator. Go to Entra ID > Conditional Access > Policies, open the policy (or select New policy), then Assignments > Users or workload identities > Exclude > Users and groups. Choose the emergency access group.

   Points from Learn:

   • Exclusion wins when a user or group is both included and excluded.
   • Report-only policies need no exclusion.
   • Verify exclusions before deploying any policy. The planning guide also says to exclude these accounts from country/region block policies.
   • When a policy targets All users and All apps, the portal warns about lockout and by default offers to exclude the current user. Learn says to exclude at least one admin.
   • The MFA-strength policy page recommends excluding emergency access accounts from that policy to prevent lockout from misconfiguration. Hybrid tenants should also exclude the Directory Synchronization Accounts role. Start in Report-only.
   • Microsoft’s pages do not say whether a policy requiring the built-in Phishing-resistant MFA strength should exclude break-glass accounts. Learn only covers the exclusion advice for the Multifactor authentication strength policy. Work through that one deliberately.

   Remember mandatory MFA still applies after the exclusion, so the accounts still need the method from the previous step.

6. Send sign-in logs to Azure Monitor

   Learn lists this as a prerequisite for alerting: send Entra sign-in logs to Azure Monitor (a Log Analytics workspace). Learn also names Microsoft Sentinel as an alternative monitoring tool.

7. Get the account object IDs

   In the Entra admin center, as at least User Administrator, go to Entra ID > Users and copy the object ID of each emergency account.

8. Create the alert rule

   Sign in to the Azure portal as at least Monitoring Contributor. Go to Monitor > Alerts > + Create > Alert rule. Learn’s configuration:

   • Signal: Custom log search
   • Query type: Aggregated logs
   • Alert logic: Static, Greater than, threshold 0
   • Severity: 0 - Critical is the recommended value

   Learn’s example query filters SigninLogs on the account’s UserId. Replace the GUID with your own object ID:

   KQLCopy

   SigninLogs
   | where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee"
   | project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

   Learn’s emergency access page gives a sign-in alert only. It says to capture audit logs for review, but it does not give an alert for role or credential changes on these accounts. Decide separately whether you want one.

9. Store credentials and agree the procedure

   Put credentials in secure, fireproof safes in separate locations. Write down who is authorised to use the accounts, and that they use a designated secure workstation. Tell your security-monitoring staff how the alert works.

10. Test, then keep testing

    Learn says to validate the accounts at least every 90 days, after IT staff changes, and when Entra subscriptions change. Each drill:

    • Tell security-monitoring staff before you start.
    • Confirm the accounts can sign in and perform admin tasks.
    • Confirm the alert rule actually triggers.
    • Confirm there is no MFA or SSPR registration tied to an individual’s device.
    • Review the list of authorised users.
    • Change safe combinations after leavers.

For the wider identity baseline, see Identity-first Azure baseline.

Checks

• ✓

  At least two cloud-only accounts exist on the *.onmicrosoft.com domain, not federated or synchronised.

• ✓

  Each has Global Administrator as active permanent in PIM, not eligible.

• ✓

  Each has a passkey (FIDO2) or certificate-based authentication, different from the method your normal admins use.

• ✓

  A test sign-in with the passkey has succeeded for each emergency account, from the designated secure workstation.

• ✓

  No break-glass account sits in an Excluded group on the Passkeys (FIDO2) policy.

• ✓

  The break-glass group is excluded from every Conditional Access policy that blocks or restricts sign-in, including country/region blocks.

• ✓

  Entra sign-in logs reach a Log Analytics workspace, and a test sign-in fires the alert.

• ✓

  Credentials are in separate secure locations and the authorised-user list is current.

• ✓

  Your tenant's Message Center and sign-in logs have been checked for where mandatory MFA stands.

• ✓

  The next 90-day validation is in the calendar.

Use and rollback

After an emergency. Learn’s resilience guidance says that if you used an emergency access account, regenerate its credentials and physically secure the new details as part of your emergency access procedure. Hold a post-mortem, as Learn recommends after any use.

If you enabled contingency Conditional Access policies, Learn’s order is:

1. Before activating, exclude the contingency, core-admin and emergency groups from the existing MFA policy.
2. Enable the contingency policies one by one, verifying each.
3. Disable the existing MFA policy.

Afterwards, re-enable the regular policies, return the contingency policies to report-only, regenerate any emergency account credentials you used, and revoke refresh tokens. Learn also advises documenting every change and the previous state, archiving sign-in activity for the period, and triaging risk detections, because disabling security policies lowers your security posture.

Backing out a change from this post.

• Conditional Access: Learn says policies can be rolled back by disabling them.
• Passkey: Remove it in the Entra admin center under the user’s Authentication methods. Right-click the passkey and select Delete.
• Passkey profiles: Learn says that once you opt in you can’t opt out, so treat that as a one-way door. Existing global settings move to a Default passkey profile, and up to three profiles are supported.

Common pitfalls

• Excluding from Conditional Access and stopping there. Mandatory MFA applies regardless of exclusions. Learn’s FAQ says there are no exceptions.
• Same method as everyone else. Learn says the authentication method for emergency accounts should differ from the ones your normal admin accounts use. Its example: admins on Microsoft Authenticator, a FIDO2 key for the emergency accounts.
• Eligible instead of active. Learn says the Global Administrator assignment must be active permanent. An eligible one needs activation, which is exactly what may not work in an emergency.
• Excluded group on the passkey policy. It overrides inclusion and blocks FIDO2 sign-in entirely.
• Registering and never testing the key. Registration alone does not show the key signs in. Do a test sign-in with it before you rely on it.
• Changing key restrictions later. Removing an allowed AAGUID locks out anyone who registered that key.
• Contingency policy guidance disagrees. Learn’s Conditional Access planning guide recommends contingency policies disabled until needed, named with an ENABLE IN EMERGENCY prefix, the disruption name and a sequence number. Learn’s resilient controls page says they should remain in report-only mode when not in use, and gives a naming standard of EMnnn - ENABLE IN EMERGENCY: [Disruption][i/n] - [Apps] - [Controls] [Conditions]. Microsoft’s own wording is inconsistent. Check the current text of both pages and your tenant’s Message Center, then document the choice you make.
• Credentials that expire or get cleaned up. Learn says the device or credential must not expire or fall into automated clean-up for lack of use.
• Tying the account to a person’s phone. Learn says to confirm there is no MFA or SSPR registration to an individual’s device.
• Untested alerting. Learn says drills should confirm that the monitoring and alert rules trigger. An alert that has never fired is a guess.
• Hitting the policy cap. The 240-policy limit counts report-only and disabled policies too.