Microsoft's MFA enforcement ends the "excluded from MFA" envelope for Entra break-glass accounts
Microsoft's mandatory MFA enforcement blocks an Entra break-glass account with no MFA method from admin portals, a dev.to guide says. A vaulted password therefore fails when the lockout it was kept for arrives.
The Engineer · Build desk
Key figures from the dev.to post's checklist: test the emergency accounts every 90 days at minimum; keep at least two emergency access accounts; the sign-in alert fires when the result count is greater than 0.
| Figure | Value | Note | Claim |
|---|---|---|---|
| Test the emergency accounts every, at minimum | 90 days | 14 | |
| Accounts to keep, at least | 2 accounts | 10 | |
| Alert fires above this count | 0 sign-in results | 15 |
What happened
- The setup the post describes is one cloud-only Global Admin, a long password in a safe, and "excluded from MFA" written on the envelope.
- The checklist calls for at least two emergency accounts that are cloud-only, on the *.onmicrosoft.com domain, and neither synced nor federated.
- Every sign-in to those accounts should raise an alert, and the accounts should be tested at least every 90 days.
Why it matters
- constraint A tenant that still keeps a vaulted password for its emergency account has a recovery path that fails the first time anyone needs it.
- decision Teams have to pick a phishing-resistant method that differs from the daily admins' method, and decide where that credential is stored.
- exposure Whoever can edit the exclusion group can exempt themselves from every Conditional Access policy, so its ownership and membership alerts matter as much as the accounts.
- cost The setup adds recurring work: a Log Analytics alert, an action group that reaches more than one person, and a drill every 90 days.
A password-only account has no second factor to present. The post says Microsoft's enforcement turns that into a hard stop: an emergency account with no MFA method cannot sign in to the admin portals [4]. Azure Resource Manager rejects its create, update and delete calls [5]. The post calls those "exactly the things you need it for" [5].
The post says Microsoft's documentation is explicit that break-glass and emergency access accounts must sign in with MFA once enforcement starts [6]. It names passkeys (FIDO2) or certificate-based authentication as the recommended methods, because both satisfy the requirement without a phone or a person [7]. The author restates the goal in one line: "excluded from Conditional Access, protected by a phishing-resistant method that doesn't depend on anyone's phone." [8]
The method choice follows from the lockout list. Two of the post's lockout causes are lost or unreachable MFA devices and a down phone network where SMS or voice was the only method [1]. A break-glass method that rides the same path fails with it, so the post says not to reuse the method the daily admin accounts use [9]. The post does not say where the passkey or certificate should be kept. In our view the same test applies to storage: the credential should not depend on anything the daily admins' recovery depends on.
The exclusion is where the design breaks next. The post's author says the lockout seen most often is a Conditional Access policy that was just turned on and blocks every admin [2]. The fix is one dedicated group, excluded from every policy that blocks or restricts sign-in [11]. Report-only policies do not block, so they need no exclusion [11].
That group is itself a bypass. Anyone who can add members to it can exclude themselves from the whole Conditional Access set, so the post says to make it role-assignable or restrict its owners, and to alert on membership changes [12]. In PIM, the Global Administrator assignment should be active and permanent, not eligible [13].
Detection has a documented shape. It is an Azure Monitor log search alert over SigninLogs that fires when the result count is greater than 0 [15]. The post says to key on object IDs, not UPNs, so a rename does not break the alert, to set severity 0, and to send it to an action group that reaches more than one person [15]. Without Log Analytics, a weekly look at the accounts' sign-in activity is a stopgap [16]. The post also supplies a read-only PowerShell check for a quarterly run [17].
Enforcement comes in two phases, and some tenants asked Microsoft to postpone Phase 2 [18][19]. The post tells those tenants to check the date they chose. The text available here does not list the phase dates. Everything above comes from one third-party post paraphrasing Microsoft's emergency access guidance, and Microsoft's own pages are not among the sources.
What to watch
- The Phase 2 date each tenant chose if it asked Microsoft to postpone; the post warns against finding a broken break-glass account on enforcement day.
- The first 90-day test after migration: whether the passkey or certificate account actually signs in to an admin portal and completes an Azure Resource Manager write.
- Whether Microsoft's own emergency access page matches the post's account of what Azure Resource Manager now rejects.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence50
- Adoption
- Insufficient
- Hype gap−5
- Incentives
- Insufficient
- Confidence55
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Lockout situations listed in Microsoft's emergency access guidance, per the post, include admins' MFA devices being lost or unreachable, or the phone network being down when SMS or voice was their only method.
- [2]
The post's author says a Conditional Access policy that was just turned on and blocks every admin is the lockout the author sees most.
- [3]
The post says a common break-glass setup is one cloud-only Global Admin, a long password in a safe, and "excluded from MFA" written on the envelope.
- [4]
Under Microsoft's mandatory MFA enforcement, an emergency account with no MFA method can't sign in to the admin portals, according to the post.
- [5]
Azure Resource Manager now rejects create, update and delete calls from an account with no MFA method; the post calls those exactly the things you need the account for.
- [6]
The post says Microsoft's documentation is explicit that break-glass and emergency access accounts must sign in with MFA once enforcement starts.
- [7]
Microsoft recommends a passkey (FIDO2) or certificate-based authentication for these accounts because both satisfy the requirement without relying on a phone or a person.
- [8]
The post's author wrote that the goal now is "excluded from Conditional Access, protected by a phishing-resistant method that doesn't depend on anyone's phone."
- [9]
The post says to give break-glass accounts a phishing-resistant method that is not the same method as the daily admin accounts use, and that a break-glass account must not share a failure mode with normal admin accounts.
- [10]
The checklist says to keep at least two emergency access accounts that are cloud-only, use the *.onmicrosoft.com domain, and are not synced or federated.
- [11]
The post says to exclude the accounts, ideally through one dedicated group, from every Conditional Access policy that blocks or restricts sign-in; report-only policies don't block and don't need the exclusion.
- [12]
The post warns that anyone who can add members to the exclusion group can exclude themselves from the entire Conditional Access set, and advises making it a role-assignable group or restricting its owners and managers, and alerting on membership changes.
- [13]
The post says the accounts' Global Administrator assignment in PIM should be active and permanent, not eligible.
- [14]
The post says to alert on every sign-in to the emergency accounts and to test them every 90 days at minimum.
- [15]
For Entra sign-in logs sent to Log Analytics, Microsoft's documented approach per the post is an Azure Monitor log search alert over SigninLogs that fires when the result count is greater than 0, keyed on object IDs rather than UPNs, at severity 0, sent to an action group that reaches more than one person.
- [16]
Without Log Analytics, the post says a weekly check of the accounts' sign-in activity is a stopgap, not a replacement for the real alert.
- [17]
The post provides a read-only PowerShell check, using Microsoft Graph PowerShell, to run every quarter.
- [18]
The post says Microsoft now enforces MFA for Azure sign-ins in two phases.
- [19]
Some tenants asked Microsoft to postpone Phase 2; the post tells those tenants to check the date they chose.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toEntra ID Break-Glass Accounts: Best Practices After Mandatory MFA
1 article · October 13, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Cloud security operationsFollow
- Identity and Access ManagementFollow
- Multi-Factor AuthenticationFollow