Cloudflare Access can now protect a Worker directly

Cybersecurity ,
Cloudflare Access authenticating requests before Worker execution.

Cloudflare Access can now protect the Worker itself, not just a hostname in front of it. Identity is checked before the request reaches Worker code, no matter which address the request used.

A Worker is reachable through a custom domain, a route, its workers.dev address, and preview URLs. Before August 14, 2026, protecting one hostname did not protect the others. A new domain without a matching Access application could open a public path to an internal service.

What a policy can cover

  1. Previews for one Worker.
  2. Production and preview traffic for one Worker.
  3. Previews for every Worker in an account.
  4. Production and preview traffic for every current and future Worker in an account.

The account-wide option makes private the default, which helps when many teams or AI coding tools deploy Workers. A deliberately public Worker gets an explicit bypass. Hostname policies remain the right tool for one route or one part of a public application.

Policy precedence matters

Cloudflare evaluates the applicable Access configurations from the most specific to the broadest:

  1. Hostname or path policy.
  2. Worker-level policy.
  3. Account-level Worker policy.

An account-wide rule works as a safety net, not as the final word. A more specific rule can change the result for one hostname. Record every intentional bypass, or a temporary test quietly becomes a permanent hole.

Turn it on

The shortest dashboard path:

  1. Enable Cloudflare Zero Trust for the account.
  2. Open Workers & Pages and select the Worker.
  3. Open the Access tab.
  4. Select Protect this Worker behind Access.
  5. Choose Previews only or All traffic.
  6. Pick who may sign in and apply the policy.

The first policy can allow account members or a verified email domain. Identity providers, groups, and service tokens stay in Zero Trust.

Identity in Worker code

An authenticated request exposes the user identity on ctx.access. The Worker reads the email, name, and groups through ctx.access.getIdentity() without parsing the Access JWT.

Access still only authenticates the caller. Application code decides what that person may read. Wrangler can also simulate a test user during local development.

Limits to remember

  • WebSockets receive 403 under Worker-level policies. Real-time Durable Object applications should keep a hostname-based Access application.
  • ctx.access does not cross service bindings or RPC. Pass downstream only the authorization data the next Worker needs.
  • Preview URLs are not generated for Workers implementing Durable Objects. Access cannot protect a preview that the platform does not create.

The key gain is a safer unit of policy. Identity enforcement now rides the workload, closing the gap between deploying a Worker and remembering every address it answers.

Sources