14.3 Break-Glass (Emergency Access) Accounts
Key Takeaways
- Break-glass (emergency access) accounts are highly privileged accounts reserved for tenant recovery when normal admin paths fail—MFA outages, misconfigured Conditional Access, IdP issues, or PIM approver unavailability.
- Microsoft guidance calls for at least two cloud-only emergency accounts that do not depend on a single on-premises sync path, hybrid dependency, or one person’s personal MFA device.
- Emergency accounts are typically excluded from Conditional Access policies that could lock out all other admins, but they must use strong credentials such as long complex passwords and/or phishing-resistant hardware keys and must be continuously monitored and alerted.
- Using permanent Global Administrator accounts for daily work without a controlled emergency design is an anti-pattern; conversely, excluding weak unmonitored accounts from all CA ‘so we never lock out’ is also an anti-pattern.
- Documented procedures, dual control over secret storage, periodic validation that accounts still work, and immediate investigation of any sign-in are mandatory operational controls for break-glass.
Why emergency access exists alongside PIM
Sections 14.1 and 14.2 pushed hard toward just-in-time privilege, approval, and Conditional Access for admins. Those controls improve security—and they introduce a new failure mode: every normal admin path can fail at once. A bad Conditional Access change can block all interactive admins; an MFA provider outage can stop activations; the only PIM approver can be unreachable during an incident. Break-glass (also called emergency access) accounts are the pre-staged recovery keys for the tenant.
What break-glass accounts are (and are not)
| Break-glass is | Break-glass is not |
|---|---|
| Emergency Global Administrator (or equivalently powerful) cloud accounts for tenant recovery | Daily driver accounts for helpdesk or cloud ops |
| Rarely used, highly monitored, procedure-bound | “Extra Global Admins so tickets are faster” |
| Excluded from lockout-prone Conditional Access policies by design | Excluded from all monitoring, logging, and credential hygiene |
| Protected with strong credentials / hardware keys | Shared SMS MFA on a single personal phone only |
| At least two accounts for redundancy | A single account that is also someone’s everyday UPN |
If an engineer uses a break-glass account to reset ordinary user passwords every afternoon, it is not a break-glass account anymore—it is an unmonitored standing super-admin.
Microsoft guidance pattern (exam checklist)
Microsoft’s emergency access guidance is a frequent SC-300 design checklist. Memorize the spirit of these requirements:
1. At least two emergency access accounts
| Reason for two+ | Failure mode avoided |
|---|---|
| Redundancy | One account’s password/hardware key is unavailable |
| Dual control potential | Two people / two sealed processes for retrieval |
| Avoid single geo/person dependency | One admin on leave during a CA outage |
2. Cloud-only accounts
Emergency accounts should be cloud-only Microsoft Entra accounts—not synchronized from on-premises Active Directory—so they still work if:
- Entra Connect / Cloud Sync fails.
- On-premises AD is down or compromised.
- Federation (AD FS) or hybrid auth paths break.
- You must remediate hybrid identity configuration itself.
Exam trap: “Break-glass = Domain Admin synced to the cloud as Global Admin.” That still depends on hybrid health and may be wrong for pure cloud recovery.
3. Exclude from Conditional Access that can lock the tenant
Emergency accounts are typically excluded from Conditional Access policies that could prevent sign-in when policies are misconfigured—especially broad policies targeting All users + All cloud apps with device compliance, network restrictions, or other controls that might fail closed.
| Exclusion guidance | Detail |
|---|---|
| Do exclude from policies that could block all interactive admin recovery | Avoid total tenant lockout |
| Do not treat exclusion as “no security” | Compensate with credential strength, monitoring, rarity of use |
| Document every exclusion | Auditors and future admins must know why |
| Prefer excluding only emergency accounts, not large admin groups forever | Keep normal admins under CA + PIM |
Related: exclude break-glass from PIM approval dead-ends in the sense that emergency accounts are often active permanent Global Administrator (by design) so recovery does not depend on PIM activation and approvers being available. That is the intentional exception to the “no permanent GA” rule—few, cloud-only, monitored, unused daily.
4. Strong credentials and phishing-resistant factors
| Control | Guidance |
|---|---|
| Password | Extremely long, randomly generated, stored in secure offline/break-glass vault procedures |
| Passwordless / hardware keys | FIDO2 security keys kept in secure locations (separate keys, separate storage) are strongly preferred where practical |
| Avoid weak phone SMS as the only factor for the only recovery path | SIM swap and phone dependency defeat emergency design |
| No personal forwarding | Do not tie both emergency accounts to one person’s consumer email/phone only |
| Separate secrets | Account A and Account B must not share the same password or the same single hardware key |
5. Monitor and alert on any use
Any sign-in or token activity for break-glass accounts should page security immediately. Expected usage is near zero. Treat every login as a potential incident until proven to be an authorized emergency drill or real recovery.
| Monitoring idea | Purpose |
|---|---|
| Alert on sign-in success/failure | Instant awareness |
| Alert on Azure portal / Graph activity | Detect misuse after sign-in |
| Periodic access reviews / inventory | Confirm still only the intended two accounts |
| Audit CA exclusions | Ensure exclusions did not silently expand |
| Tabletop + live validation | Prove accounts work before a real outage |
6. Documented emergency procedure
Written runbooks should cover: who can authorize break-glass use, how secrets are retrieved (dual custody), which account to use first, how to fix CA/PIM/federation, how to revoke sessions after recovery, how to rotate credentials after use, and how to record the incident.
Create and manage break-glass accounts (workflow)
Creation steps (conceptual)
- Create two cloud-only user accounts with clear naming (for example
emergencyA@contoso.onmicrosoft.comstyle patterns often used in training—follow your org naming standard; prefer *.onmicrosoft.com or carefully controlled cloud UPNs that do not depend on unavailable custom domain federation). - Assign Global Administrator (active permanent assignment by design for true emergency use).
- Configure strong authentication: long password in a vault process and/or FIDO2 hardware keys registered for those accounts.
- Exclude the accounts from Conditional Access policies that could block recovery (and from other lockout risks such as restrictive security defaults interactions when CA is your path—know your tenant’s enforcement model).
- Ensure they are not subject to risky dependencies: not requiring a single on-prem MFA server, not only reachable via broken hybrid path.
- Configure monitoring and alerting in Microsoft Entra / Microsoft Sentinel / SIEM on sign-ins.
- Store credentials/keys under dual control; train a small set of trusted staff on the procedure without making passwords common knowledge.
- Test on a defined cadence (for example quarterly): sign-in in a controlled drill, validate GA still works, then rotate if policy requires and re-seal storage.
- Never use for daily administration, development, or “break-glass for convenience.”
Ongoing management
| Task | Cadence |
|---|---|
| Validate sign-in and role still present | Periodic drill |
| Review CA exclusions still correct and minimal | After every major CA change |
| Rotate credentials / re-key hardware after use or on schedule | After emergency use; scheduled hygiene |
| Confirm monitoring alerts still fire | After SIEM changes |
| Verify only approved personnel know retrieval process | Workforce changes |
| Confirm accounts remain cloud-only and not disabled by lifecycle automation | After identity governance automation changes |
Automation hazard: entitlement lifecycle, inactive account disablement, or HR leaver tooling might disable emergency accounts if they look “stale.” Exclude them from naive inactive-user disable jobs.
Anti-pattern vs correct design
SC-300 loves contrasting bad and good privileged access designs.
Anti-pattern A: Permanent Global Admins for daily work
| Practice | Why it fails |
|---|---|
| Ten engineers with active permanent Global Administrator for everyday tasks | Huge standing blast radius |
| No PIM eligibility conversion | No time box, no activation audit trail for routine elevation |
| Weak MFA or legacy auth allowed | Easy account takeover becomes tenant takeover |
| No break-glass distinction | When something fails, chaos; when nothing fails, perpetual over-privilege |
Fix: Convert daily admins to eligible least-privilege roles + PIM; keep only two emergency GA accounts for recovery.
Anti-pattern B: “Exclude everything from CA so we never lock out”
| Practice | Why it fails |
|---|---|
| Exclude all admins from all CA | Admins become the weakest sign-in path |
| Exclude break-glass and then never monitor | Silent super-user backdoor |
| Single emergency account with password in a wiki | Trivial insider or wiki-leak compromise |
Fix: Exclude only emergency accounts from lockout-prone policies; protect them heavily; monitor every use; keep normal admins under CA + PIM.
Anti-pattern C: No emergency accounts at all
| Practice | Why it fails |
|---|---|
| 100% of admins behind CA device compliance + PIM approval only | One bad policy or MFA outage = no recovery |
| All GA eligibility requires an approver who is also locked out | Deadlock |
Fix: Maintain tested break-glass accounts that can still authenticate when the normal control plane fails.
Correct balanced design
| Layer | Configuration |
|---|---|
| Daily admins | Least-privilege roles; PIM eligible; CA phishing-resistant; short activations; approvals on Tier-0 |
| Break-glass | Two cloud-only GA accounts; strong secrets/hardware keys; CA excluded carefully; alert on any sign-in; unused operationally |
| Operations | Runbooks, dual custody, drills, post-use rotation |
| Review | Inventory GA assignments; ensure only emergency + rare justified exceptions are permanent active |
Exam stem decoding
| Stem cue | Likely answer |
|---|---|
| “Prevent tenant lockout if Conditional Access is misconfigured” | Break-glass accounts excluded from those CA policies |
| “At least two cloud-only emergency accounts” | Microsoft emergency access guidance |
| “Admins should not have standing Global Admin” | PIM eligible assignments—not delete every GA including emergency without a plan |
| “Alert whenever emergency account signs in” | Monitoring/alerting on break-glass |
| “Hybrid AD is down; still need cloud recovery” | Cloud-only emergency accounts |
| “Shared Global Admin password for the team” | Wrong—violates break-glass and least privilege |
| “Exclude all users from MFA” | Wrong—over-broad and insecure |
Relationship to other SC-300 controls
- Conditional Access: exclude break-glass from policies that can lock the tenant; do not exclude ordinary admins as a substitute for good pilots and report-only rollout.
- PIM: normal privilege is JIT; break-glass is the active permanent exception set, tiny and monitored.
- Authentication methods: prefer phishing-resistant keys for emergency accounts where feasible; avoid single-point phone MFA.
- Access reviews: review who holds Global Administrator; emergency accounts should remain intentional and few.
- Logs: sign-in and audit monitoring for these accounts is mandatory; see the monitoring chapter for log routing.
Operational drill scenario (teaching story)
- Identity team deploys a CA policy requiring compliant devices for All users, All cloud apps, accidentally including all admins; report-only was skipped.
- No admin laptop is compliant after an Intune outage; portal access fails for normal accounts.
- On-call retrieves emergency account A via dual custody; sign-in alert fires and is acknowledged as authorized emergency.
- Emergency GA disables or corrects the CA policy, restores admin access, revokes unnecessary sessions if needed.
- Team rotates emergency credentials per procedure, documents timeline, and adds process gates so future CA changes require What If + report-only + break-glass validation.
That story is the exam-ready mental model: break-glass is recovery infrastructure, not convenience privilege.
Summary of section 14.3
Which configuration best matches Microsoft-aligned emergency access (break-glass) guidance for a cloud-first Entra tenant?
Why should break-glass accounts typically be cloud-only rather than authoritative only via on-premises sync?
An organization converts all daily administrators to PIM-eligible roles with approval, then also creates two monitored cloud-only emergency Global Administrator accounts excluded from restrictive Conditional Access. What problem does this design solve that PIM alone does not?
Which practice is an exam/design anti-pattern for privileged access?