Summary: Cloudflare announced on August 14, 2026 that Cloudflare Access can attach directly to a Worker or every Worker in an account, covering custom domains, routes, workers.dev subdomains, and preview URLs. Authentication now happens before application code runs, and authenticated identity is available through ctx.access. Account-level defaults make private-by-default deployment practical, with per-Worker bypasses where public access is intentional.
What Changed: Access Now Attaches to Workers, Not Hostnames
Employees on every team can now build and ship applications with AI tools, and the pace is faster than it has ever been. That pace carries a hazard: a deploy to the public Internet can expose internal work or company data before anyone notices. Cloudflare’s announcement on August 14, 2026 introduces capabilities that keep Workers-hosted applications private with very little effort. Cloudflare Access can be applied directly to one Worker, or to every Worker in your account, which places your applications behind the company login by default instead of depending on each developer to remember the setup.
Access used to be configured at the hostname level, which meant creating a policy on each domain where your Worker answered. Add a custom domain afterwards and fail to update Access first, and that hostname would serve anyone who asked, with no authentication. The policy now attaches to the Worker itself, so every domain or URL associated with it is covered automatically. The scope is yours to choose: preview URLs alone, or all hostnames.
Choose previews only and every preview URL the application creates—a workers.dev preview URL or a custom preview domain—requires authentication each time you deploy a new version. Choose all hostnames and the protection reaches everything tied to that Worker: custom domains, routes, workers.dev subdomains, and preview URLs.
How It Works: Code Never Runs Before Authentication
Switch Access on for a Worker and Cloudflare demands authentication before a request ever reaches your application code. The path a request takes makes no difference—custom domain, route, workers.dev subdomain, or preview URL. With Access on, the user authenticates first.
You decide how users authenticate. Connect the identity provider you already have so employees sign in with credentials they know, or limit entry to particular email addresses, email domains, or groups. Agents can be let in through service tokens.
Once Access stands in front of your Worker, details about whoever is making each request—email, name, groups—are available directly in your code. The mechanism is your Worker’s context object (ctx). Every request carries a ctx holding metadata, and with Access enabled the authenticated user’s identity is attached as ctx.access. A call to ctx.access.getIdentity() hands back the user’s email, name, and more.
Doing this by hand used to mean validating a JWT yourself: parsing the token, verifying the signature, extracting claims. Every authenticated request now carries ctx.access. This is all you need to get the user’s identity:
export default {
async fetch(request, env, ctx) {
if (!ctx.access) {
return new Response("Access required", { status: 403 });
}
const identity = await ctx.access.getIdentity();
const email = identity?.email ?? "unknown";
return new Response(`Hello, ${email}`);
}
};Practical Use Cases: Defaults Across the Account, Platforms for Internal Apps
When developers across your organization are deploying Workers, counting on each one to enable Access is not a plan. You want private to be the default. Set the Access policy once at the account level, and every Worker in the account—existing and future alike—is private the moment it is created.
What the policy covers is up to you: preview URL traffic only, all production traffic, or both. Preview-only fits the case where production Workers are public on purpose but an in-progress deployment must never be exposed. Need a Worker to be public? Bypass the account-wide policy on that single Worker.
If an account-wide default is more than you need and the goal is to lock down one specific Worker, apply Access to that Worker directly. The new Access tab in the Worker view shows exactly which policies apply. With several in play, the most specific one wins: hostname policies first, then Worker policies, then account policies.
Internal platforms where employees prototype and deploy applications need every application private without access controls configured one by one. Workers for Platforms is built for deploying Workers at scale. Each Worker lives inside a namespace, and all traffic enters through a single point: the dispatch Worker. Put an Access policy on your dispatch Worker and everything deployed through it is private by default.
Cloudflare has also open-sourced an example for standing up your own internal drag-and-drop deployment platform. Configure access on the dispatcher worker once, and every site deployed through it is private by default. It can be deployed straight from the template repository.
Local Testing with a Simulated Identity
Access-protected Workers can be tested locally with wrangler dev. Put an access block in wrangler.jsonc to stand in for an authenticated user:
{
"access": {
"dev": {
"aud": "my-app",
"identity": { "email": "admin@company.com" }
}
}
}Your Worker reads the block through ctx.access.getIdentity(), which returns an identity object shaped the same way as it would be in production. Change the email in your config to test as someone else. So you can confirm that the right content reaches the right user without deploying and signing in through Access after every change.
Limits and Trade-offs
Security gets simpler with this feature, but there are trade-offs worth naming. The account-level policy covers all Workers by default, which can be too restrictive when some Workers need to be public. A per-Worker bypass exists, though it costs a manual step. The policy priority (hostname > Worker > account) also means mixing policies calls for care, since the wrong combination can produce unexpected exposure.
Under the hood the feature rests on FL2, Cloudflare’s new Rust-based modular proxy. Access traditionally ran ahead of all Workers logic in the request pipeline. Targeting individual Workers rather than hostnames requires Access to know which Worker a request is destined for. That in turn required separating Workers routing from execution and moving the routing logic ahead of Access. In the old FL1 system (based on NGINX and Lua), such a change would have been complex and risky. FL2’s strict module system divides logic into well-defined phases that statically declare inputs and outputs, which lets the compiler surface broken interactions and makes a gradual rollout something you can approach with confidence.
Takeaway: Private by Default
For product builders, the upshot is that internal tools ship faster while the security burden shifts off individual developers and onto the platform. Default-private policies plus direct identity access cut setup friction and make auditing and personalization easier. Try it today in the Cloudflare dashboard, or read the Cloudflare Access for Workers documentation to get started. The key takeaway: a few clicks put every Worker in your account behind the company login by default, leaving you free to focus on building without worrying about accidental exposure.