Passkeys and Break Glass Accounts in One Entra Tenant

Your security baseline says every administrator signs in with a phishing-resistant method. Your recovery plan says two Entra emergency access accounts, the break glass accounts, must work on the worst day of the year, when federation is down, the MFA app is gone, or the last Global Administrator has left. Those two goals pull in opposite directions. One wants every sign-in locked to strong, policy-enforced credentials. The other wants an account that no policy can ever trap.

You do not have to pick one. Microsoft's current guidance lets a single Entra tenant run passkeys for everyone, including the emergency accounts, as long as you design the two populations differently. This guide shows how: which passkey type each group gets, how to word the Conditional Access exclusions, what mandatory MFA changes, how to alert on every emergency sign-in, and how to prove the accounts still work every quarter.

It is written for senior Microsoft 365 and Entra administrators who already run Conditional Access and want a design they can defend in an audit.

---

Why Do Passkeys and Break Glass Accounts Conflict?

Break glass accounts are cloud-only Global Administrator accounts kept for emergencies, when normal admin sign-in fails. Passkeys are phishing-resistant credentials bound to a device or a passkey provider. The conflict is simple: the policies that enforce passkeys for admins can also lock out the accounts meant to rescue the tenant.

Microsoft lists the lockout cases its emergency access guidance is built for:

• A federation or on-premises identity outage.
• MFA devices that are lost, broken, or unavailable.
• The last Global Administrator leaving the organization.
• A disaster that takes out normal admin workstations or people.
• Every Global Administrator or Privileged Role Administrator assignment set to eligible with approval, and no approver available.

Each case has the same root cause: the tenant's only path to Global Administrator runs through something that has failed. A good design gives you a second path that shares as little as possible with the first. That is the whole idea. The emergency path should not depend on the same identity provider, the same device type, the same authentication method, or the same Conditional Access policies as your daily admins.

---

What Has Changed for Passkeys in Entra ID?

Entra now supports synced and device-bound passkeys, governed through passkey profiles that set attestation, allowed types and AAGUID lists per target group. Microsoft also enabled passkeys by default for users on SMS or voice from 1 September 2026, so admin accounts should be on a profile you chose, not the default. The full explainer on passkey types, attestation and profiles covers the detail; this guide assumes you have read it and focuses on the two account populations that matter here. For the telephony side, see the SMS and voice MFA migration plan.

---

Which Passkey Type Should Admins and Emergency Accounts Get?

Microsoft's passkey guidance recommends FIDO2 security keys for elevated-privilege users, with Authenticator passkeys as another option for them. Passkey types for everyday users are covered in the explainer.

The emergency access guidance adds one more rule: break glass accounts must use a different method from your normal admins. Microsoft's example is admins on Authenticator and emergency accounts on a FIDO2 key. That rule decides the rest of the table.

Two points are worth stating outright.

First, if your daily admins already use FIDO2 security keys, the emergency accounts need something else. Certificate-based authentication is the documented alternative, and only if you already operate a PKI. A second FIDO2 vendor is our pragmatic fallback, not Microsoft's wording. Microsoft frames the rule as a different method, and two brands of FIDO2 key are arguably the same method.

Second, never give a break glass account a synced passkey. The credential would live in one person's Apple or Google account, which ties the emergency path to an individual. Microsoft says the accounts must not be tied to an individual or to employee devices.

For Authenticator, the Authenticator passkey guide lists the AAGUIDs to allow: de1e552d-db1d-4423-a619-566b625cdc84 for Android and 90a3ccdf-635c-4729-a248-9b709135078f for iOS. It requires Android 14 or later, or iOS 17 or later. Attested Authenticator passkeys must be registered directly in the app; cross-device registration does not support them.

---

How Does Phishing-Resistant Authentication Strength Work?

Authentication strength is the Conditional Access control that says which methods satisfy a grant. The built-in Phishing-resistant MFA strength allows three things: Windows Hello for Business or platform credential, FIDO2 security key, and certificate-based authentication (multifactor).

Three behaviours catch admins out:

1. It does not restrict the first factor. A user can type a password first and is then asked to step up. Strength is enforced at the grant, not at the sign-in screen.
2. Windows Hello for Business does not auto-prompt. If an admin signed in to Windows with a password, Entra will not offer Windows Hello to satisfy the strength. They must restart and pick it from Sign-in options.
3. Synced passkey mapping is not spelled out. The strength page's table lists three method rows and does not list synced passkeys separately. The passkey how-to only says to use "a built-in phishing-resistant authentication strength" or a custom one. Microsoft has not published a clearer mapping on that page, so test with What If and a pilot user before you rely on it.

