NIST Token Security Guidelines Shift the Burden to Cloud Providers and Agencies

NIST finalized new token security guidelines on September 15, 2026, after stolen credentials exposed a weakness that passwords and multifactor authentication cannot resolve alone. Developed with CISA, NIST IR 8587 targets the signed tokens and identity assertions behind cloud access, federation, and single sign-on.

The report changes the security conversation in one important way. A valid signature no longer provides enough confidence to grant access. Agencies and cloud providers must also verify where a token came from, what it can access, when it expires, and whether its behavior looks suspicious.

That demand responds directly to incidents such as Storm-0558. Microsoft found that the threat actor used a stolen signing key to forge tokens and enter email accounts. NIST says the campaign resulted in more than 60,000 stolen emails from one federal agency.

The central conflict is therefore shared responsibility versus fragmented control. Cloud providers issue tokens and operate core identity infrastructure. Agencies configure access policies, connect multiple environments, and investigate activity using whatever telemetry providers expose.

NIST IR 8587 tries to close the space between those responsibilities. Its recommendations cover signing-key isolation, token validation, revocation, workload identities, logging, and continuous monitoring. They apply most directly to federal systems, but NIST says commercial organizations can also use them.

NIST Token Security Guidelines Move Beyond Valid Signatures

NIST IR 8587 treats a correctly signed token as one security signal, not as final proof that an access request is trustworthy.

The final report focuses on systems using asymmetrically signed tokens and assertions. These include Security Assertion Markup Language, OpenID Connect, and OAuth-based deployments.

An assertion communicates authentication information from an identity provider to another system. An access token represents authorization to use particular resources or perform defined actions. Both can let users and services cross security boundaries without repeatedly presenting a password.

That efficiency makes them essential to single sign-on, cloud APIs, federation, and machine-to-machine access. It also makes them attractive targets. An attacker who steals a reusable token can inherit its permissions without defeating the original authentication process.

A compromised signing key creates a more serious problem. It can let an attacker create new tokens that appear legitimate to systems trusting that key. Those systems might accept the forged identity, permissions, and expiration data unless they apply further checks.

The NIST token security guidelines therefore require relying parties to validate more than the cryptographic signature. A relying party is the application or service making the access decision. It must confirm the token’s integrity, source, scope, validity, and intended environment.

Tokens should also contain an explicit audience restriction. The audience identifies the application, service, or security domain allowed to accept the token. Access controls must reject credentials with missing or incorrect audience values.

This requirement limits lateral movement. A token issued for one application should not become a general credential for unrelated services. The same principle applies across tenants, environments, and cloud boundaries.

NIST also calls for signing keys to have the narrowest reasonable scope. Providers can isolate them by tenant, customer group, or operating environment. Development and testing keys should not remain valid in production.

Keys used outside federally authorized environments should not sign credentials accepted inside those environments. An exception requires an intentional federation relationship and an appropriate trust agreement.

These measures address a dangerous property of federated systems. One compromised component can affect every service that trusts its output. Narrow scopes reduce the number of systems exposed when a key or token is stolen.

The report also distinguishes stateless and stateful access architectures. Stateful systems maintain centralized session information and can revoke sessions directly. Stateless systems package the needed information inside signed tokens that applications validate locally.

Stateless tokens work well across distributed services and high-volume APIs. However, their independence from a central session store can make immediate revocation harder. Short lifetimes, constrained use, and continuous evaluation help contain that weakness.

NIST is not asking organizations to abandon signed tokens. It is defining the surrounding controls needed when those tokens become portable authority across a distributed enterprise.

A Stolen Key Turned Cloud Trust Into an Attack Path

Storm-0558 showed that strong user authentication cannot protect a system that accepts credentials forged with a compromised signing key.

Microsoft disclosed the incident in July 2023 after investigating unauthorized access to customer email. Its Storm-0558 analysis described an actor using forged authentication tokens to access Outlook Web Access and Outlook.com.

The attacker obtained a Microsoft account consumer signing key and used it to forge tokens. A validation flaw then allowed consumer-signed tokens to reach enterprise email systems. The combination crossed a boundary that should have separated consumer and enterprise identities.

NIST cites this incident because it illustrates several linked failures. The key was highly valuable, its potential scope was broad, and relying systems accepted forged credentials. Investigators also needed suitable logs to identify affected accounts and actions.

The compromise did not begin by guessing thousands of passwords. It attacked the machinery that tells applications which identities to trust. Once that machinery accepted forged tokens, normal authentication controls offered limited protection.

This is the reversal behind NIST IR 8587. Single sign-on reduces repeated login exposure and centralizes access management. Yet the same centralized trust can magnify the consequences of a signing-system compromise.

