Introducing Cloudflare Access for Workers. Attach an Access policy directly to a Worker and it applies everywhere that Worker runs — routes, custom domains, workers.dev, and previews — automatically.
Setting a single policy can instantly lock 100% of your account's edge deployments behind company SSO—including unconfigured custom domains and temporary preview URLs—before your app code even receives a request. 👇
With AI tools accelerating app creation, employees are building and deploying internal tools faster than ever. But previously, Cloudflare Access enforced authentication strictly at the hostname level. If a developer added a new custom domain or generated a preview URL without manually updating Access policies first, that internal app was exposed publicly to the internet.
Cloudflare fixed this by attaching Access policies directly to Workers and accounts rather than hostnames. Now, authentication runs at the edge before any request reaches application code, making preview and production deployments private by default.
Making this work required re-architecting Cloudflare's edge pipeline. Traditionally, Access ran before all Workers logic because it only checked hostnames. To enforce policy on specific Workers, Cloudflare had to split Workers routing from Workers execution, moving the routing phase ahead of Access so the proxy knows the target Worker before evaluating user permissions.
This pipeline change was enabled by FL2, Cloudflare's Rust-based modular proxy that replaced their older NGINX and Lua setup. Because FL2 organizes logic into strict phases with statically declared inputs and outputs, the compiler surfaced broken interactions and allowed Cloudflare to safely shift routing ahead of Access.
Once Access authenticates a request, it attaches the user's identity metadata directly to the Worker's context object. Instead of writing code to parse and verify JWT signatures, developers simply call `ctx.access.getIdentity()` to read the user's email, name, and groups. Developers can also simulate these authenticated user objects locally in `wrangler.jsonc` while running `wrangler dev`.
Account admins can now lock down all current and future Workers with one global setting while retaining per-Worker bypasses for intentional public apps. Platform teams using Workers for Platforms can also secure thousands of user-deployed sites at once by placing a single Access policy on their entry-point dispatch Worker.
NayaRead shows a summary and links to the original article. The full article is hosted on blog.cloudflare.com.