A person signs in, closes the laptop, and reasonably thinks the sensitive part is over. In a modern cloud system, that can be exactly when the important credential begins its life. The service issues a token or accepts an assertion that lets later requests proceed without repeating the entire login. Convenience is the point. A person should not have to solve the same authentication challenge every time a browser fetches an inbox message. The engineering bargain is that the system has created a portable statement of authority.
NIST and CISA's final September 2026 report, IR 8587, is about the ways that statement can be forged, stolen or misused. It is aimed chiefly at federal agencies and cloud providers, but its control questions apply wherever tokens carry access. The useful way to read it is not as a new reason to fear every login. It is an inventory of where a trusted identity statement can part company with the person or workload it was supposed to represent.
A correct signature can still carry the wrong person
A token answers a narrower question than many people assume. A service may verify that a trusted issuer signed it, that it has not expired, that its intended audience matches, and that its claims permit a particular action. Those checks are important. They do not prove the token is still in the custody of its rightful holder. If an attacker obtains a bearer token and the receiving service treats possession as sufficient, the service can perform its checks correctly while granting the attacker access. The cryptography is working; the chain of custody is not.
Forgery is a different failure. NIST's release notice points to an incident in which attackers used a stolen commercial signing key to produce forged tokens that opened agency email systems. The agency says more than 60,000 messages were taken from one agency in that case. That example makes the trust hierarchy visible. The service accepting the token depended on the issuer's key. Once the key was compromised, apparently valid signatures could no longer separate legitimate claims from attacker-made ones.
Neither scenario is solved by telling users to choose a longer password. A stronger initial login helps against some account attacks; it does little for a live token copied after authentication or a key that can mint new tokens. Teams need to know which failure they are defending against before choosing a control.
The four places to audit
The first is issuance. Who may mint a token, which signing keys are trusted, how are those keys protected, and can a verifier reject an old key quickly after compromise? The second is custody. Where can the token appear after issue: browser storage, application logs, crash reports, URL parameters, CI output, telemetry or a developer's clipboard? A token with a short lifetime still gives an attacker a useful window if it can be copied into a place the defenders do not monitor.
The third is acceptance. A receiving service needs to check the intended audience, issuer, expiration and relevant scope rather than treating any correctly signed blob as universal permission. If one token is valid across too many services, a leak in a modest application can become a key to a more important one. The fourth is withdrawal. When an employee leaves, a device is lost, a key is rotated or an attack is detected, how quickly does the relying service actually stop accepting the old authority? “Revoked” in a console is an aspiration until the enforcement point receives and acts on the change.
These are not four independent departments. A narrow scope reduces the damage of theft. Reliable logging helps investigators find where a token was exposed. Revocation can limit the remaining time, but cannot un-send data already accessed. The point is to shorten both the path to misuse and the time during which the misuse remains valid.
AI agents put the same old credential in a new pair of hands
NIST says the final report added high-level considerations about AI and post-quantum migration after feedback on the draft. It explicitly does not present a complete toolkit for either. That boundary is useful. An agent calling tools on behalf of a person still needs a token, a service identity or both. The familiar questions remain: whose authority is it using, how narrowly is that authority scoped, and how can it be withdrawn? The new complication is that software may decide when to exercise the authority across a chain of tasks.
A practical test is to ask what happens when an agent reads untrusted material that asks it to call an unrelated tool. If its credential allows broad access, a prompt-injection failure can become an authorization failure. That is our inference from the trust model, not a measured result in IR 8587. The document's value is that it gives a team a vocabulary for the credential side of the problem without pretending the model side has been settled.
What a response drill should reveal
Imagine an access team discovers a token in an application log. A weak drill stops after the log is deleted. A useful one asks which systems ingested that log, who could read its copies, when the token was last accepted, and whether the token's scope reaches an unrelated service. If the token is still live, the team needs a path to kill that authority and watch for attempted reuse. If the token cannot be revoked individually, the architecture has converted a small disclosure into a broader rotation problem.
Now imagine the signing key rather than one token was exposed. The response changes scale: every claim signed by that key may need to be distrusted for a period, and relying services need a dependable way to learn that the key is no longer valid. Investigation must distinguish tokens the attacker minted from those issued legitimately. An audit log that records only a successful signature check will not be enough. These are scenario tests derived from the trust model, not a claim that a particular provider currently lacks the controls.
The operational question is also who gets the telephone call. Identity, application security, incident response, a cloud provider and business owners may each control a different step. IR 8587 treats token protection as a shared responsibility because the token crosses organizational boundaries. The fastest safe revocation procedure is the one tested before a Friday-night compromise.
What this report does and does not establish
The report is guidance, not a survey of every cloud provider's actual deployment. It cannot tell us how many exposed tokens exist today, whether a particular tenant is vulnerable, or which one of many mitigations will fit every architecture. Its strongest contribution is the division of labor: providers have to design secure token services, while customers have to configure and operate their side of the trust relationship. An organization can buy a capable identity platform and still leave a token in a log. A provider can build a flawless user interface and still need disciplined key management behind it.
The ordinary user sees a login box. The defender has to see a lifecycle. Authority is minted, passed around, accepted and eventually killed. Security lives in the handoffs.
Session authority must be guarded at issuance, storage, use and revocation, not only at the login screen. The report does not measure the current exposure of any specific cloud tenant or provider.