NIST IR 8587 Guide: Token and Assertion Protection

Signed tokens and assertions are the keys to every SSO session, federated login and API call, and a single stolen signing key or bearer token can open them all. NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse: Implementation Recommendations for Agencies and Cloud Service Providers, was published as final on 15 September 2026 by NIST with CISA, after an initial public draft on 22 December 2025. It turns the new SP 800-53 control IA-13 (Identity Providers and Authorization Servers) into concrete MUST and SHOULD requirements for key protection, token verification and token lifecycle management. This guide explains what the report requires, how to read it if you are a cloud service provider (CSP) or a consuming organisation, and how to roll it out. It is written for identity architects, IAM engineers and security teams running identity providers, authorisation servers and the applications that trust them.

Source note: requirements are taken from the final NIST IR 8587 PDF and the NIST and CISA announcements, checked 11 November 2026. ATT&CK and most SP 800-53 mappings are NHI Mgmt Group analysis. Confirm against the official text before relying on it.

Key takeaways

It is the implementation layer for IA-13. IR 8587 expands SP 800-53 Rev. 5 (release 5.1.1 and later) and responds to NIST's tasking in Executive Order 14306; it is written for federal agencies and CSPs but NIST says any organisation using tokens can apply it.
Signing keys belong in isolated hardware. At moderate impact and above, signing keys MUST sit in hardware-based, hardware-backed or otherwise isolated storage and MUST NOT persist on applications, servers, VMs or containers; high impact keys SHOULD be active for no more than 90 days.
One hour is the ceiling for access and ID tokens. Access and identity tokens SHOULD be valid for no more than one hour, and every token MUST carry issuer, subject, audience, issuance time, validity window, token ID or nonce, authentication time and a signature with key identifier.
Theft is answered with binding and revocation. CSPs SHOULD offer sender-constrained tokens (DPoP, mutual TLS) and session revocation signals (Shared Signals Framework, CAEP), and consumers SHOULD turn them on.
Logging is a hard requirement, tokens in logs are forbidden. All components MUST keep tamper-resistant logs of token events, and tokens and assertions MUST NOT be written to logs, pipelines or build artifacts.

What IR 8587 is and why it was written

NIST and CISA released the report on 15 September 2026. The CSRC page lists the authors as Ryan Galluzzo and Andrew Regenscheid (NIST), Stephanie Nelson (Accenture Federal Services) and Christine Lazcano (CISA), with DOI 10.6028/NIST.IR.8587. NIST's announcement cites the attack in which foreign actors used tokens forged with a single stolen commercial signing key to read agency email, taking more than 60,000 emails from one agency. That is the Storm-0558 intrusion; see the Storm-0558 and Cloud Key Theft Profile. The same class of failure sits behind forged SAML tokens in the SolarWinds supply chain compromise.

Status: final interagency report. It is guidance, not a regulation, but it implements IA-13, which agencies and FedRAMP-style assessments use, and CISA urges CSPs and cloud consumers to adopt it.
Audience: two parties with shared responsibility. CSPs must ship secure, configurable products; consuming agencies must configure them correctly and assess what the CSP discloses.
Language: the report uses MUST, SHOULD and MAY. Treat MUST as the baseline an assessor will test and SHOULD as the default you need a written reason to deviate from.
Changes from the draft: NIST says key protection guidance became more outcome-based, high-level considerations for AI and post-quantum cryptography were added, and references to emerging revocation and signal-sharing standards were expanded.

The report has seven sections: an introduction with principles for CSPs (1.4) and consuming agencies (1.5) and a note on AI agents (1.1.1); an overview of tokens; IA-13 architecture requirements (Section 4); two control enhancements on key protection (5.1) and token verification (5.2) plus token management (5.3); a threat table (Section 6); and additional considerations (Section 7).

Requirement 1: protect the signing keys

