NIST Just Told Cloud Providers Your Login Tokens Live Too Long. Here's the New Math.
October 21, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
A token that never expires is a credential an attacker never has to steal twice. NIST and CISA's new Interagency Report 8587 answers the question identity teams usually skip: how long should an access token actually live? The guidance says generally no more than one hour, with signing keys rotated at least every 90 days for high-impact systems, and it applies the rule to humans, workloads, and AI agents alike.
What Is NIST IR 8587 and Why Does It Exist Now?
NIST IR 8587, titled "Protecting Tokens and Assertions from Forgery, Theft, and Misuse," is implementation guidance for federal agencies and cloud service providers, finalized on September 15, 2026 after a public comment period that drew nearly 250 responses. It was developed jointly by NIST and CISA's Joint Cyber Defense Collaborative, with input from Google, Microsoft, Okta, AWS, and the OpenID Foundation among others, and it supports Executive Order 14306 on secure software development practices.
The timing is not arbitrary. CISA's Chris Butera framed the stakes directly: identity has become the primary target, and the tokens and assertions behind it are attractive targets for sophisticated adversaries. The report builds directly on the IA-13 "Identity Providers and Authorization Servers" control added in NIST Special Publication 800-53 Release 5.1.1, turning what had been a fairly abstract control statement into concrete architectural requirements.
What Does the Guidance Actually Require?
The short version is that tokens get shorter-lived, keys get rotated more often, and every token has to prove exactly what it is for. Specifically, access and identity tokens should generally expire within one hour, with shorter periods applied to higher-risk resources, and expired tokens must be rejected outright rather than quietly accepted by a lenient validator.
A few other requirements stand out for anyone who actually configures an identity provider:
- Signing keys for high-impact systems should rotate at least every 90 days, with a maximum of a year for lower-impact systems, and must be stored in hardware-backed or isolated storage rather than persistently on the servers that use them.
- Every token must carry an explicit audience field, and any access control mechanism receiving a token without one must reject it outright, which closes the exact gap that let one compromised key work across services it was never scoped for.
- For theft and replay resistance, the report recommends sender-constrained mechanisms such as mutual TLS and Demonstrating Proof of Possession, along with fine-grained conditional-access decisions informed by device, network, geolocation, and behavioral context.
Workload identities and automated services get the same treatment as human users. The report calls for tightly scoped, short-lived credentials from approved identity platforms instead of static secrets, and it explicitly extends to AI agents that use signed tokens to reach tools, data, and APIs, while acknowledging that broader agent identity governance still needs more standards work.
Why Did It Take an Incident to Get Here?
Because one did happen, and it is the clearest illustration of why audience restriction and key isolation matter. In the Storm-0558 breach, a China-based threat actor acquired an inactive Microsoft consumer signing key and used it to forge authentication tokens for Azure AD enterprise and consumer accounts to access Outlook Web Access and Outlook.com. The key was meant for one context. A validation gap let it work in another, and the forged tokens read government email for roughly a month before anyone caught it.
That single flaw maps almost one-to-one onto two of IR 8587's core requirements: isolate and scope signing keys so a consumer-grade key can never validate an enterprise-grade token, and reject anything missing an explicit audience claim. The guidance was not written in a vacuum. It was written because a scoping failure that sounds theoretical on a whiteboard already cost a federal agency a month of undetected email access.
What Does This Mean for Identity and Access Administrators?
It means the token lifetime and conditional access settings you configure are no longer a tuning decision, they are a documented control with a federal benchmark attached. If your organization issues access tokens valid for eight or twelve hours because shorter sessions annoy users, you now have a specific government reference point showing that is a wider exposure window than current guidance recommends.
This lands squarely in the daily work covered by Microsoft's SC-300: Identity and Access Administrator certification, which trains on configuring conditional access policies, token lifetime settings, and sign-in risk detection inside Microsoft Entra ID. An administrator who understands why a one-hour token lifetime matters, not just how to set the value in a policy blade, can explain the tradeoff to a risk committee instead of just clicking a checkbox someone else recommended.
The guidance is voluntary for now and aimed at federal agencies and the cloud providers that serve them, but voluntary federal guidance has a track record of becoming the baseline vendors build to and auditors ask about anyway. If your organization sells into government, works with a CSP that adopts IR 8587's defaults, or simply wants a defensible answer the next time an insurer or auditor asks how long your tokens live, this report is the document that sets the bar.
How Should a Security Team Start Closing the Gap?
Start by finding out what you do not currently know: how long your tokens actually live today, whether refresh tokens get reauthenticated after suspected compromise, and whether your logs ever capture a raw token value. IR 8587 is explicit that tokens and any personal data within them must never be written to logs, which is a surprisingly common finding in debug logging and CI/CD pipelines that nobody audited after the integration shipped.
From there, the practical sequence looks like an inventory before a rebuild. List every identity provider and authorization server in use, note the token lifetime and key rotation interval each one is configured with, and flag anything issuing long-lived static secrets to service accounts or automated workloads. One analysis of the report's blind spots points out that the governance practices needed to know which tokens exist, who holds them, and how long they should live remain immature across the non-human identity population the guidance now explicitly covers, which means the inventory step is often the hardest part, not the policy change itself.
None of this is exotic engineering. It is disciplined identity hygiene applied with a specific number attached instead of a vague best practice. Forge University's resources page breaks down which certification paths map to which identity and cloud security skill sets if you are trying to figure out where token lifecycle management fits into your own study plan. If your team is building that discipline from the ground up, you can start training on the Entra ID and conditional access content this guidance now touches directly.
The deeper lesson is that identity infrastructure failures do not look like a firewall breach. They look like a key that was scoped for one purpose quietly working somewhere it should not have, for weeks, before anyone notices the audit log. IR 8587 is NIST and CISA's attempt to put a number on the window that failure gets to stay open. Whether your organization treats one hour as a hard requirement or a reasonable default, it is now the number everyone downstream is going to compare you against.