NIST Interagency Report 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse: Implementation Recommendations for Agencies and Cloud Service Providers, is recorded as final on September 15, 2026 on the Computer Security Resource Center publication page, with the PDF at nvlpubs and DOI 10.6028/NIST.IR.8587, after NIST and the Cybersecurity and Infrastructure Security Agency announced the same-day release and CISA said the final text incorporates nearly 250 public comments.[1][2][3][4][5][6]
That publication record then shows the report expanding on NIST Special Publication 800-53 Release 5.1.1 control IA-13, Identity Providers and Authorization Servers, written under 15 U.S.C. 278g-3 for federal environments.[2][3] NIST's news page says it is written primarily for federal agencies and the cloud service providers they work with.[1] Conformance remains voluntary for CSPs and federal agencies unless a policy, including an OMB policy, or a binding agreement such as a contract or grant says otherwise.[3]
That scope covers identity and access systems that rely on digitally signed assertions and tokens based on asymmetric cryptography, including single sign-on, federation, API, and workload access. Stateful management, schemes based on symmetric cryptography, and API keys are mentioned where they come up, and they are out of scope for those controls.[3]
So the report recounts why verification of the environment matters. Foreign actors accessed multiple agency email systems using forged tokens and assertions. Rather than elevating administrator accounts to mint those assertions, the attackers used consumer signing keys that were inadvertently exposed. Those keys should only have been valid for tokens issued in the affected vendor's commercial environments, not their enterprise or government systems. Because of token validation failures, the stolen keys generated signed tokens that were used to access email servers and personal email accounts, with over 60,000 emails exfiltrated from a single agency.[1][3] NIST's news page describes the same incident as forged tokens derived from a single stolen commercial signing key.[1] Neither page names the vendor. A signature can be cryptographically valid and still belong to the wrong environment's key.
Meanwhile Table 1 is an example of responsibility areas in a software-as-a-service environment. Token issuance and signing are marked for the CSP. Token revocation is marked for both the CSP and the consumer. The report says actual boundaries vary by service model, contract terms, and the technical capabilities the CSP exposes.[3] CSRC's September 15 note on the final text also adds workload identity considerations and a preference for short-lived tokens rather than static credentials and secrets, and it shifts signing-key validity periods toward system classification and transaction sensitivity rather than tying them to a deployment model.[5]
Section 1.1.1 then puts agents on the same token layer without expanding the rest of the IAM problem. Artificial intelligence systems, especially agentic AI systems, use signed tokens or assertions in many emerging identity schemes. Organizations should apply these guidelines when agents use signed tokens to access systems, data, tools, or APIs. The document is not a comprehensive guide to AI and AI-agent access risks, and it excludes those topics from scope.[3] NIST's news page says the final text added high level considerations for handling AI and for migration to post-quantum cryptography, and that it does not offer a comprehensive set of tools for either topic.[1]
Section 7.7 is the post-quantum note. Token and assertion systems rely on public-key cryptography, including RSA, ECDSA, and ECDH, which the report says are vulnerable to a cryptographically relevant quantum computer. FIPS 203 specifies ML-KEM as a key-encapsulation mechanism. FIPS 204 specifies ML-DSA as a digital signature algorithm. The identity protocols named in that section, including OIDC, OAuth, JOSE, COSE, SAML, and X.509, are still being updated to support those algorithms. Legacy federation systems, including some SAML deployments, might not be updated.[3]
CISA's September 15 release says the report supports Executive Order 14306 and urges federal agencies, CSPs, and cloud consumers to review and implement IR 8587.[6] That urge is CISA's statement. It does not, by itself, make the report a rule. This remains an implementation report. It does not decide a named agency file, and it is not cybersecurity, legal, procurement, or investment advice.
Verification bottleneck
This scarce check is whether a resource server can show it verified a named token against the signing keys for that environment, before anyone treats a valid-looking signature as proof that the token belonged there.
- Work can already move on a signed token through single sign-on, federation, an API, or a workload. The report's incident is a consumer key accepted where the text says it should not have been valid.
- Agencies and CSPs would have to show which environment issued the token, which keys signed it, whether verification used those keys, and which side can revoke it. Table 1's SaaS example puts issuance with the CSP and revocation with both.
- The remaining open facts are whether a contract or OMB policy is what binds any MUST language, whether an agent using a signed token is listed in the local scheme, and whether section 7.7 is still a migration note while the named protocols are still being updated.
Opportunities
Where value may appear is a one-token verification worksheet. For a single production flow it would record the issuer, the environment whose keys signed the token, the resource server that is supposed to verify it, whether revocation sits with the CSP, the consumer, or both, and whether an AI agent uses that token. Conclusions stay with qualified reviewers. Idea fodder only.
Sources
[1] National Institute of Standards and Technology, "NIST Finalizes Guidelines on Protecting Online Identity and Access Tokens From Misuse," September 15, 2026. https://www.nist.gov/news-events/news/2026/09/nist-finalizes-guidelines-protecting-online-identity-and-access-tokens
[2] NIST Computer Security Resource Center, IR 8587 publication page, document history 09/15/26 Final. https://csrc.nist.gov/pubs/ir/8587/final
[3] Ryan Galluzzo, Andrew Regenscheid, Stephanie Nelson, and Christine Lazcano, *Protecting Tokens and Assertions from Forgery, Theft, and Misuse: Implementation Recommendations for Agencies and Cloud Service Providers,* NIST IR 8587, September 2026. https://nvlpubs.nist.gov/nistpubs/ir/2026/NIST.IR.8587.pdf
[4] DOI. https://doi.org/10.6028/NIST.IR.8587
[5] NIST CSRC, "Hands Off my Tokens! NIST Finalizes Interagency Report 8587," September 15, 2026. https://csrc.nist.gov/news/2026/protecting-tokens-and-assertions-nist-ir-8587
[6] Cybersecurity and Infrastructure Security Agency, "CISA and NIST Release Guidelines to Protect Federal Cloud Identity Systems from Token Theft, Forgery, and Misuse," September 15, 2026. https://www.cisa.gov/news-events/news/cisa-and-nist-release-guidelines-protect-federal-cloud-identity-systems-token-theft-forgery-and
[7] CISA resource page, publish date September 15, 2026. https://www.cisa.gov/resources-tools/resources/protecting-tokens-and-assertions-forgery-theft-and-misuse-implementation-recommendations-agencies