NIST IR 8587: protecting identity and access tokens

The 60-second summary

On 15 September 2026, NIST released the final NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse. The publication provides implementation guidance for cloud service providers and consuming organisations protecting identity tokens, access tokens and assertions used in SSO, federation and API access. It covers provider and customer responsibilities, identity-provider and authorization-server architecture, key management, token verification, lifecycle controls, secure design, interoperability and continuous monitoring. Compared with the December 2025 draft, the final version makes cryptographic-key guidance more outcome-focused, expands key-use and storage advice, and adds high-level AI, post-quantum and standards references. It is guidance, not a new legal obligation.

Timeline that matters

December 2025
Initial draft
NIST released the initial draft for public feedback.
15 September 2026
Final publication
NIST published IR 8587 in final form with revisions and expanded guidance.
16 September 2026
Editorial review
PrivacyBuilt verified the NIST announcement and final publication record.
16 December 2026
Next review
Check for errata, implementation resources and related identity guidance.

What changed

NIST converted the draft into final implementation guidance and refined its recommendations after public feedback. The final publication strengthens the practical baseline for securing token issuance, signing keys, validation, revocation, federation and monitoring, while adding high-level considerations for AI identities and post-quantum migration.

Who should pay attention?

Identity and access teams

Apply stronger lifecycle, verification, key-management and revocation controls.

Cloud and Microsoft 365 administrators

Review federation, application consent, session, token and incident-response configurations.

Application and API teams

Validate tokens rigorously and minimise scope, lifetime and exposure.

Security operations

Detect suspicious issuance, replay, privileged use and signing-key activity.

Vendor-risk and assurance teams

Clarify shared responsibilities and retain evidence from identity and cloud providers.

What the guidance clarifies

The publication is final: NIST published IR 8587 in final form on 15 September 2026 after revising the December 2025 draft.
The scope extends beyond passwords: The report addresses identity tokens, access tokens and assertions used in SSO, federation and API access.
Providers and customers share responsibilities: The guidance distinguishes provider capabilities from consuming-organisation configuration and operation.
Key protection is outcome-focused: The final version uses less prescriptive cryptographic-key guidance and expands advice on key use, protection and storage.
Revocation and signal sharing matter: The final publication adds references and options for token revocation and sharing token-related risk signals.
This is guidance, not a new law: NIST IR 8587 is an implementation resource, primarily for federal agencies and their cloud providers, that can also help other organisations.

Identity tokens are portable access—and must be governed like high-value credentials

Why this matters for global organisations

Cloud applications, APIs and federated services rely on tokens that can bypass repeated authentication. A defensible programme connects key protection, token validation, least privilege, short lifetimes, revocation, monitoring and rehearsed incident response across provider and customer environments.

Treat token issuance and signing keys as critical security infrastructure.
Make shared cloud responsibilities explicit and testable.
Reduce token lifetime, privilege and unnecessary exposure.
Prepare to revoke access and investigate across connected services quickly.

15 actions to start now

Inventory identity providers, authorization servers, federation services, API gateways and applications that issue, sign, exchange or consume tokens.
Classify token types, assertions, trust relationships, signing keys and privileged access paths.
Map provider and customer responsibilities for configuration, verification, monitoring, revocation and incident response.
Use secure-by-design defaults and disable unnecessary token features, flows and legacy protocols.
Protect signing and encryption keys through strong access controls, separation of duties, rotation and monitored storage.
Validate issuer, audience, signature, algorithm, expiry, nonce and other required claims at every relying service.
Minimise token lifetime, scope and privileges according to business need and risk.
Use sender-constrained or otherwise misuse-resistant token approaches where supported and appropriate.
Implement rapid revocation, session termination and risk-signal sharing across connected services.
Prevent tokens from appearing in logs, URLs, support captures, analytics, browser storage or unsecured caches.
Monitor anomalous token issuance, replay, impossible travel, unusual API access and signing-key activity.
Create a response playbook for suspected token or signing-key compromise, including containment and evidence preservation.
Test federation failure, key rollover, emergency revocation and recovery through tabletop and technical exercises.
Review supplier assurances, configuration options, audit evidence and notification commitments.
Track identity standards, post-quantum migration dependencies and AI-agent identity use as the environment evolves.

Suggested next steps

Run one token-theft tabletop across identity, cloud, application and incident-response teams. Assume a signing key or privileged refresh token is compromised, then test detection, revocation, session termination, provider escalation, evidence preservation and recovery.

Evidence worth retaining

Token and assertion inventory with owners and business purpose.
Identity-provider, authorization-server and relying-party architecture diagrams.
Federation trust and application-registration records.
Signing and encryption key inventory, custody, rotation and access logs.
Token lifetime, scope, claim and algorithm configuration baselines.
Validation test results for issuer, audience, signature, expiry and replay controls.
Administrative and workload-identity privilege reviews.
Revocation, session termination and risk-signal test evidence.
Logging and data-loss checks showing tokens are not unnecessarily retained.
Detection rules, alerts and investigations for anomalous token activity.
Incident playbooks and tabletop records for token or key compromise.
Provider contracts, shared-responsibility matrices and assurance reports.
Change records for federation, key rollover and protocol deprecation.
Exceptions, risk acceptances and remediation tracking.

Questions to take to counsel or your conformity team

These are discussion prompts, not legal advice or conclusions.

Which systems can issue or exchange tokens with privileged access?
Where are signing keys stored, and who can use or export them?
Do all relying services validate issuer, audience, signature, algorithm and expiry?
Are token lifetimes and scopes proportionate to actual need?
Can sessions and tokens be revoked quickly across every dependent service?
Which logs could accidentally expose bearer tokens or assertions?
Can monitoring distinguish legitimate automation from token replay or theft?
How are workload identities, service principals and AI agents governed?
What evidence will the cloud provider supply after suspected token compromise?
Can key rollover occur without extended downtime or insecure fallback?
Which privacy, breach-notification or sectoral duties could be triggered by token misuse?

Official sources

PrivacyBuilt / PrivacyBuilt is an independent educational publisher. It is not affiliated with, or endorsed by, any regulator or the European Union.

PrivacyBuilt publishes educational and technical guidance. Nothing on this site constitutes legal advice, and it should not be relied on as a legal determination for your organisation.

LinkedIn Share on X WhatsApp

NIST finalises token-protection guidance: securing SSO, federation and API access