Protecting Tokens from Forgery and Theft: What NIST IR 8587 Asks For

IdentityOctober 02, 2026

NIST and CISA's final token guidance sets clear expectations for signing keys, token lifetimes, audience checks and revocation. Here is what it means for any SSO or API setup, and what to check this week.

Abstract navy illustration of a glowing teal core surrounded by concentric blue rings with arc segments, linked by thin lines to outer nodes, suggesting tokens issued to connected systems

Most identity attacks no longer need a password. Once a user has signed in, the identity provider issues signed tokens and assertions. Applications then trust those tokens for an hour, a day or longer. An attacker who can steal one of those tokens, or forge one with a stolen signing key, can get past MFA without triggering a login prompt.

In September 2026 NIST and CISA published the final version of NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse. It is written for US federal agencies and their cloud providers, but the recommendations apply to any organisation that runs single sign-on, federation or API access. This article summarises what the report asks for and turns it into steps you can start this week.

Why tokens became the target

The report starts from incidents rather than theory. It describes how attackers in a supply chain intrusion discovered in December 2020 compromised federation infrastructure, exposed signing certificates and minted forged SAML assertions that bypassed MFA. It then turns to a later case where a consumer signing key was exposed. Because of a token validation failure, that key could sign tokens that enterprise email systems accepted. The report says more than 60,000 emails were exfiltrated from a single agency.

Microsoft's own analysis of the Storm-0558 activity describes the same root cause. An inactive consumer signing key was trusted for enterprise tokens because of a validation issue.

The lesson is that both kinds of failure matter. A key that leaks lets an attacker forge tokens. A relying party that checks too little lets an attacker reuse tokens in places they were never meant for.

Protect the signing keys

The IR 8587 full text is direct about key protection:

Isolated storage. For systems at moderate impact or above, signing keys must live in hardware-based, hardware-backed or otherwise isolated key storage, such as an HSM or an isolated key management service.
No keys at rest on workloads. Signing keys must not be stored persistently on the servers, virtual machines or containers that use them. Where key material has to be present, it is retrieved at runtime and protected while in memory.
Narrow scope. Keys must be scoped to the lowest reasonable level, such as a tenant or a set of customers, and to one environment (development, test or production). Signing keys must not be used for any other purpose.
Rotation. For high-impact systems, signing keys should have a maximum active usage period of no more than 90 days. For moderate and low impact systems, the period should still be under one year. Rotation should be automated so that rollover is routine rather than an emergency.

If you run your own identity provider, these are direct requirements for your team. If you use a hosted provider, they become questions to ask about where tenant signing keys are held, how they are scoped and how often they rotate.

Shorten what a stolen token is worth

Key protection prevents forgery. Lifetime and binding controls limit theft, which is far more common. The report recommends that access tokens and identity tokens be valid for no more than one hour, and says expired tokens must be rejected.

Refresh tokens need extra care. They can live longer than access tokens. However, the report says refresh tokens for interactive users should not outlive the reauthentication time frames in SP 800-63B-4 unless compensating controls exist. It also says they must be protected against replay through rotation or sender-constraining.

Sender-constraining ties a token to a key the client holds, so a token copied from a browser or a log is not enough on its own. The report points to DPoP, defined in RFC 9449, where the client proves possession of a private key on each request. It also points to mutual-TLS certificate-bound tokens. For workloads, it asks for tightly scoped, short-lived tokens and recommends sender-constrained mechanisms wherever feasible.

Validate strictly and revoke quickly

Three verification rules in the report deserve immediate attention:

Audience. All tokens and assertions must carry an explicit audience. Access control points must reject tokens with a missing or incorrect audience, and should raise a security alert when they see one.
Least scope. Token services must limit scope to what the intended operation needs.
Revocation on suspicion. Identity providers must not accept refresh tokens linked to a suspected-compromised identity token until the user has reauthenticated.

The report acknowledges that stateless tokens cannot always be revoked globally. Its answer is to make revocation status travel. It recommends implementing session revocation signals through the OpenID Shared Signals Framework and the Continuous Access Evaluation Profile (CAEP). Relying parties that receive a revocation must reject the token and end the sessions linked to it.

Keep tokens out of logs, and log the right things

Tokens leak in mundane places. The report says tokens must be kept out of system logs, CI/CD pipelines and build artifacts. Pipelines should pull secrets from a secret manager and inject them only at runtime. Any token found in a log or artifact should be treated as a security incident.

Logging is still essential, but it should record metadata rather than the token. Token and assertion events must be kept in tamper-resistant logs in a format your SIEM can consume. The tokens themselves, and any personal data inside them, must not be logged. Useful fields include the token type, issuer, scopes, a hashed client or user identifier, the audience, and timestamped issuance, refresh and revocation events. With these fields, you can spot one token being used from two locations, or a token presented to the wrong audience.

A checklist for this week

List every system that issues tokens or SAML assertions, including the identity provider, API gateways, CI/CD platforms and any self-hosted federation services.
For each issuer, record where its signing keys are stored, how they are scoped and when they last rotated. Flag any key held on a general-purpose server or older than one year.
Check access token and ID token lifetimes against the one-hour recommendation, and document any exceptions with a reason.
Review refresh token lifetimes and confirm that they rotate on use or are sender-constrained.
Test that each API and application rejects a token issued for a different audience. Wire those rejections to an alert.
Search logs, CI output and artifact stores for bearer tokens. Treat any finds as incidents and fix the source.
Ask your hosted identity provider which revocation signals it emits and which of your applications consume them.

Conclusion

IR 8587 does not introduce new cryptography. It sets clear expectations for practices that many organisations already know about but apply unevenly: isolated and rotated signing keys, short-lived and bound tokens, strict audience checks, and revocation that reaches every relying party. Together, these controls make a stolen token less useful and a forged one much harder to create.

A shared identity layer, such as OXU Identity, and centralised key management, such as OXU KMS, can make these controls easier to apply consistently. The checklist above is useful whatever platform you run.