Why granular Zero Trust policies need better session visibility

Zero Trust security relies on finely tuned controls that decide who gets access to which applications, under what conditions. An administrator might combine user identity, device posture, network context, and more into a single access decision. That precision is valuable, but it creates a troubleshooting problem: when a user can't reach a resource, the administrator must reconstruct what the policy actually saw at decision time. That often means asking the end user to export cookies or capture HAR files, then manually correlating data from multiple sources.

Cloudflare One now offers a way around that friction. Administrators can view all active user sessions and the identity data those sessions carried when Cloudflare Zero Trust policies evaluated them. Instead of logging into a user's browser or digging through raw logs, the relevant session details are available in one place.

How authentication and authorization work in practice

Every Zero Trust access decision hinges on two steps. Authentication verifies that the user, device, or system is who it claims to be — typically via credentials, certificates, or biometrics. Authorization then applies policy to decide what that verified entity may do.

For web applications, HTTP cookies handle most of this state. The flow looks like this:

  • The user submits credentials and the server verifies them against its identity provider.
  • The server creates an authenticated session, usually as a cookie or JSON Web Token (JWT).
  • The browser stores that session and attaches it to every subsequent request.
  • The server checks the session against the user's permissions to authorize or deny each request.

Modern applications increasingly store session state using JWTs. These tokens carry claims about the user, issuer, issuance time, and expiration, and are signed so they can be validated without a central session store.

The problem with debugging JWT-based sessions

JWTs are stateless by design, which scales well but makes them awkward when a session fails. Debugging typically requires the exact token that caused the problem:

  • Token specificity — each JWT is tied to a particular user and session, so generic logs don't reveal what policy evaluated.
  • No server-side record — stateless tokens mean the server isn't persisting sessions, unless the application was explicitly built to log them.
  • Transient failures — an expired token or a context change can be momentary, with no trace left behind once the request completes.
  • Privacy risk — JWTs contain sensitive identity claims, and sharing them via email or chat exposes credentials to interception.

These constraints force administrators to hunt for the specific token through the user's browser or ask the user to share captured traffic. That's slow, invasive, and a potential security liability.

Session audit data in Cloudflare One

The new capability gives administrators visibility into what Cloudflare Zero Trust actually saw when it made its decision. For each active Access session, they can inspect the full identity context that was evaluated — including IdP claims, device posture data, network context, and other attributes used by policy. On the Gateway side, registry identity is also visible for the same user.

Recording session data does not slow down the authentication path. When a user authenticates against Access, Cloudflare stores the associated identity as a key-value pair in Workers KV. Because this write happens within the authentication event itself, there is no extra external dependency or added latency on the user-facing flow.

The feature is enabled for all Cloudflare Zero Trust customers across every plan. For organizations still building out their Zero Trust deployment, the Cloudflare dashboard offers a free tier for up to 50 users to get started.