Single sign-on makes modern IT usable. It also creates a class of credentials that many organizations do not manage as deliberately as passwords or multifactor authentication.
On September 15, 2026, the National Institute of Standards and Technology (NIST) published the final version of NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse. Developed with the Cybersecurity and Infrastructure Security Agency (CISA), the report focuses on the identity and access tokens that underpin single sign-on, cloud services, federated identity, and API access.
The takeaway for IT teams is straightforward: authentication is not finished when a user passes MFA. The token issued afterward may become the credential that grants access for the rest of the session. If that token is stolen, forged, replayed, or accepted by the wrong service, an attacker may gain access without repeating the original login.
What changed in the final guidance
NIST’s September 15 announcement says the final report expands the December 2025 draft in several useful ways. It makes the cryptographic-key recommendations more outcome-focused, adds detail about key use, protection, and storage, and introduces high-level considerations for artificial intelligence agents and post-quantum cryptography. It also points readers to additional standards and mechanisms for token revocation and security-event sharing.
This is a final NIST Interagency Report, not a proposed rule. It is written primarily for federal agencies and cloud service providers, but NIST explicitly notes that the practices can benefit organizations more broadly. For school districts, local governments, nonprofits, and private-sector IT teams, it is best treated as authoritative implementation guidance—not as a guarantee of compliance or a substitute for requirements that apply to a particular organization.
Seven practical reviews to conduct now
1. Inventory every trust relationship
Document which systems issue tokens, which systems validate them, which identity providers are trusted, and which applications accept each token type. Include SaaS platforms, internal applications, service accounts, APIs, automation platforms, and machine-to-machine integrations. An incomplete inventory makes it difficult to know where a compromised token could be reused.
2. Protect signing keys as critical infrastructure
Token security depends heavily on the keys used to sign and verify tokens. Review how keys are generated, stored, distributed, rotated, and revoked. Prefer managed or hardware-backed protection where appropriate, tightly limit administrative access, and make sure emergency rotation is documented and tested. The report devotes a full section to cryptographic key management, including generation, storage, rotation, revocation, and compromise recovery.
3. Validate more than the signature
A valid signature does not automatically mean a token should be accepted. Applications should verify the expected issuer and audience, enforce approved algorithms, check time-related claims, and reject tokens intended for another service. Validation rules should be consistent across custom applications, vendor products, gateways, and APIs.
4. Limit token lifetime and plan for fast revocation
Short-lived access tokens reduce the window in which a stolen token can be abused. Refresh tokens require stronger protection because they can extend that access. Review token and session lifetimes against actual operational needs, then confirm that administrators can revoke access quickly when an account, device, application, or key is compromised.
5. Monitor token use, not only login events
Centralize identity-provider, application, cloud, and API logs so the security team can follow a session after authentication. Look for unusual audiences, locations, devices, refresh patterns, token reuse, impossible travel, and access that continues after a role change or account disablement. NIST IR 8587 specifically includes continuous monitoring among its core consumer practices.
6. Make shared responsibility explicit
Cloud providers secure part of the token lifecycle; customers still control configuration, integration, monitoring, and access decisions. The report separates recommendations for service providers and service consumers. Contracts, architecture diagrams, and incident-response plans should clearly state who rotates keys, retains logs, detects misuse, revokes sessions, communicates incidents, and verifies recovery.
7. Include workloads and AI agents
NIST notes that the guidance applies when AI agents use signed tokens to reach systems, data, tools, or APIs. The report is not a complete guide to AI-agent security, and NIST says guidance in this area is still evolving. Even so, the immediate lesson is useful: give each workload or agent a distinct identity, minimize its privileges and token audience, avoid unnecessary long-lived credentials, and ensure its activity can be traced and revoked independently.
A useful tabletop exercise
Ask a simple question: If an attacker stole a valid token from one of our most connected applications today, how quickly could we identify its reach and invalidate it?
The answer should identify the issuing system, accepted audiences, token lifetime, refresh path, revocation method, relevant logs, response owner, and downstream dependencies. If several teams or vendors must be contacted before those facts are known, the organization has found a valuable improvement opportunity without waiting for an incident.
The bottom line
SSO remains one of the best ways to improve usability and centralize access control, but the convenience can obscure the credentials moving behind it. NIST IR 8587 gives IT and security teams a practical framework for treating tokens, assertions, and their signing keys as first-class security assets.
For most organizations, the best first step is not a new product. It is a short inventory followed by a focused review of validation, key management, token lifetime, revocation, logging, and provider responsibilities. That work makes existing identity investments substantially more defensible.
This article provides general cybersecurity information and is not legal or compliance advice.