infospace-bench/infospaces/patterns-of-it-securita-architecture/artifacts/entities/pattern-break-glass-access.md

Pattern: Break-Glass Access

Status: reviewed Readiness target: RL3 production Primary owners: NetKingdom, Railiance platform

Problem

Operators need a recovery path when normal identity, policy, cluster, or secret services fail, but emergency access can easily become an unbounded platform-root bypass.

Context

Use this pattern for OpenBao recovery, cluster recovery, privileged account recovery, incident containment, and platform restore workflows.

Forces

• Emergency access must work during partial outages.
• It must be limited, auditable, and rarely used.
• Tenant administrators must not receive platform-root powers.
• Post-event review must turn emergency use into durable fixes.

Solution

Define a small emergency path with explicit custody, MFA or quorum where possible, narrow scope, recorded use, and mandatory post-event review. Keep it separate from ordinary administration.

Implementation Sketch

1. Identify emergency scenarios and required minimum authority.
2. Store emergency material separately with named custodians.
3. Require ceremony, reason, and timestamp for use.
4. Alert on activation where systems are available.
5. Rotate or reseal affected credentials after use.
6. Run post-event review and close follow-up tasks.

Failure Modes

Failure	Mitigation
Break-glass becomes routine admin	require review and track frequency
Emergency access is too broad	define scenario-specific bundles
Recovery material is stale	run drills and rotation checks
Tenant admins gain platform-root access	hard-separate tenant and platform authority

Related Capabilities

• Incident response and recovery.
• Privileged access management.
• Secrets, keys, and credentials.
• Security governance and production readiness.

Maturity

Reviewed. The concept is anchored in NetKingdom/OpenBao planning, but drills and custody evidence are required before canonical graduation.

Verification

• Emergency path is documented and tested.
• Activation produces an event record and follow-up review.
• Credentials are rotated or revalidated after use.
• Tenant and platform emergency powers are separated.

Research Basis

Seeded by break-glass access, incident response process, backup restore, and secret-zero avoidance requirements.

References

• Initial exploration: Identity and access patterns.
• Initial exploration: Incident response and recovery.
• Railiance OpenBao platform secrets service.