NIST Finalises New Guidance to Protect Cloud Tokens From Theft, Forgery and Misuse

NIST Finalises IR 8587 to Strengthen Token and Assertion Security

The National Institute of Standards and Technology (NIST) has finalised NIST Interagency Report 8587, a new set of implementation recommendations designed to help federal agencies and cloud service providers protect identity tokens, access tokens and assertions from forgery, theft and misuse.

Published in September 2026, the report focuses on a security component that often operates behind the scenes of modern cloud applications. Tokens and assertions are used to represent identity and authorisation across systems, including single sign-on (SSO), identity federation, APIs and workload access.

NIST developed the guidance primarily for federal environments and their cloud service providers, but the report notes that its recommendations are also relevant to cloud services more broadly.

The final report builds on updates to NIST SP 800-53, particularly the identity provider and authorisation server control known as IA-13. It provides more detailed implementation guidance around cryptographic keys, token verification, token lifecycle management and cloud provider responsibilities.

Why Token Security Matters

A token can act as evidence that a user, application or workload has been authenticated or authorised to access a particular resource.

That makes tokens valuable targets.

NIST points to recent incidents in which attackers were able to steal, modify or forge tokens and assertions used by enterprise SSO and federation systems. In some cases, compromised signing keys allowed attackers to generate apparently legitimate assertions and gain access to protected resources.

The report describes a December 2020 supply-chain intrusion in which attackers used forged SAML assertions to bypass MFA and other application-level protections after compromising relevant identity infrastructure. It also discusses a separate SSO and federation incident involving exposed signing keys and failures in token validation.

The underlying security lesson is straightforward: a valid-looking token is not automatically trustworthy.

Its issuer, signature, scope, audience, validity and usage context all need to be considered before access is granted.

What NIST IR 8587 Covers

The report concentrates on IAM systems that use digitally signed assertions and tokens based on asymmetric cryptography.

The guidance covers scenarios including:

• Single sign-on

• Identity federation

• API access

• Workload identity

• Identity providers

• Authorisation servers

• Cryptographic key management

• Token verification

• Token lifecycle management

• Session monitoring

• Token revocation

• Logging and security analysis

NIST specifically excludes some systems from the controls covered by the report, including systems based on symmetric cryptography, API keys and certain stateful management approaches.

The Shared Responsibility Challenge in Cloud Security

One of the report's important themes is the relationship between cloud service providers and their customers.

NIST describes responsibilities that can exist on both sides of the cloud shared-responsibility model.

Cloud providers may be responsible for areas such as:

• Core IAM services

• Token issuance and signing

• Secrets storage

• Infrastructure logging and monitoring

• Underlying infrastructure

Cloud consumers may be responsible for:

• IAM policy configuration

• Application and user access controls

• Application secrets

• Authentication configuration

• Session management

• Application logging

• Incident response

Some areas, including continuous monitoring, user education, incident response and token revocation, can require cooperation between both parties. The precise boundaries depend on the service model, contracts and technical capabilities exposed by the provider.

This means token security cannot always be treated as a problem that belongs exclusively to the cloud provider or the customer.

Protecting the Cryptographic Keys Behind Tokens

One of the strongest themes in IR 8587 is the protection of signing keys.

Identity assertions and access tokens are commonly digitally signed. If an attacker obtains the private key used to sign them, that attacker may be able to create tokens or assertions that appear legitimate.

NIST therefore recommends protections around the complete cryptographic key lifecycle, including:

1. Key generation

2. Key distribution

3. Key storage

4. Key usage

5. Key rotation

6. Key revocation

7. Key destruction

For systems assessed at moderate impact or above, the report says signing keys must be stored using hardware-based, hardware-backed or otherwise isolated mechanisms. It also states that signing keys should not be persistently stored directly on applications, servers, virtual machines or containers.

Possible protection mechanisms discussed by NIST include hardware security modules (HSMs), secure enclaves, trusted execution environments and isolated key-management services.

For high-impact systems, NIST adds requirements around isolating the use of signing keys and cryptographic functions themselves.

Key Rotation Becomes a Lifecycle Issue

NIST also addresses how long signing keys should remain active.

For high-impact systems, the report says signing keys should have a maximum active usage period of no more than 90 days.

For moderate- and low-impact systems, longer periods may be appropriate, but the report recommends that these periods remain below one year. Organisations should consider shorter periods when key protections are weaker or compromise detection and recovery capabilities are limited.

The report also recommends documenting the entire rollover process, including:

• Key creation

• Publication

• Activation

• Overlap

• Deactivation

• Removal from trust stores

• Revocation

• Destruction

Automation is encouraged where practical.

Token Verification Must Go Beyond Checking a Signature

Another major area of IR 8587 is token verification.

NIST says relying parties and resource servers need to evaluate tokens at the appropriate level of use and confirm that the token represents an identity with the permissions required for the requested service.

