ZTNA — Cloudflare One

ZTNA at Cloudflare

Build access policies from identity, device, and traffic context.

Cloudflare Access combines who the user is, whether their device is trusted, and where the request comes from. These signals become policies that define access to self-hosted and SaaS applications without granting broad network access.

ID

01 · IdentityWho is requesting access?

Identity providers identify the user and add group and authentication context.

SAMLOIDCgroupsauth method

DV

02 · Device postureIs the device trusted?

The Cloudflare One Client and endpoint integrations continuously supply posture signals.

WARPOS stateEDRUEM

TX

03 · Traffic contextWhere is the request coming from?

Network and request attributes describe the source reaching the application.

source IPcountrynetworkvirtual network

Cloudflare Access Access policy Identity + Device + Traffic context

IncludeRequireExclude

APP

Self-hosted applicationsPublic or private resources behind Access

SAAS

SaaS applicationsIdentity-aware access through SSO

01 · Endpoint

Start with the Cloudflare One Client

Begin with the software users recognize on the endpoint. WARP registers the device, establishes its path to Cloudflare, and supplies identity and posture context to the controls that follow.

EnrollAssociate a device with the Zero Trust organization. ConnectSend selected DNS, HTTP, and private traffic to Cloudflare. SignalExpose client, device, network, and posture state to policy.

DashboardOpen devices ↗Client inventory, profiles, enrollment and device activity

Managed endpoint on-ramp Cloudflare One Client One agent turns endpoint state into policy context and a protected traffic path.

CF

Managed endpointClient connected · profile active

ON

01

Organization enrollmentDevice registration · profile · unique identity

02

Continuous postureOS · disk encryption · firewall · EDR

03

Traffic selectionDNS · web · private routes · split tunnels

MASQUE / WARP tunnel

selected traffic + device context

☁

Nearest Cloudflare locationCloudflare One control point

Access contextdevice identity + posture Gateway policiesDNS + Network + HTTP Private routingapplications + infrastructure

ENROLL→EVALUATE→ROUTE→ENFORCE

02 · Trust signals

Establish identity and device trust

Access can combine the user asserted by an identity provider with continuously evaluated endpoint signals. The policy later decides which of those signals are required for a particular resource.

DashboardOpen identity providers ↗SAML, OIDC, social providers and One-Time PIN DashboardOpen users ↗Users, groups, SCIM attributes and risk context DashboardOpen posture checks ↗Native client checks and third-party endpoint integrations

WHOSAML / OIDCusers + groupsMFA method

ACCESStrust context

WHAT DEVICEWARP statusOS + clientEDR / UEM

03 · Access decision

Create the application and policy

Use a self-hosted browser application first. The application defines the protected resource; its policies combine rule logic, selectors, values, and one primary action.

DashboardOpen applications ↗Self-hosted, SaaS, private, infrastructure and service applications DashboardOpen Access policies ↗Reusable Include, Require and Exclude policy logic

APPLICATIONself-hosted browser appprotect one resource

RULE LOGIC

IncludeRequireExclude

Who is considered, what must also be true, and who is carved out.

SELECTOR USE-CASE BRIEF

01Who are you?Email, IdP group, SAML/OIDC claim, login method 02Is the device trusted?Posture, WARP, Gateway, endpoint integrations 03Is context acceptable?Country, IP, auth method, risk and external evaluation 04Is this a workload?Service token, certificate and linked application token

PRIMARY ACTIONAllowBlockBypassService Auth

ADDITIONAL CONTROLSIsolate applicationPurpose justificationTemporary authenticationIndependent MFA

DashboardOpen service credentials ↗Service tokens and mutual TLS for non-human access DashboardOpen Access settings ↗Session, login, JWT, MFA and organization-wide controls Traffic policyControl Internet and SaaS traffic

Move from who may access an application to what DNS, Network, and HTTP traffic may do.

Explore capability → Isolate applicationExecute risky content remotely

Follow the isolation control into browser execution and data-in-use restrictions.

Explore capability →

04 · Private connectivity

Connect private resources when needed

A Tunnel provides outbound-only connectivity and routes; it does not create an Access application or Target. The same Tunnel can publish a web service, route a private application, and carry infrastructure traffic. Access objects then define what is protected and who may connect.

DashboardOpen Tunnels ↗Connectors, public hostnames, private routes and virtual networks DashboardOpen applications ↗Public hostnames and private destinations protected by Access policies DashboardOpen targets ↗Routed servers used by Infrastructure Access applications

Connectivity before authorizationOne named Tunnel, three protected outcomesOne Tunnel UUID · multiple replicas · several routes and Access objects

☁

Cloudflare edgeRoutes each request to an available replicaAccess policy is evaluated before the private origin is reached.

A

Replica Acloudflared · host 1Multiple outbound-only connections

B

Replica Bcloudflared · host 2Same Tunnel UUID · host redundancy

WEBPublish a browser application

Published application routeapp.example.com → http://localhost:8080

↓

Access applicationProtect the hostname with an Access application

PRIVATE APPRoute a private destination

Private hostname or CIDR routewiki.internal · 10.20.0.25/32

↓

Private destinationProtect the private destination with Access

INFRASTRUCTUREAuthorize an operator

CIDR route10.20.0.25/32 · default virtual network

↓

TargetTarget matches the routed IP + virtual network

↓

Infrastructure applicationInfrastructure application authorizes SSH, RDP, or VNC

Route = how Cloudflare reaches it. Access application or Target = what is protected and who may connect. Replicas add basic redundancy, not granular traffic steering.

Extend the foundation