## Why break-glass account design deserves more attention
Most Microsoft 365 and Entra ID tenants eventually accumulate strong security controls: multifactor authentication, Conditional Access, compliant-device requirements, sign-in risk policies, privileged identity workflows, and sometimes federation to an on-premises identity provider. Those controls are necessary, but they also introduce a difficult operational question: how do you administer the tenant when the identity system itself is part of the outage?
That is the purpose of an emergency access account, commonly called a break-glass account. It is a highly privileged cloud-only identity that can be used when normal administrative access is unavailable. Examples include a failed federation service, a Conditional Access misconfiguration, an MFA provider issue, a lost privileged access workflow, or an endpoint compliance incident that blocks administrators from every trusted device.
The risk is obvious. A break-glass account that can bypass normal controls is also attractive to attackers. If it is created casually, excluded from every policy, named predictably, and never monitored, it becomes a quiet permanent backdoor into the organization.
This article walks through a practical design for Entra ID emergency access accounts that balances survivability with security. The goal is not to create an account that is easy to use every day. The goal is to create an account that works during a real identity emergency, produces immediate alerts if touched, and is tested often enough that no one is guessing under pressure.
## What problem are we actually solving?
A good break-glass design must survive failures in the same systems that usually protect administrators. That means the emergency path should not depend on:
– On-premises Active Directory synchronization
– AD FS or another federation provider
– A single MFA method or phone carrier
– A compliant or hybrid-joined device requirement
– Privileged Identity Management approval workflows
– A network location that might be unavailable during an incident
– A single administrator who remembers the password
At the same time, it must not become a general-purpose administrative shortcut. If an emergency account is used because an admin forgot their security key at home, the design has failed operationally even if it succeeded technically.
The best implementations treat break-glass access as a controlled safety mechanism. It is documented, sealed, monitored, and tested. Daily administration continues through named administrator accounts, role-based access, Privileged Identity Management, and Conditional Access.
## Recommended account model
### Create two cloud-only accounts
Maintain two emergency access accounts, not one. Two accounts reduce the chance that a single credential issue, accidental lockout, deletion, or authentication method failure prevents recovery. Both should be cloud-only accounts using the tenant’s `onmicrosoft.com` domain rather than a federated custom domain.
For example, if the tenant is `contoso.onmicrosoft.com`, the accounts might use non-obvious names such as:
“`text
[email protected]
[email protected]
“`
Avoid names such as `breakglass`, `emergencyadmin`, or `globaladmin`. Security through obscurity is not a control by itself, but there is no reason to make the account easier to identify in password spraying or credential stuffing attempts.
### Assign the minimum emergency role that still works
In many environments, at least one emergency access account needs the Global Administrator role. That is uncomfortable, but it is often the only role with enough authority to recover from severe tenant-wide policy or identity failures.
If your organization has a mature operating model, you can consider splitting duties. One account may hold Global Administrator, while the second holds Privileged Role Administrator plus Conditional Access Administrator. However, be careful: during a real outage, a partial role set may not be enough. For many SMBs and nonprofits, two well-controlled Global Administrator emergency accounts are simpler and more reliable than a clever design no one can operate during an incident.
Do not rely on eligible-only Privileged Identity Management activation for break-glass access. PIM is excellent for normal privileged administration, but emergency access should not depend on an approval, MFA challenge, or workflow that may be unavailable.
### Keep the accounts unlicensed when possible
Emergency access accounts usually do not need Exchange mailboxes, Teams, OneDrive, or desktop applications. Leaving them unlicensed reduces attack surface and avoids creating mailboxes that could be abused or overlooked. The accounts can still sign in to the Entra admin center and perform directory administration if properly privileged.
Document any exception. If a licensing dependency is introduced later, make sure it is intentional and reviewed.
## Authentication strategy: survivable, not convenient
### Use long, unique passwords stored offline
Each emergency account should have a unique, high-entropy password. Think passphrase length measured in dozens of characters, not a clever variation of a company name. The password should be stored in a controlled offline process, such as a sealed envelope in a safe, a split-secret procedure, or an enterprise password vault with emergency access controls.
Do not store the only copy in the same Microsoft 365 tenant you are trying to recover. A SharePoint document named `Emergency Passwords` is not a disaster recovery plan.
### Consider phishing-resistant MFA carefully
Many organizations ask whether emergency accounts should use MFA. The answer depends on what failure modes you are trying to survive.
A phishing-resistant method such as a FIDO2 security key can significantly reduce credential theft risk. However, if the account is subject to Conditional Access policies that require MFA, and the MFA system or policy evaluation path is the thing that is broken, the account may not serve its emergency purpose.
A practical compromise is:
– Use very long unique passwords.
– Store passwords offline with dual-control access.
– Register at least one phishing-resistant method where appropriate.
– Exclude emergency accounts from Conditional Access policies that could block all access during an identity outage.
– Alert aggressively on any sign-in attempt, successful or failed.
For larger organizations, give each emergency account a different authentication path. For example, one may have a FIDO2 key stored in a safe at headquarters, while another is protected through a different controlled method at a secondary location. The point is to avoid a shared dependency.
## Conditional Access: exclude deliberately, not lazily
The most common mistake is creating a group named `CA Exclusions`, adding emergency accounts, service accounts, executives, scanners, and old applications, and then excluding the group from every policy forever. That is not a break-glass strategy. It is a bypass bucket.
Create a dedicated group for emergency access only. Do not mix it with ordinary service accounts or policy exceptions.
Example group:
“`text
Emergency Access Accounts
“`
Emergency accounts should normally be excluded from Conditional Access policies that could prevent login during an outage, including:
– Require MFA for all administrators
– Require compliant or hybrid joined device
– Block access from unknown locations
– Sign-in risk or user risk enforcement that could block access
– Policies scoped to all users and all cloud apps
That does not mean the accounts should be forgotten. Conditional Access is only one layer. Monitoring, password handling, role review, and operational testing become more important because these accounts intentionally sit outside parts of the standard access path.
## Create and review the design with Microsoft Graph PowerShell
The following examples use Microsoft Graph PowerShell. Run them from a secured administrative workstation with an account that already has the necessary permissions.
Install the module if needed:
“`powershell
Install-Module Microsoft.Graph -Scope CurrentUser
“`
Connect with appropriate scopes:
“`powershell
Connect-MgGraph -Scopes User.ReadWrite.All,Group.ReadWrite.All,RoleManagement.ReadWrite.Directory,Policy.Read.All
“`
Create the dedicated exclusion group:
“`powershell
New-MgGroup -DisplayName ‘Emergency Access Accounts’ `
-MailEnabled:$false `
-MailNickname ’emergency-access-accounts’ `
-SecurityEnabled:$true
“`
Create a cloud-only emergency user. In production, generate the password through an approved secure process rather than typing it into a script history.
“`powershell
$PasswordProfile = @{
Password = ‘Replace-With-A-Unique-Offline-Generated-Password’
ForceChangePasswordNextSignIn = $false
}
New-MgUser -DisplayName ‘Tenant Recovery A’ `
-UserPrincipalName ‘[email protected]’ `
-MailNickname ‘svc-tenant-recovery-a’ `
-AccountEnabled:$true `
-PasswordProfile $PasswordProfile
“`
Add the account to the emergency access group:
“`powershell
$Group = Get-MgGroup -Filter “displayName eq ‘Emergency Access Accounts'”
$User = Get-MgUser -UserId ‘[email protected]’
New-MgGroupMember -GroupId $Group.Id -DirectoryObjectId $User.Id
“`
If you use these commands directly, note the double quotes around the OData filter. In production scripts, avoid embedding reusable emergency passwords in files, terminal transcripts, ticket notes, or shell history.
## Check Conditional Access exclusions
After the accounts and group exist, review Conditional Access policies and confirm the group is excluded where required. This example lists policies and their excluded groups.
“`powershell
$Policies = Get-MgIdentityConditionalAccessPolicy -All
foreach ($Policy in $Policies) {
[PSCustomObject]@{
PolicyName = $Policy.DisplayName
State = $Policy.State
ExcludedGroups = ($Policy.Conditions.Users.ExcludeGroups -join ‘,’)
ExcludedUsers = ($Policy.Conditions.Users.ExcludeUsers -join ‘,’)
}
}
“`
This output gives you object IDs, not friendly names. Export it, compare it against your emergency access group ID, and keep the result with your security documentation.
For a more controlled review, record the group ID:
“`powershell
$EmergencyGroup = Get-MgGroup -Filter “displayName eq ‘Emergency Access Accounts'”
$EmergencyGroup.Id
“`
Then verify which policies exclude that exact group:
“`powershell
$Policies | Where-Object {
$_.Conditions.Users.ExcludeGroups -contains $EmergencyGroup.Id
} | Select-Object DisplayName, State
“`
This is a useful quarterly control because Conditional Access policies change frequently. A new all-users policy can accidentally block emergency access if the exclusion is forgotten.
## Monitoring: treat any use as an incident
A break-glass sign-in should be rare. Any successful sign-in should trigger an urgent alert. Failed sign-ins should also be reviewed because they may indicate password spraying, account discovery, or an administrator testing the wrong process.
If you send Entra ID sign-in logs to Microsoft Sentinel or a Log Analytics workspace, create an analytic rule similar to this:
“`kusto
let EmergencyAccounts = dynamic([
‘[email protected]’,
‘[email protected]’
]);
SigninLogs
| where UserPrincipalName in~ (EmergencyAccounts)
| project TimeGenerated, UserPrincipalName, ResultType, ResultDescription, IPAddress, AppDisplayName, ConditionalAccessStatus, UserAgent
“`
Set the rule to alert on any result. During an actual emergency, the alert becomes part of the incident timeline. Outside an emergency, it is a high-priority investigation.
You should also monitor changes to the accounts and the emergency access group:
“`kusto
let EmergencyTerms = dynamic([
‘svc-tenant-recovery-a’,
‘svc-tenant-recovery-b’,
‘Emergency Access Accounts’
]);
AuditLogs
| where tostring(TargetResources) has_any (EmergencyTerms)
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, Result
“`
This helps detect role changes, password resets, group membership changes, account disablement, and other administrative activity that could silently break your recovery plan.
## Operational controls that matter in the real world
### Store credentials with dual control
For small organizations, dual control can be simple: two executives or IT leaders each hold part of the recovery procedure, and access is logged when the sealed credential is opened. For larger organizations, use a privileged password vault with emergency access workflows and offline contingency.
The important rule is that no single employee should be able to quietly retrieve and use a break-glass credential without detection or accountability.
### Remove mailbox and collaboration exposure
Emergency accounts should not be used for email, Teams, OneDrive, Power Automate, application ownership, or device enrollment. Block or avoid unnecessary service access wherever possible. If the account does not need a mailbox, do not license one.
Also avoid using the account as the owner of production applications, Azure subscriptions, automation jobs, or certificates. Break-glass identities are for recovery, not routine ownership.
### Document exactly when use is allowed
Write a short procedure that defines acceptable use cases. Examples:
– All normal Global Administrator accounts are blocked by Conditional Access.
– Federation or identity synchronization prevents administrator sign-in.
– A Conditional Access policy change locked out administrators.
– A security incident requires tenant recovery and normal privileged workflows are unavailable.
Also document what is not acceptable:
– Convenience administration
– Bypassing a slow approval process
– Accessing mail or files
– Testing in production without an approved window
This may sound procedural rather than technical, but unclear rules are one of the main reasons emergency accounts become everyday shortcuts.
## Testing without normalizing misuse
A break-glass account that has never been tested is a theory. Test at least quarterly and after major identity changes, such as new Conditional Access baselines, federation changes, MFA migrations, device compliance rollouts, or administrator role redesigns.
A good test includes:
1. Approving a test window.
2. Retrieving credentials through the documented process.
3. Signing in from a controlled workstation and network.
4. Confirming access to the Entra admin center.
5. Verifying that monitoring alerts fired.
6. Making no unnecessary tenant changes.
7. Signing out and recording the result.
8. Rotating the password if the procedure requires it.
Do not test by casually using the account to perform real administrative work. The point is to validate the emergency path, not to make the account familiar.
## Common failure modes
### The account is synchronized from on-premises AD
If the account depends on directory synchronization, on-premises domain controllers, or federation, it may fail during exactly the kind of outage it is meant to survive. Use cloud-only accounts with the tenant’s `onmicrosoft.com` domain.
### The account is excluded from monitoring
Some teams exclude emergency accounts from SIEM rules because they generate scary alerts during tests. That defeats the control. Tune the incident workflow, not the visibility. A test should create an alert, and the alert should be closed with evidence that it was an approved exercise.
### The password expires
Password expiration policies can break emergency access quietly. Use a controlled rotation schedule instead of relying on automatic expiration. The password should change after use, after suspected exposure, and during planned credential refreshes.
### The account is disabled by cleanup automation
Automated identity governance tools sometimes disable accounts that have not signed in recently. Emergency accounts are supposed to be dormant. Exclude them from stale-account cleanup jobs, but compensate with explicit review and monitoring.
### Nobody can find the procedure
If the documentation lives only in the Microsoft 365 tenant, a tenant access incident can make it unreachable. Keep a copy in your broader business continuity documentation, protected appropriately and available during an identity outage.
## Practical summary and key takeaways
Emergency access accounts are a small part of an Entra ID tenant, but they carry enormous operational importance. When designed well, they provide a last-resort path to recover from MFA outages, federation failures, Conditional Access mistakes, and privileged workflow problems. When designed poorly, they become an unmonitored administrative backdoor.
Key takeaways:
– Maintain two cloud-only emergency accounts using the tenant’s `onmicrosoft.com` domain.
– Keep them separate from normal administrator, service, and application accounts.
– Assign enough privilege to recover the tenant, usually Global Administrator for at least one account.
– Exclude them only from Conditional Access controls that could cause lockout, and document every exclusion.
– Use long unique passwords, offline storage, dual control, and carefully chosen authentication methods.
– Alert on every successful and failed sign-in.
– Monitor changes to the accounts, group membership, roles, and passwords.
– Test quarterly and after major identity changes.
– Keep recovery documentation available outside the Microsoft 365 tenant.
For SMBs, nonprofits, and enterprise IT teams, this is one of those controls that may never be needed until it is urgently needed. Build it before the outage, test it before the incident, and monitor it as if an attacker will eventually look for it.