NIST’s response begins with cryptographic key protection. Moderate-impact systems must use hardware-based, hardware-backed, or otherwise isolated storage for signing keys. Applications, virtual machines, servers, and containers must not store those keys persistently.

Acceptable mechanisms include hardware security modules, secure processors, cloud key-management systems, and isolated secrets-management services. These systems separate key material from the workloads requesting cryptographic operations.

High-impact systems receive a stronger requirement. They must protect both the stored key and the signing operation within an isolated execution environment. A compromised host or administrator account should not automatically expose the signing function.

Possible implementations include hardware security modules, security coprocessors, confidential computing environments, and remote signing services. The correct choice depends on system impact, operational constraints, and the provider’s architecture.

Isolation does not solve every problem. An attacker might abuse an authorized signing interface without extracting the private key. Providers must therefore restrict who can request signatures, record those requests, and monitor unusual signing activity.

Key rotation also needs operational planning. Changing a signing key affects every system that validates its output. Providers need controlled distribution, overlap periods where necessary, and rapid revocation procedures for compromised material.

That creates tension between availability and containment. A rushed rotation can disrupt legitimate services. A delayed rotation leaves forged credentials usable for longer.

NIST avoids prescribing one universal key lifetime in the final version. Instead, it uses an outcome-based approach tied to risk and organizational capabilities. The release summary says this change followed public feedback on the December 2025 draft.

The final guidance also expands advice on key usage, storage, and protection. It gives organizations more flexibility, but that flexibility transfers judgment back to security and architecture teams.

A provider cannot claim compliance merely because it owns an HSM. Agencies still need evidence that the key’s scope, signing interface, authorization rules, rotation process, and audit trail match the protected system’s risk.

Shared Responsibility Now Requires Shared Evidence

The report pressures cloud providers to expose security capabilities and agencies to configure, monitor, and test them rather than assume protection is automatic.

Cloud providers usually control physical infrastructure, core identity services, token issuance, signing systems, secrets vaults, and infrastructure-level monitoring. Agencies usually control IAM policies, user access, application secrets, session settings, and application logs.

Several duties remain shared. NIST identifies incident response, continuous monitoring, user education, and token revocation as areas requiring coordination. Actual boundaries vary by service model, contract, and exposed technical capabilities.

This is not a tidy division. A software-as-a-service customer cannot inspect every internal signing system. A provider cannot determine every agency’s mission sensitivity or decide which users should access a particular record.

NIST addresses that mismatch through four provider principles: secure design, transparency, configurability, and interoperability. Each principle gives agencies more influence over controls they do not operate directly.

Transparency requires enough architectural information and system data for consumers to make informed decisions. It also requires communication channels for token-related events, security findings, and incident response.

Configurability lets consumers adjust controls for their risks. Examples include stronger monitoring, shorter sessions, narrower access policies, or additional provider services. NIST recommends making broadly accepted protections available by default.

Interoperability supports consistent controls across hybrid and multi-cloud environments. Standards such as OpenID Connect, OAuth, and SAML reduce dependence on custom integrations. They also make it easier to exchange identity data between approved systems.

Standards do not guarantee secure deployment. A correctly formatted OAuth token can still have excessive privileges or an inappropriate lifetime. A valid SAML assertion can still be replayed if the relying party ignores uniqueness checks.

Agencies therefore retain several direct responsibilities. They must conduct risk assessments, select and tailor controls, document token-management policies, and configure cloud environments according to their assurance requirements.

The required documentation covers token lifetimes, validation processes, key management, logging, revocation, session management, and incident response. Agencies and providers must also record the protocols and token contents they support.

This documentation is not paperwork detached from operations. It defines what responders need when a token is exposed. Teams should already know which systems trust it, which logs contain related activity, and how revocation reaches connected services.

NIST ties these duties to its broader control catalog, especially controls for identity providers, authorization servers, cryptographic keys, and token management. The report translates those controls into implementation considerations.

The final publication supports Executive Order 14306. However, conformance remains voluntary unless policy, contracts, grants, or other binding agreements make particular provisions mandatory.

That limitation matters. The NIST token security guidelines can shape procurements and assessments, but they do not automatically change deployed systems. Agencies need to turn desired outcomes into contract terms, technical requirements, and acceptance tests.

Cloud providers face a related challenge. Supporting a control does not mean customers have enabled it. Providers need secure defaults, usable configuration paths, and telemetry that customers can integrate without custom engineering.

Procurement teams should ask direct questions. Can the customer restrict signing keys by tenant? Can it revoke active sessions across services? Are token events available in real time? Does the service identify missing audience restrictions?

They should also test those answers. Documentation can describe a feature without proving it works across every identity path. Federation gateways, legacy applications, mobile clients, and automated workloads can all behave differently.

