How Token-Based Identity Systems Inherit Trust Without Revalidation

The Azure identity system — Azure Active Directory, now Entra ID — evaluated access requests against token validity: cryptographic signature, expiration timestamp, and embedded claims. It did not evaluate the current state of the principal the token represented. The access decision was made once, at authentication. Every subsequent request to a protected resource inherited that decision unchanged.

The trust model assumed authentication events were terminal. A successful primary authentication — credential validation, MFA challenge, certificate assertion — produced a token that carried resolved trust forward into downstream systems. Entra ID issues short-lived access tokens (default 60–90 minutes) and longer-lived refresh tokens (default 90 days for persistent sessions on compliant devices). Primary Refresh Tokens (PRTs), tied to Azure AD-joined device state, persist across reboots and user switches. Conditional Access policies evaluated at token issuance, not at each resource request. The system treated the token as a portable container of resolved trust. It assumed that what was true at authentication remained true at access.

The operational environment changed in ways that invalidated that assumption. PRTs persisted across device handoffs, compliance state changes, and policy revisions. Refresh tokens issued at onboarding remained valid across role changes and offboarding events. Service principal credentials and delegated tokens propagated across automated workflows, version boundaries, and infrastructure changes. Device join state, network boundary, and compliance posture became decoupled from session state. The system did not re-evaluate. It continued to process tokens issued against conditions that no longer existed.

Each resource access request resolved to token validation: signature verification against the issuer’s public key, expiration check, audience and scope claim inspection. The system did not query current group membership, current Conditional Access policy state, current device compliance posture, or current Identity Protection risk score at the time of the request. A token issued before a user was offboarded remained valid until expiration. A token issued before a device fell out of compliance remained valid until expiration. A token issued before a Conditional Access policy was updated remained valid until expiration. The reference to a resolved authentication event substituted for validation of current state. Pass-the-token and PRT extraction attacks — operationalized via tooling such as AADInternals and ROADtools — exploit this gap directly: the token is the trust, and the system has no mechanism to distinguish a replayed token from a legitimate one without additional controls in place.

access not constrained at runtime Evaluation (CAE), deployed by Microsoft beginning in 2021, provides near-real-time revocation signaling for a defined set of triggers: account disable, password reset, high-risk sign-in detection from Identity Protection, and explicit token revocation. It does not cover all revocation events. It does not cover all resource providers — coverage depends on the resource implementing the CAE protocol. For resources outside CAE scope, for revocation events CAE does not surface, and for environments without enforced sign-in frequency policies, the access decision remains a function of token age. Conditional Access sign-in frequency policies can enforce re-authentication intervals but operate at session level, not at each resource access event. These are supplementary controls layered on top of an unchanged core validation loop.

The system is operating as designed. The design assumes policy, entitlement, and device state remain stable across a token’s lifetime. That assumption held in environments where authentication events were bounded by physical sessions and on-premises network boundaries. It did not hold as session lifetimes extended across distributed infrastructure, remote access patterns, and automated workloads. The token expiration clock defines the access window. Entitlement changes that occur within that window are not reflected until the token expires and a new one is issued — or until an administrator intervenes. The system does not revoke access. It allows access to age out.