Entra ID Break-Glass Accounts: Best Practices After Mandatory MFA

A lot of tenants still have the same break-glass setup: one cloud-only Global Admin, a long password in a safe, and "excluded from MFA" written on the envelope. Microsoft's mandatory MFA enforcement means that last part doesn't hold anymore. An emergency account with no MFA method can't sign in to the admin portals, and Azure Resource Manager now rejects its create, update and delete calls. Those are exactly the things you need it for.

This post walks through the current guidance and the mistakes I see most, then gives you a read-only PowerShell check you can run every quarter. Nothing below changes your tenant until you decide to.

TL;DR

• Keep at least two emergency access accounts. They should be cloud-only, use your *.onmicrosoft.com domain, and not be synced or federated.
• Give them phishing-resistant MFA, either passkeys (FIDO2) (Microsoft's recommendation) or certificate-based authentication. Don't use the same method as your daily admin accounts.
• Exclude them (ideally through one dedicated group) from every Conditional Access policy that blocks or restricts sign-in. Report-only policies don't need the exclusion.
• In PIM, make their Global Administrator assignment active and permanent, not eligible.
• Alert on every sign-in, and test every 90 days at minimum.

---

Why do you need a break-glass account at all?

Microsoft's emergency access guidance lists the situations that lock admins out of their own tenant:

• Federation or your on-premises identity provider is down, so every synced admin is stuck at the redirect.
• Admins' MFA devices are lost or unreachable, or the phone network is down and SMS or voice was their only method.
• The last person with an active Global Administrator role leaves, or their account gets disabled on-premises.
• Every Global Admin and Privileged Role Admin assignment is eligible in PIM, activation needs approval, and there are no approvers left.
• A Conditional Access policy you just turned on blocks every admin. This is the one I see most.

A break-glass account only helps if it doesn't share a failure mode with your normal admin accounts. Keep that rule in mind for everything below.

What changed with mandatory MFA?

Microsoft now enforces MFA for Azure sign-ins in two phases:

Phase	What's covered	What it means for break-glass
Phase 1	Sign-in to the Azure portal, Microsoft Entra admin center and Intune admin center	An account with no MFA method can't get into the portals you'd use to roll back a bad policy.
Phase 2	Create, update and delete operations through Azure Resource Manager (Azure CLI, Azure PowerShell, REST, SDKs, IaC)	Scripted recovery from a break-glass account needs MFA too. Read-only operations aren't affected.

The documentation is explicit: break-glass and emergency access accounts must sign in with MFA once enforcement starts. Microsoft recommends a passkey (FIDO2) or certificate-based authentication, because both satisfy the requirement without relying on a phone or a person.

So "excluded from MFA" isn't a valid design anymore. The goal now is "excluded from Conditional Access, protected by a phishing-resistant method that doesn't depend on anyone's phone."

Some tenants asked Microsoft to postpone Phase 2. If you're one of them, check the date you chose. Don't let your break-glass account be the first thing you discover is broken on enforcement day.

How should a break-glass account be configured?

Here's a checklist based on Microsoft's emergency access guidance. Each line is something you can verify:

Setting	Recommended	Why
Count	2 or more	One lost key or one locked safe shouldn't end your recovery.
Identity source	Cloud-only, *.onmicrosoft.com UPN	No dependency on AD, Entra Connect, AD FS or your custom domain's DNS.
Role	Global Administrator, active permanent in PIM	An eligible assignment needs activation, and activation may need approvers who are also locked out.
Auth method	Passkey (FIDO2) or CBA	Satisfies mandatory MFA, it's phishing-resistant, and it works without a phone.
Method diversity	Different from your daily admin method	If everyone uses Authenticator and Authenticator has a bad day, the break-glass still works.
Personal ties	No personal phone, no personal email, no SSPR on someone's mobile	The account belongs to the role, not to an employee.
Licensing / cleanup	Excluded from inactive-account cleanup and lifecycle workflows	Nobody signs in for months, and that's by design.
CA policies	Excluded from every policy that blocks or restricts	An enforced policy can block the account during the exact emergency it exists for.
Storage	Keys or credentials in separate, secure, fireproof locations	Split between two sites if you can.
Workstation	Use from a designated secure workstation (PAW)	Don't sign in to Global Admin from a kiosk browser.

One group, many exclusions

Create a dedicated security group, for example CA-Excl-BreakGlass, and put only the break-glass accounts in it. Exclude that group from your Conditional Access policies instead of excluding the accounts by name.

Two things to watch:

1. Protect the group. Anyone who can add members to it can exclude themselves from your entire CA set. Make it a role-assignable group, or at least restrict who owns and manages it, and alert on membership changes.
2. Don't exclude it from everything blindly. Microsoft's wording is to exclude break-glass from policies that block or restrict sign-in. Report-only policies don't block, so they don't need the exclusion.

What are the common break-glass mistakes?

Mistake	What happens	Fix
Account still "excluded from MFA" with no method registered	Can't get past the portal MFA prompt once Phase 1 applies	Register a FIDO2 passkey (or CBA) now, then test it.
FIDO2 key registered, but the passkey method isn't enabled for that account	Sign-in falls back to password-only and fails mandatory MFA	Check the Passkey (FIDO2) policy under Authentication methods and confirm the account is in scope.
Break-glass is synced from AD	AD or Entra Connect outage, or an on-prem disable, takes it out	Recreate it as cloud-only on *.onmicrosoft.com.
Excluded by name from 4 of 11 policies	The new policy someone created last month blocks it	Exclude one group, and make "includes the exclusion group" part of your CA change checklist.
GA is eligible in PIM	Can't activate during an outage, and approvers may be locked out too	Make it active permanent for emergency accounts only.
Location-based block catches it	Recovery from a home ISP or a hotspot gets blocked	The group exclusion fixes this too. Re-check it whenever you add a named-location policy.
No sign-in alert	A misused break-glass account looks like any other Global Admin	Set up an alert on every sign-in (see below).
Never tested	You find out the key's PIN is unknown during the outage	Run a drill every 90 days and after any staff change.

How do I alert on break-glass sign-ins?

If your Entra sign-in logs go to a Log Analytics workspace, Microsoft's documented approach is an Azure Monitor log search alert that fires when the result count is greater than 0:

SigninLogs
| where UserId == "<object-id-break-glass-1>" or UserId == "<object-id-break-glass-2>"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

Use the object IDs, not UPNs, so the alert keeps working if someone renames the account. Set severity 0, and send it to an action group that reaches more than one person. Also include the people who aren't holding the keys. Every alert should end in a short review: was this a drill, a real emergency, or misuse?

No Log Analytics yet? At minimum, check the accounts' sign-in activity in the read-only script below as part of a weekly routine. Treat that as a stopgap, though. You do want the real alert.

A read-only break-glass audit script

This uses Microsoft Graph PowerShell with read-only scopes only. It doesn't create, change or delete anything. For each emergency account, it reports:

• whether it's cloud-only and on onmicrosoft.com
• whether it's enabled, and when it last signed in
• whether it holds an active Global Administrator assignment
• which authentication methods are registered (and whether a FIDO2 passkey is one of them)
• every enabled Conditional Access policy that does not exclude it, either directly or through a group

# Read-only. Requires Microsoft.Graph PowerShell SDK.
# signInActivity needs AuditLog.Read.All and Entra ID P1+.
$scopes = @(
  'User.Read.All',
  'Directory.Read.All',
  'RoleManagement.Read.Directory',
  'UserAuthenticationMethod.Read.All',
  'Policy.Read.All',
  'AuditLog.Read.All'
)
Connect-MgGraph -Scopes $scopes -NoWelcome

$breakGlass = @(
  '[e-mail]',
  '[e-mail]'
)

$gaTemplateId = '62e90394-69f5-4237-9190-012177145e10'   # Global Administrator
$caPolicies   = Get-MgIdentityConditionalAccessPolicy -All |
                Where-Object State -eq 'enabled'          # report-only doesn't need the exclusion

$report = foreach ($upn in $breakGlass) {
  $u = Get-MgUser -UserId $upn -Property id,userPrincipalName,accountEnabled,onPremisesSyncEnabled,signInActivity

  $groupIds = (Get-MgUserTransitiveMemberOf -UserId $u.Id -All).Id

  $activeGA = Get-MgRoleManagementDirectoryRoleAssignment -All `
                -Filter "principalId eq '$($u.Id)' and roleDefinitionId eq '$gaTemplateId'"

  $methods = (Get-MgUserAuthenticationMethod -UserId $u.Id).AdditionalProperties.'@odata.type' |
             ForEach-Object { $_ -replace '#microsoft.graph.','' -replace 'AuthenticationMethod','' }

  $notExcluded = foreach ($p in $caPolicies) {
    $users = $p.Conditions.Users
    $excludedDirect = $users.ExcludeUsers -contains $u.Id
    $excludedGroup  = @($users.ExcludeGroups | Where-Object { $groupIds -contains $_ }).Count -gt 0
    if (-not ($excludedDirect -or $excludedGroup)) { $p.DisplayName }
  }

  [pscustomobject]@{
    UPN               = $u.UserPrincipalName
    Enabled           = $u.AccountEnabled
    CloudOnly         = -not $u.OnPremisesSyncEnabled
    OnMicrosoftDomain = $u.UserPrincipalName -like '*.onmicrosoft.com'
    LastSignIn        = $u.SignInActivity.LastSignInDateTime
    ActiveGlobalAdmin = [bool]$activeGA
    AuthMethods       = ($methods -join ', ')
    HasFido2          = $methods -contains 'fido2'
    EnabledCaPoliciesNotExcluding = ($notExcluded -join '; ')
  }
}

$report | Format-List
$report | Export-Csv ".\breakglass-audit-$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation

How to read the output:

• CloudOnly = False or OnMicrosoftDomain = False: fix this first. The account depends on something that can fail.
• HasFido2 = False (and you don't use CBA): the account probably can't pass mandatory MFA. Treat it as broken until you've tested it.
• ActiveGlobalAdmin = False: the role is missing or eligible-only. Check PIM → Microsoft Entra roles → Assignments to see which.
• EnabledCaPoliciesNotExcluding isn't empty: read each one. A policy that only applies to a specific app or to guest users may be fine. Anything that targets All users, all resources, a location block, or a device or MFA requirement is a lockout risk.

The script only checks direct and group-based exclusions. It doesn't simulate each policy. For a borderline policy, run What If in the Conditional Access blade as the break-glass account. It's also read-only.

How often should I test break-glass accounts?

Microsoft says at least every 90 days, and also after IT staff changes or subscription changes. A drill that takes 15 minutes:

1. Tell security monitoring a drill is starting, so the alert is expected.
2. Fetch the key or credential from storage and log who had it and when.
3. Sign in from your designated secure workstation and confirm you can open the Entra admin center and see Conditional Access.
4. Confirm the sign-in alert fired and reached everyone it should.
5. Run the read-only audit script and save the CSV with the drill notes.
6. Check that nobody has registered a personal phone or SSPR method on the account.
7. Return the credential, and change safe combinations if anyone with access has left.

Put the drill on the calendar the same way you'd schedule a restore test. If it isn't scheduled, it won't happen.

FAQ

Should break-glass accounts be excluded from MFA?
Not anymore. Mandatory MFA applies to emergency access accounts for the Azure portal, Entra admin center and Intune admin center, and for Azure Resource Manager write operations. Exclude them from Conditional Access policies that block or restrict, and protect them with a FIDO2 passkey or certificate-based authentication.

How many break-glass accounts should I have?
At least two. Store their credentials in separate secure locations, and use a different authentication method from your day-to-day admin accounts.

Should the break-glass Global Admin role be eligible in PIM?
No. Microsoft recommends an active permanent assignment for emergency access accounts, so recovery doesn't depend on activation or approvers.

Do I need to exclude break-glass accounts from report-only Conditional Access policies?
No. Report-only policies are evaluated but never enforced, so they can't block the account.

Can a break-glass account use Microsoft Authenticator?
Technically, yes. But it ties the account to a phone and probably to the same method your daily admins use. That's the shared failure mode you're trying to avoid. A FIDO2 key in a safe is the cleaner design.

---

Related posts

• Conditional Access baseline for Entra ID: naming, pilot groups, report-only, Insights, break-glass and rollout waves
• Conditional Access Report-Only Results: Logs vs On
• Conditional Access Report-Only Mode: Safe Rollout Steps
• Connect-MgGraph "Insufficient privileges": scopes, roles, consent and app-only

Free checklist

If you're about to touch Conditional Access, the free Conditional Access pre-enforcement checklist includes the break-glass checks above, along with pilot groups and report-only review steps, on one page:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=entra-break-glass-accounts

If you want the longer version, the Entra ID Conditional Access Starter Pack has a full break-glass and exclusions playbook, a starter policy library and read-only Graph exports for policies and named locations: https://cashflow4375.gumroad.com/l/nhuyrc?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=entra-break-glass-accounts

---

Admin Pack Studio; not affiliated with Microsoft. Always test in a pilot or lab tenant before you change production identity settings.