Break-Glass Access: When Your IdP Goes Dark

When your primary identity provider suffers a total outage — a misconfigured Conditional Access policy, an expired federation certificate, or an upstream Entra ID/Okta service disruption — every downstream system that trusts it becomes unreachable simultaneously. This is the architectural blind spot most zero-trust deployments never test: break-glass access is the only mechanism left standing, and if it was designed as an afterthought, it is either unusable in a genuine emergency or it is the softest target in your entire estate. This article covers the engineering required to make break-glass access survivable, auditable, and resistant to the exact failure conditions it exists to solve.

#Problem Statement: The Zero-Trust Single Point of Failure

Modern enterprise IT has correctly converged on centralised identity — a single IdP issuing tokens, enforcing Conditional Access, and gating every SaaS, VPN, and privileged workload. The trade-off is rarely quantified: when that IdP’s control plane degrades, every conditional policy, every MFA challenge, and every federated login path degrades with it. Administrators locked out of the Entra ID admin portal cannot fix Entra ID from inside Entra ID.

Break-glass access exists to break this circular dependency. The problem is that most organisations treat it as a compliance checkbox — two accounts, excluded from Conditional Access, password written on a sticky note in a physical safe — rather than as a piece of architectural patterns requiring the same rigour as any other high-availability control plane. That gap produces two failure outcomes: either the break-glass path is too weak (attackers find and exploit an unmonitored, MFA-exempt account), or it is too brittle (the credential vault holding the recovery password is itself gated behind the SSO that just failed).

#Architectural Breakdown

A defensible break-glass access design separates into three independent layers, each of which must survive the failure of the layer above it: the credential layer, the authorisation layer, and the detection layer. If any layer inherits a dependency on the primary IdP, the design has failed its own premise.

#Credential Layer: Out-of-Band Storage

Break-glass credentials must never live in a system that authenticates against the primary IdP. This rules out password managers using SSO login, and it rules out storing the credential in a ticketing system gated behind Okta. The credential layer should use one of two patterns:

• Shamir’s Secret Sharing via a self-hosted HashiCorp Vault instance, unsealed by a quorum of key holders, running on infrastructure with its own independent authentication path (local accounts, hardware tokens, no federation).
• Physical custody — printed, sealed credentials in a fireproof safe with dual custody and tamper-evident bags, used only for the smallest organisations where a Vault cluster is disproportionate overhead.

#Authorisation Layer: Explicit Conditional Access Exclusion

Break-glass accounts must be explicitly excluded from every Conditional Access policy that could plausibly fail closed — MFA enforcement, device compliance checks, sign-in risk evaluation, and location-based restrictions. This sounds like it weakens the security posture, and it does; that weakening is the point. Break-glass access is a controlled trade-off between availability and confidentiality, and the compensating control is not prevention — it is detection and time-boxing.

#Detection Layer: Independent Alerting Path

Alerting on break-glass account usage cannot route exclusively through a SIEM correlation rule that ingests sign-in logs from the same IdP that just failed. You need a secondary telemetry path — a lightweight webhook or syslog forward from the identity backend directly to an on-call paging system, bypassing the primary SIEM pipeline if that pipeline itself depends on IdP-gated dashboards.

#Implementation Logic

The following sequence reflects a production-grade break-glass access rollout for a hybrid Entra ID / on-prem AD estate, though the logic generalises to Okta, Ping, or any SAML/OIDC-based IdP.

#Step 1 — Provision Isolated Accounts

Create two (never one — you need redundancy against a single credential failing during the incident) cloud-only accounts with no on-prem sync, no license assignment beyond the minimum required for admin portal access, and randomly generated 32-character passwords with no expiry policy tied to standard rotation automation.

1# Create break-glass account (cloud-only, no hybrid sync)
2Connect-MgGraph -Scopes "User.ReadWrite.All","RoleManagement.ReadWrite.Directory"
3
4$password = [System.Web.Security.Membership]::GeneratePassword(32, 8)
5$passwordProfile = @{
6    Password = $password
7    ForceChangePasswordNextSignIn = $false
8}
9
10New-MgUser -DisplayName "BreakGlass-Emergency-01" `
11    -UserPrincipalName "bg-emergency-01@tenant.onmicrosoft.com" `
12    -AccountEnabled:$true `
13    -PasswordProfile $passwordProfile `
14    -MailNickname "bgemergency01"
15
16# Assign Global Administrator directly, no PIM eligibility wrapper
17New-MgRoleManagementDirectoryRoleAssignment -PrincipalId $userId `
18    -RoleDefinitionId "62e90394-69f5-4237-9190-012177145e10" `
19    -DirectoryScopeId "/"

#Step 2 — Exclude from Conditional Access

Every existing and future Conditional Access policy must reference an exclusion group containing exclusively these two accounts. Do not exclude by username — group-based exclusion prevents drift when policies are cloned.

1{
2  "displayName": "CA001-Require-MFA-AllUsers",
3  "state": "enabled",
4  "conditions": {
5    "users": {
6      "includeUsers": ["All"],
7      "excludeGroups": ["sg-breakglass-exclusion-9f21"]
8    },
9    "applications": {
10      "includeApplications": ["All"]
11    }
12  },
13  "grantControls": {
14    "operator": "OR",
15    "builtInControls": ["mfa"]
16  }
17}

