NIST IR 8587 Token Security: The Holiday Guidance You Missed

NIST dropped critical token security guidance Dec 22. Learn what IR 8587 requires for key rotation, validation, and the AI agent gap NIST missed. Comments due Jan 30.

Three days before Christmas 2025, NIST and CISA quietly released the most comprehensive federal guidance on token security since the SolarWinds fiasco. NIST IR 8587 dropped on December 22nd while you were wrapping presents and arguing about whether Die Hard counts as a holiday movie (for the record, it absolutely does). The comment period closes January 30, 2026. If you’re reading this in early January, you’ve got weeks to weigh in on guidance that will shape how federal agencies and cloud providers protect the authentication tokens that attackers love to steal.

The document matters. The timing was terrible. And there’s a gaping hole in the middle of it that we need to talk about.

The Guidance That Got Buried

NIST IR 8587, officially titled “Protecting Tokens and Assertions from Forgery, Theft, and Misuse,” provides implementation recommendations for federal agencies and cloud service providers. It builds on IA-13, the identity provider control added to SP 800-53 back in November 2023 after nation-state attackers demonstrated exactly how devastating token-based attacks could be.

The document covers key management, token validation, signing key rotation schedules, audience restrictions, and session monitoring. It references both SolarWinds and Storm-0558 by name and establishes specific requirements that federal contractors and cloud providers must meet.

What caught my attention is that NIST explicitly calls out the shared responsibility model between cloud service providers and their government customers. They want CSPs to be “transparent about their deployed technology, the architecture underpinning the technology, and system-generated data.” They want configurability so agencies can tune security controls to their risk tolerance. They want interoperability so organizations aren’t locked into single-vendor solutions.

Figure 1: Token Attack Timeline and Federal Response

That’s the good news. The bad news is that we’re having this conversation in 2026.

Five Years of Token Attacks and We’re Still Writing Drafts

Let me give you a quick history lesson. In December 2020, attackers compromised SolarWinds Orion software and used it to breach thousands of organizations, including federal agencies. Once inside, they generated forged SAML assertions to bypass MFA and access protected resources. They compromised Active Directory Federation Services, exposed signing certificates, and minted valid-looking tokens to conduct a coordinated espionage campaign.

In May 2023, the Storm-0558 group used a stolen Microsoft consumer signing key to forge authentication tokens. They accessed email accounts at 25 organizations, including government agencies. The State Department alone lost 60,000 emails from 10 accounts, nine of which belonged to people working on East Asia and Pacific diplomacy. A key that was supposed to be valid only for consumer accounts worked against enterprise government systems because of token validation failures.

That was 18 months ago. And we’re still in the “initial public draft” phase of the guidance.

Meanwhile, Microsoft detects 39,000 session token attacks per day. Push Security’s analysis of 2024 breaches found that 73% of confirmed identity-based attacks resulted from compromised credentials. Unit42 documented a 388% increase in cloud security alerts during 2024, with the most significant spike in high-severity alerts related to serverless IAM token abuse. Palo Alto researchers saw a 116% rise in impossible travel alerts for cloud identities.

The attackers aren’t waiting for NIST to finalize their recommendations. Shocker, I know…

The Shared Responsibility Mirage

NIST IR 8587 includes a responsibility matrix in Table 1 that splits duties between CSPs and consumers. Physical security? CSP. Infrastructure? CSP. Token issuance and signing? CSP. But IAM policy configuration? Consumer. Application secrets management? Consumer. Session management? Consumer.

The problem is that these binary assignments don’t reflect reality. When a signing key gets compromised because it ended up in a crash dump on a debugging server, whose responsibility is that? When token validation fails because a consumer key works against enterprise systems, who owns the fix? When an organization can’t detect a breach because it doesn’t have access to the right logs, who bears the cost?

A minority of organizations I work with believe they’re effectively securing their cloud resources. That’s a visibility gap, a configurability gap, and sometimes a transparency gap.

NIST tries to address this. The document calls on CSPs to “apply Secure by Design best practices” and “prioritize transparency, configurability, and interoperability.” However, these principles are voluntary unless mandated by contract or policy, and the document explicitly states that “conformance with this guideline remains voluntary for CSPs and federal agencies unless otherwise determined through policy.”

Voluntary guidance doesn’t stop nation-state attackers.

Figure 2: Cloud Security Responsibility Gaps

The AI Agent Blind Spot

