ST-2026-207 · Authentication & identity
Cloudflare Access can protect a Worker or all Workers at account scope
Cloudflare added Worker-level and account-wide Access protection on 14 August 2026, allowing one Access policy to follow a Worker across its domains and preview URLs or to make all existing and newly created Workers require sign-in by default.
Previous state
Protecting a Worker across routes, Custom Domains and workers.dev URLs required adding and maintaining those hostnames individually in an Access application, and there was no announced account-wide default for all Workers.
Current state
Access policies can attach directly to a Worker across associated domains and preview URLs, and an account-wide setting can require sign-in for all existing and newly created Workers by default with Worker-level bypass exceptions.
Affected users
Who needs to care
Cloudflare Workers administrators using Access to protect Worker routes, Custom Domains, workers.dev URLs and preview deployments.
Required response
What to do
Choose Worker-level or account-wide Access scope deliberately, review sign-in policies and bypass exceptions, and test preview and production behavior before changing access defaults.
Evidence boundary
What the source does not prove
The source proves that Worker-level and account-wide Access protection are available. It does not mean every customer Worker was automatically made private; administrators choose whether to enable the controls and may configure Worker-level bypasses.
Lifecycle history
Dated event sequence
- Worker-level and account-wide Access protection becomes available
Cloudflare announced Access attachment to individual Workers and an account-wide default-protection option for existing and new Workers.
Evidence ledger
First-party sources
- 01Cloudflare — You can now enable Access on a Worker or all Workers at once
Official Cloudflare changelog · 2026-08-14
Open official source ↗