intellimetrics Learning
Zero Trust Implementation Module 4 · Applications and Data

Continuous Authorization

Last reviewed

Advanced

What you'll learn

~15 min
  • Close the token-lifetime gap: revocation events that reach sessions in near-real-time
  • Trace a compromise through the session timeline and find where each control fires
  • Place the emerging standards honestly: continuous evaluation now, shared signals as direction

Tenet 3’s uncomfortable fine print

Access is per-session, said Lesson 1.1 — but what is a session, mechanically? A token, minted at sign-in after the PDP said yes, honored by resource servers until it expires. There’s the gap: the decision was per-session; the token makes it per-hour. Disable a compromised account at 2:05 and its access token happily works until expiry — the attacker’s grace period, sponsored by your token lifetime.

The naive fix — shrink lifetimes toward zero — trades the gap for a re-authentication storm. The real fix is continuous access evaluation (CAE): resource providers subscribe to critical identity events (account disabled, password changed, refresh revoked, risk elevated, network location anomalous), and when one fires, the session is re-evaluated now — the token challenged mid-lifetime instead of trusted to its printed expiry. Long-lived tokens for the quiet case, near-instant revocation for the loud one.

The timeline exercise

The artifact for this lesson is a table you’ll build for your own estate — walk one compromise through the clock and mark where each control fires:

Trace this scenario minute by minute and name the control that acts at each
step, with its actual latency in OUR tenant configuration:


14:00  attacker phishes a session via AiTM proxy (token replayed off-device)
14:03  SOC disables the account + revokes sessions
14:0?  ...when does each resource actually stop serving the token?


Columns: control (CAE event / token-protection binding / device-compliance
flip from 3.1 / conditional access re-eval), fires-at, latency source,
and the resources NOT covered (which apps ignore revocation events
entirely and ride the token to expiry - list them by name).

That last column is the audit that matters: CAE coverage is per-application. The big productivity suites participate; the long tail of SaaS and everything speaking plain OAuth to your APIs typically does not — those apps’ sessions survive on token lifetime alone, which is where the sender-constrained token work from Lesson 2.4 re-enters: a token bound to the requesting client’s key fails when replayed elsewhere, even if no revocation ever reaches the resource. Binding and evaluation are complementary: evaluation kills sessions you know are bad; binding pre-kills the replay you never detect. (The token-protection policies from Lesson 3.1 are the same idea enforced at the device layer.)

The standards weather report, honestly

Where this is going, with 2026 adoption stated plainly so you don’t over-build on futures:

  • CAE: shipped, mainstream within the major identity platforms’ own ecosystems. Table stakes — enable it, then measure the coverage map above rather than assuming it.
  • Shared Signals / CAEP (the open, cross-vendor version — providers transmitting risk events to each other): final specs, real adopters among major IdPs and device vendors, but transmitter/receiver coverage is a patchwork; your tenant’s biggest platform may consume signals without emitting them publicly. Architect so you can join it (event-driven session policy, not batch), don’t wait on it.
  • Sender-constrained tokens (DPoP-style / mTLS-bound): standardized, mandated in the newest agent-protocol profiles, near-zero deployment among mainstream SaaS issuers as of mid-2026. Direction, not destination — the honest posture from Lesson 2.4 stands.
💡The re-evaluation triggers you control today

While the standards mature, three levers are already yours: wire the SOC’s containment runbook to revoke refresh tokens (not just disable accounts — disabling alone doesn’t recall every token type); set session frequency ceilings per app tier in conditional access (Restricted-label apps re-evaluate hourly, per Lesson 4.2’s table); and alert on token-anomaly signals (impossible travel mid-session, user-agent flips) as detection where enforcement can’t yet reach — Lesson 5.2 turns those into detections-as-code.

KNOWLEDGE CHECK

Post-incident review: the SOC disabled a compromised account at 14:03, but exfiltration from a third-party SaaS app continued until 14:52. The identity platform shows the disable event fired and CAE-capable apps cut the session within a minute. What happened, and what's the durable fix?

Key takeaway

Per-session must mean per-moment: continuous evaluation recalls sessions when the world changes, token binding pre-empts the replays you never see, and the coverage map — which apps actually honor revocation — is the audit that separates architecture from assumption. Applications and data are governed; Module 5 makes all of it provable.

Search lessons