What happens when a signing key leaks?
What happens when access tokens appear in logs?
What happens when Redis session store is compromised?
What happens when refresh-token reuse is detected?
What happens when IdP JWKS endpoint is down?
What happens when one tenant's token is accepted by another tenant route?
What happens when password hashes are exfiltrated?
What happens when credential stuffing traffic rises 100x?

Do not destroy evidence during containment.
Do not preserve availability by accepting invalid authentication.
Do not rotate one secret while leaving derived/session state valid without analysis.
Do not communicate certainty beyond evidence.

[ ] Declare incident channel and commander.
[ ] Freeze risky deploys except approved emergency changes.
[ ] Preserve relevant logs, metrics, traces, audit events.
[ ] Identify suspected mechanism: password/session/JWT/OIDC/API key/mTLS/MFA/tenant.
[ ] Determine if invalid authentication is being accepted.
[ ] Determine if active abuse is ongoing.
[ ] Decide immediate containment: block, revoke, rotate, disable, degrade.
[ ] Record every action with timestamp and operator.

authentication audit events
security logs
resource server rejection logs
IdP admin events
JWKS/key rotation events
session creation/revocation events
refresh token rotation events
API key usage events
rate limiter metrics
network/proxy access logs
application deploy timeline
configuration changes

passwords
access tokens
refresh tokens
session ids
API key secrets
authorization codes
MFA codes
recovery codes

Incident ID:
Time window:
Detected by:
Mechanism affected:
Tenants affected:
Users/clients affected:
Indicators:
Controls observed:
Immediate containment:
Open questions:
Evidence locations:
Access restrictions:

private key exposed in repository, logs, build artifact, or secret manager incident
unexpected tokens signed with valid key
resource servers accepting tokens not issued by trusted IdP flow
unknown token issuance pattern

[ ] Confirm key id (`kid`) and issuer.
[ ] Stop new token issuance with compromised key.
[ ] Generate new signing key pair in secure environment.
[ ] Publish new JWKS key if not already available.
[ ] Change active signing key.
[ ] Decide whether to remove compromised public key immediately or after emergency window.
[ ] Force resource servers to refresh JWKS cache.
[ ] Revoke/expire affected access tokens if possible.
[ ] Revoke refresh token families that could mint new access tokens.
[ ] Increase monitoring for old `kid` usage.

Remove old key immediately => invalidates all tokens signed by it, may cause outage.
Keep old key briefly => attacker may continue using forged tokens.

cache eviction endpoint or restart
short emergency JWKS cache TTL
alert for old kid
issuer/audience validation verification

public interface JwksCacheControl {
    void evictIssuer(String issuer);
    void evictKey(String issuer, String kid);
}

[ ] New tokens use new `kid`.
[ ] Old compromised `kid` is rejected or accepted only under explicit temporary window.
[ ] Resource servers refreshed key cache.
[ ] Tokens with wrong issuer rejected.
[ ] Tokens with wrong audience rejected.
[ ] Unsigned/none-alg tokens rejected.
[ ] Audit detects any old `kid` usage.

[ ] Move signing to HSM/KMS if appropriate.
[ ] Reduce access to private key material.
[ ] Separate signing key by environment/tenant if needed.
[ ] Add secret scanning for key format.
[ ] Test emergency key rotation quarterly.
[ ] Document max JWKS cache staleness.

access tokens found in logs, analytics, browser crash reports, support tickets, URL query strings, referrer headers, third-party tooling

Are tokens JWT or opaque?
Are they expired?
What issuer/audience/client/tenant?
Were refresh tokens also leaked?
Was leakage continuous or one-time?
Who had access to the logs/tool?
Can leaked tokens be replayed from attacker environment?

[ ] Stop further leakage immediately.
[ ] Reduce token lifetime if systemic.
[ ] Revoke related refresh tokens if leak includes refresh token or long-lived path.
[ ] Add detection for leaked token `jti` if present.
[ ] Rotate session/token if user session path contaminated.

[ ] Revoke token through token store/introspection source.
[ ] Invalidate cache entries in resource servers.
[ ] Search for related tokens from same session/client.

[ ] Restrict log access.
[ ] Create sanitized copy if investigation needs broad sharing.
[ ] Delete/expire contaminated logs according to legal/security policy.
[ ] Fix logger/redaction at source.