This means security teams should not treat cryptographic validity as the only check.

NIST recommends considering factors such as:

• Token source

• Digital signature

• Scope

• Audience

• Validity period

• Token identity

• Intended environment

• Context surrounding the request

The report specifically states that the scope, validity, source and integrity of identity assertions and tokens should be confirmed before access is granted.

Short-Lived Tokens and Token Lifecycle Management

IR 8587 also places significant emphasis on token lifetime.

NIST recommends that access and identity tokens have defined, short lifetimes, with expired tokens rejected by authorisation services and policy enforcement points.

The report recommends that access and identity tokens generally be valid for no more than one hour, while also recognising that organisations have different risk profiles and use cases. It therefore recommends configurable token validity periods for cloud consumers.

The broader lifecycle includes:

Generate → Issue → Refresh → Validate → Monitor → Revoke → Expire

This approach limits the period during which a stolen token can potentially be reused.

Audience Restriction and Replay Protection

NIST also highlights the importance of restricting where a token can be used.

The report says tokens and assertions must include explicit audience information, and access-control mechanisms should reject tokens with missing or incorrect audience restrictions.

This addresses a class of attacks in which a legitimate token is redirected into an unintended environment.

Replay is another concern.

NIST recommends uniquely identifying tokens and assertions and validating their uniqueness before access decisions. Sender-constrained mechanisms and refresh-token rotation are also discussed as ways to reduce replay risks.

Monitoring Token Usage

Token security does not end after issuance.

NIST recommends continuous monitoring and analysis of token usage to help identify potential compromise and support contextual access decisions and forensic investigations.

Relevant signals can include:

• Geolocation

• Device information

• Usage velocity

• Token activity

• Identity context

• Actions performed across services

NIST also recommends that token and assertion usage data be available in formats that can be consumed by security tools such as SIEM, UEBA and CNAPP platforms where appropriate.

This creates a broader security loop:

Token → Usage → Telemetry → Detection → Risk Decision → Response

Keep Tokens Out of Logs and CI/CD Artifacts

One particularly practical recommendation concerns software development and deployment environments.

NIST states that tokens must be protected from exposure in:

• System logs

• CI/CD pipelines

• Build artefacts

• Execution traces

• Debug output

• Cache directories

The report recommends retrieving secrets through dedicated secret-management systems and injecting them ephemerally at runtime rather than writing them into logs or deployment artefacts.

This is particularly relevant for DevSecOps teams because a credential that appears harmless in a build log can remain accessible long after the original deployment has finished.

NIST says detected token exposure should be treated as a security incident and handled through established incident-response procedures.

Workload Identity Gets Specific Attention

Modern cloud environments increasingly rely on machine-to-machine communication.

Applications, services and automated workloads may need tokens even when there is no human user involved.

NIST recommends that workload identities use tightly scoped, short-lived tokens issued through approved enterprise identity platforms.

Where feasible, it also recommends sender-constrained mechanisms such as mTLS and DPoP. The report discusses SPIFFE-based workload identities as another approach for dynamically providing verifiable workload identities rather than relying on long-lived static credentials.

This is especially relevant as cloud environments become more distributed and automated.

What About AI Agents?

NIST explicitly includes a section covering AI and AI agents.

The report notes that AI systems, particularly agentic AI systems, can use signed tokens or assertions to access systems, data, tools and APIs.

NIST recommends applying the report's token-security guidance when agents use signed tokens.

However, it also makes an important distinction: IR 8587 is not a comprehensive guide to AI-agent access security.

NIST says agentic AI introduces additional IAM challenges that require further guidance and, in some cases, new or expanded standards and protocols.

This makes the AI section particularly relevant as organisations increasingly connect AI systems and agents to enterprise APIs and cloud resources.

Federation and API Security

The report also addresses the way tokens operate across federated systems and APIs.

For API access, an authorisation server can authenticate a client and issue an access token. The protected resource then uses the information contained within that token to make an access decision.

For machine-to-machine scenarios, traditional user reauthentication may not be practical. NIST therefore discusses contextual signals such as device registration, network restrictions, transaction behaviour and proof-of-possession mechanisms.

For federation, the report emphasises the importance of trust relationships and approved identity providers.

The objective is to ensure that a token issued in one context cannot automatically become trusted in another context simply because the cryptographic signature appears valid.

Front-Channel vs Back-Channel Token Presentation

NIST also discusses how tokens are transmitted between identity providers and protected resources.

In a front-channel flow, tokens or assertions can pass through a browser or client. This can increase exposure to leakage, interception or manipulation.

For high-risk scenarios, the report does not recommend front-channel presentation.

By comparison, back-channel approaches allow a resource server to obtain the token directly from the authorisation server. NIST notes that this can reduce token exposure and provide additional opportunities to detect forged tokens.

The report also references protections relevant to OAuth deployments, including PKCE, exact redirect URI matching and issuer validation.

