## Why Microsoft 365 Break-Glass Accounts Matter
Microsoft 365 and Entra ID have become the control plane for email, files, endpoint management, SaaS access, and often line-of-business applications. That is convenient until the identity layer itself becomes the problem.
A bad Conditional Access policy, expired federation certificate, broken MFA provider, deleted admin role assignment, misconfigured authentication strength, or identity synchronization failure can lock out every administrator in the organization. At that point, the issue is no longer simply technical. It becomes an operational incident affecting business continuity, compliance, legal discovery, payroll, finance, and customer communication.
A Microsoft 365 break-glass account, also called an emergency access account, exists for one purpose: to regain administrative control when normal authentication or administration paths fail. It should not be used for daily work. It should not be convenient. It should be carefully protected, continuously monitored, and tested often enough that you know it works before an outage.
This article walks through a practical design for emergency access accounts in Microsoft 365 and Entra ID. The goal is not to create an insecure backdoor. The goal is to build a controlled recovery path that survives the failures your normal administrator accounts may not.
## The Failure Modes You Are Designing Against
Before creating accounts, it helps to understand what they must survive. A useful break-glass design accounts for several real-world scenarios.
### Conditional Access Lockout
This is one of the most common self-inflicted outages. An administrator creates or modifies a Conditional Access policy that unintentionally applies to all users, all cloud apps, or all locations. The result may be that admins are required to satisfy an impossible condition, use an authentication method they do not have, connect from a blocked network, or access from a compliant device when no compliant device is available.
### MFA or Authentication Method Failure
Phishing-resistant MFA is strongly recommended for administrators, but no authentication method is immune to operational problems. Hardware keys can be lost, certificate-based authentication can be misconfigured, phone-based methods can fail during telecom outages, and third-party MFA integrations may become unavailable.
### Federation and Hybrid Identity Problems
Organizations using AD FS or another federation provider have another dependency in the sign-in path. If federation fails, cloud authentication may fail for federated users. Similarly, a hybrid identity problem can block newly changed passwords, disabled accounts, or synced attributes from reaching Entra ID.
### Privileged Access Workflow Failure
Privileged Identity Management is excellent for reducing standing privilege, but it is still part of the normal administrative path. If role activation policies, approval workflows, MFA requirements, or licensing dependencies break, administrators may be unable to elevate.
### Security Incident Response
During a suspected tenant compromise, you may need an account that is known, documented, monitored, and capable of resetting access quickly. Emergency access accounts should not replace incident response planning, but they are an important tool when privileged access is degraded.
## Design Principles for Emergency Access Accounts
A resilient design usually follows six principles:
1. Create at least two emergency access accounts.
2. Keep them cloud-only, not synchronized from on-premises Active Directory.
3. Use the tenant’s onmicrosoft.com domain, not a federated custom domain.
4. Assign only the privileges required for recovery, typically Global Administrator.
5. Exclude them from policies that could cause lockout, while compensating with strong monitoring and storage controls.
6. Test them on a documented schedule.
The controversial part is Conditional Access exclusion. Security teams often dislike exclusions, and for good reason. Exclusions can become permanent blind spots. However, a break-glass account that is subject to the same Conditional Access rules as every other admin may fail during the exact incident it is meant to solve.
The safer approach is not to pretend the risk does not exist. Instead, isolate the account, make usage highly visible, store credentials offline, and treat any sign-in as a security event.
## Recommended Account Architecture
For most small and mid-sized organizations, two emergency accounts are sufficient. Larger enterprises may need more, especially if they operate in multiple regions or have separate administrative boundaries.
### Account 1: Maximum Independence
The first emergency account should be designed to survive the widest set of identity failures.
Recommended properties:
– Cloud-only account
– Uses the tenant.onmicrosoft.com domain
– Permanent Global Administrator assignment
– Excluded from Conditional Access policies
– Excluded from per-user MFA if still present in the tenant
– Protected by a very long randomly generated password stored offline
– No mailbox, no Teams usage, no daily sign-in
– Monitored aggressively
This account is the last-resort option. It trades normal sign-in controls for maximum survivability, so compensating controls are essential.
### Account 2: Stronger Authentication Control
The second emergency account can use stronger authentication while still being independent of normal admin workflows.
Recommended properties:
– Cloud-only account
– Uses the tenant.onmicrosoft.com domain
– Permanent Global Administrator assignment
– Excluded from broad Conditional Access policies that could cause lockout
– Protected with phishing-resistant MFA, such as FIDO2 security keys, where supported
– Credentials and recovery materials stored separately from Account 1
– Monitored aggressively
This account gives the organization a recovery option that retains stronger authentication. In many incidents, this should be tried first. The first account remains available if MFA or authentication method enforcement is part of the outage.
## Creating Emergency Access Accounts with Microsoft Graph PowerShell
You can create these accounts in the Entra admin center, but PowerShell gives you repeatability and a clear record of intent. The examples below use Microsoft Graph PowerShell.
First, connect with the required permissions:
“`powershell
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes “User.ReadWrite.All”, “RoleManagement.ReadWrite.Directory”
“`
Create two cloud-only users. Replace the tenant name and generate unique passwords using your approved password manager.
“`powershell
$tenantDomain = “contoso.onmicrosoft.com”
$breakGlass1Password = “REPLACE-WITH-LONG-RANDOM-PASSWORD-1”
$breakGlass2Password = “REPLACE-WITH-LONG-RANDOM-PASSWORD-2”
New-MgUser `
-AccountEnabled:$true `
-DisplayName “Emergency Access Account 1” `
-MailNickname “ea-admin-01” `
-UserPrincipalName “ea-admin-01@$tenantDomain” `
-PasswordProfile @{ Password = $breakGlass1Password; ForceChangePasswordNextSignIn = $false }
New-MgUser `
-AccountEnabled:$true `
-DisplayName “Emergency Access Account 2” `
-MailNickname “ea-admin-02” `
-UserPrincipalName “ea-admin-02@$tenantDomain” `
-PasswordProfile @{ Password = $breakGlass2Password; ForceChangePasswordNextSignIn = $false }
“`
Next, assign the Global Administrator role. In Microsoft Graph, the role may need to be enabled in the directory before assignment.
“`powershell
$roleDefinition = Get-MgDirectoryRoleTemplate | Where-Object DisplayName -eq “Global Administrator”
# Enable the role if it is not already enabled
$directoryRole = Get-MgDirectoryRole | Where-Object DisplayName -eq “Global Administrator”
if (-not $directoryRole) {
New-MgDirectoryRole -RoleTemplateId $roleDefinition.Id
Start-Sleep -Seconds 10
$directoryRole = Get-MgDirectoryRole | Where-Object DisplayName -eq “Global Administrator”
}
$bg1 = Get-MgUser -UserId “ea-admin-01@$tenantDomain”
$bg2 = Get-MgUser -UserId “ea-admin-02@$tenantDomain”
New-MgDirectoryRoleMemberByRef -DirectoryRoleId $directoryRole.Id -BodyParameter @{
“@odata.id” = “https://graph.microsoft.com/v1.0/directoryObjects/$($bg1.Id)”
}
New-MgDirectoryRoleMemberByRef -DirectoryRoleId $directoryRole.Id -BodyParameter @{
“@odata.id” = “https://graph.microsoft.com/v1.0/directoryObjects/$($bg2.Id)”
}
“`
After creation, verify the accounts in the Entra admin center and document their object IDs, UPNs, creation date, storage location, and testing schedule.
## Conditional Access: Exclude Carefully, Not Casually
Emergency access accounts should be excluded from policies that could prevent recovery. The most important examples are policies that:
– Require MFA for all users
– Require compliant or hybrid-joined devices
– Block unknown locations
– Require approved client apps
– Require specific authentication strengths
– Block legacy or unrecognized authentication contexts in overly broad ways
This does not mean every security control should ignore these accounts. The design should be intentional. A common pattern is:
– Exclude emergency accounts from broad enforcement policies.
– Include emergency accounts in monitoring policies where possible.
– Create alerts for any sign-in attempt, successful or failed.
– Review exclusions quarterly.
### Example Conditional Access Exclusion Standard
Your internal standard might read like this:
“`text
Emergency Access Account Conditional Access Standard
1. Emergency access accounts must be cloud-only accounts using the tenant.onmicrosoft.com domain.
2. Emergency access accounts must be excluded from Conditional Access policies that could block tenant recovery.
3. Exclusions must be limited to named emergency access accounts only, not groups used for normal administration.
4. Any sign-in attempt for an emergency access account must generate a high-priority alert.
5. Emergency access account exclusions must be reviewed quarterly and after any Conditional Access redesign.
6. Emergency access accounts must not be used for routine administration, testing outside the approved procedure, or service integrations.
“`
Avoid placing break-glass accounts in a broad group such as “CA Exclusions” that later becomes a dumping ground for executives, service accounts, and troubleshooting exceptions. That is how a recovery mechanism becomes a security weakness.
## Password and Secret Storage
The password for a break-glass account is not just another password manager entry. It is a business continuity asset.
For the maximum-independence account, use a long randomly generated password. Many organizations use 32 to 64 characters or longer, depending on their systems and password manager support. Store it in a way that survives loss of Microsoft 365 access.
Good storage options include:
– An enterprise password manager with offline emergency access procedures
– A sealed printed copy stored in a physical safe
– Split knowledge between two trusted executives or IT leaders
– A documented escrow process with the organization’s legal or compliance officer
Avoid storing the only copy in Exchange Online, SharePoint Online, OneDrive, Teams, or a password manager that depends exclusively on Entra ID single sign-on. If Microsoft 365 authentication is unavailable, those locations may also be unavailable.
### Separate Storage for Each Account
Do not store both emergency account credentials in the exact same way. For example:
– Account 1 password: sealed envelope in a fire-rated safe, logged and witnessed
– Account 2 password and FIDO2 keys: stored in separate physical locations with named custodians
The details depend on the organization, but the principle is simple: one failure, theft, or process mistake should not compromise every recovery path.
## Monitoring and Alerting: Treat Any Use as an Incident
Because emergency access accounts have powerful privileges and reduced policy enforcement, monitoring is non-negotiable. Any sign-in attempt should trigger an alert, even if it fails.
At minimum, monitor:
– Successful sign-ins
– Failed sign-ins
– Password changes
– Role assignment changes
– Authentication method changes
– Conditional Access exclusion changes
– Account disablement or deletion
### Microsoft Sentinel KQL Examples
If you send Entra ID sign-in logs to Microsoft Sentinel, you can use Kusto Query Language to detect emergency account activity.
Successful sign-ins:
“`kql
SigninLogs
| where UserPrincipalName in~ (“[email protected]”, “[email protected]”)
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location, DeviceDetail, ConditionalAccessStatus
“`
Failed sign-ins:
“`kql
SigninLogs
| where UserPrincipalName in~ (“[email protected]”, “[email protected]”)
| where ResultType != 0
| project TimeGenerated, UserPrincipalName, ResultType, ResultDescription, IPAddress, Location
“`
Changes to the accounts:
“`kql
AuditLogs
| where TargetResources has_any (“[email protected]”, “[email protected]”)
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, Result
“`
If you do not use Sentinel, configure equivalent alerts in your SIEM, managed detection platform, or Microsoft 365 security tooling. The important point is that alerts must go somewhere outside a single person’s inbox. Use your ticketing system, SOC queue, MSP escalation process, or incident response channel.
## Testing Without Creating Bad Habits
A break-glass account that has never been tested is only a theory. However, frequent casual use creates risk and weakens the control.
A reasonable testing schedule for many organizations is quarterly, plus after major identity changes. Highly regulated environments may test more often.
### Suggested Test Procedure
Use a written procedure similar to this:
“`text
Emergency Access Account Test Procedure
1. Open a change ticket for the scheduled test.
2. Notify security monitoring staff or the MSP help desk.
3. Retrieve credentials using the approved escrow process.
4. Sign in from an approved administrative workstation.
5. Confirm access to the Entra admin center.
6. Confirm the account can view Conditional Access policies and administrator role assignments.
7. Do not make production changes unless part of an approved recovery simulation.
8. Sign out immediately.
9. Confirm that alerts were generated and received.
10. Record the test result, timestamp, tester, and any remediation items.
11. Re-seal or rotate credentials according to policy.
“`
Testing should validate three things: the credential works, the account still has the required role, and monitoring detects usage. If any of those fail, the account is not ready for an actual emergency.
## Common Mistakes That Break Emergency Access
### Using a Federated Domain
If your emergency account uses a federated domain, it may depend on the same federation infrastructure that failed. Use the tenant’s onmicrosoft.com domain instead.
### Syncing from On-Premises Active Directory
A synced account depends on directory synchronization, on-premises account status, and possibly on-premises password policies. Keep emergency accounts cloud-only.
### Requiring Device Compliance
Device compliance is valuable for normal administrators, but it can block emergency recovery if Intune, device registration, or the admin workstation is unavailable.
### Giving the Account a Mailbox and Daily Duties
The more an emergency account is used, the more likely it is to be phished, cached, targeted, or included in workflows. It should not receive mail, own resources, run scripts, or act as a service account.
### Forgetting About Licensing
Global Administrator role assignment does not necessarily require the same licensing as a normal productivity user, but some security features, logs, and alerting capabilities depend on tenant licensing. Confirm that your monitoring strategy works with your actual licenses.
### Storing Recovery Instructions Only in Microsoft 365
If the runbook is stored only in SharePoint Online, and Microsoft 365 access is broken, the runbook may be inaccessible. Keep an offline copy of the emergency procedure.
## Operational Runbook for a Real Lockout
When a real administrative lockout occurs, the response should be controlled. Panic-driven changes can make the outage worse.
A practical runbook should include:
1. Declare an identity incident or high-priority service incident.
2. Assign an incident lead.
3. Retrieve the emergency account credentials using the approved process.
4. Sign in from a known, secured administrative device and network where possible.
5. Identify the likely lockout cause: Conditional Access, MFA, federation, PIM, synchronization, or role assignment.
6. Make the smallest reversible change necessary to restore normal admin access.
7. Validate that at least two normal admin accounts can sign in.
8. Sign out of the emergency account.
9. Rotate credentials if policy requires or if exposure is suspected.
10. Perform post-incident review and update controls.
For example, if a Conditional Access policy is blocking all administrators, do not disable every policy in the tenant unless absolutely necessary. Start by placing the affected admin group in a temporary exclusion, disabling the newly changed policy, or reverting the specific condition that caused the outage.
## Governance: Who Owns the Accounts?
Emergency access is both a technical and governance issue. IT may create the accounts, but business leadership should understand why they exist and who can authorize their use.
Document the following:
– Account names and object IDs
– Purpose and scope
– Assigned roles
– Credential storage locations
– Authorized custodians
– Approval process for use
– Monitoring and alert recipients
– Testing frequency
– Rotation requirements
– Incident response steps
For outsourced IT and MSP-managed environments, this is especially important. The client should know whether the MSP holds emergency credentials, whether the client holds a sealed copy, and what happens if either party is unavailable. Ambiguity during a lockout wastes time.
## Security Trade-Offs and Practical Compensating Controls
There is no perfect break-glass design. If the account is subject to every normal control, it may fail during an emergency. If it is excluded from too much, it becomes a high-value target.
Compensating controls reduce that risk:
– Use unique, extremely long passwords.
– Store credentials offline or in an escrow process independent of Entra ID.
– Prevent routine use.
– Monitor all sign-ins and account changes.
– Review Conditional Access exclusions regularly.
– Test access on a schedule.
– Keep recovery documentation outside Microsoft 365.
– Rotate credentials after use or suspected exposure.
For many organizations, the greatest risk is not that a well-designed emergency account exists. The greater risk is discovering during an outage that no reliable recovery path exists at all.
## Practical Summary and Key Takeaways
Microsoft 365 emergency access accounts are not optional hygiene for mature environments. They are a core business continuity control for any organization that depends on Entra ID, Microsoft 365, Intune, Azure, or SaaS applications tied to Microsoft identity.
Key takeaways:
– Create at least two cloud-only emergency access accounts.
– Use the tenant.onmicrosoft.com domain to avoid federation dependencies.
– Exclude emergency accounts from Conditional Access policies that could cause tenant-wide lockout.
– Use strong compensating controls: offline credential storage, strict governance, and high-priority monitoring.
– Treat any sign-in attempt as a security event.
– Test quarterly and after major identity changes.
– Store the runbook somewhere accessible when Microsoft 365 is unavailable.
A good break-glass design is quiet most of the year. It does not help with daily administration, and it should not make anyone’s work more convenient. But when identity controls fail, it can be the difference between a short, controlled recovery and a prolonged business outage.
