NIST and CISA finalize playbook to stop token theft and forgery

NIST and CISA have finalized guidelines to help federal agencies and cloud service providers (CSPs) protect identity and access tokens from forgery, theft, and misuse.

The guidance, Protecting Tokens and Assertions from Forgery, Theft, and Misuse (NIST IR 8587), explains how agencies and cloud providers can strengthen key management, token verification, and token lifecycle controls. It also covers how identity providers and authorization servers should be designed and managed.

“This publication provides implementation considerations for protecting tokens appropriately,” said Ryan Galluzzo, NIST Digital Identity Program Lead and one of the publication’s authors. “Anyone who is using tokens as part of their access management infrastructure can look to this for insights, whether they are in government or commercial industry.”

Representative architecture: Token- and assertion-based systems (Source: NIST)

Why tokens need protection

The guide focuses on tokens that help digital systems confirm who or what is requesting access and which resources they are allowed to use.

Tokens are widely used by cloud services and other digital systems. They can contain protected information about a user and support authentication. They also make single sign-on (SSO) possible, allowing users to access several applications without signing in to each one separately.

Tokens and identity assertions also support zero trust security by helping systems verify access before allowing it.

Poorly protected tokens can give attackers access to sensitive systems. NIST cites an attack in which foreign actors used forged tokens created with a stolen commercial signing key to access government email accounts. More than 60,000 emails were stolen from one agency.

Protecting keys and verifying tokens

NIST IR 8587 covers identity and access management (IAM) systems that use digitally signed assertions and tokens based on asymmetric cryptography to make access decisions.

These systems are commonly used for SSO, identity federation, API access, and access by workloads such as applications and automated services.

The guidance focuses on protecting the cryptographic keys used to sign tokens and assertions, limiting how those keys can be used, and making sure tokens are properly verified before access is granted. It addresses token lifetimes, revocation, session management, logging, and protections against the reuse of stolen tokens.

Systems that do not rely on asymmetrically signed assertions and tokens are discussed where relevant but are outside the main scope of the guidance.

Cloud providers and customers have different roles

The guidance sets out responsibilities for both cloud providers and the agencies or organizations that use their services.

Cloud providers are responsible for protecting the infrastructure and services they operate. This includes securing identity providers and authorization servers, protecting signing keys, issuing tokens securely, and providing customers with security features and configuration options.

Customers are responsible for configuring the services they use, managing access policies, reviewing permissions, and making use of the security controls available from their providers.

Some security tasks require coordination between the two sides. These include responding to compromised tokens or signing keys, sharing security signals, revoking access, and investigating incidents.

Defining these responsibilities can reduce the risk of security gaps.

Organizations should collect information about token use and look for activity that could indicate stolen credentials, forged tokens, or unauthorized access.

Maintaining logs that can support security monitoring and incident investigations is recommended. They should also monitor changes to access permissions and configurations and have procedures for responding when tokens or signing keys may have been compromised.

These controls can help them detect misuse and determine which accounts, applications, or resources may have been affected during an incident.

Preparing for AI agents and PQC

AI agents use the same kinds of signed tokens to access email, files, APIs, tools, and other systems. NIST says organizations should apply these token protections to AI agents too, but it also acknowledges that agents introduce broader identity and access problems that this guide does not cover, and that additional standards and guidance will be needed.

NIST added considerations for the transition to post-quantum cryptography (PQC). Organizations should understand where public-key cryptography is used in their identity systems and consider how a future move to post-quantum algorithms could affect tokens, protocols, and applications.

Download: The Agentic Software Development Guide