Pattern — Break-Glass Access

The problem it solves

The person with the most context has the fewest permissions at the worst possible moment. In Drill 34 an expert on the misbehaving subsystem is on the Sev-1 bridge but her roles were auto-revoked after a team transfer, and the approval workflow needs a manager who is on a plane — so the incident runs ninety extra minutes while she dictates commands through a screen-share, and the audit log credits the typist for everything she did. In Drill 25 an expired service-account key needs renewing at 3 a.m. on a Saturday, but the runbook names a departed engineer and the vendor login lives in a personal password manager. The common shape: least privilege and offboarding did their job on standing access, but nobody designed the emergency exception — so under pressure people invent an unsanctioned path that is slower, riskier, and lies about who did what.

The pattern

Build a break-glass path: a pre-authorized, just-in-time privilege elevation that a declared incident unlocks. The scope is defined and security-approved when the path is built, not while the incident burns, so activation is a single command or button — no per-incident approval chain. Every grant is time-boxed and auto-revoked, runs under the operator's own identity with session recording on, and automatically opens a postmortem review item. The counter-intuitive core: it is fast because it is heavily audited, not despite it — the audit is what lets security pre-approve a path with no human gate at incident time.

How to apply it

1. Gate on a declared incident, not a manager. Activation requires an open Sev-1/Sev-2 in the incident tool (PagerDuty, Opsgenie) plus the operator's own federated SSO identity and an MFA prompt. Zero approval chain at incident time — the review already happened at design time. If you must add a live gate, make it peer visibility: any other on-call can acknowledge in seconds, or the grant simply auto-announces to #incident so a second person always witnesses it. Target time-from-request-to-access under 5 minutes (p95), and treat anything over that as an incident-response gap, not an access-team backlog item.
2. One pre-built break-glass role per critical system. Scope is least-privilege-for-the-emergency (the decisioning service, the vendor-key rotation), defined and security-signed-off in advance. No standing god-mode account — the role is eligible, activated only during an incident.
3. Time-box hard and auto-revoke. Default grant 2 hours, max session 4 hours, extendable only by re-granting (which re-logs and re-announces). Revocation fires on a TTL — never a manual cleanup that gets forgotten — so break-glass can never silently become standing access.
4. Log under the real identity, record the session. Every action runs as the human's own SSO principal (shared emergency accounts are banned); capture keystroke/session logs (AWS SSM Session Manager to S3, Teleport session recording) so "who did what?" has a truthful answer.
5. Close the loop automatically. Each grant auto-creates a postmortem item — who granted, to whom, scope, what was done, and whether the underlying gap should be fixed permanently. Store any bootstrap secrets (root/recovery keys, vendor logins) in a shared team vault with at least 2 holders, never a personal manager.
6. Drill it quarterly. Once a quarter, an incident commander grants break-glass to a volunteer who did not build it; they run a scratch task, revocation fires, and the audit trail is verified. An emergency path never walked is a runbook wearing a badge.

flowchart TD
    A["Sev-1 declared in<br/>incident tool"] --> B["Operator activates break-glass<br/>(own SSO + MFA, no approval chain)"]
    B --> C["Pre-built least-privilege role<br/>for this system only"]
    C --> D["Grant is time-boxed<br/>(2h default, 4h max)"]
    C --> E["Actions logged + recorded<br/>under the real identity"]
    D --> F["TTL auto-revokes —<br/>never becomes standing access"]
    E --> G["Audit answers who did what"]
    B -.-> H["Grant auto-announced to #incident<br/>and opens a postmortem item"]

When to use it — and when not

Reach for it wherever least privilege can lock out the very person who must act in an incident — production consoles, credential rotation, database hotfixes, infra tooling that guards a Sev-1 recovery path. Do not use it as a substitute for granting the right standing access to people who need it daily; break-glass is the rare-event exception, not the everyday door. And do not bolt an approval chain onto it — "security sign-off, then the manager, then…" is the normal path wearing a red sticker, and if it is slower than the screen-share workaround, the workaround wins again and the audit log lies. The cost is real: a pre-built privileged role is attack surface, so it must be tightly scoped, MFA-gated, session-recorded, and reviewed every quarter — an un-drilled, un-audited break-glass role is just the god-mode service account of Drill 47 with better branding.

Signals it's working

• Time-from-request-to-access during incidents is measured and stays under 5 minutes (p95); a rising number is an incident-response gap, alarmed the same as any SLO breach.
• Zero screen-share-dictation incidents and zero shared-emergency-account logins — every privileged action in a postmortem maps to a named human.
• Every grant auto-revoked on schedule: standing-grant count from break-glass holds at 0; any grant older than its TTL is an alert.
• A quarterly drill is on the calendar and passes — a volunteer who didn't build it can grant, use, revoke, and produce a clean audit trail using only the runbook.

Seen in the wild

• Microsoft Entra Privileged Identity Management (PIM) — roles are eligible, activated just-in-time with MFA, justification, a time limit, and optional approval; Microsoft also documents dedicated emergency-access ("break-glass") accounts.
• Teleport (Gravitational) — access requests grant just-in-time, time-boxed elevation with full session recording, so the grant is fast and the replay is complete.
• AWS — temporary elevated access via IAM Identity Center, with SSM Session Manager session logging to S3/CloudTrail for the audit trail.
• HashiCorp Vault — short-lived dynamic secrets and a root/recovery-key break-glass whose unseal shares are split across multiple people, so no single person is the bus factor.

See it

The LayersScene splits standing access from the emergency path, TilesScene/CardsScene carry the load-bearing config (declared-incident gate, no approval chain, 2h/4h TTL, own identity, quarterly drill), and the MetricLineScene alarms when time-to-access crosses 5 minutes.

Named concepts: break-glass access, just-in-time privilege elevation, time-boxed access grants, audit under real identity.