Break-glass access audit: emergency power with a permanent record

1. The problem: standing access vs. unreachable systems

Every estate has accounts that must work when everything else fails: the domain recovery key, the cloud root, the database superuser, the HSM officer quorum, the vendor backdoor you inherited. If those credentials sit in a shared vault with standing access, they are the highest-value target in your environment — and every access review flags them. If they are locked away with no defined release path, the 3 a.m. outage becomes a 3 p.m. outage while someone hunts for the one person who knows the safe combination.

Common compromises satisfy nobody:

• Standing admin for on-call. Fast in a crisis, indefensible in an audit. The credential's every use — legitimate or not — looks identical, and “we trust the team” is not access control.
• Password-vault emergency access. Good for storage and rotation, but most vaults record that something was read — not why, not under what authority, and not as an immutable governance event.
• Split knowledge with no procedure. Two halves of a password in two safes works until the holders are on the same flight, or disagree about whether this counts as an emergency, with no record either way.

Auditors ask a pointed question: show me every emergency access granted last year, who authorized each, and why. Teams without a break-glass record answer from memory and ticket archaeology. That is the gap.

2. What good looks like on your infrastructure

1. Sealed by default. Emergency material is encrypted and unusable until a release workflow runs. There is no standing session, no ambient privilege.
2. Released only with reason. Every break requires an attributable actor and a recorded justification — and optionally a second approval — before decryption.
3. Recorded immutably. The release emits a signed, hash-chained receipt: who, when, which policy version, what reason. The entry cannot be deleted afterward.
4. Scoped and expirable. Released access carries boundaries — which systems, for how long — with rotation or re-seal after the incident closes.

The point is not to make emergencies hard. It is to make them legible: fast to execute, impossible to hide, complete to reconstruct.

3. How it works — seal, break, audit

Seal

Break-Glass Envelope takes the emergency credential, encrypts it under keys in your KMS, and stores the sealed envelope with its policy: eligible releasers, approval threshold, allowed scope, and expiry behavior. Sealing is itself receipted — creation time, policy version, envelope identifier — so the starting state is on record before any crisis.

Break

When the incident hits, the responder opens a release: identity, reason, scope requested. If policy demands multi-party approval, the release parks until the threshold is met — each approval attributable. Only then does decryption proceed, delivering time-bounded access. The workflow is designed for stress: minimal steps, no hunting for key holders, no out-of-band exceptions that bypass the record.

Audit

The break emits the governance event into the AI Decision Audit Trail: release receipt, policy version, reason text, timestamps, and subsequent rotation or re-seal. Post-incident review replays the whole arc — and the next access review has a complete, attributable list instead of archaeology.

4. The components

One envelope, one trail. The pair covers the full emergency-access lifecycle.

5. How to verify it — releases, reasons, and drills

• Release listing. Enumerate every break in a period with actor, reason, scope, and policy version. Compare against incident records — every entry should map to a real event and vice versa.
• Reason quality. Reasons must be specific and attributable. “Emergency” with no incident reference is a finding about your process, not proof of one.
• Seal-before-break proof. Confirm the envelope existed sealed before the incident — creation receipt predates the break — so access was genuinely exceptional, not standing.
• Post-break rotation. Verify credentials released in an incident were rotated and re-sealed afterward. A break without follow-through is standing access with extra steps.
• Game-day drill. In a pilot, run the full loop on a test envelope: seal, page the responder, break with reason, verify the receipt, rotate, re-seal. Time it. The drill is the deliverable.

6. Buying checklist

• ☐ Envelopes sealed by default — no standing emergency sessions
• ☐ Release requires actor identity plus recorded reason, at minimum
• ☐ Multi-party thresholds configurable per envelope
• ☐ Every break emits a signed, hash-chained, undeletable receipt
• ☐ Released access is scoped and time-bounded with rotation workflow
• ☐ Breaks land in the same audit trail as other governance events
• ☐ Keys in your KMS/HSM — vendor cannot release on your behalf
• ☐ Studio experiment available without signup — isolated demo host, rehearse before installing
• ☐ No vault-replacement or rotation-automation claims beyond scope

7. Common anti-patterns to avoid

• Break-glass as daily driver. If the envelope opens weekly, the underlying access model is broken. Emergency paths used routinely are standing access with theater.
• Reasons nobody reads. A mandatory free-text field filled with “asdf” proves the field exists, not the control. Review reasons in access recertification.
• No re-seal discipline. Post-incident rotation and re-sealing must be tracked to closure, with the same rigor as the break itself.
• Approvers who always approve. Multi-party release with rubber-stamp approvers is single-actor release with latency. Rotate approvers and sample their decisions.
• Separate, unreviewed audit silo. Break receipts in a tool nobody opens are archaeology. Feed them into the trail your governance team already reviews.

Frequently asked questions