How Identity Systems Fail When Trust Is Assumed, Not Verified

Azure Active Directory issues bearer tokens with embedded claims: group membership, role assignments, conditional access evaluation state. At each service boundary, the receiving component validates the cryptographic signature and checks the expiration timestamp. It does not re-query group membership against the directory. It does not re-evaluate conditional access policy against current device or network state. It reads the claims, verifies the signature, checks the clock. That is the full evaluation.

---

The model was built on a specific assumption: that the conditions at token issuance would remain valid through the token’s lifetime. Access was granted at issuance. The downstream service trusted that grant. The trust model assumed the organizational state — roles assigned, groups populated, policies configured — was stable enough that a short-lived token represented current entitlement. Transferability of trust across service boundaries was the design goal. Persistence of that trust through the token window was the operational premise.

---

The operational envelope changed. Service accounts, automation workloads, and inter-service authentication chains pushed effective token lifetimes from minutes into hours. Access tokens with one-hour expiration windows became the floor, not the ceiling. Refresh token chains extended sessions into days. Organizational policy state — role assignments, group memberships, conditional access configurations — changed on timescales shorter than token expiration. A user’s group membership was revoked. The token reflecting that membership was still valid. The assumption was not re-evaluated. The system did not attempt to re-evaluate it. It inherited the prior state and continued operating on it.

---

Bearer tokens in the Azure AD model are self-contained authorization artifacts. A resource provider receiving a token calls no policy endpoint at evaluation time. It reads the embedded claims, verifies the signature against the tenant’s published signing keys, checks the expiration timestamp, and makes an access decision. This is the full evaluation path. If group membership was revoked after issuance, the token does not reflect that revocation. The resource provider has no mechanism to detect it — not because of a bug, but because querying live state was not part of the protocol.

access not constrained at runtime Evaluation (CAE) was introduced to narrow this gap: specific events — password change, account disable, explicit token revocation — can trigger near-real-time session termination for supported clients. CAE is not universal. It applies to specific clients, specific resource providers, specific event types. It is not enforced at the protocol level. It does not apply retroactively to tokens already in circulation. The gap between a policy change and enforcement remains the token’s remaining lifetime, bounded only by what CAE covers — which is not everything.

---

The Storm-0558 intrusion, disclosed in 2023, demonstrated what the trust model’s structural property looks like under adversarial conditions. Forged tokens bearing valid cryptographic signatures — generated using an acquired MSA signing key — were presented to Exchange Online and accepted. Service boundaries performed their evaluation: signature valid, expiration valid, claims present. No step in the evaluation chain queried whether the signing authority was compromised. No step re-validated the claimed identity against current directory state. The trust model’s design property — validate the artifact, not the current state — held exactly as designed. The access chain was not broken by the architecture because the architecture had no mechanism to break it.

---

Azure’s identity model resolves authorization once. Token issuance is the decision point. Every subsequent access evaluation is a reference check against the state that existed at issuance. The system does not detect that state has changed. It does not attempt to. CAE narrows the window for specific clients handling specific event types. It does not close the gap at the architectural level. What was built was a system that trusts its own history. The assumption embedded in that design was that history and present would remain coupled. That assumption is load-bearing. It was not re-examined as the operational envelope expanded.