Entra ID Break Glass Account: Setup, Monitoring & Zero Trust Best Practices

The Lockout That Shouldn't Have Happened

The call came on a Friday afternoon. A customer's IT team had just rolled out a new Conditional Access policy requiring compliant devices across all users, including admins. The policy was intended to apply only to regular users, but the scope was set to "All users" — including every Global Admin in the tenant. Within minutes of going live, every admin in the organization was locked out of the Azure portal, the Microsoft 365 admin center, and Entra ID itself.

Their Global Admins were authenticating from personal laptops that weren't enrolled in Intune. The compliant device requirement blocked them all simultaneously. They had no break glass accounts. They had to open a Microsoft support case and wait several hours for Microsoft to intervene — during which time they had zero administrative access to a tenant running production workloads for hundreds of employees.

This is not a hypothetical. This exact sequence of events happens regularly. Break glass accounts exist specifically to prevent it.

What a Break Glass Account Actually Is

A break glass account (also called an emergency access account) is a highly privileged cloud-only account that is intentionally excluded from all Conditional Access policies. Its sole purpose is to restore administrative access to your Entra ID tenant when every normal administrative path has been blocked — whether by a misconfigured CA policy, an identity provider outage, MFA service disruption, or an expired certificate on your federation server.

The term comes from the old concept of a fire extinguisher behind glass: you break the glass in an emergency. You don't use it for everyday tasks.

Break glass accounts are not a workaround or a security compromise. They are an explicit requirement in Microsoft's Zero Trust guidance and the NIST identity framework. Zero Trust is built on the principle of resilience — the ability to maintain operations even when individual controls fail. A tenant with no break glass account is a single misconfiguration away from a complete administrative outage.

How Many Break Glass Accounts Do You Need?

You need exactly two.

One is not enough because the break glass account itself might have an issue — a corrupted credential record, a sync problem, or simply a typed-wrong password under pressure at 2 AM during an incident. Two accounts provide redundancy without creating an unmanageable sprawl of emergency credentials.

More than two starts to create coordination and auditing problems. You need to test these accounts periodically (more on that below), and every additional account is another set of credentials to manage securely. Two is the right number.

The two accounts should be completely independent: different passwords, stored in different physical locations, and — if your organization has multiple people who hold the physical credentials — held by different people.

Creating Break Glass Accounts Correctly

Naming Convention

There's a real tension here. You want the account to be easily identifiable to administrators who are working through an incident, but you don't want the account name to be obvious to an attacker who has gained read access to your user list.

Don't name them breakglass@yourdomain.com or emergency-admin@yourdomain.com. These names are the first thing an attacker checks when they get a foothold in your tenant.

A reasonable approach is a name that looks like a service account to anyone browsing the user list but is documented internally with its true purpose. Something like svc-iam-recovery01@yourdomain.com — it looks like an IAM service account. Your internal runbook documents exactly what these accounts are and where their credentials are stored.

Whatever naming you choose, document it clearly in an offline runbook and make sure the right people know where that runbook is.

Account Configuration

Create these accounts through the Entra ID portal (Entra ID → Users → New user → Create new user). The key settings:

Cloud-only account — Do not sync these accounts from on-premises Active Directory. If your AD Connect sync breaks, your federated accounts become unusable. Cloud-only accounts authenticate directly against Entra ID regardless of what happens on-prem. In the user creation screen, the UPN should use your .onmicrosoft.com domain, not your custom domain — this ensures the account works even if there's a DNS or federation issue with your custom domain.

No MFA requirement — This is the counterintuitive part. Break glass accounts exist for scenarios where MFA infrastructure may be unavailable (Authenticator service outage, lost device, expired SSPR configuration). Requiring MFA on the break glass account defeats its purpose. The security model here shifts entirely to the strength of the password and the physical security of where it's stored.

64+ character password — Since MFA is not required, the password must be exceptionally strong. Generate a random 64-character password using a cryptographically secure generator. This password should be written on paper and stored in two separate physical locations — a fireproof safe in your primary office and an offsite location. Do not store it in a password manager, key vault, or any digital system. The break glass account is your escape hatch when digital systems fail.

Here's how this looks when creating the account via PowerShell (Microsoft Graph module):

# Install if needed: Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "User.ReadWrite.All", "Directory.ReadWrite.All"

# Generate a strong random password (64 characters)
$chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*'
$password = -join ((1..64) | ForEach-Object { $chars[(Get-Random -Maximum $chars.Length)] })