Authorization header redaction
query parameter denylist
structured logging allowlist
HTTP client interceptor redaction
proxy/access-log redaction
support bundle scrubber
browser URL fragment/callback hygiene

refresh_token_reuse_detected{client_id, tenant_id, token_family_id}

[ ] Mark token family compromised.
[ ] Revoke all descendants in family.
[ ] Revoke active access tokens associated with family if possible.
[ ] Terminate related sessions.
[ ] Require user/client re-authentication.
[ ] Notify user/client if policy requires.
[ ] Record source IP/device/client metadata for investigation.

Two legitimate refresh requests arrive concurrently.
Both see old token active.
Both issue new child.

UPDATE refresh_token
SET status = 'ROTATED', rotated_at = now()
WHERE id = :token_id
  AND status = 'ACTIVE';

user reports suspicious activity
impossible travel
same session id used from different networks/devices
session id leaked in logs

[ ] Revoke specific session id.
[ ] Rotate user's active sessions if necessary.
[ ] Revoke remember-me tokens.
[ ] Require re-authentication / MFA step-up.
[ ] Review account changes after suspected compromise time.

[ ] Isolate session store network access.
[ ] Rotate session encryption/signing keys if used.
[ ] Revoke all sessions in affected environment.
[ ] Force global re-login.
[ ] Review whether session payload contained secrets.
[ ] Rotate downstream tokens stored in session.
[ ] Patch network/IAM/security group/config.

public interface SessionIncidentService {
    int revokeSession(String sessionId, String reason);
    int revokeAllForAccount(String accountId, String reason);
    int revokeAllForTenant(String tenantId, String reason);
    int revokeAll(String environment, String reason);
}

session index stale
Redis scan too slow
application local session cache not evicted
sticky sessions retain old context
logout event not propagated

[ ] Old session cookie rejected.
[ ] Existing API request cannot continue with old SecurityContext after boundary.
[ ] All pods observe revocation.
[ ] Metrics show session recreation after login only.

Which tables/columns were accessed?
Were password hashes exfiltrated or only read?
Which algorithm/parameters?
Were salts included?
Was pepper used?
Was pepper exposed?
Were reset tokens/recovery codes/MFA secrets also exposed?
What time window?

[ ] Stop data exfiltration path.
[ ] Rotate database credentials and affected app secrets.
[ ] If pepper exposed, rotate pepper strategy carefully.
[ ] Invalidate password reset tokens/recovery codes if exposed.
[ ] Increase credential stuffing monitoring.
[ ] Force password reset for affected users if risk/policy requires.
[ ] Block known compromised passwords during reset.
[ ] Rehash credentials with upgraded parameters on reset/login.

password reset campaign
MFA enrollment/step-up
breached password screening
suspicious login detection
session revocation after password reset
notification with concrete guidance

[ ] Upgrade weak hashes.
[ ] Remove legacy hash acceptance after migration window.
[ ] Review DB access control.
[ ] Add anomaly detection for credential table reads.
[ ] Add canary credentials / honey hashes if appropriate.
[ ] Verify backup/security snapshot exposure.

Which API key prefix?
Which client/tenant/environment?
What scopes?
When was it last used?
Was it used from unusual IP/location?
Was it production or sandbox?
Was it logged in client code/repository/support ticket?

[ ] Disable leaked key.
[ ] Create replacement key with least privilege.
[ ] Notify client owner.
[ ] Monitor old key usage attempts.
[ ] Review actions performed by leaked key.
[ ] Rotate related webhook/HMAC secret if same client secret hygiene failed.

temporary allowlist IP
scope reduction
short emergency overlap window
heightened monitoring
explicit expiry

key prefix for lookup and identification
hashed secret storage
last-used throttled audit
secret scanning pattern
client self-service rotation
dual-key overlap rotation
scope minimization

[ ] Identify key id/client id.
[ ] Disable compromised secret or mark as retiring.
[ ] Issue new secret.
[ ] Support dual-signature overlap if required.
[ ] Reduce replay window if under attack.
[ ] Clear nonce cache if semantics require.
[ ] Monitor old key id usage.
[ ] Review signed requests during compromise window.

[ ] Old secret rejected after cutoff.
[ ] New secret accepted.
[ ] Requests without timestamp rejected.
[ ] Replayed signatures rejected.
[ ] Canonicalization tests still pass.

