Cloudflare pins Access policies to Workers themselves

Cloudflare has rolled out a new set of controls that let you attach Cloudflare Access directly to Workers — either individually or account-wide — so that internal applications are protected by company credentials by default, without relying on every developer to configure their own auth.

The feature covers several scenarios:

  • Account-level policies that force all preview and production deployments behind your company login by default.
  • Per-Worker policies that enforce authentication on every domain associated with a single application.
  • Inline identity data where authenticated user email, name, and groups are passed directly to your code, no JWT parsing required.
  • Private-by-default internal platforms, backed by an open-source example template.

Enforcement moves to the Worker, not the hostname

When Access is enabled on a Worker, Cloudflare handles authentication before any request reaches your application code — no matter the path the request takes. Custom domains, routes, workers.dev subdomains, and preview URLs are all covered.

Previous setups required configuring Access at the hostname level, meaning each domain attached to a Worker needed its own policy. Adding a new custom domain meant updating the Access policy first, or else that hostname would sit unprotected. Now the policy travels with the Worker itself, so every URL associated with that Worker is automatically gated once the policy is set.

You can scope what gets protected: preview URLs only, or all hostnames. Preview-only coverage is useful for teams that want production Workers public but never want an in-progress deployment exposed. When protecting all hostnames, any custom domain, route, workers.dev subdomain, or preview URL for that Worker is locked down. Authentication itself remains flexible — connect your existing identity provider, restrict access by email address, domain, or group, or allow service tokens for agents.

Setting a private-by-default policy at scale

Any organization with multiple developers deploying Workers can enforce a private default at the account level. Applying an Access policy once at the account level means every Worker — current and future — is protected from the moment it is created.

Account-level policies can be scoped to cover only preview traffic, only production traffic, or both. If a specific Worker must remain public, you can bypass the account-wide policy on that single Worker.

When you need to lock down one application, the Worker view now includes an Access tab showing exactly which policies apply. If multiple policies are present, the priority order is hostname policies first, then Worker policies, then account policies.

Identity data without the token work

Previously, pulling the authenticated user's details out of a request meant validating a JWT yourself — parsing the token, checking the signature, extracting claims. That's no longer necessary when Access protects the Worker. The request context (ctx) now carries the user's identity whenever Access is enabled.

ctx.access.getIdentity()

This call returns the user's email, name, groups, and related metadata, making it possible to personalize responses, enforce permissions, or log activity per user without custom token handling.

Testing the identity flow locally

The same identity mechanism works when developing locally with wrangler dev. Add an access block to your wrangler.jsonc to simulate an authenticated user. Your Worker picks it up via ctx.access.getIdentity(), returning an identity object shaped exactly like the production response. Swap the email in your config to test as a different user — no need to deploy and authenticate through Access on every change.

Security for multi-tenant Worker platforms

For internal platforms where employees quickly spin up prototype applications, keeping every deployment private is essential. Workers for Platforms enables deploying Workers at scale, where each Worker lives in a namespace and all traffic passes through a single dispatch Worker. Applying an Access policy to that dispatch Worker makes every Worker deployed through it private by default.

Cloudflare also published an open-source example: an internal static site platform where every Worker deployed is private, configured by setting access on the dispatcher Worker once.

Built on the FL2 refactor

This capability relied on an architectural shift underneath the hood. Access traditionally ran before all Workers logic in the request pipeline, since it acted as the front gate to applications. To attach Access to individual Workers instead of hostnames, the routing logic — which determines which Worker a given request targets — needed to execute before Access. That meant splitting Workers routing from Workers execution.

Moving logic between phases was a high-risk change in the previous NGINX/Lua-based FL1 system, where product interactions could behave subtly and moving code earlier in the pipeline could break if it depended on shared state. The Rust-based FL2 architecture simplified things: its strict module system organizes logic into defined, consistently ordered phases with statically declared inputs and outputs, letting the compiler surface broken interactions between phases during the refactor.

Access for Workers is available now in the dashboard, with documentation covering configuration details.