A user signs in with a passkey. The authentication is phishing-resistant. The identity provider records a successful challenge. Every dashboard says the login worked as designed.

Hours later, an attacker reuses a stolen session token.

No password is entered. No push notification appears. No new authentication ceremony occurs. The application sees a valid artifact and accepts it.

Both facts can be true at the same time: the authentication was strong, and the session was compromised.

That is the identity problem security programs need to address next.

Passkeys, hardware security keys, conditional access, and stronger account recovery are essential. They protect the process of establishing identity. But modern applications rarely ask a person or workload to prove identity again for every action. They rely on tokens and assertions that carry the result of an earlier decision across applications, APIs, clouds, and sessions.

The security boundary therefore does not end at login. It moves with the token.

NIST and CISA made that point operational in the final September 2026 release of NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse. The report addresses the keys that create trust, the systems that validate it, the lifetime of tokens, session monitoring, revocation, workload identity, and the division of responsibility between cloud providers and their customers.

The practical lesson is straightforward:

Treat every token as a live authorization decision, not as a receipt proving that authentication once succeeded.

A Valid Token Can Represent a Stale Decision

Tokens make modern computing possible.

They support single sign-on, federation, application programming interfaces, mobile applications, service-to-service communication, and non-human workloads. Instead of asking every application to handle passwords or repeat an authentication process, an identity provider or authorization server issues a signed artifact. A relying application validates that artifact and uses its claims to make an access decision.

That model creates scale. It also creates a gap between the moment trust is established and the period during which that trust can be exercised.

During that gap:

• The token can be stolen from a browser, endpoint, log, pipeline, cache, or integration.
• A signing key can be exposed, allowing an attacker to manufacture apparently valid tokens.
• A token intended for one audience can be accepted somewhere else if validation is incomplete.
• A user can be disabled while previously issued tokens remain usable.
• A device, network, privilege, or risk condition can change after the original authentication.
• A refresh token can extend access long after the short-lived access token expires.

The 2023 Storm-0558 intrusion demonstrated the scale of this failure mode. The Cyber Safety Review Board reported that the actor used forged tokens to access cloud email across 22 organizations and downloaded approximately 60,000 emails from the U.S. Department of State alone. The State Department found the activity through custom analysis of mailbox-access logs—not because the forged authentication artifacts failed to look valid. (Cyber Safety Review Board, April 2024)

That incident was not a failure of user password quality. It was a failure in the machinery that creates, validates, observes, and constrains trust.

The Identity Control Plane Has Two Jobs

Most identity programs concentrate on the first job: establish who or what is requesting access.

The second job is just as important: continuously determine whether the resulting access should still be allowed.

Those are different decisions.

Authentication answers a question at a moment in time. Session security must keep answering questions as the context changes:

• Is this the intended user, device, application, or workload?
• Is the token being presented to the intended resource?
• Is the requested action within the token’s scope?
• Has the account, role, device, or risk state changed?
• Has the token or its signing key been exposed?
• Can the organization terminate the access everywhere it matters?

NIST’s guidance is explicit that authorization systems should not rely solely on a token’s technical validity. They should also consider the context in which the token is presented and connect token validity to the full identity lifecycle, including provisioning, entitlements, deprovisioning, least privilege, and just-in-time access.

That shifts the goal from valid token to valid access, right now.

Use the Issue, Bind, Observe, Terminate Model

Security leaders do not need to become protocol engineers. They do need a way to test whether token-based access is being managed as a complete system.

Use four verbs: Issue, Bind, Observe, Terminate.

1. Issue the Smallest Useful Trust

A token should carry no more authority and remain valid no longer than the task requires.

That means defining:

• The issuer that is allowed to create the token.
• The identity or workload the token represents.
• The resource or audience that may accept it.
• The operations or scopes it authorizes.
• The conditions under which it can be refreshed.
• The exact time at which it expires.

NIST IR 8587 says access and identity tokens must have defined, short lifetimes and recommends that they generally remain valid for no more than one hour, while allowing providers and consumers to tailor that period to system risk, assurance level, and available compensating controls. Higher-risk resources should use shorter periods.

The number itself is not the entire control. A five-minute token that can be silently refreshed for months may preserve more access than its nominal lifetime suggests. Leaders should examine access tokens, refresh tokens, reauthentication requirements, and session limits as one design.

The same principle applies to machines. Long-lived secrets for workloads create durable impersonation paths. NIST recommends tightly scoped, short-lived tokens issued through approved enterprise identity systems for non-person entities and automated services.

The objective is not shortness for its own sake. It is to minimize how much trust remains portable after the conditions that justified it have changed.

2. Bind Trust to Its Intended Use

Traditional bearer tokens have a dangerous property: possession may be enough to use them.

The IETF’s OAuth 2.0 Security Best Current Practice recommends audience restriction and sender-constrained access tokens to reduce replay. Audience restriction limits the resources that may accept a token. Sender constraining requires the presenter to prove possession of additional key material, using mechanisms such as mutual TLS or Demonstrating Proof of Possession.

Neither control makes theft impossible.

They make a stolen artifact less portable.

That is a useful design goal. If a token leaks into a log, lands on a compromised host, or is presented to the wrong service, the architecture should limit where and by whom it can be used.

Security reviews should therefore ask more than whether a token is signed. They should ask:

• Does every relying service validate the issuer, signature, audience, expiration, and permitted use?
• Can one signing key or validation error create trust across unrelated environments?
• Are high-value tokens bound to a client, device, certificate, or workload when feasible?
• Does the resource server reject a correctly signed token that was not intended for it?

A signature can prove that an artifact was signed by a particular key. It does not, by itself, prove that every claim is appropriate for every use.