The report consequently turns shared responsibility into shared evidence. Both sides need verifiable records showing who configured a control, how it operates, and what happens during compromise.

Token Lifecycles Become the Main Containment Mechanism

When organizations cannot prevent every theft, they must reduce how long a stolen token works and where an attacker can replay it.

Token management begins at issuance. Identity providers and authorization servers should issue credentials for defined subjects, audiences, scopes, and validity periods. Relying applications must enforce those restrictions during every access decision.

OAuth scopes describe actions that a user or application can perform. Narrow scopes support least privilege because they limit the authority carried by one token. Fine-grained authorization can reduce exposure further.

Validity periods present an operational tradeoff. Long-lived tokens reduce authentication traffic and user disruption. They also give attackers more time to reuse stolen credentials.

Short-lived access tokens reduce that window. However, refresh tokens can extend sessions by requesting new access tokens. Those refresh tokens therefore require strong storage, rotation, and revocation controls.

NIST recommends sender-constrained tokens where practical. A sender constraint cryptographically binds a token to a specific client or key. Possessing the token alone does not provide enough information to replay it from another system.

Two methods appear in the report. Mutual TLS binds token use to a client certificate. Demonstrating Proof of Possession, or DPoP, uses a client-generated key and signed proof for HTTP requests.

The relevant DPoP standard describes how an authorization server can bind tokens to a public key. A resource server can then verify that the requester controls the corresponding private key.

Sender constraints raise implementation costs. Clients need secure key handling, services need compatible validation, and distributed environments need reliable metadata. Legacy applications might not support the necessary protocols.

The report does not pretend these constraints fit every system immediately. It recommends them whenever feasible, especially for workload identities and higher-risk access.

Workload identities represent software services, automated processes, and other non-person entities. Their population is growing as enterprises connect APIs, deployment pipelines, cloud functions, and AI agents.

NIST says workloads must use tightly scoped, short-lived tokens issued through approved identity platforms. It discourages long-lived static credentials that remain useful after copying.

The report also highlights SPIFFE-based identities. SPIFFE supplies cryptographically verifiable identity documents to workloads through a trusted control plane. Credentials can rotate automatically and remain bound to a specific workload.

This approach changes secrets management. Applications retrieve temporary credentials during runtime rather than embedding them in source code, container images, or configuration files.

NIST applies the same logic to build pipelines. Tokens must not appear in logs, console output, caches, or deployment artifacts. Pipelines should retrieve secrets from approved systems and inject them only when needed.

A detected exposure should trigger incident response. Teams should not assume deletion from the original log eliminates the threat. Copies might already exist in log aggregators, backups, developer tools, or third-party integrations.

Audience restrictions provide another containment layer. An access token intended for one API must fail at another API, even when both services trust the same identity provider.

Unique token identifiers can also help detect replay. A relying system can recognize repeated presentation of a credential that should only support one transaction. This becomes more useful when providers preserve appropriate event records.

Revocation remains harder in stateless architectures. A self-contained token can continue passing local validation until it expires. Systems need revocation lists, introspection, shared event signals, or short lifetimes to shorten that gap.

The final report adds more references to current and emerging revocation approaches. It does not select one universal protocol because enterprise architectures and availability requirements differ.

That flexibility is reasonable, but it creates a measurable requirement. Each organization needs to determine how quickly it can invalidate a token across all relying services. A revocation process that takes hours leaves a large incident window.

Teams also need to test failure conditions. They should know how applications behave when an identity provider, revocation service, or key-distribution endpoint becomes unavailable. Security controls cannot quietly fail open.

Detection Must Follow Tokens Across Cloud Boundaries

Prevention protects keys and credentials, while detection determines whether defenders can recognize misuse before a stolen token expires.

NIST says identity controls should never become “set and forget” configurations. Providers and agencies need continuous monitoring for every system that issues, validates, consumes, or represents tokens.

Useful signals include geolocation, device information, request velocity, access time, and resource selection. None proves compromise alone. Correlation can reveal behavior that conflicts with the identity’s normal pattern.

A token used from two distant locations within an impossible interval deserves scrutiny. So does a workload credential appearing from an unapproved network or requesting resources outside its usual role.

NIST recommends shared security signals between identity providers and relying parties. OpenID Continuous Access Evaluation can communicate events that affect active sessions across connected services.

Such events can include account disablement, credential changes, increased session risk, or other security conditions. Receiving systems can reevaluate access before the original token reaches its normal expiration time.

The report also requires token data in formats consumable by security information and event management systems. Relevant information can feed behavioral analytics, cloud protection platforms, and other detection tools.

This requirement addresses a recurring problem in cloud incidents. An agency might control the affected account but lack visibility into the provider’s identity infrastructure. The provider might detect unusual activity without understanding the agency’s mission context.

