On September 15, 2026, the National Institute of Standards and Technology (NIST) announced the final version of NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse, written with the Cybersecurity and Infrastructure Security Agency (CISA). It follows a December 2025 draft, which the authors revised in response to public feedback. NIST says the report responds to its tasking in Executive Order 14306 and builds on recent updates to Special Publication (SP) 800-53.
A token is a small piece of cryptographically protected information that identifies a user or service and what it is permitted to access. The report opens by noting that recent incidents at major cloud service providers resulted from the ability to steal, modify, or forge identity tokens and assertions.
Who it applies to
The report is written primarily for federal agencies and the cloud service providers (CSPs) they work with. NIST says it can help any organization that handles identity tokens. Conformance is voluntary for CSPs and agencies unless policy or another binding agreement says otherwise. The guidance expands on IA-13, Identity Providers and Authorization Servers, the control NIST added to SP 800-53 in release 5.1.1 in November 2023.
A shared responsibility table splits the work. The CSP is responsible for token issuance and signing. The customer is responsible for identity and access management (IAM) policy configuration, application secrets management, session management, and application logging. Token revocation, incident response, and continuous monitoring are shared.
What the report asks for
In the report, MUST marks a requirement to follow in order to conform, and SHOULD marks a preferred course of action. The list below uses the words the same way.
- Signing key storage. For systems assessed at moderate impact or above, signing keys must be stored in a hardware-based, hardware-backed, or otherwise isolated key storage mechanism.
- Key rotation. Organizations should automate key rotation. For high-impact systems, signing keys should be in active use for no more than 90 days. For moderate and low impact systems, the period should be less than one year.
- Key scope. Signing keys must be scoped at the lowest reasonable level, such as a single tenant or customer, and must not be used for any other purpose.
- Token lifetime. Access tokens and identity tokens should be valid for no more than one hour. CSPs should make the validity length configurable by customers.
- Audience. Every token and assertion must include an explicit audience field, and access control mechanisms must reject tokens where it is missing or incorrect.
- Workloads. Workload identities, including automated services and machine-to-machine processes, must use tightly scoped, short-lived tokens.
- Pipelines and logs. Tokens must be protected from exposure in system logs, CI/CD pipelines, and build or deployment artifacts. Pipelines must retrieve secrets only through secret management systems. The tokens themselves must not be stored in logs.
What changed from the draft
NIST says the guidelines on cryptographic key protection are now less prescriptive and more outcome-based. The final version adds references to current and emerging standards, and high-level considerations for AI and for migration to post-quantum cryptography. On AI, the report says organizations should apply the guidelines when agents use signed tokens to access systems, data, tools, or APIs. It also states that it is not a comprehensive guide to AI agent access risks.
Where to start
- Build an inventory of signing keys: where each is generated, stored, and used. The report says organizations should maintain one.
- Compare the token lifetimes configured in your identity provider with the one-hour recommendation.
- Search logs, pipeline output, and artifact stores for tokens. The report says any detected exposure should be treated as a security incident.
- Confirm that your applications and APIs check the audience of every token and raise a security alert when it is missing or incorrect.
- Review the token logs your CSP offers. The report tells federal agencies to enable logs that are not on by default.
This article is general information, not legal or procurement advice. Confirm which requirements apply to your systems with the relevant agency.