3. Observe Trust Without Exposing It

Identity teams often know that a token was issued. Security teams need to know how that token was used.

NIST recommends monitoring token and assertion usage for signals such as geolocation, device information, and velocity anomalies, and correlating the underlying identity with actions across the enterprise or cloud provider. It also calls for token-related data to be available to security monitoring and analytics systems.

The distinction between logging the event and logging the secret matters.

Useful records can include:

• Token or assertion type.
• Issuer.
• Scope.
• Obfuscated user, client, or workload identifier.
• Intended audience.
• Issuance, refresh, acceptance, rejection, and revocation events.

The token itself should not be written to logs. NIST also warns against exposing tokens in CI/CD output, build artifacts, traces, caches, and debugging data. A control intended to create visibility should not become the theft path.

This is where many shared-responsibility assumptions fail. The cloud provider may generate an event, the application may record an action, and the enterprise SIEM may retain an alert, but nobody may have designed a reliable way to connect the three.

The result is technically available evidence that cannot answer a basic incident question: what did this identity do while the token was valid?

4. Terminate Trust Everywhere It Propagated

Revocation is where architecture claims meet operational reality.

Disabling a user does not necessarily invalidate every access token. Resetting a password may not end every session. Revoking one refresh token may not terminate access at every relying party. Stateless tokens can remain valid until they expire unless resource servers receive and enforce another signal.

NIST notes that immediate, global revocation may be difficult or technically impossible in some stateless designs. It recommends combining short token lifetimes with reauthentication, revocation capabilities, session analysis, and shared risk signals. Where providers can propagate revocation status, relying parties need to reject revoked tokens and terminate the associated sessions.

That makes revocation a system property, not an identity-console button.

Security leaders should measure time to effective revocation:

From the moment the organization decides that access is no longer trustworthy, how long does it take to stop that access across every material application, API, cloud, and workload?

The answer should come from a test, not a product brochure.

Shared Responsibility Is Not Shared Assurance

Cloud providers and customers both participate in the token lifecycle, but they do not control the same parts.

The provider may operate core identity services, protect signing infrastructure, issue tokens, and expose logs or revocation interfaces. The customer may configure authentication, define access policies, manage sessions, enable application logging, connect telemetry, investigate incidents, and decide which provider capabilities to activate.

Token revocation, monitoring, and incident response cross that boundary.

That means a responsibility matrix is not enough. Each critical capability needs an evidence path:

• What does the provider do by default?
• What must the customer configure?
• Which telemetry is available, at what service tier, and for how long?
• Which events can be exported programmatically?
• How are signing-key compromises communicated?
• How are revocation and risk signals propagated?
• Which applications actually consume and enforce those signals?
• What happens when the identity provider, provider API, or network connection is impaired?

An organization can satisfy its side of a responsibility statement and still have an unprotected end-to-end path.

The control is only real when the complete chain works.

Test the Session, Not Just the Login

Most identity tests begin with enrollment and end with successful authentication.

Extend the test.

Use a non-production environment and a representative high-value service. Issue a session, change the conditions that justified it, and observe what happens.

For example:

1. Authenticate normally and obtain authorized access.
2. Disable the user, remove a role, mark the device untrusted, or revoke the session.
3. Attempt to reuse the existing access and refresh tokens.
4. Confirm which applications and APIs reject them, which continue to accept them, and for how long.
5. Verify that the security team receives usable events without receiving the token value itself.
6. Confirm that responders can connect token activity to consequential actions.

Repeat the exercise for a workload identity. Human and machine sessions may use different issuers, lifetimes, scopes, and revocation paths.

The test will expose more than a technical configuration problem. It may reveal a contract limitation, a premium logging dependency, an application that ignores revocation signals, an unmanaged legacy integration, or an incident playbook that assumes password reset ends access.

Those are governance findings as much as identity findings.

What Security Leaders Should Do This Week

Start with one consequential access path.

1. Map the token lifecycle. Identify the issuer, signing keys, token types, audiences, scopes, lifetimes, refresh paths, relying services, logs, and revocation mechanisms.
2. Find the bearer-token exposure. Review browsers, endpoints, logs, pipelines, debugging systems, caches, and integrations for places where possession could become access.
3. Measure time to effective revocation. Disable or revoke a test identity and verify when access actually stops at each material service.
4. Inspect shared responsibility. Document which token-security capabilities belong to the provider, the customer, and each connected application—and collect evidence that each handoff works.
5. Add workload identity. Apply the same lifetime, scope, monitoring, and termination questions to service accounts, automation, APIs, and AI agents.
6. Update the incident playbook. Treat token exposure as an identity incident that may require session termination, key rotation, evidence preservation, and coordinated action across providers and applications.

Strong authentication remains essential.

It is simply not the finish line.

The security decision begins when identity is established. It continues every time a token is issued, presented, refreshed, accepted, rejected, or revoked.

Organizations that protect only the login are securing a moment.

Organizations that issue, bind, observe, and terminate trust are securing the session.

---

More Information and Assistance

MicroSolved, Inc. can help organizations:

• Assess identity, federation, token, and session-management architectures.
• Test token theft, replay, refresh, and revocation scenarios.
• Review cloud-provider responsibilities, logging capabilities, and evidence gaps.
• Evaluate workload, API, service-account, and AI-agent identity controls.
• Build identity incident-response and session-containment playbooks.
• Design practical improvements for authentication, authorization, monitoring, and recovery.

Contact MicroSolved at info@microsolved.com or +1.614.351.1237.

Relax. We’re on watch.

AI tools were used as a research assistant for this content, but human moderation and writing are also included.