NIST on Sept. 15 finalized new guidance for protecting the identity and access tokens that sit behind cloud sign-ins, federated logins, and API calls. The document, NIST Interagency Report 8587, was developed with CISA participation and is aimed mainly at federal agencies and the cloud service providers that serve them. But its practical importance is broader: it turns a usually invisible identity layer into a concrete architecture and control checklist at a time when stolen or forged tokens can let attackers move through connected services without ever re-entering a password.
For companies that rely on cloud SSO, federation, and machine-to-machine APIs, the real question is not whether the report creates a new compliance deadline. It does not. The more useful question is what to test first. IR 8587 sharpens the answer by shifting attention from the login screen to the token supply chain behind it: signing keys, issuer and audience checks, token lifetime and refresh behavior, revocation, logging, and the division of labor between provider and customer. NIST points to a case in which foreign actors used forged tokens derived from one stolen commercial signing key to access an agency email system and steal more than 60,000 emails. The lesson is not that every company faces that exact blast radius. It is that one key-management failure can become a cross-service access problem very quickly.
The security boundary moved behind the login screen
Tokens are cryptographically protected data used after an authentication event to represent identity or authorization. They power single sign-on, federation between an identity provider and an application, and API access for software and services. In modern cloud estates, that makes them part of the enterprise control plane, not a back-office detail.
That matters because an attacker who steals or forges a valid post-authentication token may be treated as an already authorized user or workload. Password resets and MFA prompts are not much help if downstream systems accept the token anyway. NIST’s final report therefore focuses on identity providers and authorization servers, recommending stronger controls for key management, token verification, and token life-cycle management.
The operating model is explicitly shared responsibility. Cloud providers are expected to deliver secure, configurable, interoperable controls. Customers still have to understand how their identity provider, authorization server, token validation, key storage, logging, and revocation settings actually work in production. For security leaders, that turns token security into a supplier-management issue as much as a technical one.
What changed in the final report
The final publication follows an initial public draft from December 2025 and ties into Executive Order 14306 and updates to NIST Special Publication 800-53 Release 5.1.1. NIST says the final version makes its advice on cryptographic-key protection less prescriptive and more outcome-based, while expanding discussion of key use, protection, and storage. It also adds newer standards, more options for token revocation and sharing signals about token risk, and high-level considerations for AI and post-quantum cryptography.
Those last two points matter, but mostly as markers of where identity architecture is headed. Organizations are increasingly issuing tokens to software and AI agents, which raises difficult questions about delegated authority, token scope, and revocation for non-human identities. NIST’s report acknowledges that trend without pretending to settle it. The same is true for PQC: the document flags future migration concerns for long-lived data and signatures, but it is not a full migration plan.
The immediate business consequence is more concrete. A finalized NIST reference architecture gives buyers a stronger basis for asking providers how token trust is established, where keys live, how rotation works, what defaults are enforced, and what telemetry a customer gets during an incident. For private-sector companies, the report is best read as a practical framework to adapt, not a one-size-fits-all rulebook.
Which controls security and procurement teams should test first
NIST does not rank its recommendations by urgency, cost, or expected risk reduction. Even so, the first tests are fairly clear: start with the controls that determine whether a malicious token can be minted, accepted, or left alive too long.
First, inventory the token and assertion types in use. Many organizations discuss “identity” as if it were one system, when in practice they may be juggling OAuth access tokens, refresh tokens, SAML assertions, workload identities, and service-to-service credentials across several clouds and SaaS tools. Without that inventory, there is no meaningful way to assess exposure.
Second, map the trust relationships: issuer, audience, scope, expiry, signing key, and refresh path for each important workflow. This is where excessive token lifetime or overly broad audience scope becomes dangerous, because some mistakes cannot be fully recovered after a token has already been issued.
Third, scrutinize signing-key protection and rotation. A buyer should ask which party owns signing-key protection, how keys are isolated and stored, how rotation is handled, and what happens in a compromised-key event. NIST’s guidance is especially useful here because a single stolen signing key can undermine many otherwise sound access controls.
Fourth, test token validation where it counts: at resource servers and applications. In live SSO, federation, and API environments, teams should verify that services reject tokens from the wrong issuer, with the wrong audience, with expired timestamps, or with scopes that do not match the request. This is one of the clearest places where “secure by design” has to be visible in behavior, not just in documentation.
Fifth, exercise expiry and revocation. The final report supports more options for revocation and risk-signal sharing, but support may vary across identity providers, SaaS vendors, APIs, and legacy applications. Security teams should ask how quickly compromised keys or tokens can be revoked, which token types are covered, what signals are passed to customers, and what operational side effects to expect.
That last point is where tradeoffs become real. Short token lifetimes can reduce replay risk while increasing refresh traffic, outage sensitivity, and support burden. Aggressive revocation can cut attacker dwell time but also break legitimate sessions. NIST does not publish a benchmark for latency, availability, or cloud-spend impact, so companies will have to test those effects in their own environments.
Finally, centralize token-related telemetry and write shared responsibility into contracts and runbooks. Logs from identity providers, authorization servers, resource servers, and monitoring teams need to line up well enough to support incident response. Procurement teams should press vendors to show which controls are enforced by default, which require customer configuration, and which are not available for every token type.
That may be the biggest practical shift in IR 8587. The report does not replace MFA, endpoint security, least privilege, or incident response. It does make it harder to treat token security as invisible plumbing. The most revealing vendor test is not a polished sign-in demo. It is a compromised-key tabletop: show how a bad token is detected, rejected, revoked, logged, and explained to the customer when something has already gone wrong.
By
By
By
By
By
By