Generation: keys MUST be generated per SP 800-57 Part 1 Rev. 5 inside FIPS 140 validated modules using NIST-approved algorithms, and each key MUST be tied to its purpose, system and device. Keep a key inventory.
Distribution: private keys SHOULD NOT be exported in plaintext; backup copies SHOULD be wrapped by a key-encryption key held in a hardware module. Metadata and JWKS endpoints MUST be served over HTTPS. See the JWKS and Signing Key Rotation Guide.
Storage and isolation: at moderate impact and above, MUST use hardware-based, hardware-backed or otherwise isolated storage; signing keys MUST NOT persist on applications, servers, VMs or containers. At high impact, key use MUST occur in an isolated execution environment. Low impact MAY use software isolation.
Scoping: signing keys MUST be scoped to the lowest reasonable level and a specific environment, and token signing keys MUST NOT be used for anything else. A consumer key that also signs enterprise tokens is exactly the boundary failure Storm-0558 exploited.
Revocation and destruction: retired keys SHOULD be removed from published metadata, and retired private keys MUST be erased, including backups and archives.

FIPS 199 impact	Key storage	Maximum active signing period	Rotation
Low	Software isolation MAY be used	SHOULD be under one year	Automated, rollover before expiry, process documented
Moderate	MUST be hardware-based, hardware-backed or otherwise isolated	SHOULD be under one year	Automated, rollover before expiry, process documented
High	Isolated storage plus key use in an isolated execution environment (MUST)	SHOULD be no more than 90 days	Automated, rollover before expiry, process documented

The report adds that shorter periods SHOULD be used where protection is weaker or detection is limited. If you cannot see who used a key, you should rotate it more often, not less.

Requirement 2: verify every token properly

Section 5.2 is aimed at relying parties and resource servers. Parsing a JWT and reading its claims is not verification.

Required content (5.2.1.1)	JWT claim	What the verifier MUST do
Issuer identifier	`iss`	Match against the expected issuer for that key
Subject or client identifier	`sub`, `client_id`	Map to a known principal
Audience identifier	`aud`	Reject missing or wrong audience and SHOULD raise an alert (5.3.1.3)
Issuance time and validity window	`iat`, `nbf`, `exp`	Reject expired tokens (MUST)
Token identifier or nonce	`jti`, `nonce`	Use for replay detection
Authentication time	`auth_time`	Enforce reauthentication policy
Signature with verification key identifier	JWS signature, `kid`	Verify with the correct key; validate key authenticity, algorithm and key size

OAuth access tokens SHOULD also carry scopes, and relying parties MUST confirm scope, validity, source and integrity before granting access. The report points to the JWT Best Current Practices (RFC 8725), the JWT profile for access tokens (RFC 9068) and the OAuth 2.0 Security BCP (RFC 9700). See the JWT Security Guide.

Requirement 3: manage the token lifecycle

Lifetimes and refresh

Access and identity tokens MUST have defined short lifetimes and SHOULD be valid for no more than one hour. Refresh tokens MAY live longer, CSPs SHOULD let consumers configure their validity, and for interactive human sessions they SHOULD NOT exceed the reauthentication timeframes in SP 800-63B-4. See the stolen refresh token detection how-to.

Revocation

The report accepts that stateless tokens often cannot be revoked globally before expiry, which is why short lifetimes matter. IdPs and token services MUST NOT accept a refresh token tied to a suspected-compromised identity token without reauthenticating the user, SHOULD propagate revocation status to relying parties through introspection, status lists or shared signals, and CSPs SHOULD implement session revocation signals using the OpenID Shared Signals Framework and CAEP. Relying parties MUST reject revoked tokens and terminate associated sessions where they can. CSPs MUST disclose how far their revocation goes, and consuming agencies MUST assess that risk. The IETF Token Status List and Global Token Revocation work is named as still in development. See CAEP and Continuous Access Evaluation.

Sender-constraining and presentation

Bearer tokens work for whoever holds them. The report describes DPoP (RFC 9449) and mutual TLS certificate-bound tokens (RFC 8705) as proof-of-possession options that CSPs SHOULD offer and consumers SHOULD implement where possible, with TLS channel binding as a fallback. Section 7 adds that back-channel presentation reduces exposure compared with front-channel, that tokens carrying personal or privileged data SHOULD be encrypted at payload level (JWE, SAML encrypted assertions), that holder-of-key assertions suit FAL3, and that Device-Bound Session Credentials counter cookie hijacking. See the DPoP Guide, the mTLS Guide and the DBSC Guide.

Where identity fits: workloads, pipelines and AI agents