For admin roles, Microsoft publishes a Conditional Access template that requires phishing-resistant MFA for administrators. It targets roles such as Global, Privileged Role, Privileged Authentication, Security, Conditional Access, Exchange, SharePoint, and User Administrator. Note its limits. It does not apply to roles scoped to an administrative unit or to custom roles. It also tells you to exclude your emergency accounts and to start in report-only mode.

Protected actions go one step further. They attach an authentication context to sensitive permissions, such as changing Conditional Access policies or hard-deleting users. Azure PowerShell fails on protected actions; the Entra admin center, Graph PowerShell, and Graph Explorer support the step-up. Microsoft again says to keep an emergency account excluded.

---

How Do You Bootstrap Admin Passkeys With a Temporary Access Pass?

An admin cannot register a passkey if a policy already demands one. A Temporary Access Pass (TAP) breaks that loop. It is a time-limited passcode that counts as strong authentication for registration.

The TAP documentation sets the limits:

• Lifetime from 10 minutes to 43,200 minutes (30 days).
• Defaults: minimum lifetime 1 hour, maximum 8 hours, default lifetime 1 hour.
• One-time use is off by default. With a one-time TAP, registration must finish within 10 minutes of sign-in.
• Authentication Administrators can create TAPs for members. Privileged Authentication Administrators can create them for admins and members, but not for themselves.

TAP satisfies the plain MFA strength only. It does not satisfy the passwordless or phishing-resistant strengths. That causes a known trap: if you require phishing-resistant MFA for all resources, an admin using TAP cannot reach the Authenticator passkey registration flow. Microsoft's documented workaround is two policies, one for desktop and one for mobile, with TAP allowed on mobile.

The passkey how-to adds a second rule: a user must have completed MFA within the last five minutes before registering a passkey. Admin provisioning of FIDO2 keys through Graph is still in preview, so plan for the account holder, or the custodians, to register keys interactively.

For break glass accounts, use a short one-time TAP created by a Privileged Authentication Administrator. Register both FIDO2 keys in one supervised session on a secure workstation. Then confirm no TAP remains on the account.

---

How Should You Design Entra Emergency Access Accounts?

Here is the design that follows Microsoft's emergency access guidance and role best practices, point by point. If you manage customer tenants as a Microsoft partner, the setup differs; see our guide to CSP break glass accounts and passkeys for customer tenants.

Count. Create two or more break glass accounts. The best-practices page names two cloud-only accounts with Global Administrator. Two is the floor, not the ceiling. Microsoft also allows individual emergency accounts per admin as an alternative model.

Identity type. Cloud-only, on the *.onmicrosoft.com domain, not federated and not synced from on-premises. A federation outage is one of the scenarios these accounts exist for, so they cannot depend on federation.

Role assignment. Global Administrator, assigned as active permanent in PIM, not eligible. An eligible assignment needs PIM to work, and may need an approver. Both can fail in an emergency.

Not tied to a person. The accounts should not belong to an employee or live on employee devices. Our advice, not Microsoft's wording: use a neutral name that does not reveal the purpose to an attacker scanning the directory.

Authentication method. Passkey (FIDO2) is Microsoft's recommended option; certificate-based authentication is the alternative if you already have PKI. Both satisfy mandatory MFA. The method must differ from what daily admins use.

No expiry, no cleanup. Credentials and devices must not expire and must not be caught by automated cleanup for inactivity. Check lifecycle workflows, inactive-account scripts, and any certificate expiry that would quietly kill the account.

Storage and split custody. Microsoft says to store credentials in "secure, fireproof safes that are in secure, separate locations." Register two FIDO2 keys per account and put them in different safes. Split custody of the key PIN and the safe combination so no single person can use an account alone. That custody split is our recommendation; Microsoft's text covers the safes.

Where you use them. Sign in from a designated secure workstation or Privileged Access Workstation.

A note on restricted management administrative units: they can stop even a Global Administrator from changing member objects without a scoped assignment. The emergency access guidance does not mention them, so using one for break glass accounts is our inference, not a Microsoft recommendation. The restricted management AU page also says PIM and access reviews do not work on members. If you use one, treat it as your own design decision and test recovery carefully.

---

How Do You Word the Conditional Access Exclusions?

Microsoft's wording is precise, and old runbooks often get it wrong. Exclude break glass accounts from Conditional Access policies that "block or restrict sign-in." Restrict covers more than block. A policy that requires MFA, a compliant device, an approved location, or a specific authentication strength restricts sign-in.

Use one dedicated group, for example EmergencyAccess, and exclude that group rather than individual users. Report-only policies need no exclusion, because they never enforce.

Practical rules for the exclusion:

