# Break-glass (emergency access) accounts in Microsoft Entra ID

Source: https://startwithidentity.com/recipes/entra-break-glass-accounts/
Last updated: 2026-11-05
License: content by Start with Identity. Cite the source URL.

---

A [break-glass](https://startwithidentity.com/glossary/break-glass/) account in [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/) is a cloud-only Global Administrator that you only use when normal admin sign-in fails. Microsoft's guidance on [emergency access accounts](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access) comes down to six steps: create two or more such accounts on the `*.onmicrosoft.com` domain, make the Global Administrator assignment permanent and active, sign them in with [FIDO2 passkeys](https://startwithidentity.com/glossary/fido2/) or certificate-based authentication, exclude them from Conditional Access policies that block or restrict sign-in, alert on every sign-in, and test them at least every 90 days. When you finish, you have accounts that still work through a federation outage, a lost MFA device, or a bad policy, and nobody can use them without the security team knowing.

## Before you start

The accounts exist for specific failures that Microsoft lists. Federation is down, so sign-in redirects to an identity provider that does not answer. Admins cannot complete MFA because their devices or the phone network are unavailable. The last Global Administrator leaves or is disabled on-premises. Or every privileged role is eligible-only, activation needs approval, and no approver is left.

Do not skip MFA on these accounts. Microsoft's [mandatory MFA enforcement](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication) covers the Azure portal, Microsoft Entra admin center, and Intune admin center (Phase 1, from October 2024), the Microsoft 365 admin center (from February 2025), and Azure CLI, PowerShell, mobile app, IaC tools, and REST API create, update, and delete operations (Phase 2, from October 1, 2025). Learn says break-glass accounts are not exempt. An account with only a password cannot do its job.

| Decision | Microsoft's guidance |
| --- | --- |
| How many | Two or more |
| Domain | Cloud-only, `*.onmicrosoft.com`, not federated or synced |
| Role | Global Administrator, active permanent in PIM (not eligible) |
| Auth method | Passkey (FIDO2) recommended; certificate-based auth if you already run PKI |
| Owner | Not tied to an individual or to employee phones |
| Test cadence | At least every 90 days |

## 1. Create the accounts

[Create two cloud-only users](https://learn.microsoft.com/en-us/entra/fundamentals/how-to-create-delete-users) in the Microsoft Entra admin center, for example `bg-01@contoso.onmicrosoft.com` and `bg-02@contoso.onmicrosoft.com`. Use names that do not advertise the account's purpose if you prefer, but record the mapping in your runbook.

Assign the **Global Administrator** role. In Privileged Identity Management, make the assignment **active** and **permanent**, not eligible, so the account never depends on PIM activation or an approver.

**Check:** The user's properties show no on-premises sync, and the role assignment shows as permanent active.
**Common failure:** Creating the account on a federated custom domain. If AD FS or the external IdP is down, the account fails with it. Microsoft says to keep cloud and on-premises emergency access separate, with no dependency of one on the other.
**Rollback:** Delete the user; the tenant keeps your other Global Administrators.

## 2. Register phishing-resistant credentials

Enable passkeys (FIDO2) in the Authentication methods policy, then register at least two security keys per account. Microsoft adds that emergency accounts should not use the same method as your other admin accounts: if admins use Microsoft Authenticator, use FIDO2 security keys here. The credential must not expire or be removed by automated cleanup for inactivity. Hardware keys from vendors such as [Yubico](https://startwithidentity.com/vendors/mfa/yubico/) work; any FIDO2 key your Authentication methods policy allows is fine.

**Check:** The user's authentication methods list the passkeys, and nothing tied to a personal phone. Microsoft's validation list includes confirming no MFA or SSPR is registered to an individual's device or personal details.
**Common failure:** Registering a synced [passkey](https://startwithidentity.com/glossary/passkey/) on one administrator's phone. That ties the account to a person and a device, which the guidance rules out.
**Rollback:** Remove the method from the user's authentication methods and register a new key.

## 3. Exclude the accounts from Conditional Access

Create a security group such as `EmergencyAccess`, add both accounts, and exclude the group from every Conditional Access policy that blocks or restricts sign-in. Microsoft's reasoning: a policy that requires MFA, a compliant device, or another control could make the account unusable in the emergency it exists for, and the phishing-resistant method already protects it. Report-only policies do not block access and do not need the exclusion. The [Conditional Access baseline recipe](https://startwithidentity.com/recipes/entra-conditional-access-baseline/) builds this exclusion into every policy.

Microsoft also suggests creating disabled contingency policies whose names start with `ENABLE IN EMERGENCY` so an admin can enable them during an outage ([deployment plan](https://learn.microsoft.com/en-us/entra/identity/conditional-access/plan-conditional-access)).

**Check:** In **Conditional Access** > **Policies** > **What If**, simulate a sign-in as `bg-01`. No blocking policy should apply.
**Common failure:** A new policy created from a template without the exclusion. Make the group exclusion part of your policy review checklist.
**Rollback:** Remove the group from a policy's exclusions only if you have a deliberate reason.

## 4. Store the credentials

Keep credentials known only to authorized people, in secure, fireproof safes in separate locations. Microsoft also says authorized users should work from a designated secure workstation, such as a Privileged Access Workstation, when they use these accounts. Change safe combinations regularly and whenever someone with access leaves.

**Check:** Two people in different locations can each reach one key without the other.
**Common failure:** Both keys in one safe in one building. A site outage then takes out both accounts.
**Rollback:** Re-register keys if custody is ever in doubt.

## 5. Alert on every sign-in

First [send Entra sign-in logs to Azure Monitor](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/howto-integrate-activity-logs-with-azure-monitor-logs). Copy each account's **Object ID** from **Entra ID** > **Users**. In the Azure portal, open **Monitor** > **Alerts** > **+ Create** > **Alert rule**, scope it to your Log Analytics workspace, and choose **Custom log search** with **Query type** set to **Aggregated logs**. Use the query from Learn:

```kusto
// Search for multiple Object IDs (UserIds)
SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription
```

Set **Threshold type** to **Static**, **Operator** to **Greater than**, **Threshold value** to **0**, pick an evaluation frequency, and use severity **0 - Critical**. Attach an action group with **Email/SMS message/Push/Voice** notifications to several administrators.

**Check:** The alert rule shows as enabled, and a test sign-in triggers it.
**Common failure:** No sign-in data in the workspace, because the diagnostic setting was never created. The query then returns nothing and never fires.
**Rollback:** Disable or delete the alert rule in Azure Monitor.

## 6. Review every use

When the alert fires, preserve the Entra and workload logs and decide whether the use was a planned drill, a real emergency, or misuse. Then check what the account did and confirm it matched authorized use.

## Verify it works

Run this drill at least every 90 days, after staff changes, and when the tenant's Microsoft Entra subscriptions change:

1. Tell the security monitoring team a drill is underway.
2. From the designated workstation, sign in as `bg-01` to the Microsoft Entra admin center with the security key. Expect success and an MFA requirement satisfied by the passkey in the sign-in log.
3. Perform one read-only admin task, such as reviewing role assignments.
4. Confirm the Azure Monitor alert arrived within your evaluation window.
5. Repeat for `bg-02`, then review the authorized-user list and the runbook.

## Related

- [Break-glass account](https://startwithidentity.com/glossary/break-glass/) and [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/)
- [Microsoft Entra Conditional Access baseline](https://startwithidentity.com/recipes/entra-conditional-access-baseline/)
- [IAM disaster recovery guide](https://startwithidentity.com/guides/implementation/iam-disaster-recovery-guide/)
- [Entra ID stops delivering SMS and voice codes](https://startwithidentity.com/blog/2026-09-21-entra-id-stops-delivering-sms-and-voice-codes-february-1-and-global-admins-go-last/)