$passwordProfile = @{
  password                      = $password
  forceChangePasswordNextSignIn = $false
}

New-MgUser -DisplayName "SVC IAM Recovery 01" `
  -UserPrincipalName "svc-iam-recovery01@yourtenant.onmicrosoft.com" `
  -AccountEnabled `
  -PasswordProfile $passwordProfile `
  -MailNickname "svc-iam-recovery01"

Write-Host "Password: $password" -ForegroundColor Yellow
Write-Host "WRITE THIS DOWN IMMEDIATELY AND STORE IN SECURE PHYSICAL LOCATION"

Assign Global Administrator — In the Entra ID portal, go to the newly created user's profile, select Assigned roles, and add Global Administrator. This is one of the rare cases where Global Admin is the correct role — break glass accounts need the ability to modify Conditional Access policies and restore access in any failure scenario.

Verify the account — Before storing the credentials and closing the laptop, sign in once with the new account to confirm it works. You do not want to discover the account has a problem during an actual emergency.

Excluding Break Glass From All Conditional Access Policies

This is where most teams make mistakes. Excluding break glass accounts from Conditional Access is not just about the policies that require MFA or compliant devices — it means all Conditional Access policies, without exception.

Think about what policies you might have:

• Require MFA for all users
• Block legacy authentication protocols
• Require compliant or hybrid-joined device
• Block sign-ins from outside approved countries
• Require specific authentication strengths
• Block access from risky sign-in locations

If your break glass account is caught by any of these during an incident, it won't work. Include the break glass accounts explicitly in the exclusions list of every single Conditional Access policy.

In the Entra ID portal, when editing a CA policy under Users → Exclude, add both break glass accounts directly (not via group membership — group membership changes can accidentally remove the exclusion).

You should also create a named location or a dedicated group for break glass accounts and use that consistently, but direct user exclusion is the safest approach because it's the least likely to be accidentally removed.

After updating a CA policy, always test immediately with a non-break-glass account to confirm the policy behaves as expected before declaring the work done.

Checking Your Coverage With PowerShell

This script lists all CA policies that do not exclude your break glass accounts:

Connect-MgGraph -Scopes "Policy.Read.All"

$breakGlassIds = @(
  "00000000-0000-0000-0000-000000000001",  # Object ID of break glass 1
  "00000000-0000-0000-0000-000000000002"   # Object ID of break glass 2
)

$policies = Get-MgIdentityConditionalAccessPolicy -All

foreach ($policy in $policies) {
  $excludedUsers = $policy.Conditions.Users.ExcludeUsers
  $covered = $breakGlassIds | Where-Object { $_ -in $excludedUsers }

  if ($covered.Count -lt 2) {
    Write-Warning "Policy '$($policy.DisplayName)' does not exclude all break glass accounts"
    Write-Host "  Excluded users: $($excludedUsers -join ', ')"
  }
}

Run this script as part of your quarterly identity security review, and run it every time a new CA policy is created.

Monitoring: Alerting When Break Glass Signs In

Any use of a break glass account should trigger an immediate alert to your security team. These accounts are only used during emergencies, so any sign-in is either a genuine incident or someone using the break glass account inappropriately for routine tasks (which is itself a problem worth investigating).

Log Analytics / Azure Monitor Alert

First, make sure sign-in logs are flowing to Log Analytics. If you're already sending Entra ID diagnostic logs to a Log Analytics workspace (which you should be — see the section on auditing in our [Microsoft Entra ID PIM guide](/blog/microsoft-entra-id-pim-privileged-identity-management-guide)), you already have the data.

The KQL query to detect break glass sign-ins:

SigninLogs
| where UserPrincipalName in (
    "svc-iam-recovery01@yourtenant.onmicrosoft.com",
    "svc-iam-recovery02@yourtenant.onmicrosoft.com"
  )
| project
    TimeGenerated,
    UserPrincipalName,
    AppDisplayName,
    IPAddress,
    LocationDetails,
    Status,
    ConditionalAccessStatus,
    AuthenticationRequirement
| order by TimeGenerated desc

To turn this into an alert: in Azure Monitor, create a new Log search alert rule pointing to your Log Analytics workspace. Set the query to the one above. Set Measurement to count of rows, Alert logic to "Greater than 0", and Frequency to 5 minutes. Connect it to an Action Group that sends an email and a Teams/Slack webhook to your security team immediately.