• Consider making the exclusion group role-assignable, so changing its membership needs a privileged role. This is our recommendation, not Microsoft's.
• Exclude the group from the phishing-resistant admin policy, device compliance policies, location policies, session controls, and protected-action policies.
• Never exclude it from monitoring. The exclusion moves the control from policy to detection.
• Review the group in every quarterly drill. One extra member is a standing bypass.

Microsoft's rationale is that the phishing-resistant credential protects the account even when Conditional Access does not. That only holds if the account has no weaker method registered. Remove passwords from use where you can, and make sure no SMS, voice, or Authenticator push method sits on the account.

To check coverage, run What If for each emergency account against every enabled policy. Our Conditional Access gap analysis guide walks through that method.

---

What Does Mandatory MFA Mean for Break Glass Accounts?

Excluding an account from Conditional Access does not exempt it from Azure mandatory MFA. The mandatory MFA page is explicit: "Break glass or emergency access accounts are also required to sign in with MFA once enforcement begins." Its FAQ adds that enforcement applies to break glass accounts and any user exclusions.

The phases:

• Phase 1, from October 2024: Azure portal, Entra admin center, and Intune admin center. The Microsoft 365 admin center followed from February 2025.
• Phase 2, rolling out gradually from 1 October 2025: Azure CLI, Azure PowerShell, the Azure mobile app, infrastructure-as-code tools, and REST or Resource Manager control-plane calls. Phase 2 covers create, update, and delete; reads are exempt.

The postponement windows ended on 30 September 2025 (Phase 1) and 1 July 2026 (Phase 2). Microsoft describes Phase 2 as gradual and does not publish a per-tenant enforcement list, so assume it applies to you. After enforcement, a Global Administrator can ask Microsoft Support to lift it temporarily.

The fix Microsoft recommends is the same one this guide uses: a FIDO2 passkey or certificate-based authentication on the emergency account. Workload identities such as managed identities and service principals are not affected. User accounts that act as service accounts are.

---

How Do You Alert on Every Break Glass Sign-In?

Every sign-in to one of your break glass accounts should page someone. Microsoft's guidance uses an Azure Monitor alert rule on the SigninLogs table in Log Analytics, or Microsoft Sentinel. Send Entra sign-in logs to the workspace first.

Microsoft's sample query, with your two account object IDs:

// Every sign-in attempt by either break glass account
SigninLogs
| where UserId == "<object-id-account-1>" or UserId == "<object-id-account-2>"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

Filter on UserId, the object ID, rather than the UPN. A renamed account keeps its object ID, so the alert survives a rename.

Configure the rule as Microsoft describes:

• Signal: custom log search, using the query above.
• Measurement: aggregated logs, threshold greater than 0.
• Severity: 0 – Critical.
• Action group: email, SMS, push, and voice to more than one on-call person.

The query includes failed attempts on purpose. A failed sign-in to a break glass account is often the first sign that someone is probing it.

Every alert needs a short post-mortem: was it a drill, a real emergency, or misuse? Record who signed in, from which workstation, and what changed. Then check the audit logs for changes made in that session.

---

How Do You Run the Quarterly Validation Drill?

Microsoft says to validate break glass accounts at least every 90 days, and also after IT staff changes and when Entra subscriptions change. Test both sign-in and an admin task. A sign-in that works but cannot reach the admin center is not a pass.

A drill checklist that covers both:

1. Announce the drill to the alert recipients, with a time window.
2. Two custodians retrieve one key from one safe. Use the second key next quarter.
3. Sign in from the designated secure workstation.
4. Confirm the sign-in alert fired and reached each channel.
5. Open the Entra admin center and perform a harmless admin task, such as reading a Conditional Access policy.
6. Run What If for the account against current policies and confirm no new policy blocks it.
7. Confirm the EmergencyAccess group membership is unchanged.
8. Confirm the role is still active permanent Global Administrator, not eligible.
9. Change the safe combination, as Microsoft advises, and return the key.
10. Write the post-mortem, even for a clean run.

Link the drill to your incident plan. Our Microsoft 365 outage runbook guide shows where emergency access fits in a wider response. Microsoft also recommends preparing contingency Conditional Access policies you can switch on during an outage.

---

How Do PIM and the Five Global Administrator Limit Fit In?

Microsoft's best practices recommend fewer than five Global Administrators. The Entra overview shows an alert card at five or more privileged Global Administrator assignments, and warns at more than ten privileged role assignments.

Break glass accounts hold Global Administrator too, so they use up part of that headroom, which is why the rest of the design matters. If you count them against the fewer-than-five guidance, two permanent emergency accounts leave room for two daily Global Administrators at most. Everyone else should hold narrower roles.

