NIST and CISA finalized joint guidance on protecting identity and access tokens. If you sell cloud services to a federal agency, it describes what your customer will expect you to deliver.
On September 15, 2026, NIST published the final version of NIST IR 8587, *Protecting Tokens and Assertions from Forgery, Theft, and Misuse: Implementation Recommendations for Agencies and Cloud Service Providers*. The report was authored jointly by NIST and CISA staff, responds to NIST's tasking under Executive Order 14306, and builds on the updates in NIST SP 800-53 Release 5.1.1. It replaces the initial public draft issued December 22, 2025.
Start With What This Is — and Is Not
IR 8587 is an interagency report. It is guidance, not a regulation, and no contract clause currently incorporates it by reference. Nothing in it changes what FAR 52.204-21, DFARS 252.204-7012, or a FedRAMP authorization already require of you.
What it does is describe, in NIST's own words, how federal agencies and their cloud service providers should protect identity tokens, access tokens, and assertions. That matters for a practical reason: agency security teams read these documents, and what appears in an interagency report today tends to appear in a solicitation's technical requirements, a security questionnaire, or a FedRAMP control narrative later. Understanding it early is a positioning advantage, not a compliance obligation.
Why Tokens Are a Contracting Problem, Not Just an Engineering One
A token is the credential your system issues after a user authenticates — the thing that lets them reach an inbox, a records system, or an API without signing in again. Tokens are what make single sign-on and federation work, and they are foundational to zero trust architectures.
They are also a concentrated point of failure. NIST's announcement of the report points to an incident in which actors accessed federal agency email using forged tokens derived from a single stolen commercial signing key — tens of thousands of messages taken from one agency. The compromise was not of the agency's own network. It was of a vendor's key material.
That is the contracting insight. When a government customer's data is reachable through tokens your platform issues, the security of your key management becomes part of your performance obligation, whether or not anyone wrote it into the statement of work.
What the Report Actually Covers
Per NIST's published abstract, IR 8587 sets out:
- Principles split between the two parties — separate expectations for cloud service providers and for the consuming agencies that configure their services.
- Architectural considerations for identity providers and authorization servers.
- Enhancements to key management, token verification, and life cycle controls — the mechanics of issuing, validating, and revoking tokens.
- Specific recommendations for SSO, federation, and API access scenarios.
- An emphasis on secure-by-design practices, configurability, interoperability, and continuous monitoring.
NIST notes three notable changes from the December 2025 draft: cryptographic key protection guidance is now less prescriptive and more outcome-based; new high-level considerations address AI and migration to post-quantum cryptography; and new references to current and emerging standards give organizations more options for tasks like token revocation and sharing signals about tokens. On the post-quantum point, see our coverage of EO 14412 and the PQC FAR rule.
What a Vendor Should Do With It
1. Read the split. The report separates provider duties from consumer duties. Know which side of that line each of your obligations sits on before a customer assumes it is yours. 2. Inventory your signing keys. Where they live, who can reach them, how they rotate, and what happens if one is compromised. 3. Check your revocation story. Issuing tokens is easy; invalidating them quickly across a federation is not. This is where the report's life cycle discussion will be hardest to answer. 4. Map it against SP 800-53 Release 5.1.1, since that is the baseline the report builds on and the one FedRAMP authorizations run through. 5. Expect the questions. Agency customers will ask. A documented answer beats a scramble — start with Build a Program.
Key Takeaways
- IR 8587 is guidance, not a mandate. It creates no new contractual obligation on its own, but it tells you what agency customers are being told to expect from cloud vendors.
- The exposure runs through your key material. A compromised signing key can expose an agency's data without anyone touching the agency's network — which makes key management a contract performance issue.
- The report divides responsibility. Provider-side and agency-side duties are stated separately; know which ones your customer will treat as yours.
GovConCyber publishes educational information about government contractor cybersecurity requirements. It is not legal advice, and it does not create an attorney-client relationship.