Correlation needs data from both sides. Provider logs can show token issuance, key use, and infrastructure events. Agency logs can show application activity, authorization outcomes, and access to sensitive records.

NIST recommends tamper-resistant records for token and assertion events. Useful elements include timestamps, token identifiers, issuers, subjects, audiences, clients, validation results, and revocation activity.

Logging every token value would create another security problem. Raw bearer tokens must not appear in logs because anyone obtaining them might replay them. Systems should record safe identifiers and relevant attributes instead.

Retention also matters. An organization cannot investigate an intrusion that began before its available logs. Contracts and configurations should align retention with the agency’s detection and reporting needs.

The scalability challenge is substantial. Large cloud environments can generate enormous volumes of authentication and API events. Collecting everything without prioritization can bury meaningful signals.

Agencies need detection rules tied to actual abuse cases. These include unexpected audience values, tokens from unapproved issuers, repeated token identifiers, abnormal refresh activity, and signing operations outside normal patterns.

Providers should make these fields available consistently. Proprietary formats increase the work required to correlate events across clouds. They also complicate incident response when agencies move data between analytics platforms.

The NIST token security guidelines stop short of defining one detection architecture. They describe the outcomes and the event relationships that systems should support. Organizations must still build operational processes around those capabilities.

That work includes assigning alert ownership. A technically accurate alert creates little value if no team has authority to revoke the token, isolate the account, or contact the provider.

Security teams also need documented investigation context. A searchable engineering knowledge base can keep architecture decisions, trust relationships, and response procedures available during an incident.

The broader lesson is that identity telemetry must travel with identity trust. If a token can cross services and cloud boundaries, the evidence needed to investigate it must cross those boundaries too.

The Final Guidance Still Leaves Three Tests Ahead

The report establishes a baseline, but procurement enforcement, revocation performance, and machine-identity adoption will determine its practical effect.

The first signal to watch is how federal agencies translate NIST IR 8587 into contracts and service requirements. Conformance remains voluntary unless another authority makes specific provisions binding.

Procurement language can strengthen the report’s impact. Agencies can require isolated signing operations, tenant-scoped keys, interoperable logs, tested revocation, and incident notification. They can also demand evidence during authorization reviews.

A lack of contractual adoption would weaken the guidance. Providers might support some capabilities without exposing them consistently to customers. Agencies could then remain dependent on manual workarounds and provider-specific tooling.

The second signal is measured revocation time across federated and multi-cloud environments. Organizations should determine how long an exposed token remains accepted after responders initiate containment.

Shorter and consistently tested revocation times would support NIST’s approach. Large differences between documented and observed performance would reveal gaps in relying applications, event delivery, or identity-provider integrations.

This measurement should include refresh tokens and active sessions. Revoking an access token offers limited protection if another credential can immediately mint a replacement.

The third signal is adoption of short-lived, sender-constrained workload identities. Automated services now use tokens at a scale that manual secrets management cannot reliably govern.

Broader use of mutual TLS, DPoP, SPIFFE, and managed workload identity would reduce dependence on copied static credentials. Slow adoption would leave pipelines, containers, and AI-connected services exposed to replay attacks.

AI agents make this issue more urgent. NIST added high-level guidance because agents increasingly call tools, data services, and APIs with delegated authority. The report explicitly says it is not a comprehensive AI-agent security guide.

That boundary is important. An agent can use a properly protected token and still make an unsafe decision. Token controls establish who or what receives access, but they do not verify the quality of every automated action.

Post-quantum migration presents another unresolved area. NIST added high-level considerations, yet organizations still need detailed plans for replacing cryptographic algorithms and rotating dependent credentials.

Legacy systems will complicate both transitions. Older applications might not support audience restrictions, rapid revocation, modern federation protocols, or sender-constrained tokens. Translation gateways can help, but they introduce additional trust points.

The skeptical reading of NIST IR 8587 is therefore straightforward. Outcome-based guidance supports architectural diversity, but organizations with limited identity expertise can implement those outcomes unevenly.

Hardware isolation can protect key material while leaving an overprivileged signing interface exposed. Short token lifetimes can coexist with long-lived refresh credentials. Extensive logging can still fail if teams cannot correlate provider and agency events.

The report should not become a compliance checklist detached from attack paths. Its real value lies in forcing connected questions across issuance, validation, monitoring, and response.

For cloud customers, the next step is to map every issuer, signing key, audience, relying service, and revocation path. Then test what happens when one component becomes compromised.

For providers, the task is to make secure configurations observable and interoperable. Customers need evidence that protections work across tenants, APIs, workloads, and federation relationships.

NIST token security guidelines will matter most when a valid token stops ending the security discussion. Ask whether your systems can reject a correctly signed credential when its source, scope, behavior, or context is wrong.