infochanged

Workers, Access - You can now enable Access on a Worker or all Workers at once

Announced: 2026-08-14
Tags: Workers, Access
Severity: info, set by reef/rss-rule-v1
Source: https://developers.cloudflare.com/changelog/post/2026-08-14-workers-access/

You now have two new ways to protect your <a href="https://developers.cloudflare.com/workers/">Workers</a> with <a href="https://developers.cloudflare.com/workers/configuration/cloudflare-access/">Cloudflare Access</a>. Protect an application across all its domains at once Until now, if a Worker was reachable on a route, a Custom Domain, and a <code>workers.dev</code> URL, you had to manually add each one to an Access application and keep the list in sync whenever routes or domains changed. Now, Access attaches the policy to the Worker itself, so every associated domain and preview URL stays protected even when its routes or domains change. <img src="https://developers.cloudflare.com/cdn-cgi/image/onerror=redirect,width=1476,height=689,format=webp/_astro/protect-one-worker.BSpeeOry.png" alt="Access setting for protecting a single Worker" loading="lazy" decoding="async" width="1476" height="689"> Protect all new and existing Workers by default Make all Workers private by default, so every existing and newly created Worker requires sign-in before anyone can reach it. <img src="https://developers.cloudflare.com/cdn-cgi/image/onerror=redirect,width=2436,height=1432,format=webp/_astro/protect-all-workers._AWy-S-E.png" alt="Account-wide Access setting that protects all Workers" loading="lazy" decoding="async" width="2436" height="1432"> If a specific Worker should remain publicly accessible, add a Worker-level bypass to exempt it. <img src="https://developers.cloudflare.com/cdn-cgi/image/onerror=redirect,width=1228,height=756,format=webp/_astro/make-worker-public.D3yjPjtf.png" alt="Make a Worker public when all Workers are protected" loading="lazy" decoding="async" width="1228" height="756"> Whether you protect a single application or all Workers at once, you can choose whether to protect preview deployments only or both previews and production, and control who can sign in by Cloudflare account membership, email address, or email domain. For more advanced policy options, edit the policy in <a href="https://dash.cloudflare.com/?to=/:account/one/access/apps" target="_blank" rel="noopener">Zero Trust ↗︎</a>. <img src="https://developers.cloudflare.com/cdn-cgi/image/onerror=redirect,width=1276,height=1220,format=webp/_astro/choose-who-can-sign-in.DKf3kWAK.png" alt="Access policy configuration for controlling who can sign in" loading="lazy" decoding="async" width="1276" height="1220"> View all of your Worker Access policies You can view and manage all of your Access policies in the Access tab of the Workers & Pages section in the dashboard. <img src="https://developers.cloudflare.com/cdn-cgi/image/onerror=redirect,width=1646,height=1366,format=webp/_astro/access-policies.DN7yCwHX.png" alt="Access tab showing all configured Access policies" loading="lazy" decoding="async" width="1646" height="1366"> See who is accessing your Worker When Access is enabled on your Worker, every authenticated request includes <code>ctx.access</code>. Call <a href="https://developers.cloudflare.com/workers/runtime-apis/context/#access"><code>ctx.access.getIdentity()</code></a> to get the user's email, name, and groups — no manual JWT validation required. <figure class="nb-code-figure" data-nb-lang="js"><pre class="astro-code astro-code-themes github-light github-dark nb-shiki-c6xiwz" tabindex="0" data-language="js" data-nb-lang="js"><code>export default { async fetch(request, env, ctx) { if (!ctx.access) { return new Response("Access did not run", { status: 401 }); } const identity = await ctx.access.getIdentity(); return Response.json({ aud: ctx.access.aud, email: identity?.email }); }, };</code></pre></figure> Test Access locally You can now test Cloudflare Access locally with <code>wrangler dev</code>. Add a <code>dev</code> block to your <code>wrangler.jsonc</code>: <figure class="nb-code-figure" data-nb-lang="json"><pre class="astro-code astro-code-themes github-light github-dark nb-shiki-c6xiwz" tabindex="0" data-language="json" data-nb-lang="json"><code>{ "access": { "dev": { "aud": "my-app", "identity": { "email": "admin@example.com" } } } }</code></pre></figure> Your Worker will receive this identity through <code>ctx.access</code> and <code>ctx.access.getIdentity()</code>, letting you test authenticated and unauthenticated flows without deploying. Remove the <code>dev</code> block to simulate unauthenticated requests. API and programmatic access You can also set up these policies through the <a href="https://developers.cloudflare.com/workers/configuration/cloudflare-access/">Workers API</a> instead of the dashboard.

The text above is the source's. reef added the severity, the dates it could read from the text, and the endpoints and scopes named in code.