Skip to main content

Respond to an identity and access incident

Prepare, investigate, contain, recover, and learn when identity or access authority is abused or compromised.

Learning outcomes

  • Define response roles, evidence, authority, communications, and recovery before an incident.
  • Scope an incident across identity, session, credential, route, policy, and application layers.
  • Contain harmful access without erasing evidence or creating hidden persistent authority.
  • Recover known-good access and turn findings into tested improvements.

Operating objective

The organization can detect and stop unauthorized access, preserve trustworthy evidence, restore required service, and reduce recurrence. Preparation is part of normal risk management. It includes ownership, communication, decision authority, inventory, evidence access, containment controls, known-good state, break-glass access, exercises, and recovery criteria.

Define incident categories around consequences, not product alerts. Examples include stolen human session, compromised service credential, malicious administrator, route bypass, policy expansion, issuer compromise, signing-key exposure, and access-control outage.

Signals and evidence

Start with what happened, when, to which asset, through which authority, and with what effect. Preserve identity-provider events, session and credential issuance, authorization decisions, proxy activity, application actions, configuration and administrative changes, network evidence, endpoint evidence, and time quality.

Track observed facts, hypotheses, confidence, missing evidence, decisions, owners, and timestamps. Build a scope matrix for subject, actor, tenant, credential, session, issuer, audience, route, resource, policy version, enforcement point, application action, and persistence mechanism.

Investigate independent paths. A Pomerium deny after containment does not prove that a direct origin, copied credential, existing application session, queued task, or another environment stopped.

Response and recovery

  1. Assign incident command, technical leads, evidence owner, service owners, and authority for disruptive actions.
  2. Validate the signal and preserve volatile and durable evidence before avoidable changes.
  3. Bound affected identities, credentials, sessions, policies, routes, resources, actions, and time.
  4. Contain new access at the narrowest reliable layer, then widen if uncertainty or impact requires it.
  5. Remove persistence, rotate exposed trust material, and close bypass paths.
  6. Restore known-good configuration, identity, credentials, routes, and application state.
  7. Validate normal and negative access through independent tests. Monitor for recurrence.
  8. Reauthorize people and workloads deliberately. Do not restore a compromised snapshot of authority.
  9. Record causes, contributing conditions, response delays, evidence gaps, and concrete control or test changes.

Design tradeoffs and residual risk

Immediate broad revocation reduces attacker time and can stop critical operations. Narrow containment preserves service and can miss linked authority. Evidence collection improves scope and can delay action. Predefine thresholds for disabling one session, one identity, one route, one issuer, or the full access plane.

Fail-closed recovery protects sensitive resources and can block responders. Break-glass improves recoverability and creates high-value authority. Keep it independent, narrow, time-bound, tested, and observable.

Residual risk includes unknown direct paths, copied credentials, compromised identity recovery, stale caches, unobserved downstream actions, and incomplete restoration of trust.

Pomerium boundary

Pomerium can deny configured traffic, apply changed policy, and provide evidence for requests and authorization decisions it processed. It cannot disable an identity at its issuer, revoke an application's own session, cancel queued work, reverse an application action, or prove that a direct path was unused. Response must coordinate the identity provider, Pomerium, network, application, credential, and control-plane owners.

Exercise

Run a tabletop and technical exercise for a stolen administrator session. Detect one unauthorized policy change and one protected application action. Preserve and join the available evidence, state the facts Pomerium provides, and identify the facts that only the identity provider and application can provide.

Contain the subject, session, credential, route, and direct origin as needed. Use a tested break-glass identity to restore a known-good policy while the normal administrator path is disabled. Verify that emergency access expires and that the compromised authority still fails.

Evaluation checklist

  • Are response roles, decision authority, evidence access, and service owners defined in advance?
  • Does scoping include identity, session, credential, route, policy, application, and direct paths?
  • Can containment stop new access while preserving evidence and critical recovery access?
  • Does recovery prove known-good positive and negative behavior?
  • Do findings produce owned control, telemetry, and exercise changes?

Next learning unit

Revocation Latency

Measure how long a disabled identity, authenticator, session, claim, or permission can continue to authorize action.

Sources and further reading

Keep learning

Identity and AuthenticationSecurity Operations and Risk

Revocation Latency

Measure how long a disabled identity, authenticator, session, claim, or permission can continue to authorize action.

Learn this term
Application and Service AccessNetwork and Infrastructure

Gateway Bypass Path

Find every route that reaches a protected origin without the intended identity, policy, and evidence controls.

Learn this term
Identity and Authentication

Account Recovery

Restore account access without giving attackers an easier path than the normal authentication and enrollment process.

Learn this term

Get a Personalized Demo

Schedule a Call with a Pomerium Engineer

Get a Demo