Microsoft Sentinel Alert Rule

If you're running Microsoft Sentinel, add a scheduled analytics rule:

let breakGlassAccounts = dynamic([
  "svc-iam-recovery01@yourtenant.onmicrosoft.com",
  "svc-iam-recovery02@yourtenant.onmicrosoft.com"
]);
SigninLogs
| where UserPrincipalName in (breakGlassAccounts)
| where ResultType == "0"  // Successful sign-in only
| extend
    AccountName = tostring(split(UserPrincipalName, "@")[0]),
    AccountDomain = tostring(split(UserPrincipalName, "@")[1])
| project
    TimeGenerated,
    UserPrincipalName,
    AccountName,
    AccountDomain,
    IPAddress,
    AppDisplayName,
    LocationDetails,
    ConditionalAccessStatus

Set severity to High and map the entities to Account and IP. This will create a Sentinel incident every time a break glass sign-in succeeds, which your SOC can triage.

Also create an alert for *failed* sign-in attempts on break glass accounts — multiple failures could indicate someone is probing the accounts.

Periodic Testing Without Triggering False Alarms

You need to verify that break glass accounts work before you need them in a crisis. The recommended cadence is quarterly testing.

The challenge is that testing will trigger your monitoring alerts — and that's actually fine. Testing should trigger the alerts. What you need is a process so your team knows the difference between a test and a real incident.

Before each test:

1. Notify your security team that a break glass test is scheduled (time and who will perform it).
2. Document the planned test window in your incident management system.
3. Retrieve the physical credentials from their secure storage location (do not type from memory).

During the test:

• Sign in to the Azure portal with the break glass account.
• Verify you can access Entra ID and Conditional Access policies.
• Verify the Global Admin role is still active.
• Do not use the account for any actual administrative changes.
• Sign out immediately after verification.

After the test:

• Confirm the alert fired as expected.
• Log the test result (success/failure, any issues noted).
• Return the credentials to secure storage.
• Update your runbook with the test date.

If the test fails — the account doesn't work, the credentials are wrong, the role was removed — fix it immediately. A break glass account that doesn't work is as dangerous as no break glass account at all.

Common Mistakes

Storing credentials only digitally — A password manager, Azure Key Vault, or secrets management system can all be unavailable during the exact type of incident where you need break glass. Physical paper in a secure location is the correct storage medium for these credentials.

Not excluding from all CA policies — Teams often remember to exclude break glass from their "Require MFA" policy but forget about country-based blocking, device compliance policies, or risk-based policies. Every policy must explicitly exclude break glass accounts.

Using break glass for routine tasks — The moment an engineer uses a break glass account because they forgot their own MFA device or need to do a quick admin task, you've introduced monitoring noise and potentially exposed the credentials to compromise. These accounts exist for one purpose only.

Single break glass account — One account provides no redundancy. If that single account has a corrupted credential record, a phone-based MFA somehow attached to it, or simply a wrong password written down, you have no fallback. Always two.

Forgetting to test — Break glass accounts that haven't been tested in a year may have had their Global Admin role removed during a permissions cleanup, or the password complexity policy may have forced an expiry. Test quarterly. It takes ten minutes.

Not monitoring — A break glass account being used without anyone knowing is a significant security event. Without monitoring, you might not notice that someone has been logging in with those credentials for weeks.

Break Glass and Zero Trust Are Aligned

A common misconception is that break glass accounts violate Zero Trust because they bypass controls like MFA and device compliance. They don't — they're designed into the model.

Zero Trust is not about applying maximum friction to every access path regardless of context. It's about verifying every access decision appropriately and building resilient systems. A Zero Trust architecture that can be permanently disabled by a single misconfiguration is not resilient — it's fragile.

Break glass accounts represent a conscious, documented, monitored, and tested exception. They exist within a control framework: the credentials are physically protected, every use is immediately alerted on, periodic testing confirms they work, and they're excluded from policies by explicit decision rather than oversight.

The [Microsoft Entra ID Conditional Access setup guide](/blog/microsoft-entra-id-conditional-access-setup) covers the policy design that break glass accounts need to be excluded from, and the [PIM guide](/blog/microsoft-entra-id-pim-privileged-identity-management-guide) covers how to use just-in-time privileged access to minimize how often any standing privileged account — including break glass — is active.

Build the break glass accounts. Monitor them. Test them. The Friday afternoon lockout call is not a hypothetical — it's a scheduled event for any team that skips this step.