The security boundary continues beyond the sign-in screen
A familiar security story ends when a user enters a password and approves a second factor. In practice, an application must keep deciding which requests to trust afterward. NIST's final token-protection guidance, published on September 15, addresses that less visible part of online security.
The report, NIST IR 8587, follows a draft released in December 2025 and was developed with CISA. It is written for federal agencies and cloud service providers, covering identity assertions, access tokens and the infrastructure that issues and checks them. It is not an announcement that a new attack has compromised every account.
For readers, the central lesson is straightforward: a good login and a well-protected session solve related but different problems. Treating one as a substitute for the other creates an incomplete picture of how a cloud service keeps its users and their data separated.
Sources: NIST: final token-protection guidance announcement; NIST IR 8587: final report and publication history
A token is a permission, not another password
An access token represents authorization to use a resource. An identity assertion conveys information about an identity. Their exact format and behavior depend on the protocol and deployment; not every token is a JSON Web Token, and an identity token should not casually be treated as an interchangeable API permission.
An everyday analogy is a visitor badge. Checking someone's identity at reception is one decision. Deciding which doors the badge opens, when it expires and whether it has been canceled involves others. The analogy is imperfect, but it explains why protecting the original password is not the entire job.
OAuth's security best-current-practice document, RFC 9700, recommends restricting tokens to their intended audience and, where appropriate, to the sender authorized to use them. A credential intended for one service should not silently become a pass for unrelated services. Those limits reduce the consequences when information reaches the wrong place.
Sources: NIST IR 8587: full implementation recommendations; IETF RFC 9700: OAuth 2.0 security best current practice
Key protection and validation have to work together
NIST emphasizes the full chain: protecting signing keys, checking a token's integrity and intended use, limiting its lifetime and managing revocation. The report also warns against recording raw tokens in logs. Security teams need an audit trail without turning their diagnostic systems into a store of reusable credentials.
A valid signature is therefore not the same as permission for every action. An application also needs to establish whether the issuer, destination, time window and authorized operations fit the request. Our practical takeaway is that a procurement checklist should ask about enforcement at the application, not just the identity provider's branding.
Responsibilities can fall across several organizations. A provider may issue a token, a customer may configure access rules and another service may accept the request. Clear ownership matters because a missing check at a connection between systems can undermine otherwise careful work. The final report's guidance is not automatically a universal legal obligation; its applicability depends on the relevant policies and agreements.
What proof of possession can—and cannot—do
One established option is DPoP, defined in RFC 9449. In a supported deployment, it binds token use to a cryptographic key and requires the client to demonstrate possession of the corresponding private key. Simply copying the token should then be insufficient for a different client to use it.
That is an additional check, not a replacement for encrypted transport, token validation or access-control decisions. DPoP is not itself a user-login method. Its protection also depends on correct support at the participating services and on what an attacker can do to the client.
Revocation deserves equal attention. NIST notes that immediate, global cancellation is not always possible in stateless token systems. A dashboard showing that an account has been disabled does not, by itself, prove every connected application has already rejected existing access. Buyers should ask providers to demonstrate the actual termination behavior, including the slowest integrated service.
Sources: NIST IR 8587: full implementation recommendations; IETF RFC 9449: demonstrating proof of possession
Scientific perspective: test the recovery path
Lumacta's evidence-based assessment is that the most useful security metric is not the number of authentication features advertised. It is whether the complete system behaves as intended under realistic failure conditions. That assessment follows the documents' focus on validation and lifecycle management; it is not a claim that Lumacta has audited a particular cloud provider.
An authorized defensive test could measure how long unwanted access survives after a revocation decision, whether permissions remain separated between applications and whether legitimate users can recover safely. The test should document configuration, network conditions and exceptions. A single clean demonstration is less informative than repeatable results across the applications an organization actually uses.
There is a trade-off to evaluate rather than hide. Shorter credential lifetimes can reduce an exposure window, but renewal and outage handling must remain dependable. Key-bound tokens can limit copying, but RFC 9700 explains that compromised client software or access to the necessary key material can weaken that protection. Security is an interaction between controls, not a property conferred by an acronym.
Sources: NIST IR 8587: full implementation recommendations; IETF RFC 9700: OAuth 2.0 security best current practice; IETF RFC 9449: demonstrating proof of possession
Keep MFA—and ask better questions of providers
This guidance is not a reason to turn off multifactor authentication. CISA continues to describe MFA as an extra layer that makes unauthorized account access harder. Individuals should retain it, use the service's account-security controls and take unexpected session or access alerts seriously. Most people cannot configure a provider's signing infrastructure, and should not be expected to.
For a small business choosing cloud software, a more useful conversation starts with practical questions: can administrators review active access, remove obsolete integrations and demonstrate what happens after an account is disabled? Can the provider explain the boundary between what it secures and what the customer must configure?
The economic case is preventive rather than glamorous. A visible sign-in feature is easy to sell; reliable session termination and tested key rotation are harder to showcase. Yet a business depends on those less visible mechanisms when a problem occurs. NIST's contribution is to give that discussion a more concrete structure. The real test is implementation, not the publication of another security document.
Sources: NIST IR 8587: full implementation recommendations; CISA: require multifactor authentication
Sources & Methods
Checked September 19, 2026 against the final NIST record and report. RFC 9700 and RFC 9449 supply protocol context; CISA supplies baseline MFA advice. This is a defensive explainer, not a provider audit, compliance certification or legal opinion.
- NIST: final token-protection guidance announcement — Primary announcement
- NIST IR 8587: final report and publication history — Final guidance record
- NIST IR 8587: full implementation recommendations — Primary technical guidance
- IETF RFC 9700: OAuth 2.0 security best current practice — Protocol security standard
- IETF RFC 9449: demonstrating proof of possession — Protocol specification
- CISA: require multifactor authentication — Baseline defensive guidance