new login
token refresh
JWKS fetch
introspection
UserInfo
federated logout
admin API automation

Do not show stack trace.
Do not reveal IdP internals.
Do not claim credentials are wrong.
Use clear temporary-unavailable message for login path.
Existing authenticated users may continue if policy allows.

IdP health dashboard
JWKS cache status
token endpoint error rate
introspection error rate
login callback failure rate
fallback admin/break-glass path

hardware MFA
small allowlisted group
separate audit
time-limited activation
post-use review

credential stuffing spike
many failed logins across many accounts
successful logins from unusual networks
MFA push fatigue pattern
password reset spike
risk score spike
known breached credential list usage

[ ] Tighten rate limits for affected routes.
[ ] Enable step-up for suspicious logins.
[ ] Block obvious abusive networks/ASNs if reliable.
[ ] Require password reset for confirmed compromised accounts.
[ ] Revoke sessions for confirmed compromised accounts.
[ ] Disable risky recovery paths temporarily if abused.
[ ] Increase audit retention for incident window.

progressive throttling
risk-based step-up
known breached password checks
user notification for confirmed suspicious successful login
support workflow for recovery

high volume of login/recovery attempts
identifier spray
response timing anomaly
registration lookup spike
forgot-password event spike

[ ] Verify generic response behavior.
[ ] Check response timing distribution for known vs unknown accounts.
[ ] Tighten pre-auth rate limits.
[ ] Add CAPTCHA/challenge only where appropriate.
[ ] Monitor email/SMS sending volume.
[ ] Prevent notification flooding.

Known and unknown account responses have equivalent semantics.
Recovery does not reveal account existence.
Registration does not reveal existing account unless intentionally designed and protected.

Which factor is affected? TOTP? SMS? Email? Push? WebAuthn?
Are backup codes available?
Are high-risk actions blocked?
Can existing sessions continue?

Do not disable MFA globally as first action.
Prefer alternate enrolled factors.
Allow backup codes if designed.
For low-risk sessions, defer step-up if policy allows.
For high-risk/admin actions, fail closed.

[ ] Rate limit MFA challenges.
[ ] Require number matching or phishing-resistant factor if available.
[ ] Temporarily disable push for targeted accounts.
[ ] Notify affected users.
[ ] Revoke sessions if compromise confirmed.

token from tenant A accepted on tenant B endpoint
issuer/realm routing mismatch
email domain maps to wrong tenant
session tenant switched without revalidation
admin from one tenant sees another tenant resource

[ ] Disable affected route/client/tenant routing path if needed.
[ ] Add emergency check: token tenant must equal route/resource tenant.
[ ] Revoke sessions/tokens created through broken flow.
[ ] Identify all cross-tenant access events.
[ ] Preserve audit logs and data access logs.
[ ] Notify legal/compliance/security leadership.

issuer not validated per tenant
audience too broad
tenant taken from request parameter instead of authenticated principal
account linked by email alone
shared realm without tenant-bound membership check
resource server tries multiple issuers until one validates

[ ] Tenant A token rejected on Tenant B route.
[ ] Tenant B session cannot switch to Tenant A by parameter/header.
[ ] OIDC issuer + subject mapping is tenant-safe.
[ ] API key tenant binding enforced.
[ ] Audit event contains authenticated tenant and resource tenant.

sudden login failure spike after deploy
all JWTs rejected due to audience config
all sessions invalidated unexpectedly
CSRF token mismatch spike
OIDC callback broken due to redirect URI change

[ ] Compare deploy/config timeline.
[ ] Roll back if security invariant remains safe.
[ ] If new version accepted invalid auth, revoke sessions/tokens created during window.
[ ] Run auth regression suite before redeploy.
[ ] Check feature flags and environment-specific config.

Fail-closed regression: users cannot login, but invalid auth not accepted.
Fail-open regression: invalid/unauthorized auth accepted.

revoke session by id
revoke all sessions by account
revoke all sessions by tenant
revoke refresh token family
disable API key
rotate signing key
evict JWKS cache
force reauthentication for account/tenant
increase auth risk policy level
put IdP integration in maintenance mode

admin authentication with step-up
authorization for operation type
dry-run support
idempotency key
audit event for every operation
bounded batch size
progress reporting
rollback where possible