#Step 3 — Seal Credentials with Quorum Unlock

Store both passwords inside a Vault instance configured with a five-key Shamir split, requiring three key holders to reconstruct the unseal key. This ensures no single administrator — including one who may have been socially engineered — can unilaterally retrieve break-glass access.

1vault operator init -key-shares=5 -key-threshold=3
2
3# Store the resulting root token and unseal keys with separate
4# custodians: security lead, IT director, on-call SRE, CISO, auditor.
5
6vault kv put secret/breakglass/account-01 
7    username="bg-emergency-01@tenant.onmicrosoft.com" 
8    password="@REDACTED_32CHAR_STRING@" 
9    rotation_due="2025-04-01"

#Step 4 — Independent Detection Path

Configure sign-in log streaming to trigger a direct webhook, not solely a SIEM dashboard tile.

1alert_rule:
2  name: breakglass-signin-detected
3  source: entra-id-signin-logs
4  condition:
5    userPrincipalName: ["bg-emergency-01@tenant.onmicrosoft.com", "bg-emergency-02@tenant.onmicrosoft.com"]
6  actions:
7    - webhook: https://oncall.internal/pagerduty/breakglass-trigger
8    - webhook: https://oncall.internal/slack/security-channel
9  severity: critical
10  suppress_deduplication: true

#Failure Modes and Edge Cases

Break-glass access designs fail in predictable, recurring patterns. The most common is credential staleness — the accounts are provisioned once, during an audit remediation sprint, and never touched again. Eighteen months later the password reconstruction ceremony fails because two of the three quorum custodians have left the organisation and their key shares were never re-issued. Rotation cadence for break-glass credentials should be quarterly at minimum, with each rotation logged and quorum membership re-validated.

A second failure mode is alert fatigue from drills. Security teams correctly test break-glass access quarterly, but if the detection layer cannot distinguish a scheduled drill from a genuine incident, on-call staff begin ignoring the alert entirely — precisely when a real compromise occurs. Tag drill logins with a pre-shared ticket reference in the sign-in metadata where possible, and route drills through a separate, lower-severity notification channel.

A third, more severe edge case is dual compromise: an attacker who has already achieved persistence inside the tenant discovers the break-glass exclusion group via directory enumeration and targets both accounts directly, since they are known to bypass MFA. This is why break-glass access should never rely on password-only authentication as its sole control — FIDO2 hardware keys registered to the account, stored alongside the sealed credential, close this gap without reintroducing an MFA dependency on the failed IdP’s push-notification infrastructure.

Finally, consider the case where the outage is not the IdP itself but the network path to it — a misconfigured firewall rule or BGP withdrawal. Break-glass accounts hosted entirely in the same cloud tenant as the failed service will not help. Maintain at least one recovery path — console access, out-of-band VPN, or a secondary jump host — that does not transit the same network segment as production identity traffic. Microsoft’s own emergency access guidance covers the account-level controls in detail; see the Entra ID emergency access documentation for the platform-specific configuration baseline.

#Designing Break-Glass Access for Quorum and Blast Radius

The core design tension in break-glass access is that every control which reduces blast radius (smaller quorum, tighter scoping, shorter credential lifetime) also increases the operational friction of using it during a genuine 3am outage. Getting this balance wrong in either direction defeats the purpose — over-engineer it and nobody can execute the recovery fast enough; under-engineer it and you have created a standing exception to zero-trust that attackers will eventually find.

#Scaling and Security Trade-offs

• Quorum size: A 3-of-5 Shamir split balances resilience against key-holder attrition; 2-of-3 is faster to execute but tolerates only a single custodian being unavailable during an incident.
• Account count: Two break-glass accounts is the accepted minimum; scaling beyond three increases attack surface without materially improving availability, since only one is typically needed per incident.
• Rotation cadence: Quarterly rotation limits the exposure window of a leaked credential but increases the operational overhead of re-sealing Vault shares each cycle — annual rotation is common but leaves a longer compromise window if a leak goes undetected.
• MFA exemption scope: Exempting break-glass accounts from all Conditional Access is standard practice, but exempting them from sign-in risk detection entirely (rather than just blocking policies) removes a detection signal you may want to keep active in read-only mode.
• Detection latency: A direct webhook to on-call paging achieves sub-minute detection; relying solely on batch SIEM ingestion can introduce 15–30 minute detection lag, which is unacceptable for an account with unconditional Global Administrator rights.
• Physical vs digital custody: Sealed paper credentials in a safe eliminate dependency on any running infrastructure but do not scale past a handful of custodians across distributed offices; a self-hosted Vault cluster scales geographically but reintroduces an infrastructure dependency that must itself be monitored for availability.

Break-glass access is ultimately a discipline of controlled exceptions, not a static artefact you provision once and forget. Treat the quorum ceremony, the rotation schedule, and the detection webhook with the same change-management rigour applied to production identity infrastructure, and the emergency path will still be there the one time you actually need it.