Why Break-Glass Accounts Exist
Break-glass accounts (also called emergency access accounts) exist for one scenario: your primary authentication infrastructure is unavailable, and you need to regain administrative access to your Entra ID tenant. This includes situations where:
- Your MFA provider (Microsoft Authenticator, FIDO2 hardware keys) experiences a global outage
- Conditional Access policies are misconfigured and lock out all administrators
- Your sole Global Administrator leaves the organisation and their account is disabled
- A federated identity provider (AD FS, Okta, Ping) is unavailable and all admin accounts authenticate through federation
- PIM approval workflows are broken and no administrator can activate their role
Without a break-glass account, you are calling Microsoft Support and proving tenant ownership via DNS TXT record verification, a process that takes days, not hours. During those days, you have zero administrative control over your environment.
Design Principles
Account Architecture
Create exactly two break-glass accounts. One is not enough (single point of failure). Three or more increases your attack surface unnecessarily.
Naming convention: Do not name them "BreakGlass1" or "EmergencyAdmin." Attackers specifically scan for these patterns. Use innocuous names that do not signal elevated privilege - something like a generic service account name that blends with your naming convention.
Account properties:
Account 1:
- UPN: [non-obvious name]@yourtenant.onmicrosoft.com (NOT your vanity domain)
- Cloud-only: Yes (must not depend on AD Connect, federation, or pass-through auth)
- Role: Permanent Global Administrator
- MFA: FIDO2 hardware key stored in physical safe
- Password: 128-character randomly generated, stored separately from FIDO2 key
Account 2:
- UPN: [different non-obvious name]@yourtenant.onmicrosoft.com
- Cloud-only: Yes
- Role: Permanent Global Administrator
- MFA: Different FIDO2 key from a different manufacturer, stored in different physical location
- Password: Different 128-character randomly generated password, stored separately
Critical Configuration Requirements
1. Cloud-only identity on the .onmicrosoft.com domain. The account must use the default tenant domain, not a custom domain. If your custom domain's DNS is compromised or your domain expires, federation-dependent accounts become inaccessible. The .onmicrosoft.com domain is managed by Microsoft and is always available.
2. Excluded from ALL Conditional Access policies. Navigate to every Conditional Access policy and explicitly add both break-glass accounts to the Exclude section. Do not rely on a group exclusion - if the group is accidentally modified, you lose your emergency path.
Verify exclusions with PowerShell:
$breakGlassIds = @("account1-object-id", "account2-object-id")
$policies = Get-MgIdentityConditionalAccessPolicy -All
foreach ($policy in $policies) {
$excluded = $policy.Conditions.Users.ExcludeUsers
foreach ($bgId in $breakGlassIds) {
if ($bgId -notin $excluded) {
Write-Warning "Break-glass $bgId NOT excluded from policy: $($policy.DisplayName)"
}
}
}
Run this script weekly via Azure Automation.
3. Excluded from PIM. Break-glass accounts must have permanent Global Admin assignment, not eligible assignment. PIM activation requires MFA and in a break-glass scenario, MFA infrastructure may be unavailable.
4. Password must never expire. Set the password expiration policy to "never" for these accounts. A password that silently expires defeats the purpose of emergency access.
Update-MgUser -UserId "break-glass-object-id" -PasswordPolicies "DisablePasswordExpiration"
5. No phone number, no email, no SSPR. Do not associate any self-service password reset methods with break-glass accounts. These methods can be socially engineered. Password reset for break-glass accounts should require physical access to the stored credentials.
Physical Storage Patterns
Pattern 1: Dual-Safe Model (Recommended for most organisations)
- Safe A (Location 1 - e.g., Head Office server room): Contains Account 1 password (printed, sealed envelope) + Account 2 FIDO2 key
- Safe B (Location 2 - e.g., DR site or Managing Director's home safe): Contains Account 2 password (printed, sealed envelope) + Account 1 FIDO2 key
This means gaining full access to either account requires accessing two physical locations. A burglar at one location gets either a password without the FIDO2 key or a FIDO2 key without the password.
Pattern 2: Shamir's Secret Sharing (For high-security environments)
Split each password into three shares using Shamir's Secret Sharing Scheme. Distribute shares to three senior leaders (CEO, CTO, CISO). Any two of three shares can reconstruct the password. This prevents any single individual from accessing the break-glass account unilaterally.
Envelope Tamper Evidence
Use tamper-evident envelopes (security bags with sequential serial numbers). Record the serial number in your ISMS documentation. During quarterly testing (see below), verify the serial number matches before opening. If it doesn't match, treat it as a security incident.
Monitoring with Microsoft Sentinel
Break-glass accounts should never be used under normal operations. Any sign-in - successful or failed - is a critical security event that demands immediate investigation.
Analytics Rule: Break-Glass Sign-In Detection
let breakGlassUPNs = dynamic(["bg1@tenant.onmicrosoft.com", "bg2@tenant.onmicrosoft.com"]);
SigninLogs
| where UserPrincipalName in (breakGlassUPNs)
| project TimeGenerated, UserPrincipalName, ResultType, ResultDescription,
IPAddress, Location, AppDisplayName, DeviceDetail,
ConditionalAccessStatus, RiskLevelDuringSignIn
| extend AlertSeverity = iff(ResultType == 0, "High", "Medium")
Set this rule to generate a High severity incident on successful sign-in and Medium on failed sign-in. Configure automated response:
- Immediate: Send SMS and email to CISO and Security Operations lead
- Within 5 minutes: Automated playbook captures full sign-in context (IP geolocation, device details, what actions were taken)
- Within 15 minutes: SOC analyst must acknowledge and document whether this was an authorised use
Analytics Rule: Break-Glass Policy Exclusion Drift
AuditLogs
| where OperationName == "Update conditional access policy"
| mv-expand TargetResources
| extend PolicyName = tostring(TargetResources.displayName)
| extend ModifiedProperties = TargetResources.modifiedProperties
| mv-expand ModifiedProperties
| where ModifiedProperties.displayName == "ConditionalAccessPolicy"
| extend NewValue = tostring(ModifiedProperties.newValue)
| where NewValue !contains "bg1-object-id" or NewValue !contains "bg2-object-id"
This detects when a Conditional Access policy is modified in a way that might remove break-glass exclusions.
Quarterly Testing Procedure
Break-glass accounts must be tested regularly. An untested emergency procedure is not a procedure, it is a hope.
Quarterly test protocol:
- Two authorised personnel (CISO + IT Director) attend together
- Retrieve credentials from physical storage
- Verify tamper-evident seal serial numbers match records
- Open sealed envelope, sign into Entra ID from a clean, isolated device
- Verify Global Admin access is functional - navigate to Users, Conditional Access, and PIM
- Sign out and revoke all sessions:
Revoke-MgUserSignInSession -UserId [break-glass-id] - Generate a new password, print it, seal in a new tamper-evident envelope
- Record new envelope serial number in ISMS documentation
- Return credentials to separate physical safes
- Verify Sentinel alert fired for the sign-in and was correctly triaged
Document each test with date, participants, outcome, and new envelope serial numbers. Your ISO 27001 auditor will ask for this evidence.
Integration with Incident Response
Your incident response playbook must include explicit steps for when break-glass accounts should be used. Define the authorisation chain: who can approve use, under what circumstances, and what documentation is required. In a standard template:
- Authorisation: Requires verbal approval from two of: CISO, CTO, CEO
- Circumstances: Only when all standard administrative access paths are confirmed unavailable
- Documentation: Incident ticket created within 30 minutes of use, post-incident review within 48 hours
Break-glass accounts are the insurance policy you hope never to claim. But like insurance, they are worthless if the policy has lapsed, the premium is unpaid, or the documentation is missing.