What Does NIST IR 8587 Mean for API Security?

TL;DR

• What happened: NIST published Internal Report 8587 on September 15, 2026, covering how to protect identity tokens, access tokens, and federated assertions from theft and forgery. 
• The real subject: it’s framed as SSO guidance, but access tokens authorize every API call, so this is effectively an API authorization standard. 
• What it asks for: strict token validation, shorter lifetimes, token binding, key rotation, leakage prevention, and continuous monitoring for misuse. 
• Who it applies to: directly, federal agencies and their cloud service providers under NIST SP 800-53 5.1.1; indirectly, any organization running OAuth 2.0, OpenID Connect, or SAML. 
• Why it matters now: agentic AI and MCP are multiplying non-human identities and the tokens tied to them, making token-layer controls more urgent, not less. 

On September 15, 2026, NIST published Internal Report 8587, “Protecting Tokens and Assertions from Forgery, Theft, and Misuse.” It’s built to extend NIST Special Publication 800-53 Release 5.1.1, and on paper it reads like an SSO hardening document for government agencies and their cloud vendors. Read past the framing, though, and it’s really a token security playbook for anything that authenticates once and then talks to APIs, which describes almost every modern application, integration, and now AI agent. 

What is NIST IR 8587

IR 8587 covers three kinds of artifacts: identity tokens that establish who a user or workload is, access tokens that authorize a request to an API or resource, and assertions exchanged during federated logins over protocols like SAML, OpenID Connect, and OAuth 2.0, the same standards behind the OWASP API Top 10. NIST’s core argument is that these tokens deserve the same treatment as high-value credentials. A stolen token can hand an attacker an already-authenticated session, which is often more dangerous than a stolen password because it skips authentication entirely and can persist quietly inside an API workflow.

Why an SSO report is really about API security

Single sign-on gets a user through the front door once. What happens after that, every subsequent request to an API, a microservice, or a cloud resource, runs on the access token that SSO issued. If that token is weakly validated, long-lived, or leaked, the SSO layer stops mattering. The attacker is no longer trying to log in; they’re already inside the API layer, replaying or forging the token that every backend service trusts by default. 

That’s the gap IR 8587 is closing. Its recommendations aren’t about login screens. They’re about how APIs and authorization servers should issue, validate, bind, and retire the tokens that sit behind every request, work that a WAF or API gateway alone was never built to do at the business logic level.

The seven controls the report asks for

Cryptographic integrity. Use strong signing algorithms and securely managed keys so tokens can’t be forged. 

Strict validation on every request. Check issuer, audience, signature, expiration, and scope before an API honors a token, not just at login. 

Shorter token lifetimes. Limit how long a token stays valid and control refresh-token behavior to reduce what a stolen token is worth. 

Key rotation and transparency. Rotate signing keys regularly and publish trustworthy key information to federated partners. 

Token binding. Tie a token to a specific client, device, workload, or cryptographic key wherever it’s technically possible. 

Leakage prevention. Keep tokens out of browser storage, application logs, URLs, telemetry, source code, and error messages. 

Continuous monitoring. Watch for abnormal token use: impossible travel, unusual API call patterns, and reuse that shouldn’t be happening. 

NIST also pushes CSPs toward secure-by-design defaults, arguing that customers shouldn’t have to discover and manually enable protections that should already be on.

Who this actually applies to

Audience	How IR 8587 applies
Federal agencies	Directly. IR 8587 extends the NIST SP 800-53 5.1.1 baseline agencies are already required to meet.
Cloud service providers serving government (FedRAMP)	Directly. The report splits responsibility between CSPs that issue tokens and agencies that consume them.
Enterprises outside government	Indirectly. No legal mandate, but the same OAuth 2.0 / OIDC / SAML tokens run their APIs and SaaS integrations, so the same failure modes apply.
Identity providers, authorization servers, relying parties	Directly named as parties responsible for enhancing token safeguards, regardless of sector.

So no, IR 8587 isn’t a law that private companies have to follow. But it’s the clearest signal yet of where the federal bar for token and API authorization security is heading, and federal guidance tends to filter into vendor requirements and governance and compliance checklists well before it becomes a mandate.

Why this lands differently now: agentic AI and MCP

The timing matters. Every one of the failure modes IR 8587 is trying to close, forged tokens, replayed assertions, over-long token lifetimes, missing scope checks, gets worse as organizations wire up agentic AI systems and MCP servers that mint and pass around their own tokens on behalf of users and other agents. Non-human identities already outnumber human ones inside most API estates, a risk the OWASP Agentic Top 10 calls out directly, and each agent-to-API call is another place a token can be over-scoped, under-validated, or quietly leaked into a log. It’s also why the list of top MCP security companies has grown so quickly this year. A report about SSO tokens written in 2026 is, whether NIST says so or not, also a report about securing the identity layer underneath agentic AI.

What security teams should do with this now

Inventory token issuers and consumers. You can’t validate what you haven’t discovered, and most environments are carrying more zombie APIs and unmanaged APIs than their inventory shows. 

Review federation trust relationships. Confirm every relying party actually needs the trust it has, and revoke what doesn’t. 

Rotate exposed signing keys. Treat any past key exposure as a live risk, not a closed incident. 

Reject malformed or improperly scoped tokens by default. Push validation into the API layer itself rather than trusting upstream checks. 

Test it before an attacker does. Continuous red-teaming catches token and authorization gaps that a point-in-time pentest misses. 

Monitor for token misuse at the API layer. Impossible travel and odd request patterns are easier to catch when you’re watching API traffic and business logic, not just login events. 

This is business logic security territory as much as it is identity security. A token that passes every cryptographic check can still be used to call an API in a sequence, volume, or context it was never meant for, which is exactly where token validation alone runs out of coverage and a Business Logic Graph picks up the context that token checks miss.

The bottom line

NIST IR 8587 is a federal document with a universal message: tokens are high-value credentials, and most organizations are securing them like an afterthought. If you’re a B2B SaaS company running OAuth, SSO, or API-based integrations, the question isn’t whether this guidance applies to you. It’s whether you’d survive an audit against it.

Frequently Asked Questions