CISA, NIST Publish Checklist to Secure Identity Tokens From Theft

Key Takeaways

• CISA and NIST have jointly released comprehensive technical guidance for securing identity and access tokens.
• The new framework, NIST Interagency Report 8587, targets federal agencies and cloud service providers, offering a roadmap to mitigate risks like token theft, forgery, and misuse in modern authentication environments.
• Key recommendations include robust cryptographic key management, stringent token validation, strict token lifetime controls, and continuous monitoring to protect single sign-on, API access, and machine-to-machine authentication.
• The guidance is voluntary but establishes measurable implementation expectations for organizations, particularly those handling moderate to high-impact systems.

The Cybersecurity and Infrastructure Security Agency (CISA) and the National Institute of Standards and Technology (NIST) have published definitive technical guidance aimed at fortifying identity and access tokens against an array of adversarial tactics, including theft, forgery, replay attacks, and general misuse.

Issued on September 15, 2026, as NIST Interagency Report 8587, this document provides a critical framework for federal agencies and cloud service providers. It outlines strategies to enhance the security posture of single sign-on (SSO), identity federation, API access, and machine-to-machine authentication systems.

Identity tokens and signed assertions are fundamental components that enable applications to trust authentication decisions made by an identity provider, thereby eliminating the need for users to repeatedly supply credentials.

CISA and NIST Address Identity Token Security Risks

Despite their utility, these tokens present significant vulnerabilities. Threat actors who successfully steal a legitimate token, compromise a signing key, or exploit validation weaknesses can bypass multifactor authentication (MFA) and gain unauthorized access to connected resources, masquerading as trusted users.

The report highlights past incidents involving manipulated SAML assertions and improperly scoped signing keys, including one notable event that resulted in the exposure of over 60,000 emails from a federal agency.

According to the technical guidance published by NIST, this report builds upon the IA-13 “Identity Providers and Authorization Servers” control, which was initially introduced in NIST SP 800-53 Release 5.1.1.

Organizations are strongly advised to meticulously document their token architectures, protocols, token lifetimes, validation processes, key management practices, revocation procedures, session controls, logging mechanisms, and incident response plans. While adherence to this guidance is voluntary unless mandated by policy or contract, the use of terms like “MUST” and “SHOULD” establishes clear, measurable expectations for implementation.

Strengthening Cryptographic Key Protection

A cornerstone of the new requirements is the enhanced protection of cryptographic keys used for signing tokens. These keys must employ approved algorithms and FIPS 140-validated modules. Furthermore, they must be inventoried by their specific purpose, transmitted via protected channels, and never exported in plaintext.

For systems classified as moderate-impact and above, signing keys are mandated to utilize hardware-based, hardware-backed, or otherwise isolated storage solutions. High-impact systems face even stricter requirements, necessitating the isolation of signing operations from general-purpose applications and operating systems.

NIST advocates for frequent, risk-based key rotation, supported by automated rollover workflows. Specifically, signing keys for high-impact systems should remain active for no more than 90 days. For moderate- and low-impact systems, key usage should generally not exceed one year. Comprehensive rollover plans should encompass the entire lifecycle of a key, including creation, publication, activation, overlap, deactivation, removal, emergency revocation, and destruction.

Enhanced Token Verification and Lifetime Controls

The technical checklist also introduces more rigorous token verification protocols. Assertions and tokens must explicitly contain details such as the issuer, subject or client, intended audience, issuance time, validity window, a unique token identifier or nonce, authentication time, and a valid signature.

Resource servers are required to verify the signature, source, integrity, scope, and audience of a token before granting access. Additionally, signing keys should be constrained to the lowest practical boundary, such as a specific tenant, customer group, application, or deployment environment. This measure is crucial in preventing cross-tenant abuse, where one environment might erroneously accept a key from another environment.

Token lifetime is another critical control addressed. Access and identity tokens should generally expire within one hour, with even shorter durations recommended for higher-risk resources. Refresh tokens, too, must have expiration dates, replay protections, secure storage, and robust revocation policies. In instances where compromise is suspected, authorization services are prohibited from accepting associated refresh tokens without first reauthenticating the user.

Resistance to Theft and Replay Attacks

To bolster resistance against token theft and replay attacks, CISA and NIST recommend sender-constrained mechanisms, including mutual TLS and Demonstrating Proof of Possession (DPoP). Other strategies include explicit audience restrictions and granular conditional-access decisions informed by factors such as device, network, geolocation, and behavioral context. For workload identities and automated services, the guidance emphasizes the use of tightly scoped, short-lived credentials from approved identity platforms, discouraging reliance on static secrets.

Continuous Monitoring and Future Considerations

Continuous monitoring is highlighted as equally vital. Token activity must be fed into tamper-resistant logs and integrated with Security Information and Event Management (SIEM), User and Entity Behavior Analytics (UEBA), or cloud-native security tools. Crucially, raw tokens and personal data must never be logged. The report also warns against exposing tokens in CI/CD logs, console output, cache directories, or build artifacts, stipulating that any discovered exposure should be treated as a security incident.

NIST IR 8587 extends these safeguards to agentic AI systems that utilize signed tokens to access tools, data, APIs, or services, while acknowledging that broader AI identity risks will necessitate additional standards. The report further advises agencies and CSPs to inventory their public-key cryptography and prepare for post-quantum migration, noting that larger quantum-resistant keys and signatures could potentially strain existing systems like JWTs, browser cookies, and HTTP headers.

For cybersecurity defenders, the overarching message is clear: token security must be approached as a continuously monitored lifecycle rather than a one-time configuration of an identity platform.

What You Should Do

• Review and update existing token architecture documentation to align with NIST IR 8587 recommendations.
• Implement robust key management practices, ensuring cryptographic keys for token signing use FIPS 140-validated modules, are inventoried, and are never exported in plaintext.
• For moderate- and high-impact systems, ensure signing keys are stored in hardware-based or isolated environments, with high-impact systems requiring isolation of signing operations.
• Establish and automate frequent, risk-based key rotation schedules, particularly for high-impact systems (every 90 days) and moderate/low-impact systems (less than one year).
• Enhance token verification processes to ensure all assertions and tokens contain necessary issuer, subject, audience, validity, and signature information.
• Implement strict token lifetime controls, aiming for access and identity token expiration within one hour, with shorter durations for high-risk resources.
• Apply expiration, replay protections, and secure storage to refresh tokens, along with policies for reauthentication upon suspected compromise.
• Utilize sender-constrained mechanisms (e.g., mutual TLS, DPoP), explicit audience restrictions, and fine-grained conditional access to prevent token theft and replay.
• Establish continuous monitoring for token activity, feeding data into tamper-resistant logs and integrating with SIEM/UEBA tools, while ensuring raw tokens and personal data are never logged.
• Conduct regular audits to prevent accidental token exposure in logs, caches, or build artifacts, treating any discovery as a security incident.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.