Cloudflare Access
The identity-aware proxy in Cloudflare One: every request to a protected app must carry a signed token that says who the user is and that a policy allowed them in.
- What it is
- Remote access
- Used for
- Authentication
- Type
- Commercial product
- Made by
- Cloudflare, Inc.
- License
- Proprietary
- Facts checked
- 12 October 2026
What it is
Access sits in Cloudflare’s reverse proxy in front of a hostname. Every application is deny by default. When a request arrives without a valid CF_Authorization cookie, the user is sent to your identity provider (Okta, Microsoft Entra ID, Google, GitHub, any SAML or OIDC provider, or a one-time PIN by email). Access then checks the policies: Allow, Block, Bypass or Service Auth actions, built from Include (OR), Require (AND) and Exclude (NOT) rules over selectors such as email domain, IdP group, country, IP range, client certificate or device posture. Non-identity selectors are checked again on every request during the session.
If the user passes, Access issues a JSON Web Token: a global session token on your <team>.cloudflareaccess.com domain, which gives single sign-on across apps (24 hours by default), and an application token on the app’s own domain. Cloudflare forwards the token to the origin in a Cf-Access-Jwt-Assertion header, signed with RS256 keys published at /cdn-cgi/access/certs and rotated every six weeks, so the origin can verify the user itself. Machines use service tokens (a client ID and secret) or mutual TLS instead of a login. Pair it with Cloudflare Tunnel and the app needs no public IP at all; SSH, RDP and other TCP apps work through client-side cloudflared.
Why teams pick it
- Replaces a VPN for web apps: users sign in with the IdP they already have, and every request is checked, not just the network connection
- Origins can verify the signed JWT themselves, so a request that skipped Access is easy to reject
- Policies combine identity with context (country, IP, device posture, certificates) and support service tokens and mTLS for automation
- Works with any SAML or OIDC identity provider, and several at once for contractors or partners
Watch out for
- Billed per seat: a user takes a seat on their first login and keeps it until an admin removes them
- Protected hostnames must be on a domain active in your Cloudflare account, or a Cloudflare for SaaS custom hostname
- Default caps of 500 applications, 50 identity providers and 50 service tokens per account, which Enterprise accounts can raise
- A Bypass policy turns off all Access checks and logging for matching traffic, and an Include “Everyone” rule in an Allow policy lets anyone in
Alternatives
What all remote access have in common →
HashiCorp BoundaryCommercialAn identity-aware proxy: users sign in once and get one proxied session to one private host or database, with credentials fetched per session.How it fits with other technologies
Verify the Access JWT in a Worker that sits behind Access (from the docs) · ts
import { jwtVerify, createRemoteJWKSet } from "jose";
interface Env {
POLICY_AUD: string; // the application's AUD tag
TEAM_DOMAIN: string; // https://<team>.cloudflareaccess.com
}
export default {
async fetch(request: Request, env: Env): Promise<Response> {
const token = request.headers.get("cf-access-jwt-assertion");
if (!token) return new Response("Missing required CF Access JWT", { status: 403 });
const JWKS = createRemoteJWKSet(new URL(`${env.TEAM_DOMAIN}/cdn-cgi/access/certs`));
try {
const { payload } = await jwtVerify(token, JWKS, {
issuer: env.TEAM_DOMAIN,
audience: env.POLICY_AUD,
});
return new Response(`Hello ${payload.email || "authenticated user"}!`);
} catch {
return new Response("Invalid token", { status: 403 });
}
},
};See it in a real stack
No architecture uses Cloudflare Access yet. Drop it into the playground and wire it up yourself.Open playground →Where it came from2018–2026
Most companies trusted anything on the corporate network and nothing outside it. Once a firewall or VPN server was breached, as the launch post put it, “the attacker gets immediate, easy and trusted access to everything”, and employees outside the office paid for the VPN in slow page loads. Google had moved its internal apps onto the internet with BeyondCorp, where no connection is trusted and everyone has to prove who they are.
On January 17, 2018, Venkat Viswanathan announced Cloudflare Access: “like BeyondCorp, but you don’t have to be a Google employee to use it.” It was a reverse proxy in Cloudflare’s 120+ data centers that authenticated each request against Google, Azure Active Directory or Okta, could require a client certificate, and was free for one user and $3 per seat per month beyond that. The same post suggested Argo Tunnel for apps that should have no public IP.
In 2020 Access became one half of Cloudflare for Teams, next to the Gateway secure web gateway, and on October 13, 2020 a Free plan covered up to 50 users of both. Today the dashboard files it under Zero Trust and the docs under Cloudflare One, where Access protects self-hosted web apps, SaaS apps, private networks and infrastructure.
Why it’s built this way
- Check every request at a reverse proxy
- Instead of trusting a network, Access makes sure each request is authenticated, authorized and encrypted, so there is no inside to break into.
- Use the customer’s existing identity provider
- Teams could keep the users and groups already defined in Google, Azure AD or Okta and write policies against them, rather than managing a second directory.
- Price it for small teams too
- Cloudflare’s stated mission was to “democratize the tools of the internet giants”: Access started at $3 a seat, and the 2020 Teams Free plan covered up to 50 users.
Timeline
- 2018
Cloudflare Access launches on January 17
- 2020
Part of Cloudflare for Teams; a Free plan covers up to 50 users from October 13
- 2021
Cloudflare Tunnel becomes free, so apps behind Access need no public IP at no extra cost
- 2026
Documented as the access controls of Cloudflare One, with policies for web, SaaS, private network and MCP portal apps
- Cloudflare Blog: Introducing Cloudflare Access, like BeyondCorp (Jan 2018)
- Cloudflare Blog: Zero Trust for everyone, Teams plans (Oct 2020)
- Cloudflare Blog: A boring announcement, free Tunnels for everyone (Apr 2021)
- Cloudflare One docs: Account limits (MCP portals)
- Cloudflare One docs: Publish a self-hosted application (Zero Trust dashboard)
Sources10 · facts checked 12 October 2026
- Cloudflare One docs: Access policies (actions, rule types, selectors, order)
- Cloudflare One docs: Publish a self-hosted application (deny by default, domain requirements)
- Cloudflare One docs: Authorization cookie (global and application tokens)
- Cloudflare One docs: Validate JWTs (header, signing keys, rotation, Worker example)
- Cloudflare One docs: Session management (global session default 24 hours)
- Cloudflare One docs: Identity providers
- Cloudflare One docs: Service tokens
- Cloudflare One docs: Seat management
- Cloudflare One docs: Account limits
- Cloudflare Tunnel docs: Routing (non-HTTP services need client-side cloudflared)