Microsoft updated its page on mandatory Entra MFA on 6 October 2026, and the line that matters for admins has not changed: break-glass and emergency access accounts must also sign in with MFA once enforcement reaches your tenant. Phase 2, which covers Azure CLI, Azure PowerShell, the Azure mobile app, IaC tools and the control-plane REST API, began rolling out gradually from 1 October 2025. Tenants could ask to postpone it to 1 July 2026. That date has passed.
If your emergency account still relies on a long password and an exclusion from MFA, it is either already broken or about to be. This is the time to rebuild it properly.
What's affected
Microsoft's FAQ is blunt: system enforcement applies to all user accounts, including break-glass accounts and any user exclusions configured for them. There is no opt-out. The page recommends moving these accounts to a passkey (FIDO2) or certificate-based authentication, and says both satisfy the requirement.
Phase 2 covers create, update and delete operations. Read operations do not need MFA. Workload identities such as managed identities and service principals are not affected.
An emergency account matters when normal paths fail, for example:
- Federation is down because your identity provider or a network link is unavailable.
- Every admin's registered MFA device is unavailable.
- The last person with Global Administrator access leaves.
- All admin roles are eligible, activation needs approval, and no approver exists.
How to check if you're exposed
Run through these five questions against the accounts you think are your emergency accounts.
- Do at least two exist, and are they cloud-only on the
.onmicrosoft.comdomain, not synced or federated? - Which authentication method do they use? A password plus SMS is the failure case.
- Is the Global Administrator assignment permanent active in Privileged Identity Management, not eligible?
- Are they excluded from Conditional Access policies that block or restrict sign-in?
- When did someone last sign in with each one, and did an alert fire?
If you cannot answer the last question, you do not have monitoring, which means you also cannot tell misuse from a drill.
What to do now
Microsoft's current guidance reduces to a checklist.
| Item | Requirement |
|---|---|
| Count | Two or more accounts, for redundancy |
| Type | Cloud-only, .onmicrosoft.com, no federation dependency |
| Authentication | Passkey (FIDO2) recommended, or certificate-based if you already run a PKI |
| Difference | Not the same method as your other admins. If they use Authenticator, use a FIDO2 key here |
| Lifecycle | Credential or device must not expire or be swept by automated cleanup for lack of use |
| Role | Global Administrator, permanent active in PIM |
| Conditional Access | Excluded from policies that block or restrict sign-in. Report-only policies do not need an exclusion |
| Storage | Not tied to one person or a personal phone. Keys in secure, fireproof safes in separate locations |
| Workstation | A designated secure workstation, such as a privileged access workstation |
| Validation | Test at least every 90 days, and after any IT staff change |
Then do the work in this order:
- Create or fix the accounts, enable passkeys (FIDO2) for the organization, and register a hardware key to each.
- Create a security group such as EmergencyAccess and exclude it from policies that block or restrict sign-in.
- Send sign-in logs to Azure Monitor and create an alert rule. Microsoft's sample query, with your own object IDs:
SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription
Set the alert to fire when the result count is greater than 0, with severity 0, Critical, and notify more than one person.
- Write the break-glass procedure: who may use it, how the key is retrieved, who is told, and how long the account stays signed in.
- After every use, hold a review. Preserve the Entra logs and check that each action matched an authorized emergency.
- Run a drill every 90 days. Tell the monitoring team beforehand, confirm the alert fires, and confirm the signed-in session can do an admin task.
- Rotate who can open the safe when someone leaves. Microsoft says to change safe combinations after anyone with access departs.
Why it matters
Break-glass accounts are the one place where a control that locks people out can become the outage. The old advice, a long password in an envelope and an exclusion from everything, bought availability at the price of a permanent weak spot. Mandatory MFA ends that trade, and a passkey on a hardware key gives you both availability and phishing resistance.
Two details are easy to miss. First, an exclusion from Conditional Access is not an exclusion from the platform's own MFA enforcement, so the credential itself has to be strong. Second, a quiet account is not proof of health. Credentials that expire or get cleaned up for lack of use are the usual way an emergency account fails on the day it is needed.
Also check the people side. If only one engineer knows where the key is, you have built a single point of failure with extra steps.
Quick check
Are break-glass accounts exempt from Azure's mandatory MFA?
No. Microsoft's FAQ says enforcement applies to all user accounts, including break-glass accounts. Use a passkey (FIDO2) or certificate-based authentication to meet it.
How often should you validate emergency access accounts?
At least every 90 days, and whenever IT staff change or the organization's Entra subscriptions change.
Why should the emergency account not use the same method as your other admins?
If a shared dependency such as the Authenticator app fails, both would fail together. A different method, such as a FIDO2 key, keeps one path open.
