Today, the U.S. federal cybersecurity authorities issued a sweeping new set of guidelines aimed at preventing misuse and theft of identity and access tokens—the credentials that let apps rely on identity providers for authentication instead of repeatedly demanding passwords. The Cybersecurity and Infrastructure Security Agency (CISA) and the National Institute of Standards and Technology (NIST) published the final version of NIST Interagency Report 8587, which delivers technical measures for safeguarding federated login systems, APIs, and machine-to-machine and cloud environments.
What’s at stake
Identity tokens—such as those used via single sign-on, signed SAML assertions, OAuth identity and access tokens, and similar credential tokens—are key to modern authentication flows. When attackers steal valid tokens, compromise signing keys, or exploit lax validation, they can bypass multi-factor authentication and impersonate legitimate users with dangerous consequences. Recent incidents cited in the guidance include forged assertions and signing-key misconfigurations, one of which exposed more than 60,000 emails in a federal agency breach.
Key requirements in the new guidance
The NIST checklist mandates detailed documentation of token architectures, validation, session handling, key management, revocation, and logging policies. It clarifies that while implementation remains voluntary unless bound by policy or contract, the language “MUST” and “SHOULD” in the text defines enforceable expectations.
One core requirement is strict handling of cryptographic signing keys. Keys must be generated using approved algorithms and modules validated under FIPS 140 standards, tracked by use-case, transmitted securely, and never exported in plain text. For moderate-impact systems, signing keys need hardware-protected or otherwise isolated storage; high-impact systems must further segregate signing operations away from general applications or OS processes. Rotation of keys must be risk-based and automated; high-impact system keys must be replaced at least every 90 days, while those for moderate and low impact typically expire within a year.
Strong validation, token lifetimes & refresh tokens
Tokens and assertions are required to include a full set of attributes: issuer, subject/client, intended audience, validity windows (issuance and expiration), unique ID or nonce, authentication time, and digital signature. Before granting access, resource servers must verify the integrity, audience, signature, source, and scope of each token. Furthermore, the guidance emphasizes compartmentalizing signing keys to prevent misuse across environments—for example to avoid a token from one tenant or deployment being accepted by another.
Token lifetime is tightly controlled: identity and access tokens should generally expire within one hour, with shorter windows for higher-risk resources. For refresh tokens, the rules call for secure storage, revocation policies, replay protection, and reauthentication when compromise is suspected. To prevent replay and theft, defenses like mutual TLS or proof-of-possession mechanisms, audience restrictions, and conditional-access based on device, geolocation, and behavior are strongly advised.
Additional measures for modern threats
The guidance covers credentialed services and automated workloads: such systems should use short-lived, tightly scoped credentials issued from approved identity platforms, avoiding static secrets. All token activity must feed into tamper-proof logs; sensitive tokens and personal data should never be logged. If tokens are exposed via CI/CD pipelines, build artifacts, caches, or output, those exposures must trigger security incidents.
Also new: the guidelines extend to systems where agentic AI uses signed tokens to access APIs or services, though broader AI identity risks are flagged for future standards. A further warning is issued about readiness for post-quantum cryptography: public-key inventories should be prepared, and organizations should anticipate larger, quantum-resistant keys that may challenge existing token formats like JWTs, cookies, or HTTP headers.
These measures represent a shift from ad hoc or patchwork token security toward treating identity tokens as part of a tightly governed, continuously monitored lifecycle. Risk-based key rotation, hardware protection, strict validation, and detailed logging combine to raise the bar significantly.
Why this matters: The new NIST/CISA token checklist essentially redefines what secure identity management looks like for federal agencies, cloud providers, and private sector services that face similar threats. Stronger token protections guard against attack vectors that often yield broad access with minimal friction. As networks grow more distributed and AI agents proliferate, mistakes in token handling will become even costlier.