IR 8587 is not only about human SSO. Section 5.3.1.6 says workload identities MUST use tightly scoped, short-lived tokens issued only through approved enterprise identity platforms and SHOULD use sender-constrained mechanisms such as mTLS or DPoP wherever feasible. It names SPIFFE SVIDs as a way to remove long-lived static credentials. Section 5.3.1.5 says tokens MUST NOT appear in logs, CI/CD pipelines or build artifacts, pipelines MUST retrieve secrets from secret management systems and inject them ephemerally at runtime, and any detected exposure should be handled as a security incident. The Red Hat Consulting GitLab breach shows what happens when tokens end up in documents and repositories.

Section 1.1.1 says organisations SHOULD apply the guidelines when AI agents use signed tokens to reach systems, data, tools or APIs, while stating that AI-specific access risks are not addressed and remain under development at NIST and CISA. In practice, an agent's OAuth token is a workload token and gets the same lifetime, audience and binding rules. See the JWT and Session Tokens in Code and Logs Guide and the Agentic AI Identity Guide.

Threats mapped to mitigations

Section 6 (Table 7) maps five threats to mitigations. The ATT&CK column is our mapping, not the report's.

Threat (IR 8587)	Related ATT&CK technique	Mitigations named in the report
Token or assertion manufacture or modification	T1606 Forge Web Credentials, T1606.002 SAML Tokens	Signing and validation, key protection and rotation, sender-constrained tokens, conditional access, tamper-resistant logs
Signing key compromise	T1606.002 SAML Tokens	Hardware or software isolation, revocation and rotation, automated key management
Token theft (assertion, access or refresh token)	T1528 Steal Application Access Token, T1539 Steal Web Session Cookie	Sender-constrained tokens, signing, key rotation, conditional access, logging
Token replay	T1550.001 Application Access Token	Unique token IDs, sender constraining or refresh token rotation, uniqueness checks
Token redirect to an unintended context	T1550.001 Application Access Token	Audience validation, environment-scoped signing keys

The report notes the table does not cover endpoint malware or insider threats. Token theft from developer machines, as in the GlassWorm campaign, needs endpoint controls alongside these.

Detection and measurement

Section 5.3.1.4 says CSPs and consumers MUST monitor token usage patterns such as geolocation, device data and velocity anomalies, and usage data MUST be available in a form SIEM tools can consume. Section 5.3.1.7 requires tamper-resistant logs structured per SP 800-92, lets agencies configure CSP logging, and requires CSPs to document which logs are on by default. Table 6 suggests these log elements: token type, issuer, scopes, client or user (identifier or hash), audience, and timestamped issuance, refresh, acceptance or rejection and revocation events. Tokens themselves and personal data in them MUST NOT be logged.

Audience rejections: alerts on tokens presented with the wrong or no audience, which signal redirect or forgery attempts.
Unknown kid or issuer: any accepted token signed by a key not in the current inventory is a priority incident.
Same jti or refresh token from two clients or locations: replay or theft.

Metrics that show the programme is working:

Percentage of token signing keys held in hardware-backed or isolated storage, by impact level (target 100% at moderate and high).
Maximum and median active age of signing keys against the 90-day and one-year ceilings.
Percentage of access and ID token configurations with lifetimes of one hour or less.
Percentage of high-value API and workload flows using DPoP or mTLS bound tokens.
Mean time from compromise signal to session termination across connected relying parties.
Number of token exposures found in logs, repositories or pipeline artifacts per quarter, trending to zero.

Implementing IR 8587: a phased approach

NHI Mgmt Group recommendation: this section and the decision guidance below are our own guidance, not requirements of the source document.

Inventory (weeks 1 to 4): list every IdP, authorisation server and token service, every signing key with its storage, age, scope and FIPS 199 impact level, and every relying party with its validation library. Request the CSP's disclosure on revocation, logging defaults and key isolation.
Close the MUST gaps on keys (months 1 to 3): move moderate and high impact signing keys into HSM or cloud KMS backed storage, split keys by environment and purpose, enable automated rotation with overlapping JWKS publication. Test rollover in a staging tenant first; roll back by keeping the previous key published until all caches refresh.
Fix verification (months 2 to 4): audit relying parties for issuer, audience, algorithm and expiry checks. Start with alert-only rejection logging for a pilot set of APIs, then enforce.
Shorten lifetimes: cut access and ID token lifetimes to one hour or less in pilot rings, watch refresh traffic and error rates, then widen. Keep the old policy ready to restore if clients break.
Bind and revoke: enable DPoP or mTLS for workload and high-value flows, and wire SSF/CAEP or introspection-based revocation between the IdP and major relying parties.
Log and monitor: enable the Table 6 elements, forward to the SIEM, build the detections above and scrub tokens from logs and pipelines.
Plan for PQC: inventory public-key uses in tokens now. Section 7.7 warns ML-DSA (FIPS 204) signatures are much larger and can strain cookies of around 4 kB and headers of around 8 kB, so consider reference tokens or back-channel presentation. See the NIST IR 8547 PQC Transition Timeline Guide.

