How to Invalidate All User Sessions After a Breach

To invalidate all user sessions after a breach you need a server-side revocation path that covers every credential your systems accept without re-checking a password: session records, refresh tokens, signed access tokens, OAuth grants, API keys and the identity provider's own session. A password reset on its own does not do this. If an attacker holds a live token, the reset email lands in the user's inbox while the attacker keeps working in a session that was issued before the reset and is still valid until it expires on its own schedule.

This question got sharper in November 2026, when Chainalysis disclosed that an October intrusion exposed names, usernames, password hashes and live tokens for all of its users and pulled access to two products while it investigated. The password hashes are the headline. The live tokens are the operational problem, and pulling product access the way they did is only available to a company that built the plumbing for it in advance.

Why a password reset does not log an attacker out

Most SaaS applications authenticate a user once and then issue something that stands in for that authentication: a session cookie backed by a row in Redis, a signed JWT with a one hour or one day lifetime, a refresh token that mints new access tokens for weeks, or a long-lived "remember me" cookie. Each of those is a separate credential with its own lifetime and its own revocation story. Changing the password invalidates exactly one of them, the password, and only if your login flow actually checks it on every request, which it does not.

In testing engagements with fintech and B2B software teams, the usual finding is not that revocation is broken. It is that nobody has ever tried it. The application has a logout button that clears a cookie in the browser and leaves the server-side record intact, so a stolen cookie replayed from another machine still works. Access tokens are stateless by design, so there is no list to delete from. Refresh tokens live in a table that no admin screen touches. API keys were issued by a self-serve settings page two years ago and nobody has counted them since. Under incident pressure, the team's only lever is to redeploy everything with a new signing key and hope that does not break the mobile app.

What your session kill switch actually has to cover

Before you can build the switch, inventory every path into your product that does not require a fresh password check. For a mid-sized SaaS platform that list is usually longer than the engineering team expects:

• Web sessions, including sessions held by browsers that have not touched the app in weeks.
• Access tokens, signed and stateless, accepted by every API service without a database lookup.
• Refresh tokens, often with lifetimes measured in months.
• Mobile and desktop client tokens, which frequently use a longer lifetime than the web app because re-authentication on a phone is unpleasant.
• Personal access tokens and API keys created by customers for integrations, plus any keys your own support staff issued on request.
• OAuth grants you issued to third-party apps, and grants you hold against other platforms.
• Service accounts and machine identities used by internal jobs and by customer-facing webhooks.
• Identity provider sessions. If you kill the application session but the customer's IdP still considers the browser authenticated, single sign-on silently re-issues a new session on the next request and you have accomplished nothing.

The decision rule I use: for each item on that list, can one named person revoke every instance of it, for one tenant or for all tenants, in under fifteen minutes, without a code deploy? If the answer is no for any row, that row is the gap an attacker will live in.

How to build and test a session revocation path, in order

The implementation is not complicated. The discipline is in making it operable by a tired on-call engineer at 3 a.m. rather than by the one developer who wrote the auth service.

• Give every principal a token version. Store an integer or a timestamp on the user record and on the tenant record. Embed it in every issued token. Reject any token whose version is lower than the current one. Bumping the number revokes everything that principal holds, instantly, with no table to purge.
• Add a global not-before timestamp. One configuration value, read at request time rather than at boot, that causes services to reject any token issued before it. That is your all-tenant switch. It must take effect from a configuration change, not a deployment.
• Shorten access token lifetimes to minutes and put the state in the refresh path. A five to fifteen minute access token with a revocable refresh token gives you a bounded blast radius without a denylist on every API call. If you insist on long-lived access tokens, you owe yourself a denylist with a cache in front of it.
• Wire revocation into the identity provider. Use back-channel logout or the provider's session revocation API, and test that a revoked IdP session does not immediately re-mint an application session.
• Build the degraded mode you would actually want. Pulling access to a product, as Chainalysis did, means having a feature flag that puts the application into read-only or no-access state per module, per tenant or globally, with a maintenance page that tells customers what is happening.
• Write the runbook and name the humans. Who decides, who executes, who notifies customers, what the rollback looks like, and what you tell support when 4,000 people cannot log in at once. Tie this into your incident response plan rather than leaving it as a wiki orphan. Teams with a small engineering group can fold it into the same document they use for a disaster recovery plan written for three engineers.
• Rehearse it. Run the switch in staging against realistic data, time it with a stopwatch, then run a tabletop where the scenario is leaked live tokens and the only acceptable answer is mass revocation. Record what broke.