PIM makes this workable:

• Daily admins get eligible assignments and activate Global Administrator only when they need it.
• Use cloud-native accounts for privileged roles, not synced accounts.
• Use role-assignable groups or PIM for Groups to manage eligibility at scale.
• Run recurring access reviews on privileged roles.

Do not apply PIM to the break glass accounts themselves; PIM is for daily admins. Microsoft is clear that their assignment is active permanent. Also watch for one scenario Microsoft lists: every Global Administrator and Privileged Role Administrator set to eligible with approval, and no approver available. Your permanent emergency accounts are the way out of that.

PIM needs Entra ID P2 or ID Governance. For the rollout itself, see our PIM rollout guide.

---

Which Method Does Each Account Need? A Decision Flow

Use these inputs before you open the flowchart:

• Is the account a break glass account or a daily admin?
• Which method do your daily admins already use?
• Do you already run a PKI for certificate-based authentication?
• Does the user hold any privileged role at all?

flowchart TD
  A[New or existing account] --> B{Break glass account?}
  B -- Yes --> C{Daily admins use FIDO2 keys?}
  C -- No --> D[FIDO2 key in own attested profile]
  C -- Yes --> E{PKI already in place?}
  E -- Yes --> F[Certificate-based authentication]
  E -- No --> G[FIDO2 key from a different vendor, our fallback]
  D --> H[Exclude from block or restrict CA policies]
  F --> H
  G --> H
  H --> I[Severity 0 sign-in alert and 90-day drill]
  B -- No --> J{Holds a privileged role?}
  J -- Yes --> K[Attested Authenticator passkey or FIDO2 key]
  K --> L[Phishing-resistant strength for admin roles]
  J -- No --> M[Synced or device-bound passkey]
  M --> N[Phishing-resistant strength on sensitive apps]

---

What Does a 30/60/90-Day Rollout Look Like?

Days 1 to 30: secure the floor.

• Inventory every Global Administrator and every account excluded from Conditional Access.
• Create or rebuild two cloud-only *.onmicrosoft.com break glass accounts with active permanent Global Administrator.
• Create the break glass passkey profile with attestation on and an AAGUID allow-list.
• Register two FIDO2 keys per account using a one-time TAP. Store them in separate safes.
• Create the EmergencyAccess group and add it to exclusions on every block or restrict policy.
• Build the severity 0 alert and run the first drill.

Days 31 to 60: move the admins.

• Create the admin passkey profile and register admin passkeys with TAP.
• Deploy the phishing-resistant admin template in report-only mode, with the emergency group excluded.
• Review sign-in logs for admins who would fail, then fix their registration.
• Switch the policy on. Add protected actions for Conditional Access changes.
• Move daily Global Administrators to PIM eligible and get below five.

Days 61 to 90: extend and prove.

• Decide on synced passkeys for standard users and use the registration campaign.
• Check what the 1 September 2026 auto-enablement did for your SMS and voice users, and plan for the 2027 retirement dates.
• Apply the phishing-resistant strength to sensitive apps.
• Run access reviews on privileged roles.
• Run the second drill with the second key, and file the post-mortem.

---

What Are the Common Mistakes?

• Excluding only from block policies. Microsoft says block or restrict. An MFA or device policy can lock the account out.
• Assuming the exclusion skips mandatory MFA. It does not. The account needs a FIDO2 key or certificate.
• Same method as daily admins. One bad firmware update or one lost vendor relationship takes out both paths.
• Eligible instead of permanent. PIM becomes a dependency on the day it might be broken.
• Synced or synced-identity accounts. A hybrid-synced account fails when federation or sync fails.
• A forgotten TAP or SMS method left on the account. It quietly becomes the weakest path in.
• Alerting on UPN only. A rename silences the alert.
• Drilling sign-in but not admin tasks. Microsoft asks you to validate both.
• Inactivity cleanup. An unused emergency account looks stale to automation. Exclude it explicitly.
• Copying old figures from blog posts. Check the profile limit and policy details against current Learn pages before you build.

---

Key Takeaways

• Run two separate designs in one tenant: attested passkeys under strict policy for admins, and FIDO2 or certificate-protected break glass accounts outside the policies that block or restrict sign-in.
• Give break glass accounts a method your daily admins do not use.
• Mandatory MFA still applies to emergency accounts, so the passkey is not optional.
• Alert on every sign-in by object ID, at severity 0.
• Prove both sign-in and admin access at least every 90 days.

---

Related Articles

• Entra ID Passkeys: What Changed and Why to Move Now
• Entra ID Privileged Identity Management: Rolling Out Just-in-Time Admin Access
• Azure AD Conditional Access Policies: Complete Guide