Decision guidance: CSPs, agencies and smaller organisations

Situation	Priority	Trade-off
You run a SaaS IdP or token service (CSP)	Key isolation, configurable lifetimes, revocation disclosure, programmatic logs	HSM-backed signing adds latency and cost; IR 8587 is outcome-based on key protection, so document the equivalent isolation you chose
You consume a commercial IdP	Configuration: lifetimes, audience, binding, enabling logs that are off by default	You inherit the CSP's key controls, so assess its disclosures rather than assume
Small organisation, one IdP, few APIs	Validation hygiene, one-hour tokens, logging	Full SSF/CAEP may be out of reach; short lifetimes give most of the revocation benefit
Large hybrid estate with home-grown token services	Retire custom signers or move them behind managed KMS; SPIFFE for workloads	Migration cost is real; prioritise high-impact systems and shared signing keys first
Front-channel SPA clients	Back-channel or BFF patterns, DPoP	Architecture change versus continued bearer exposure in the browser

Common failure patterns

One signing key across tenants or environments: a key valid for both consumer and enterprise, or test and production, turns a single theft into broad access, as the Storm-0558 case showed.
Relying parties that skip audience or issuer checks: a valid token for one application gets accepted by another. This is the redirect threat in Table 7.
Refresh tokens that never die: long-lived refresh and OAuth integration tokens let attackers return for months, as in the Salesloft Drift breach.
Session tokens that outlive MFA: stolen session tokens bypass authentication entirely, as in CitrixBleed. Binding and server-side termination are the answer.
Tokens in logs and build output: debugging middleware that logs Authorization headers creates a token store nobody protects, against 5.3.1.5 and 5.3.1.7.
Assuming revocation works: teams disable a user and assume access ends, while stateless tokens remain valid until expiry and relying parties never hear about it.

Framework mapping

Framework	Reference	Link to IR 8587
NIST SP 800-53 Rev. 5	IA-13 Identity Providers and Authorization Servers	The control IR 8587 implements (Section 4 and the two control enhancements)
NIST SP 800-53 Rev. 5	SC-12 Cryptographic Key Establishment and Management; IA-5 Authenticator Management	Key generation, storage and rotation (5.1)
NIST SP 800-53 Rev. 5	SC-23 Session Authenticity; AC-12 Session Termination	Token binding, revocation and session termination (5.3)
NIST SP 800-53 Rev. 5	AU-2 Event Logging; AU-9 Protection of Audit Information	Table 6 elements, tamper-resistant logs (5.3.1.7)
NIST CSF 2.0	PR.AA-01, PR.AA-05, DE.CM-03	Credential management, enforced authorisation, monitoring of usage
MITRE ATT&CK v20	T1606.002, T1528, T1539, T1550.001	Forgery, theft and reuse of tokens

The SP 800-53 mappings other than IA-13 are our interpretation; the report itself is built on IA-13 and references IA-5. See the NIST SP 800-53 IA Identification and Authentication guide.

Practitioner checklist

Inventory every token signing key with storage type, age, scope and impact level.
Move moderate and high impact signing keys off servers and containers into hardware-backed or isolated storage.
Rotate automatically: 90 days or less for high impact, under one year otherwise, with overlapping JWKS publication.
Confirm every relying party validates signature, kid, issuer, audience, expiry and scope, and alerts on audience failures.
Set access and ID token lifetimes to one hour or less and bound refresh tokens to SP 800-63B-4 reauthentication limits.
Enable DPoP or mTLS binding for workloads, AI agents and high-value APIs.
Connect the IdP to relying parties with SSF/CAEP or introspection for revocation, and get the CSP's written revocation disclosure.
Log the Table 6 elements to the SIEM, and scan logs, repositories and pipeline artifacts for tokens.
Start a PQC inventory of token signing and size-sensitive token transports.

NIST IR 8587 Guide: Protecting Tokens and Assertions from Forgery, Theft and Misuse