One more step that teams skip: plan for what happens after. A forced mass logout drives a wave of password resets and MFA re-enrolments straight at your support queue, which is exactly the moment social engineering works. Decide in advance how your agents will verify identity before an MFA or password reset, because an attacker who lost their tokens will try to get new ones through a human.

What evidence an auditor or enterprise buyer will ask to see

Session revocation touches logical access controls and incident response, so it shows up in SOC 2 under the common criteria for access management and for responding to identified security events, and in ISO 27001 under authentication information handling and incident management. Auditors do not ask to see your code. They ask for artefacts:

• The runbook itself, with a version history showing it is maintained rather than written once.
• A dated test record: who ran the revocation, in which environment, how long it took, what the verification step showed.
• Tabletop minutes naming participants, the scenario and the follow-up actions with owners and dates.
• Log evidence that the revocation worked, typically a spike of rejected tokens and a clean count of active sessions afterward.
• The ticket for any remediation the test produced, closed, with evidence of the fix.

Enterprise security reviewers ask a related question in their questionnaires: can you terminate all sessions for our tenant on request, and how fast? A yes with a timing number is a differentiator in a vendor review, and it belongs in the same pack as the rest of your enterprise readiness material. Keep the test record in your evidence register so it does not go stale between audits, which is the same discipline behind an evidence register that survives two audits.

The mistakes that turn into findings

The failures I see repeat across companies, regardless of stack:

• Logout clears the client, not the server. Easy to find in a penetration test, embarrassing to explain to a customer.
• All-or-nothing design. If the only option is logging out every customer globally, leadership will hesitate for hours during an incident. Per-tenant and per-user revocation makes the switch usable.
• The switch requires a deploy. A 40 minute pipeline is a 40 minute window for the attacker, and it fails the moment your build system is also compromised.
• API keys left out of scope. Customer integration keys often outlive the employees who created them and are rarely rotated after an incident.
• No verification step. If you cannot produce a query or dashboard that proves zero sessions issued before time T are being accepted, you cannot tell your customers the attacker is out.
• Never tested under load. Mass revocation sends every client into a simultaneous re-authentication storm. Some teams discover their login path cannot handle it.

How this changes with company size and framework

At 20 to 40 people with a single application and a server-side session store, this is a half-day of work: add the token version, expose an admin action, write the runbook, test it. There is no reason to carry the gap.

At 100 to 200 people with several services, a mobile client and SSO for enterprise tenants, the work is coordination rather than code. Every service that validates a token independently has to honour the same revocation signal, and the mobile team has to accept a shorter token lifetime. Budget a sprint and a cross-team test, and treat the mobile and third-party integration paths as the hard part.

For regulated buyers the stakes rise. Fintech and payments companies face questions about session controls, token lifetimes and incident response testing from both auditors and their bank partners, which is why session revocation sits alongside the other items in a fintech compliance checklist. If you are in a SOC 2 Type II observation window, remember that a revocation test performed inside the period is evidence for the period, and a test performed the week before the audit is not, a distinction covered in more depth in guidance on operating a Type II observation window.

Common questions about invalidating user sessions after a breach

Does forcing a password reset log users out?

Not by default. A password reset changes the credential used at login and leaves existing sessions, refresh tokens and API keys untouched unless your code explicitly bumps a token version or purges the session store as part of the reset flow. Many frameworks offer this behaviour as an option that is off by default, so test it rather than assuming it. The test is straightforward: log in from two browsers, reset the password in one, and see whether the other still works.

How short should access token lifetimes be?

For most B2B SaaS applications, five to fifteen minutes for access tokens and days to weeks for a revocable refresh token is a workable balance. The access token lifetime is your worst-case exposure window when you have no denylist, so it sets the floor on how fast a stolen token stops working. If your product serves regulated customers or holds sensitive investigative or financial data, push toward the shorter end and add idle timeouts on the session itself.

Do we need to rotate our JWT signing keys during an incident?

Key rotation is the blunt instrument and it is worth having, but it should not be your only option. Rotating the signing key invalidates every token issued anywhere, including machine-to-machine tokens and any token held by services you did not intend to disrupt, and it tends to require a coordinated rollout. Build per-user and per-tenant revocation first, keep key rotation as the response for a case where the signing key itself may be compromised, and document how long rotation takes.

Will an auditor actually test our ability to revoke sessions?

An auditor will usually ask for evidence that the capability exists and has been exercised rather than running it themselves. Expect requests for the runbook, a dated test or tabletop record and the incident response plan that references the control. A penetration tester, by contrast, will test it directly by replaying a captured session after a logout or password change, which is one of the checks covered when deciding whether you need a penetration test for SOC 2.