Access policies that can call out to any API
Zero Trust application security hinges on denying every request unless it meets a precise set of policy conditions. Most Zero Trust products let you build those conditions from variables like user identity, device state, and location. Cloudflare has now removed the ceiling on that model: Access policies can evaluate an external API during the authentication flow, so an organization can enforce literally any check it can express in code.
The new External Evaluation rule option lets an Access policy call an arbitrary API endpoint and use the response to allow or deny a user. This means signals that Cloudflare does not natively understand — or that are specific to one company's workflow — can still gate access without waiting for a product feature or writing a custom middleware layer.
Closing the gap between custom signals and policy decisions
Access already supports a range of checks, including location and device posture. But for many applications, the deciding factor is something else entirely: a certificate registry, an endpoint protection tool, an industry-specific database. The team at Cloudflare ran into this internally. They needed to verify that a user's mTLS certificate matched a corporate registry before granting access to certain applications.
Their initial plan was to run a Worker after Access had already evaluated the request, with that Worker performing the certificate check. That approach works, but it means building and maintaining custom software. With External Evaluation, the check happens directly inside the Access policy: an API call goes out to a Worker holding the mapping between devices and mTLS certificates, the Worker applies its own logic, and it returns a simple pass or fail to Access.
How the evaluation flow works
Cloudflare Access sits in front of a web application as a reverse proxy. An unauthenticated user sees a login screen and must satisfy whatever criteria the policy defines — a typical policy might require an @example.com email domain, a hardware-backed authentication token, and a US-based login. Once those conditions are met, the user gets a session cookie.
Adding an External Evaluation rule requires you to supply two things: the API endpoint Access should call, and a key used to verify that any response actually came from your trusted source.
After the user authenticates through your identity provider, Access collects all available information about the user, device, and location and passes it to your external API. Your API evaluates that data and returns either a pass or fail response. Access admits or blocks the user based on that answer.
A minimal implementation looks like this:
/**
* Where your business logic should go
* @param {*} claims
* @returns boolean
*/
async function externalEvaluation(claims) {
return claims.identity.email === '[email protected]'
}Here the claims object carries the full set of user, device, and network context. The externalEvaluation function is where you can insert any business logic you need. Cloudflare has published an open-source repository with example code that consumes the claims and verifies the signing keys from Access.
What this unlocks
Because the check is just an API call, the boundary of what can influence an Access decision is your own code. Practical applications include:
- Building middleware that checks an endpoint protection tool's API for integrations Cloudflare does not offer natively.
- Matching request IP addresses against external threat intelligence feeds.
- Querying industry-specific user registries before granting entry.
Cloudflare notes that policy extensibility will go further. The roadmap includes supporting programmatic decisions about how a user should be treated before reaching an application — not just a binary allow or deny.
The External Evaluation rule is available now in the Cloudflare Zero Trust dashboard. A setup guide is published at the Cloudflare developers documentation.
