CISA and NIST Release Technical Checklist for Safeguarding Identity Tokens From Theft and Misuse

The Cybersecurity and Infrastructure Security Agency (CISA) and the National Institute of Standards and Technology (NIST) have released final technical guidance to stop attackers from forging, stealing, replaying, or misusing identity and access tokens.

Published as NIST Interagency Report 8587 on September 15, 2026, it gives federal agencies and cloud service providers a roadmap for securing single sign-on, identity federation, API access, and machine-to-machine authentication environments.

Identity tokens and signed assertions allow applications to trust authentication performed by an identity provider rather than repeatedly challenging users for credentials.

CISA NIST Identity Token Security

However, adversaries who steal a legitimate token, compromise a signing key, or exploit weak validation can bypass multifactor authentication and access connected resources as trusted users.

The report cites incidents involving forged SAML assertions and improperly scoped signing keys, including one that exposed more than 60,000 emails from a federal agency.

According to the technical guidance published by NIST, the report expands on the IA-13 “Identity Providers and Authorization Servers” control introduced in NIST SP 800-53 Release 5.1.1.

Organizations should document token architectures, protocols, lifetimes, validation processes, key management, revocation procedures, session controls, logging, and incident response.

Conformance remains voluntary unless made binding through policy or contract, although the terms “MUST” and “SHOULD” establish measurable implementation expectations.

A central requirement is stronger protection for the cryptographic keys used to sign tokens. Keys must use approved algorithms and FIPS 140-validated modules, be inventoried by purpose, move through protected channels, and never be exported in plaintext.

For moderate-impact systems and above, signing keys must use hardware-based, hardware-backed, or otherwise isolated storage. High-impact systems must also isolate signing operations from general-purpose applications and operating systems.

NIST recommends frequent, risk-based key rotation supported by automated rollover workflows. Signing keys for high-impact systems should remain active for no more than 90 days, while keys for moderate- and low-impact systems should generally be used for less than one year.

Rollover plans should cover creation, publication, activation, overlap, deactivation, removal, emergency revocation, and destruction.

The technical checklist also tightens token verification. Assertions and tokens must identify the issuer, subject or client, intended audience, issuance time, validity window, unique token identifier or nonce, authentication time, and signature.

Resource servers must verify the signature, source, integrity, scope, and audience before granting access, while signing keys should be restricted to the lowest practical boundary, such as a tenant, customer group, application, or deployment environment. This prevents cross-tenant abuse in which one environment incorrectly accepts another environment’s key.

Token lifetime is another major control. Access and identity tokens should generally expire within one hour, with shorter periods applied to higher-risk resources.

Refresh tokens require expiration, replay protections, secure storage, and revocation policies. Where compromise is suspected, authorization services must not accept associated refresh tokens without first reauthenticating the user.

For theft and replay resistance, the agencies recommend sender-constrained mechanisms such as mutual TLS and Demonstrating Proof of Possession, explicit audience restrictions, and fine-grained conditional-access decisions informed by device, network, geolocation, and behavioral context.

Workload identities and automated services should receive tightly scoped, short-lived credentials from approved identity platforms instead of relying on static secrets.

Continuous monitoring is equally important. Token activity must feed tamper-resistant logs and integrate with SIEM, UEBA, or cloud-native security tools, but 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, and says any discovered exposure should be handled as a security incident.

NIST IR 8587 extends these safeguards to agentic AI systems when agents use signed tokens to reach tools, data, APIs, or services, while noting that broader AI identity risks require additional standards.

It also urges agencies and CSPs to inventory public-key cryptography and prepare for post-quantum migration, since larger quantum-resistant keys and signatures may strain JWTs, browser cookies, and HTTP headers.

For defenders, the message is clear: token security must be engineered as a continuously monitored lifecycle rather than treated as a one-time identity-platform configuration.

Learn 7 Metric-Gated AI SOC Deployment Phases – Download Free AI SOC Deployment Playbook 2026.