Private by Default: Cloudflare Locks Down Every Worker in One Click

Private by Default: Employee-Built Apps Lose Their Open Door

Cloudflare has turned private-by-default into a platform-level control for every employee-built Worker.

Starting immediately, Access policies can attach directly to a Worker or to an entire account, forcing authentication before any request reaches application code across custom domains, routes, workers.dev subdomains, and preview URLs.

The move targets the core tension of AI-enabled development: employees can ship faster than security teams can manually review hostname-level access.

Worker-Level Access Replaces Hostname-Level Perimeter

Before this change, access enforcement lived at the hostname layer. Every custom domain and preview URL had to be manually tied to an Access policy, and adding a new domain without updating that policy created an unauthenticated entry point.

As detailed in Cloudflare’s announcement, the policy now travels with the Worker itself. Hostname policies still take precedence, followed by Worker policies, then account-wide policies, which keeps the operational model legible for security teams.

Administrators choose what to protect.

• Account-wide default: locks all preview traffic, production traffic, or both for every current and future Worker.
• Worker-specific policy: protects a single application across every domain and route associated with it.
• Selective bypass: lets a deliberately public Worker opt out of an account-wide policy.

Within a Worker’s view, an Access tab shows exactly which policies apply to that application.

Identity Becomes a Context Object

When Access is enabled, authenticated requests carry the user’s email, name, and group membership through the Worker’s context object.

Developers call ctx.access.getIdentity() instead of parsing and verifying a JWT by hand.

Local wrangler configurations can simulate an authenticated identity, so teams test personalized or access-restricted logic without a production deployment.

One Dispatch Policy for Platform Scale

For internal deployment platforms, one access policy on a dispatch Worker now propagates private-by-default behavior to every Worker in the namespace.

An open-source example demonstrates the pattern: a single dispatcher policy secures an entire drag-and-drop site platform.

The FL2 Foundation

The release rests on FL2, a Rust-based modular proxy that separates Workers routing from execution and moves routing ahead of Access enforcement.

The legacy NGINX and Lua architecture would have made that pipeline reordering much more complex and risky.

What Service Tokens and Session Controls Reveal for the Zero Trust Market

Beneath the headline feature, the supporting access mechanics matter more for enterprise buyers.

Service credential mechanics give automated systems a controlled path inside protected Workers. A service token pairs a Client ID with a Client Secret and authenticates through CF-Access-Client-Id and CF-Access-Client-Secret headers, with the policy action set to Service Auth.

As noted in Cloudflare’s service token documentation, service token lifecycles are not fire-and-forget. They can be renewed, refreshed, given custom durations, and revoked, and an expiring token notification can alert administrators one week before expiry.

Session management introduces its own layered control. On login, Access generates a global session token and an application token, both signed JWTs, with default durations of 24 hours and configurable windows from 15 minutes to one month.

Enforcement order is well-defined: Cloudflare One Client session, policy session, application session, then global session. Administrators can revoke tokens per application or per user, and AJAX-heavy applications can receive a 401 on expired sub-requests.

For browser-based access, the CF_Authorization cookie carries the identity, and an optional binding cookie can stop a stolen session cookie from being replayed on another device. That binding option is not recommended for non-browser protocols such as SSH or RDP.

The market implication for business leaders is straightforward: zero trust enforcement is moving from the network perimeter to the application identity layer.

Private-by-default removes a major source of accidental exposure, but it also shifts operational burden toward service token hygiene and session revocation workflows.

For internal platforms, the dispatch Worker pattern means a small configuration change can secure hundreds of employee-built prototypes at once.

The Default Is No Longer Public

The decisive change is not the authentication prompt; it is that private-by-default is now inherited rather than configured. For teams scaling AI-built internal platforms that need secure content infrastructure, programmatic SEO and AI automation is how Andres SEO Expert approaches the visibility layer — contact Andres SEO Expert.