What happened
NIST and CISA released Interagency Report 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse, on September 15. The report gives federal agencies and cloud service providers implementation guidance for the tokens that sit behind single sign-on, federation and API access.
It answers tasking under Executive Order 14306 and builds on recent updates to NIST Special Publication 800-53. The contents cover architectural considerations for identity providers and authorization servers, key management, token verification and token lifecycle controls, guidance for securing single sign-on and API access built on signed and encrypted tokens, and principles for configurable, interoperable controls. The recommendations apply across commercial and government-operated cloud services, not only federal ones.
The final version changed shape from the December 2025 draft in ways worth noting. Guidance on cryptographic key protection moved from prescriptive requirements to outcome-based expectations focused on what an organisation can demonstrate. Advice on key usage, protection and storage expanded, new references were added for token revocation and for sharing security signals, and the publication now carries considerations for AI and for migration to post-quantum cryptography.
"Identity is the new perimeter, and the tokens and assertions behind it are attractive targets for sophisticated adversaries," said Chris Butera, CISA's acting executive assistant director for cybersecurity. NIST pointed to the reason for the urgency: forged tokens derived from a stolen commercial signing key have already been used to reach federal email systems, with more than 60,000 emails taken from one agency.
Why this is a GRC story
Almost every organisation now runs on the technology this report describes, whether or not it operates a cloud service. If access to your applications flows through single sign-on tokens issued by a major provider, then token handling is one of your control environments. The report is written for agencies, but the risks it addresses do not check the size of the organisation they are attacking.
Outcome-based guidance is harder to satisfy than a checklist. When a standard stops saying "encrypt this key with that algorithm" and starts describing capabilities, the evidence burden moves to the control owner. Practically, that means records that show a token lifecycle is actually managed: issuance tied to identity proofing, short and enforced lifetimes, revocation that works and is tested, key rotation with a paper trail, and detection for token replay.
The AI and post-quantum additions are the part to read twice. Both are references to risks that will not fully arrive for years, which is exactly why they tend to be deferred in budget cycles. Standards bodies rarely add them ahead of the market by accident. Where a publication names a migration path, assurance questionnaires usually follow within a year or two.
What to watch
Watch whether assessors and auditors begin mapping token controls to IR 8587. A publication gains force the moment it appears in an assessment template.
Watch how the referenced standards for token revocation and signal sharing develop. Interoperability between vendors is the difference between revoking a stolen token in minutes and chasing it across separate systems.
Watch for AI and post-quantum considerations to appear in later revisions of the broader identity guidance. That is likely where organisations first see the timeline for real work.
Attribution: Analysis based on Infosecurity Magazine's reporting and related public reporting. This article is original commentary, not a repost of the source material.