Encryption and Sensitive Token Data

Signing and encryption address different security requirements.

A signature can help establish integrity and authenticity, while encryption can protect sensitive information contained within a token.

NIST recommends considering payload-level encryption when tokens or assertions contain sensitive information such as personal data, roles, group membership or administrative indicators, particularly when they pass through potentially untrusted environments.

The report mentions mechanisms including JSON Web Encryption (JWE) for JWTs and encrypted SAML assertions.

Preparing for Post-Quantum Cryptography

IR 8587 also connects token security with the transition toward post-quantum cryptography.

Token and assertion systems rely on public-key cryptography for signing, verification and trust management. NIST notes that widely used mechanisms such as RSA, ECDSA and ECDH are vulnerable to attacks from a sufficiently capable cryptographically relevant quantum computer.

The report therefore highlights the implications of post-quantum migration for systems that issue, sign, validate, store or transmit tokens and assertions. It references FIPS 203 ML-KEM and FIPS 204 ML-DSA as standardised post-quantum mechanisms.

NIST does not present IR 8587 as a complete post-quantum migration guide. Instead, PQC is included as an additional consideration for token and assertion infrastructures.

What Changed From the Draft?

The final version incorporates feedback received during the public review process.

According to NIST, the organisation and CISA received nearly 250 individual comments from more than 20 contributors, along with feedback through the Joint Cyber Defense Collaborative and a public webinar.

NIST highlights several changes in the final publication:

1. Signing key protection

The final report provides greater flexibility and clarity around protection and usage of signing keys.

2. Signing key validity periods

The final document moved away from deployment-model-based validity periods and instead focuses on system classification and transaction sensitivity.

3. Workload identity

Workload scenarios were integrated into the document, reinforcing the use of short-lived tokens instead of static credentials and secrets.

4. Updated standards references

The final publication includes additional standards, protocols and profiles that organisations can use when implementing the recommended capabilities.

What This Means for Cloud Security Teams

The announcement highlights a broader industry shift toward treating identity infrastructure as a critical security boundary rather than simply an authentication service.

For cloud security teams, the report provides several areas to examine:

Identity infrastructure

Review identity providers, authorisation servers and federation relationships.

Signing keys

Understand where signing keys are generated, stored, used, rotated and revoked.

Token lifetime

Review whether tokens remain valid longer than necessary.

Audience and scope

Ensure tokens cannot be reused outside their intended environment.

CI/CD

Search build logs and deployment artefacts for exposed tokens and credentials.

Workload identity

Replace long-lived static credentials with appropriately scoped, short-lived credentials where practical.

Monitoring

Ensure token activity can be correlated with security telemetry.

Incident response

Define how compromised tokens and signing keys are revoked and replaced.

AI agents

Assess how AI systems and agents receive and use identity credentials when accessing enterprise resources.

These areas are not simply about preventing token theft. They also reduce the potential impact when credentials, sessions or signing infrastructure are compromised.

NIST's Broader Security Message

IR 8587 places token security within a larger model of secure-by-design cloud identity.

For cloud service providers, NIST emphasises secure development, transparency, configurability and interoperability.

For consumers, the focus includes secure IAM configuration, access controls, secrets management, logging, monitoring and incident response.

The report also makes clear that the recommendations are voluntary for federal agencies and CSPs unless adopted through applicable policy, contracts or other binding arrangements.

The guidance therefore functions as an implementation roadmap rather than a universal compliance mandate.

The Bigger Picture

The development reflects growing demand for stronger controls around identity infrastructure as organisations move toward cloud-native applications, APIs, machine identities and AI agents.

Tokens are designed to make distributed systems work efficiently. But their value also makes them attractive targets. A stolen token can potentially provide access without requiring an attacker to compromise a password, while a compromised signing key can create a much larger trust problem.

NIST IR 8587 responds by treating token protection as a lifecycle problem.

That means securing the key, validating the token, restricting its audience and scope, limiting its lifetime, monitoring its use, and having mechanisms to revoke and replace compromised credentials.

For organisations building modern cloud and AI infrastructure, these controls provide a useful framework for examining where identity decisions are made and where trust can break down.

Key Takeaways

• NIST finalised IR 8587 on 15 September 2026.

• The report focuses on identity tokens, access tokens and assertions.

• Its primary scope is federal agencies and cloud service providers.

• SSO, federation, APIs and workload access are key scenarios.

• Signing-key protection is a central recommendation.

• NIST recommends short-lived tokens and controlled token lifecycles.

• Audience and scope restrictions are important to prevent misuse.

• Token activity should be continuously monitored.

• Tokens should not appear in logs or CI/CD artefacts.

• Workload identities should use tightly scoped, short-lived credentials.

• AI agents introduce additional IAM challenges that require further guidance.

• The report also considers post-quantum cryptography migration.