What Changed: Access Moves from Hostnames to Workers
AI tools have made it easier than ever for employees across every team to build and deploy applications. But that speed comes with a risk: anyone can deploy to the public Internet and accidentally expose internal work or company data. On August 14, 2026, Cloudflare announced new capabilities that make it simple to keep Workers-hosted applications private. You can now apply Cloudflare Access directly to a Worker or to every Worker in your account, so your applications sit behind your company login by default—without relying on each developer to remember to set it up.
Previously, Access was configured at the hostname level. You had to set up policies on each domain where your Worker was reachable. If you added a new custom domain, you had to update the Access policy first, or that hostname would be publicly accessible without authentication. Now the policy is attached to the Worker itself, so any domain or URL associated with that Worker is automatically protected. You can choose to protect just preview URLs or all hostnames.
If you set it to previews only, every preview URL created for that application—whether a workers.dev preview URL or a custom preview domain—will require authentication whenever you deploy a new version. If you set it to all hostnames, every domain associated with that Worker is protected: custom domains, routes, workers.dev subdomains, and preview URLs.
How It Works: Authentication Before Code, Identity in Your Code
When Access is enabled on a Worker, Cloudflare enforces authentication before any request reaches your application code. It doesn’t matter how the request arrives—via custom domain, route, workers.dev subdomain, or preview URL. If Access is on, the user must authenticate first.
Access gives you control over how users authenticate. You can connect your existing identity provider so employees sign in with credentials they already use, or restrict access to specific email addresses, email domains, or groups. For agents, you can grant access through service tokens.
Once Access is protecting your Worker, you can get information about who is making each request—their email, name, and groups—directly in your code. This works through your Worker’s context object (ctx). Every request carries a ctx with metadata, and when Access is enabled, the authenticated user’s identity is attached as ctx.access. Calling ctx.access.getIdentity() returns the user’s email, name, and more.
Before, this meant validating a JWT yourself: parsing the token, verifying the signature, and extracting claims. Now, every authenticated request includes ctx.access. Here’s 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: Account-Wide Defaults and Internal Platforms
If you have developers across your organization deploying Workers, you don’t want to rely on each one to remember to enable Access. You want the default to be private. You can set an Access policy once at the account level, and every Worker in your account—current and future—is private from the moment it’s created.
You choose what the policy covers: only preview URL traffic, all production traffic, or both. Preview-only is useful if your production Workers are intentionally public, but you never want an in-progress deployment exposed. Need a Worker to be public? You can bypass the account-wide policy on that one Worker.
If you don’t need an account-wide default and just want to lock down one specific Worker, you can apply Access to that Worker directly. The new Access tab in the Worker view shows exactly which policies apply. If you have multiple, the most specific one takes priority: hostname policies first, then Worker policies, then account policies.
For internal platforms where employees prototype and deploy applications, you need every application to be private without configuring access controls on each one. Workers for Platforms lets you deploy Workers at scale. Every Worker lives inside a namespace, and all traffic goes through a single entry point: the dispatch Worker. Set an Access policy on your dispatch Worker, and every Worker deployed through it is private by default.
Cloudflare has also open-sourced an example where you can deploy 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. You can deploy it directly from the template repository.
Testing Locally with Simulated Identities
You can test Access-protected Workers locally using wrangler dev. Add an access block to your wrangler.jsonc to simulate an authenticated user:
{
"access": {
"dev": {
"aud": "my-app",
"identity": { "email": "admin@company.com" }
}
}
}Your Worker picks it up through ctx.access.getIdentity(), returning an identity object shaped like what you’d get in production. Swap the email in your config to test as a different user. This means you can verify that the right content shows up for the right user without having to deploy and sign in through Access every time you make a change.
Limitations and Trade-offs
While this feature simplifies security, there are some trade-offs to keep in mind. The account-level policy applies to all Workers by default, which might be too restrictive if you have Workers that need to be public. You can bypass it per Worker, but that adds a manual step. Also, the policy priority (hostname > Worker > account) means you need to be careful when mixing policies to avoid unexpected exposure.
Under the hood, this feature relies on FL2, Cloudflare’s new Rust-based modular proxy. Access traditionally ran before all Workers logic in the request pipeline. To target individual Workers instead of hostnames, Access needs to know which Worker a request is destined for. This required splitting Workers routing from execution and moving routing logic before Access. In the old FL1 system (based on NGINX and Lua), this change would have been complex and risky. FL2’s strict module system separates logic into well-defined phases that statically declare inputs and outputs, allowing the compiler to surface broken interactions and enabling a confident gradual rollout.
Takeaway: Make Private the Default
For product builders, this means internal tools can ship faster while shifting the security burden from individual developers to the platform level. Default-private policies plus direct identity access reduce setup friction and make auditing and personalization easier. You can try it today in the Cloudflare dashboard or read the Cloudflare Access for Workers documentation to get started. The key takeaway: with a few clicks, you can ensure every Worker in your account is behind your company login by default, so you can focus on building without worrying about accidental exposure.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.