deep

[DEEP RESEARCH] The Token Was Not a Session. It Was a Signing Dependency.

New NIST guidance exposes a containment gap: the revocation command can succeed while an attacker’s access survives.

Three consoles closed the incident. The browser session missed the meeting.

On September 15, NIST published new guidance for protecting the tokens and assertions that let people and software access cloud applications and APIs. The guidance responds to a practical problem already visible in real incidents: defenders can disable an account, rotate a signing key, or revoke a token and still leave an attacker with working access somewhere else.

That happens because a token is not simply a login session. It is portable authority accepted by a chain of identity providers, applications, APIs, and other systems—often owned by different teams and operating on different clocks.

Our judgment: a token incident is contained only when the last important system stops accepting the compromised authority. The principal’s job is therefore not merely to ask whether revocation was initiated, but whether the organization can prove when access actually ended.

Principal decision: Require evidence of final access denial, not merely a successful revocation command.
Analyst starting point: Correlate the revocation timestamp with the last successful resource request and application-session activity.

The story in 60 seconds

NIST IR 8587 establishes a new federal baseline for protecting tokens and assertions from forgery, theft, and misuse. NIST says the recommendations also apply to commercial token-based systems.
NIST cites a real incident in which foreign actors used tokens forged with a stolen commercial signing key to access government email and steal more than 60,000 messages from one agency.
A recent CISA red-team assessment found that two organizations lacked mature procedures for revoking compromised access and refresh tokens. In one path, a stolen refresh token was converted into a new application credential that survived the original user-focused response.
The recurring problem is distributed trust: an identity provider may honor a revocation while an existing access token, custom verifier, SaaS session, consent grant, or application credential continues working.
The decision for principals is straightforward: measure containment from the revocation command to the final denied access—not to the first green status indicator.

Why a successful revocation can still leave access behind

Most teams can timestamp an administrative action:

the account was disabled;
sessions were revoked;
the signing key was rotated;
the endpoint was reimaged.

Those actions matter. None proves by itself that the attacker lost access.

An existing access token may remain valid until it expires. A custom application may continue trusting an old signing certificate from a local cache. A SaaS product may maintain its own session outside the identity provider’s control. A stolen refresh token may be used to create a client secret, certificate, consent grant, or service identity that survives a password reset and endpoint cleanup.

This is the kind of problem that punishes tired teams: every console can report success while one quiet access path remains open.

The defender’s advantage is that these paths are not unknowable. They can be inventoried, assigned to owners, exercised, and tested until the old authority fails.

The principal decision: replace feature assurance with containment evidence

Security reviews often ask whether a provider supports encryption, short token lifetimes, key rotation, conditional access, or token revocation.

The stronger question is:

Can we identify the compromised authority, withdraw its trust, propagate that decision through every important system, and prove that the attacker can no longer use it?

That question changes what buyers and security leaders should request. Product documentation establishes that a feature exists. Containment evidence shows whether it works across the customer’s actual architecture under incident conditions.

For high-impact systems, require three things:

A trust-chain map: who issues the authority, what signs it, which systems accept it, what it can reach, how long it lasts, and who can withdraw it.
A measured containment gap: the time between a revocation command and the final denied access at the last material resource or application session.
A witnessed test: evidence that old tokens, retired signing material, application sessions, and derived credentials fail after containment actions are complete.

One useful check now: Ask the owner of one critical application whether disabling an identity also terminates the application’s own sessions. If the answer is unclear, the revocation path is incomplete.

The next question is whether you can prove it

Knowing that revocation can fail is the primer. Next, we show how to determine whether access actually ended, measure the gap between the administrative command and effective enforcement, and test the three failure modes most likely to survive a routine response.

The result is an operating model a principal can assign and an analyst can test. The full technical report at the bottom carries the implementation details and supporting evidence.