NIST IR 8587 has a HUGE gap for modern IT in 2026. It mentions “non-person entity” exactly once, in the base control statement: “Employ IdPs and authorization servers to manage user, device, and non-person entity (NPE) identities, attributes, and access rights.”

That’s it. In a 47-page document about protecting tokens and assertions in 2025, there’s no substantive guidance on AI agent authentication.

This is a massive oversight.

The Model Context Protocol Authorization Specification was finalized in June 2025. OAuth 2.1 is now the standard for AI agent authentication. Microsoft published guidance in May 2025 arguing that OAuth must evolve for AI agents, explicitly calling for “fine-grained, resource-specific, least-privilege access” and “permission discovery and delegation” for autonomous systems. OWASP released its Securing Agentic Applications Guide in July 2025 with explicit OAuth 2.0 recommendations for agent authorization, followed by a Practical Guide for Securely Using Third-Party MCP Servers and the Top 10 Risks for Agentic Applications, which treats identity and privilege abuse as critical risks. The industry has moved. The guidance hasn’t.

AI agents don’t follow predetermined scripts. They plan, chain tools, and pursue goals through sequences of operations that emerge from reasoning rather than explicit programming. A request that starts as “summarize this quarter’s sales data” might result in the agent querying a database, calling a visualization API, accessing a document repository, and composing a report. Each step requires authentication and authorization. Each step represents an opportunity for compromise.

Consider the attack surface. An agent needs to discover what permissions it requires, request them from users or upstream agents, and then execute operations within those bounds. Traditional OAuth assumed a human would review consent screens and approve scopes. AI agents need to do this programmatically, at machine speed, across dynamically discovered services. The authorization server has to evaluate not just “is this token valid” but “should this agent be doing this thing right now.”

The Cloud Security Alliance found that 34% of organizations with AI workloads have already experienced an AI-related breach. The most common causes were exploited software vulnerabilities, AI model flaws, insider threats, and misconfigured cloud settings. Sound familiar? These are identity problems manifesting in a new context. We’re relearning lessons from the human identity era in the machine identity era.

When an AI agent obtains a token to call an API, that token needs to be scoped to the specific request or session. If an agent in a workflow needs to call a finance database, you should issue a token valid only for that database and only for a few minutes. If the agent or an attacker tries to use it on a different service or after the time window, it should fail. The agent should authenticate using infrastructure-based attestation, not shared secrets that could be extracted from memory or logs.

NIST IR 8587 doesn’t address any of this. The document talks about “subscribers” and “clients” in ways that assume human-initiated flows. It doesn’t contemplate autonomous tool chaining, inter-agent communication, or the accountability challenges that arise when agents blend delegated user authority with autonomous action. There’s no guidance on how to log agent-tool interactions, how to detect privilege escalation when an agent is tricked into exceeding its scope, or how to implement the kind of just-in-time access that agentic workflows require.

The MCP Authorization Specification attempts to address some of these challenges. It introduces Protected Resource Metadata, enabling agents to discover authorization requirements dynamically. It mandates OAuth 2.1 with PKCE even for confidential clients. It provides a consistent workflow for obtaining scoped tokens. But it’s an industry specification, not federal guidance, and it’s not referenced anywhere in NIST IR 8587.

We can’t write token security guidance in 2025 and ignore MCP and Agentic AI.

Figure 3: NIST IR 8587 AI Agent Gap

What NIST Got Right

Despite the gaps, NIST IR 8587 gets several things right. If you’re a security architect or CISO, here’s what to pull from the guidance:

Key Protection Requirements: For systems rated moderate or above, you need hardware-based mechanisms to store and use signing keys. HSMs for high-impact systems. Hardware isolation via TPMs or secure enclaves for moderate. Software isolation only for low-impact systems. The document specifies that signing keys “MUST be scoped at the lowest reasonable level” to reduce blast radius.

Key Rotation Schedules: Multi-tenant CSP systems: 30 days maximum. Single-tenant CSP systems: 3 months maximum. On-premises systems: 1 year maximum. These timelines are up for comment, and I expect pushback from vendors who find 30-day rotation operationally painful. But shorter cryptoperiods reduce the exposure window.

Figure 4: NIST IR 8587 Key Rotation Requirements

Token Validity Periods: Access tokens and identity tokens should be valid “no more than one hour.” That’s softer than I’d like. The document allows flexibility based on compensating controls like revocation capabilities, compromise detection, device registration, and proof-of-possession schemes. If you have robust sender binding and behavioral analytics, you get more runway.

