NIST IR 8587 explained: what the token protection report means for identity buyers

Published 2026-09-16 · NextGen Identity Security desk · 4 min read

Most identity security spending goes on the moment of sign-in: stronger authentication and better risk checks. NIST IR 8587 is about what happens after it. Its title states the scope: Protecting Tokens and Assertions from Forgery, Theft, and Misuse. This post summarizes what is public about the report and what it means when comparing identity providers. It is based on the NIST publication page and the OpenID Foundation's response, not on a line-by-line reading of every recommendation.

The basics

• Published as final on 15 September 2026; the draft appeared on 22 December 2025.
• The authors are from NIST, Accenture Federal Services and CISA.
• Its recommendations are addressed to identity providers, authorization servers, key management and token verification.

Where it sits among other NIST documents

NIST SP 800-207, published in August 2020, describes zero trust: access decided per request, around users, assets and resources rather than network location. NIST SP 800-63B-4, published on 31 July 2025, covers authentication and the three authenticator assurance levels. IR 8587 picks up where those leave off: once the decision is made and carried in a token, how to stop that token being forged, stolen or misused.

Why tokens need their own report

A token or assertion is a portable statement that a sign-in happened. Applications check its signature and contents, not the person. That makes three failures serious. A stolen token lets an attacker act as the user until it expires. A replayed token can work in places it was never meant to. And a stolen signing key lets an attacker create valid tokens at will, which is the attack known as Golden SAML.

The OpenID Foundation's reading

On 16 September 2026 the OpenID Foundation wrote that the report specifically recommends two of its specifications. The Shared Signals Framework defines how identity providers and relying parties exchange security event signals in a standard way. The Continuous Access Evaluation Profile lets access be re-evaluated continuously rather than only at sign-in. Separately, on 10 September 2026, OpenID Foundation members approved OpenID Connect Key Binding 1.0 as an Implementer's Draft, a specification for binding cryptographic keys within OpenID Connect flows.

Five questions for any identity provider

1. Lifetimes: how long do sessions, access tokens and refresh tokens last by default, and can they be shortened per application?
2. Signals: does the product send and receive Shared Signals or CAEP events, and with which partners?
3. Re-evaluation: what happens to a live session when risk changes?
4. Signing keys: where are token-signing keys held, who can use them, and how would a stolen key be detected and rotated?
5. Verification: do relying applications check audience, expiry and signature, and does the provider help them do it?

What the vendors on this site publish

Okta publishes the most on the signals side. Identity Threat Protection continuously assesses user risk during sessions, shares signals with CrowdStrike, Zscaler, Palo Alto Networks and Jamf through the Shared Signals Framework, and can end sessions across supported apps with Universal Logout. Microsoft's Conditional Access evaluates signals including user, device, location and risk.

NewCore publishes the most on the signing-key side. Its Secure Split Key needs both a key share in NewCore's cloud and one in the customer's environment to sign a valid token, and NewCore states that a compromise of its cloud exposes only one share. On our workforce IAM page, the other identity providers' pages reviewed do not describe customer-held signing keys, which is a gap in public material rather than evidence of a weakness.

The short version

If an identity security plan stops at sign-in, IR 8587 is a reminder that the token is the asset. Ask every vendor the five questions above, and weight the answers alongside sign-in strength.