## Why break-glass accounts still matter in modern Entra ID
Microsoft Entra ID has become the control plane for Microsoft 365, Azure, Intune, many SaaS applications, and a growing number of line-of-business systems. That makes identity both your front door and your emergency exit. If Conditional Access is misconfigured, a third-party MFA provider fails, a federation service breaks, or an administrator accidentally blocks the wrong location, the organization can lose access to the very portal needed to fix the problem.
A break-glass account, sometimes called an emergency access account, is a highly protected cloud-only administrator account reserved for tenant recovery. It is not a convenience account. It is not a shared admin login for daily work. It exists for one purpose: restoring administrative access when normal identity controls are unavailable or misbehaving.
The hard part is balance. If the account is protected exactly like every other admin, it may fail during the same outage. If it is exempted from too much, it becomes a dangerous back door. A well-designed break-glass process gives you a survivable path into the tenant while surrounding that path with monitoring, documentation, offline controls, and regular testing.
This guide walks through a practical design for Microsoft Entra ID break-glass accounts suitable for SMBs, nonprofits, and enterprises that rely on Microsoft 365 or Azure.
## Common failure scenarios these accounts solve
Break-glass access is not theoretical. The most common scenarios include:
– A Conditional Access policy blocks all administrators due to an incorrect network, device compliance, or country condition.
– A phishing-resistant MFA rollout is configured incorrectly and prevents admin sign-in.
– A third-party identity provider, federation service, or MFA service becomes unavailable.
– A Privileged Identity Management approval workflow cannot be completed because approvers are unavailable.
– A passwordless authentication deployment locks out users with broken device registration.
– An administrator deletes or disables the wrong security group used by access policies.
– A tenant is under active attack and normal privileged accounts are suspected to be compromised.
In each case, the emergency account should let a trusted responder enter the tenant, disable or adjust the broken control, rotate credentials, review logs, and return the environment to a secure state.
## Design principles for resilient emergency access
### Use two cloud-only accounts
Microsoft recommends maintaining at least two emergency access accounts. Two accounts reduce the risk that a single password problem, accidental deletion, licensing issue, or unexplained sign-in failure leaves you stranded.
These accounts should be cloud-only, not synchronized from Active Directory and not federated to an external identity provider. If your on-premises AD, AD FS, pass-through authentication agents, or hybrid identity connectors fail, a cloud-only account can still authenticate directly to Entra ID.
Use names that are recognizable to authorized staff but not easily guessed as high-value accounts. Avoid obvious names like globaladmin, breakglass, emergencyadmin, or ceo-admin. For example:
“`text
[email protected]
[email protected]
“`
Using the tenant onmicrosoft.com domain can be helpful because it avoids dependency on a custom domain registration or DNS issue. Do not use these accounts for email, automation, mailbox access, or routine administration.
### Assign only the role needed for recovery
In many tenants, the emergency account is assigned the Global Administrator role because it may need to repair any identity, security, or subscription configuration. That is defensible, but it increases the importance of monitoring and offline protection.
If your organization has a mature role model, you may consider a combination of Global Administrator for one account and Privileged Role Administrator plus Security Administrator for another. However, during a true lockout, simplicity matters. The account must have enough authority to fix Conditional Access, MFA settings, role assignments, app registrations, and tenant-wide configuration.
Do not place break-glass accounts in normal admin groups used for daily operations. They should be individually identifiable in audit logs and excluded from automation that modifies admin membership.
### Keep them outside normal Conditional Access policies
A break-glass account usually needs an exclusion from broad Conditional Access policies, especially policies that enforce MFA, compliant devices, hybrid-joined devices, named locations, or authentication strength. That exclusion is what allows the account to work when the policy itself is broken.
This does not mean the account is unprotected. It means the protection model changes from inline authentication controls to compensating controls:
– Long, unique passwords stored offline or in a tightly governed vault
– No daily use
– Dedicated alerting on any sign-in attempt
– Regular credential rotation
– Documented approval and retrieval procedure
– Periodic test sign-ins from a controlled location
Create a dedicated group such as EntraID-BreakGlass-Accounts and use that group as the explicit exclusion in relevant Conditional Access policies. Keep the group membership limited to the two emergency accounts and monitor any membership change.
## Build the accounts with Microsoft Graph PowerShell
The following examples use Microsoft Graph PowerShell. Adjust names and domains for your tenant. Run these commands from a secured administrator workstation.
“`powershell
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes ‘User.ReadWrite.All’,’RoleManagement.ReadWrite.Directory’,’Group.ReadWrite.All’
$domain = ‘contoso.onmicrosoft.com’
$password = ‘Replace-With-A-Temporary-Generated-Password’
New-MgUser -AccountEnabled:$true `
-DisplayName ‘Tenant Recovery Account A’ `
-MailNickname ‘svc-tenant-recovery-a’ `
-UserPrincipalName “svc-tenant-recovery-a@$domain” `
-PasswordProfile @{ ForceChangePasswordNextSignIn = $false; Password = $password }
New-MgUser -AccountEnabled:$true `
-DisplayName ‘Tenant Recovery Account B’ `
-MailNickname ‘svc-tenant-recovery-b’ `
-UserPrincipalName “svc-tenant-recovery-b@$domain” `
-PasswordProfile @{ ForceChangePasswordNextSignIn = $false; Password = $password }
“`
After creation, set each account to use a different strong password. Do not reuse the temporary password. A practical standard is a randomly generated passphrase of at least 24 characters, stored in separate sealed envelopes or in a highly restricted password vault with emergency access logging.
Next, create a group for policy exclusions:
“`powershell
$group = New-MgGroup -DisplayName ‘EntraID-BreakGlass-Accounts’ `
-MailEnabled:$false `
-MailNickname ‘EntraID-BreakGlass-Accounts’ `
-SecurityEnabled:$true
$acctA = Get-MgUser -UserId “svc-tenant-recovery-a@$domain”
$acctB = Get-MgUser -UserId “svc-tenant-recovery-b@$domain”
New-MgGroupMember -GroupId $group.Id -DirectoryObjectId $acctA.Id
New-MgGroupMember -GroupId $group.Id -DirectoryObjectId $acctB.Id
“`
Role assignment can be done through the Entra admin center or PowerShell. The exact role template ID for Global Administrator is well known, but using the role display name reduces mistakes:
“`powershell
Connect-MgGraph -Scopes ‘RoleManagement.ReadWrite.Directory’,’User.Read.All’
$role = Get-MgDirectoryRole | Where-Object {$_.DisplayName -eq ‘Global Administrator’}
if (-not $role) {
$template = Get-MgDirectoryRoleTemplate | Where-Object {$_.DisplayName -eq ‘Global Administrator’}
Enable-MgDirectoryRole -DirectoryRoleTemplateId $template.Id
$role = Get-MgDirectoryRole | Where-Object {$_.DisplayName -eq ‘Global Administrator’}
}
New-MgDirectoryRoleMemberByRef -DirectoryRoleId $role.Id -BodyParameter @{
‘@odata.id’ = “https://graph.microsoft.com/v1.0/directoryObjects/$($acctA.Id)”
}
New-MgDirectoryRoleMemberByRef -DirectoryRoleId $role.Id -BodyParameter @{
‘@odata.id’ = “https://graph.microsoft.com/v1.0/directoryObjects/$($acctB.Id)”
}
“`
## Conditional Access configuration pattern
The safest pattern is not to create a special policy that allows the break-glass accounts. Instead, exclude the break-glass group from policies that could prevent emergency sign-in.
Review every policy that applies to all users or all administrators, especially policies that require:
– Multifactor authentication
– Authentication strength
– Compliant or hybrid-joined devices
– Approved client applications
– Trusted locations
– Sign-in risk controls
– Terms of use acceptance
– Session controls that depend on another service
For each such policy, add the EntraID-BreakGlass-Accounts group as an exclusion. Document the reason in the policy description. For example:
“`text
Policy: Require phishing-resistant MFA for administrators
Exclusion: EntraID-BreakGlass-Accounts
Reason: Emergency tenant recovery if MFA, device registration, or CA policy configuration blocks all administrators. Sign-ins are separately monitored and investigated.
“`
Avoid excluding the accounts from every security control without thinking. For example, if you use a policy that blocks legacy authentication for all users, the emergency accounts should still be covered. They do not need POP, IMAP, SMTP AUTH, or other legacy protocols. In most tenants, the accounts should have no mailbox and no application usage at all.
## Monitoring is not optional
A break-glass account without alerting is a standing privilege risk. Any sign-in attempt, successful or failed, should generate an urgent alert to the IT team or SOC. Because the expected sign-in frequency is near zero, the signal is very clean.
If you send Entra ID logs to Microsoft Sentinel, you can create analytic rules using KQL. Start with successful sign-ins:
“`kusto
SigninLogs
| where UserPrincipalName in~ (‘[email protected]’, ‘[email protected]’)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ClientAppUsed, ConditionalAccessStatus, ResultType, ResultDescription, Location
“`
Create a second rule for failed attempts. Failed attempts may indicate password guessing, leaked account names, or someone trying to test access without authorization.
“`kusto
SigninLogs
| where UserPrincipalName in~ (‘[email protected]’, ‘[email protected]’)
| where ResultType != 0
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType, ResultDescription, Location
“`
Also monitor changes to the accounts and the exclusion group:
“`kusto
AuditLogs
| where TargetResources has_any (‘svc-tenant-recovery-a’, ‘svc-tenant-recovery-b’, ‘EntraID-BreakGlass-Accounts’)
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, Result
“`
If you do not use Sentinel, configure alerts in the Entra admin center, Defender XDR, your SIEM, or your MSP monitoring platform. The important requirement is operational: a real person must be notified quickly, including after hours.
## Password storage and access procedure
The password storage model should match the organization size and risk profile. Common approaches include:
– Two sealed envelopes stored in separate locked locations
– A password manager with emergency access approval and immutable audit logs
– A physical safe controlled by executive leadership and IT
– Split knowledge, where two authorized people must participate to retrieve a credential
Do not store emergency credentials in the same Microsoft 365 tenant they are designed to recover. A OneNote notebook, SharePoint library, Exchange mailbox, Teams channel, or cloud password vault protected by the same tenant can be unavailable during the incident.
Create a short access procedure that answers these questions:
1. Who can authorize use of a break-glass account?
2. Where are the credentials stored?
3. Who must be notified before and after use?
4. What actions are permitted during emergency access?
5. How is the password rotated after use?
6. How is the incident documented?
This procedure should be printed or stored somewhere accessible during an identity outage. If the only copy is inside Microsoft 365, it may not help when you need it.
## Testing without creating unnecessary risk
Untested break-glass accounts are assumptions, not controls. Test them at least quarterly and after major identity changes such as Conditional Access redesigns, MFA migrations, federation changes, tenant mergers, or privileged access projects.
A safe test should include:
– Confirming the password can be retrieved through the approved process
– Signing in from a controlled workstation and known network
– Verifying the account can access the Entra admin center
– Confirming it can view and modify Conditional Access policies
– Verifying that alerts fired and reached the correct responders
– Signing out immediately
– Recording the test in a change or security log
– Rotating the password if your policy requires it after retrieval
Do not browse email, access user data, run unrelated administrative tasks, or leave active sessions open. The point is to validate recovery capability, not to normalize using the account.
## Operational mistakes to avoid
### Depending on synchronized or federated identity
If the account depends on on-premises AD, AD FS, pass-through authentication, or a third-party identity platform, it may fail during exactly the scenario it is meant to solve. Keep emergency access cloud-native.
### Forgetting new Conditional Access policies
Organizations often exclude break-glass accounts from existing policies, then create a new all-users policy six months later and forget the exclusion. Add break-glass review to your Conditional Access change checklist.
### Licensing the accounts unnecessarily
Break-glass accounts usually do not need Microsoft 365 licenses because they should not use mailboxes, Teams, OneDrive, or productivity apps. Assigning licenses can increase data exposure and may create confusing audit trails.
### Allowing daily administrative use
The moment an emergency account becomes a shortcut for routine admin work, it loses its value as a clean emergency control. Daily administration should use named accounts, least privilege, Privileged Identity Management, and phishing-resistant MFA.
### Ignoring failed sign-ins
A failed sign-in against a break-glass account is still an event. Investigate it. It may be a typo during a test, but it may also be reconnaissance or credential stuffing.
## A practical review checklist
Use this checklist during your next identity security review:
– Two emergency access accounts exist.
– Both accounts are cloud-only and use the onmicrosoft.com domain.
– Accounts are not synchronized, federated, licensed, or mailbox-enabled.
– Accounts have documented privileged roles.
– Accounts are excluded from Conditional Access policies that could block recovery.
– Accounts are still covered by controls that are safe, such as legacy authentication blocking.
– Credentials are long, unique, and stored outside the tenant.
– Retrieval requires documented authorization.
– Successful and failed sign-ins generate urgent alerts.
– Group membership and account changes are monitored.
– A quarterly test is scheduled and documented.
– Password rotation requirements are defined.
– The process is included in incident response and business continuity plans.
## Summary and key takeaways
Break-glass accounts are a small control with outsized importance. When Entra ID is healthy, they should be almost invisible. When Conditional Access, MFA, federation, or privileged workflows fail, they may be the fastest path to restoring business operations.
The right design is not simply creating a Global Administrator account and hiding the password. A reliable emergency access program uses two cloud-only accounts, carefully scoped Conditional Access exclusions, strong offline credential protection, immediate alerting, and scheduled testing. It also treats every use as a security event that must be documented and followed by review.
Key takeaways:
– Build emergency access before you need it, not during an outage.
– Keep break-glass accounts cloud-only and independent of federation or on-premises identity.
– Exclude them only from controls that could prevent recovery.
– Monitor every sign-in attempt and every configuration change involving the accounts.
– Store credentials outside the tenant and document the retrieval process.
– Test regularly, especially after major identity or Conditional Access changes.
For organizations that rely on Microsoft 365 and Azure, resilient identity administration is part of disaster recovery. A well-managed break-glass process helps ensure that a security control failure does not become a business-wide outage.