Audience Restriction: All tokens and assertions must include explicit audience fields. All access control mechanisms must reject tokens with incorrect or missing audience restrictions. Services that receive tokens with the wrong audiences should “immediately generate a security alert.” This is table stakes but worth codifying.

Monitoring Requirements: IdPs, token services, and access management tools must monitor token usage patterns, including geolocation, device data, and velocity anomalies. Integration with SIEM and UEBA systems is mandatory. Logs must be tamper-resistant and follow SP 800-92 and OMB Memo 21-31 requirements.

What You Should Do Now

Don’t wait for the final version. The comment period closes January 30, 2026. Whether or not NIST incorporates your feedback, you should act on the guidance that exists. Here’s your action list:

Submit Comments by January 30, 2026: NIST requests feedback on signing key validity periods, token validity lengths, key protection definitions, and emerging standards like Demonstrated Proof-of-Possession and Global Revocation. If you have operational experience that contradicts their recommendations, tell them. If the 30-day multi-tenant rotation requirement would break your operations, explain why and what alternative you’d propose. Email iam@list.nist.gov with your comments.

Audit Your Token Validation Logic: Storm-0558 succeeded because token validation failed. A key intended for consumer accounts worked against enterprise government systems. Review your validation logic top to bottom. Are you checking issuer claims against an allowlist? Are you validating that audience claims match your service? Are you checking tenant claims to prevent cross-tenant token replay? Are you fetching signing keys from the correct JWKS endpoint, or are you trusting cached keys that might be stale or compromised?

Map Your Signing Key Inventory: You can’t protect what you don’t know about. Identify every signing key in your environment. Document the type and algorithm, the intended purpose and scope, the storage location and protection mechanism, the creation date and expected rotation date, and the owner responsible for lifecycle management. Flag any keys that don’t meet the hardware isolation requirements for your FISMA categorization. If you’re running moderate-impact systems with software-only key protection, you have a gap to close.

Implement Audience Restrictions Immediately: If your tokens don’t have explicit audience claims, fix that this week. If your services don’t validate audience before granting access, fix that too. This is low-hanging fruit that blocks token redirect attacks. Configure your authorization server to include audience in every token. Configure your resource servers to reject tokens with missing or mismatched audiences. Log every rejection as a security event.

Address AI Agent Authentication Now: NIST won’t do this for you. If you’re deploying AI agents that access protected resources, implement OAuth 2.1 with PKCE for all clients, including confidential ones. Use short-lived tokens scoped to specific operations, not long-lived tokens with broad permissions. Authenticate agents via infrastructure-based attestation rather than shared secrets. Log token issuance events with enough context to reconstruct what the agent was trying to do. Monitor for impossible travel, unexpected tool access patterns, and privilege escalation attempts. The MCP Authorization Specification provides a starting point for implementing these controls.

Evaluate Your CSP Transparency: Do you understand how your cloud provider manages signing keys? Can you access the logs you need to detect token misuse without paying for premium licensing? Is their responsibility matrix enforced through contracts, or is it marketing language with no teeth? If you can’t answer these questions, schedule a conversation with your CSP account team. Ask for documentation on their key management practices, their key rotation schedules, and their incident notification commitments. Factor that into your risk assessment if they can’t or won’t provide clear answers.

Build Token Anomaly Detection: Don’t just log token events. Analyze them. Implement detection rules for impossible travel between token uses, token reuse across multiple source IPs, tokens used after session termination, tokens with unusual scope requests, and validation failures that could indicate forgery attempts. Feed these signals into your SIEM and UEBA platforms. Create runbooks for investigating alerts. Test your detection by simulating token abuse in a controlled environment.

Key Takeaway: NIST IR 8587 provides solid fundamentals for token security, but it’s already outdated on AI agent authentication. Take the guidance, fill the gaps yourself, and don’t wait for federal bureaucracy to protect you from attacks happening today.

What to do next

If you’re building an AI governance program that addresses these identity challenges, the CARE Framework provides a structure for contextual AI risk evaluation that includes authentication and authorization controls. For broader security program maturity, the RISE Framework helps organizations build resilience against the kind of identity-based attacks NIST is trying to prevent.

The fundamentals haven’t changed. Tokens are the keys, and attackers are five years ahead of the guidance.

Subscribe for more AI security and governance insights with the occasional rant.

👉 Visit RockCyber.com to learn more about how we can help you in your traditional Cybersecurity and AI Security and Governance Journey

👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com

👉 Subscribe for more AI and cyber insights with the occasional rant.