An authentication incident is not fixed when the login endpoint is back online. You must identify the compromised authority, stop new abuse, revoke what the attacker already obtained, preserve evidence, and restore access without creating a second vulnerability through support or recovery.

Use this playbook before an incident. During one, record every decision and adapt the steps to your system, contracts, and reporting obligations.

First 15 minutes: establish control

Assign an incident commander, a technical lead, an evidence owner, and a communication owner. Open a restricted incident record and start a decision log. Use a separate channel if you suspect the normal collaboration account is compromised.

Capture the alert, time, affected tenant or environment, known indicators, recent deployments, and current authentication-provider status. Do not paste passwords, tokens, private keys, OTPs, or complete identity records into the incident channel.

The first question is: what authority may the attacker possess?

A password can create new sessions until changed or blocked.
A refresh token can mint access tokens until revoked or expired.
A stolen session can survive a password reset depending on your design.
A signing key can create apparently valid tokens.
A malicious OAuth grant can remain valid after a password change.
A compromised support account may reset other users’ factors.

Contain by incident type

Incident	Immediate containment
Credential stuffing	Rate-limit, block breached credentials, challenge suspicious traffic, revoke confirmed sessions
OTP abuse	Throttle sends and verification, block abusive destinations or sources, protect billing limits
Session-token theft	Revoke affected sessions or token families, rotate session secrets if required, investigate exfiltration path
Refresh-token replay	Revoke the token family, require fresh authentication, inspect related sessions and devices
Malicious OAuth consent	Disable the client, revoke grants and tokens, identify accessed resources
Signing-key compromise	Stop issuance, rotate keys through the emergency process, revoke affected trust, assess every token signed by the key
Admin compromise	Suspend privileged sessions, require re-authentication, review configuration and audit changes

Contain narrowly when evidence supports it, but do not preserve availability at the cost of continued account compromise. A tenant-scoped kill switch is safer than a platform-wide outage when the incident affects one customer.

Preserve evidence without collecting more secrets

Record immutable copies or hashes of relevant audit events, configuration versions, deployment identifiers, IP and device signals, client IDs, token identifiers, key IDs, and correlation IDs. Restrict access and document who handled the evidence.

Do not log raw bearer tokens “for investigation.” A log destination may widen the compromise. Hash a token when you need to correlate observations, and capture decoded non-secret metadata only when approved by your response procedure.

Synchronize clocks and note uncertainty. A five-minute clock difference can reverse an incident timeline and send responders toward the wrong root cause.

Eradicate the path, not only the symptom

Changing a password does not fix a stolen session. Rotating a signing key does not fix the deployment path that exposed it. Blocking an IP does not fix an unbounded OTP endpoint.

For each incident, identify:

Initial access.
Authority obtained.
Persistence mechanism.
Resources accessed or changed.
Control that should have prevented or detected it.
Why that control failed.

Patch the entry point, remove persistence, rotate affected credentials, and verify revocation across every region and cache. Then search for the same weakness in adjacent environments.

Recover users without opening a bypass

Incident pressure makes support teams vulnerable to social engineering. Give them a written recovery rule, approved evidence types, and an escalation path. Do not let urgency turn a support chat into a way around passkeys or MFA.

Notify affected users with concrete actions: which sessions were revoked, which factor must be re-enrolled, which integrations need reauthorization, and how to reach the legitimate support channel. Avoid vague requests to “be careful.”

Our secure account-recovery guide explains how to recover access without making the fallback weaker than the primary login.

Meet reporting and communication obligations

Bring legal, privacy, and contractual owners into the incident early. Reporting timelines and required recipients depend on the incident, sector, agreements, and applicable law. CERT-In directions and DPDP obligations may both matter, but they answer different requirements.

Prepare one verified fact set for regulators, customers, users, and internal teams. Mark unknowns as unknown. Never speculate about attribution or impact to fill a status update.

Close with tests and owners

An incident is not closed when the patch merges. Assign an owner and deadline to every follow-up, then test the controls:

Can you revoke one user, one tenant, one client, and the whole platform independently?
Does key rotation work without accepting the compromised key indefinitely?
Can support recover an account without seeing secrets?
Do audit events explain who changed authentication policy?
Will the same alert fire in a tabletop exercise?

Run a blameless review that names system failures precisely. Publish an external postmortem when customers need it, with sensitive details removed and corrective actions tracked.

Contact the NamoID team

NamoID can help startups prepare tenant-aware revocation, token-family controls, audit evidence, recovery policies, and incident runbooks before an emergency. If an active security incident is underway, use the published security-reporting channel rather than posting secrets in a community workspace.

For planning and implementation help, contact the NamoID team in Slack. Share a sanitized architecture and the incident types you need to rehearse; we can help you build the playbook.

Authentication Incident-Response Playbook for Startups