{
  "operationId": "authop_20260703_001",
  "operation": "REVOKE_ACCOUNT_SESSIONS",
  "actor": "security-ops-user-id",
  "targetAccountId": "acc_123",
  "reason": "suspected_account_takeover",
  "dryRun": false,
  "startedAt": "2026-07-03T10:15:00Z",
  "completedAt": "2026-07-03T10:15:02Z",
  "affectedCount": 4
}

SIGNING_KEY_CREATED
SIGNING_KEY_ACTIVATED
SIGNING_KEY_RETIRED
JWKS_CACHE_EVICTED
SESSION_REVOKED
ACCOUNT_SESSIONS_REVOKED
TENANT_SESSIONS_REVOKED
REFRESH_TOKEN_FAMILY_REVOKED
API_KEY_DISABLED
MFA_FACTOR_RESET
PASSWORD_RESET_FORCED
BREAK_GLASS_ACCESS_USED
AUTH_POLICY_CHANGED
IDP_CONFIGURATION_CHANGED
TENANT_ROUTING_CHANGED

actor
target
reason
correlation id
request id
before/after state if safe
timestamp
source system
approval reference if required

Status:
Impact:
Mechanism affected:
Known affected tenants/users/clients:
Containment completed:
Current risk:
Next action:
Open questions:
ETA policy:

Bad: We had an auth issue.
Better: We detected refresh-token reuse for client X and revoked affected token families. No evidence currently indicates signing key compromise.

Which invariant failed or was at risk?
Which detection fired?
Which detection was missing?
Which containment step was manual?
Which operation lacked tooling?
Which logs were insufficient?
Which secret/token appeared somewhere it should not?
Which test would have caught this before production?
Which architecture decision increased blast radius?

new regression tests
new alert
new runbook step
automated operation
auth model change
secret handling improvement
tenant isolation improvement
policy/ADR update

quarterly signing key rotation drill
monthly session revoke-all dry run in staging
refresh-token reuse simulation
JWT unknown kid storm simulation
IdP outage game day
API key leak tabletop
password hash breach tabletop
tenant confusion regression drill
MFA provider outage drill

time to detect
time to triage
time to contain
tooling gaps
operator confusion
missing permissions
log quality
customer impact estimate

[ ] Signing keys have owner, lifecycle, rotation cadence.
[ ] Emergency key rotation tested.
[ ] JWKS cache eviction supported.
[ ] Resource servers fail closed on invalid/unknown keys.
[ ] Private key access audited.

[ ] Access token leak response documented.
[ ] Refresh token family revoke implemented.
[ ] Session revoke by account/tenant/global implemented.
[ ] Revocation propagates to all pods.
[ ] Existing sessions can be forced to reauthenticate.

[ ] Password hash breach runbook exists.
[ ] Legacy hash migration plan exists.
[ ] Forced password reset process exists.
[ ] Recovery token invalidation exists.
[ ] MFA reset operation is audited and protected.

[ ] API key disable/rotate workflow exists.
[ ] HMAC secret rotation supports overlap/cutoff.
[ ] Client owner mapping exists.
[ ] Scope reduction can be applied quickly.

[ ] Auth audit events are structured.
[ ] Logs redact secrets.
[ ] Token/session/API key IDs are represented by safe hashes/prefixes.
[ ] Incident queries are prewritten.
[ ] Evidence retention policy is known.

JWT signing private key for production issuer leaked in CI logs.
Tokens are valid for 15 minutes.
JWKS cache TTL in resource servers is 1 hour.

containment steps
resource server cache refresh strategy
old key retirement decision
token/session impact
communications
post-incident hardening

token family revoked
active access tokens invalidated if supported
user forced to reauthenticate
audit event emitted
false-positive race condition avoided

blast radius
global session purge procedure
secret rotation
user impact
validation queries
post-incident controls

request rejected
cross-tenant rejection audit event created
no resource access
metric increments

Runbook is part of architecture.
Key compromise requires dependent-token analysis.
Token leak requires log/tool blast-radius analysis.
Refresh-token reuse should revoke the whole token family.
Session compromise requires tested purge operations.
Password hash breach response depends on algorithm, parameter, pepper, and exposed recovery data.
IdP outage must not become reason to skip validation.
Tenant confusion is usually SEV-1 even with small observed impact.
Every emergency operation must be audited.
Every incident should produce tests and tooling improvements.