CCloud Releases
Home
Following

Cloud Releases

Service catalogues and updates come from each provider's public product listing and announcements.

Explore

  • Home
  • Latest updates
  • Following

About

  • About
  • Contact
  • Privacy Policy
  • Terms of Use

Providers

  • Amazon Web Services
  • Microsoft Azure
  • Google Cloud
  • Cloudflare

Not affiliated with any cloud provider. Product names and logos belong to their owners.

  1. Providers
  2. ›Cloudflare
  3. ›Access
  4. ›Update

Feature•Aug 14, 2026

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

AccessCloudflare · Cloudflare One

You now have two new ways to protect your Workers with Cloudflare Access.

Protect an application across all its domains at once

Until now, if a Worker was reachable on a route, a Custom Domain, and a workers.dev 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.

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.

If a specific Worker should remain publicly accessible, add a Worker-level bypass to exempt it.

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 Zero Trust.

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.

See who is accessing your Worker

When Access is enabled on your Worker, every authenticated request includes ctx.access. Call ctx.access.getIdentity() to get the user's email, name, and groups — no manual JWT validation required.

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 }); }, };

Test Access locally

You can now test Cloudflare Access locally with wrangler dev. Add a dev block to your wrangler.jsonc:

{ "access": { "dev": { "aud": "my-app", "identity": { "email": "admin@example.com" } } } }

Your Worker will receive this identity through ctx.access and ctx.access.getIdentity(), letting you test authenticated and unauthenticated flows without deploying. Remove the dev block to simulate unauthenticated requests.

API and programmatic access

You can also set up these policies through the Workers API instead of the dashboard.

Read the original announcement↗

More from Access

All Access updates →
  1. New strict service token authentication setting for Access

    The strict service token authentication setting applies consistent behavior to requests made with service tokens. When the setting is on for a Zero Trust organization, Access handles requests with service token headers as follows:

    Access•Feature•Oct 2, 2026
  2. Simplified permissions for tagging targets with Access for Infrastructure

    You can now tag targets using only the Zero Trust Write API token permission. Previously, tagging targets through the API required both Zero Trust Write and Tag Write permissions on the API token.

    Access•Feature•Oct 1, 2026
  3. MCP server portals are now generally available

    MCP server portals are now generally available to all Cloudflare customers. A portal gives users one endpoint for approved Model Context Protocol (MCP) servers. Cloudflare Access logs tool, prompt, and resource activity.

    Access•Generally available•Sep 24, 2026
  4. Private MCP server support for MCP server portals

    MCP server portals can now connect to MCP servers available only on your private network. The portal uses Cloudflare Gateway to reach private hostnames and IP addresses without exposing the MCP server to the public Internet.

    Access•Feature•Sep 22, 2026
  5. Automatically manage inactive Access service tokens

    Cloudflare Access administrators can now automatically disable or delete inactive service tokens. Administrators can set an inactivity period from 30 to 365 days and choose what Access does when a token reaches that limit.

    Access•Feature•Sep 22, 2026