Learning outcomes
- Distinguish just-in-time, time-bound, and break-glass access.
- Define narrow grants with automatic expiry and independent approval.
- Monitor use and revoke authority across sessions and downstream systems.
- Test emergency access without normalizing permanent exceptions.
Operating objective
Temporary access grants a defined privilege for a limited period. Just-in-time access creates the grant when a valid need starts. Break-glass access is an emergency path used when normal controls cannot support an urgent recovery or safety need. All three need narrower authority, stronger evidence, and more reliable expiry than ordinary standing access.
Define the requester, approver, reason, resource, actions, start, expiry, authentication strength, session rules, monitoring, revocation owner, and review trigger. Emergency access must not share the exact dependency that it is meant to recover.
Signals and evidence
Collect request and approval identity, ticket or incident, grant revision, exact permissions, activation and expiry, authentication and device state, sessions created, resources reached, actions performed, denials, extensions, revocation, and post-use review. Alert on use outside the declared incident, expansion, repeated activation, failed expiry, or a dormant emergency account becoming active.
Measure time from approval to activation and from expiry or revocation to the end of effective access.
Response and recovery
When use is unexpected, revoke the grant, sessions, credentials, derived tokens, and downstream access. Preserve evidence, rotate any exposed emergency secret, inspect actions, restore normal controls, and document the residual access window. After legitimate use, confirm automatic cleanup and review whether standing permissions or recovery design caused the emergency need.
Test the path on a schedule. A break-glass control that has never been exercised is an unverified recovery claim.
Design tradeoffs and residual risk
Approval and strong authentication reduce misuse but can delay recovery. Offline emergency credentials improve independence but create custody and rotation risk. Automatic expiry limits persistence but cannot undo completed actions. A powerful shared account weakens attribution even when access is brief.
Prefer named principals, narrow actions, short lifetimes, two-person control for high-impact changes, and independent monitoring.
Pomerium boundary
Pomerium policy can restrict a temporary route by identity, group, device, time, and external context. The system that creates the grant must still approve, expire, and revoke it. The application must enforce temporary permission for its own privileged actions and record those actions.
Exercise
Design emergency production access for an identity-provider outage. Define what remains available, how two operators authenticate, which routes and actions are allowed, how long access lasts, and how evidence reaches an independent sink.
Run a tabletop test for activation, misuse, identity-provider recovery, revocation, session termination, credential rotation, and post-incident review.
Evaluation checklist
- Is the grant limited by person, resource, action, reason, and time?
- Can it work when the failed dependency is unavailable?
- Does activation create immediate and independent evidence?
- Do expiry and revocation reach sessions, tokens, caches, and applications?
- Is every use followed by cleanup and a review of why it was needed?
Next learning unit
Authorization Decision Log
Record enough structured evidence to explain and test an access decision without storing credentials or excess personal data.
