Debugging non-identity Access denials
Cloudflare Access enforces Zero Trust policies based on more than just who a user is. Rules can also evaluate how a connection is made — location, IP address, network context, presence of a Secure Web Gateway, device properties, and other signals. When a request fails one of these non-identity checks, it is blocked immediately to prevent a malicious actor from discovering which identity providers an organization uses. Historically, however, those denials were not logged, to avoid flooding a customer's Access request logs with what could be thousands of failed attempts from a bad actor or misconfigured API.
That made troubleshooting difficult during initial setup, when a system administrator might legitimately need to see individual block events for non-identity checks. Cloudflare has now released tooling to address that gap: a GraphQL API for looking up specific blocked requests, plus an improved end-user block page that surfaces additional session details.
Two new ways to investigate denials
Cloudflare had previously introduced block-reason tooling for denials tied to identity or device posture — for example, a user's email not being in an Access policy, or a device failing a posture check. That covered some troubleshooting cases, but not requests blocked by adaptive, contextual rules.
The new GraphQL API lets administrators query for a specific blocked request by RayID, User, or Application. The response returns the full set of properties associated with that request, which makes it much easier to determine why it was denied. These logs can be queried manually with a GraphQL client or periodically ingested into a separate log storage database.
In parallel, the user-facing block page now includes more information about the user's session, so end users and admins can diagnose legitimate denials faster without digging into an API.
Handling the scale
Logging blocked requests for every Access customer presented a significant scale challenge: a single application on one account can see millions of blocked requests in a day, and the figures multiply across all protected applications and all customers. Cloudflare addressed this by routing the data through its existing analytics pipeline, which was already built to handle traffic volumes far beyond Access's needs. The pipeline automatically begins sampling logs if an individual account starts generating too many requests. For the majority of customers, every non-identity block log will be captured; accounts with very large traffic volumes will still retain a significant portion for diagnostic purposes.
Questions to answer
Non-identity checks can cover regulatory constraints — blocking users in certain countries from sensitive data — or network context requirements for enterprise access. They also apply to automated services, such as a chatbot using a service token to reach an internal ticketing system. Since these checks do not require authentication, a bad actor can retry repeatedly, which previously would have created a flood of log entries during any investigation. Keeping the low-level denials out of the standard request logs avoids overwhelming an admin's ability to review legitimate Access requests, while the new lookup API gives them a targeted way to inspect specific blocks when needed.
Availability
The new features are enabled for all accounts across all pricing tiers. Cloudflare had a zero-product-page link to 50 free seats for new Zero Trust deployments.
