NIST IR 8587 and the token problem: what it means for the threat detection job

What was published?

NIST IR 8587, "Protecting Tokens and Assertions from Forgery, Theft, and Misuse", was published as final on 15 September 2026, with implementation recommendations for agencies and cloud service providers. On 16 September the OpenID Foundation said the guidance recommends the Shared Signals Framework and CAEP. This post summarizes where the guidance touches an IAM stack; read the document itself for its recommendations.

Why do tokens matter for every job?

After sign-in, an application trusts a token or a SAML assertion rather than asking again. A stolen token skips the password and the MFA prompt. That moves part of the identity provider's job into detection and response: noticing that a valid session is being used by the wrong party, and ending it.

Which tools act on sessions?

• Okta Identity Threat Protection evaluates risk throughout user sessions, can sign a user out of every app with Universal Logout, and shares signals with CrowdStrike, Zscaler, Palo Alto Networks and Jamf.
• Microsoft includes ID Protection and risk-based Conditional Access with Entra ID P2, and Defender for Identity detects identity-based attacks across on-premises, cloud and hybrid environments.
• Silverfort responds during authentication itself, with a block, an MFA challenge or a terminated session, before the authentication completes.

What do Shared Signals add?

The OpenID Foundation's Shared Signals work defines how tools send each other security events. CAEP covers session events such as Session Revoked, Token Claims Change and Credential Change; RISC covers account events such as Account Disabled. CAEP and RISC were approved as Final on 2 September 2025. When your identity provider, endpoint tool and network tool all speak these events, one detection can end a session everywhere.

Where do unmanaged applications come in?

Applications that keep local accounts and their own sessions do not hear a revocation event from the identity provider. Universal Logout ends sessions in connected applications; an application outside the stack keeps its session until it expires. That is the application coverage job showing up inside an incident.

What should you check in your own stack?

• Can you revoke every session for one person in minutes, across all applications?
• Which applications accept a revocation event, and which keep their own sessions?
• Do your identity provider and detection tools share signals, and in which direction?
• Who owns the response runbook, and when was it last tested?