← All products

Zero Trust Access (ZTNA)

Cloudflare Access authenticates and authorises each request to a protected application against identity, device and context policies before the request reaches the application. This page documents the enforcement path, policy model, session and revocation behaviour, limits and plan availability.

Document control

Dana
Technical writer, Integrity Czech Republic s.r.o.

Overview

A network-perimeter access model grants a connected user reach across a network segment, which means a compromised credential or device provides access beyond the single application the user needed. Zero Trust Network Access replaces that model with per-request authorisation to a named application, evaluated against identity and context rather than against network location.

Cloudflare Access implements this at the Cloudflare edge. A protected application is published on a hostname that resolves to Cloudflare. Each request is evaluated against the policies configured for that application, and only requests that satisfy a policy are forwarded to the application over the configured connector.

An internet-reachable VPN or access appliance is an attack surface that requires patching, whereas an outbound-only connector does not accept inbound connections.

Architecture

Three components define the data path:

• Connector. cloudflared establishes outbound encrypted connections from the network hosting the application to the Cloudflare edge. The application requires no inbound firewall rule and no public address. WARP Connector and Magic WAN provide alternative on-ramps for networks rather than individual services.
• Policy evaluation. A request to the application hostname arrives at Cloudflare, which checks for a valid Access session. If none exists, the user is redirected to the configured identity provider. After authentication, the configured policies are evaluated against identity attributes, group membership, network context and device posture.
• Session. On success, Cloudflare issues a signed token stored as a cookie, scoped to the application and bounded by the configured session duration. Subsequent requests present the token and are validated against it.

For non-HTTP protocols, the WARP client provides network-level access to defined destinations, and browser-rendered access allows SSH and VNC sessions through a browser. Availability of browser-rendered protocols depends on entitlement; confirm at the source before designing around it.

Enforcement occurs at the Cloudflare data centre handling the request rather than at a single concentrator, which removes the concentrator as a capacity and failure choke point. Whether this reduces latency for a given user population depends on their location relative to the application and the previous access path, and should be measured rather than assumed.

Capabilities

Configuration model

An Access application is defined by the hostname or hostname and path it protects, a session duration, and an ordered set of policies. Each policy has a decision (allow, block, bypass or service auth) and include, exclude and require rule groups. Include rules broaden, exclude rules subtract, and require rules must all be satisfied. Policy order matters, and a bypass policy removes authentication for the matched traffic entirely.

Identity is supplied by one or more configured providers. Group membership and other claims from the provider are available as policy selectors, subject to the provider's configuration and the scopes granted.

Session duration is set per application and determines how long an issued token remains valid without re-authentication. A short duration reduces the window in which a stale authorisation remains usable; a long duration reduces authentication prompts. Choose it against the sensitivity of the application rather than as a global default.

Service tokens and mTLS client certificates provide non-interactive access for automation. These credentials do not expire with a user session and must be rotated on their own schedule.

Applications, policies, tunnels and identity provider configuration are manageable through the dashboard, the API and the Terraform provider.

Limits and constraints

• Seats are consumed by users who authenticate to an application or enrol a device. When the subscribed seat count is exhausted, further users are blocked from logging in.
• The connector is software that must be patched, monitored, scaled and made redundant. Running a single cloudflared instance creates a single point of failure for every application behind it.
• Browser-rendered access for RDP and VNC is entitlement dependent and has changed across releases. Verify current availability before planning a migration that depends on it.
• Device posture signals require the WARP client on a managed device. Clientless browser access provides no posture signal.
• Access controls access to applications published through Cloudflare. It does not restrict lateral movement between systems on the internal network that remain reachable by other paths.
• Log retention differs by plan, and export to an external system requires a paid tier.
• Some policy selectors and posture integrations are restricted to paid tiers.

Plan availability

Deployment

Prerequisites.

• Inventory internal applications, their protocols, hostnames, authentication mechanisms and the user groups that need them.
• Document the identity provider or providers, the group structure that will be used in policies, and who administers group membership.
• Identify automation that accesses internal applications and the credentials it currently uses.
• Identify devices in scope for the WARP client and the management system that will distribute it.
• Select two or three applications for staged validation, covering at least one web application and one non-HTTP service.
• Record the current access path so that it can be restored.

Staged validation. Connect the identity provider and confirm that group claims arrive as expected. Deploy a connector for the selected applications in a redundant configuration. Publish the applications to a limited user group and run them in parallel with the existing access method for a defined period. Verify authentication, authorisation, session duration behaviour and logging before widening scope.

Configuration.

1. Deploy connectors with at least two instances per application group, on separate hosts, and place them under configuration management.
2. Write per-application policies with least privilege. Prefer include rules based on identity provider groups over individual user lists.
3. Set session duration per application according to sensitivity.
4. Replace shared credentials used by automation with service tokens or mTLS client certificates, and record their rotation schedule.
5. Add device posture requirements for applications where a managed device is required, and confirm the posture signal is present before enforcing it.
6. Configure log export to the SIEM, and confirm that authentication and request events arrive.

Cutover. Migrate applications in waves grouped by user population rather than by technology, so that a wave affects a bounded set of people. Keep the previous access method available for the duration of each wave. Provide contractors and partners with browser-based access where a client cannot be installed.

Verification.

• Confirm that a user in an authorised group can reach the application and that a user outside it cannot.
• Confirm that revoking a test user in the Zero Trust dashboard terminates the existing session within the documented interval, and record the observed behaviour in the offboarding runbook.
• Confirm that automation using service tokens succeeds and that the tokens are recorded in the credential inventory.
• Confirm that authentication and request logs reach the SIEM with the expected fields.
• Confirm connector redundancy by stopping one instance and observing continued service.

Rollback. Restore the previous access path for the affected application, and either disable the Access application or set a bypass policy scoped to the migration window. Retire the previous access method only after all waves are complete and the runbooks, including revocation, have been exercised.

Operational considerations

Treat connectors as production infrastructure: monitor their health, patch them on a schedule, run at least two per application group, and alert on connection loss. A connector outage presents to users as an application outage.

Write the offboarding runbook around explicit revocation. Removing a user from the identity provider is necessary but not sufficient; the Access revocation step and the propagation interval must both be recorded, and the runbook should be exercised periodically.

Review policies on a schedule. Policies accumulate exceptions, and an include rule added for a project frequently outlives it. Export policy configuration and review diffs as part of change management.

Rotate service tokens and client certificates on a defined schedule and track their expiry, because their failure mode is a silent automation outage.

Monitor seat consumption against the subscribed count, since exhausting seats blocks logins for additional users.

Failure modes to plan for: identity provider outage preventing new authentications, group claim changes silently widening or narrowing access, a bypass policy left in place after a migration, and posture checks failing after an operating system update.

Known caveats

• Identity provider deletion does not end an existing Access session. Explicit revocation is required, and it propagates over an interval of up to one minute for re-authentication.
• The connector is an appliance in software form. It requires patching, capacity planning and redundancy, and a single instance is a single point of failure.
• A bypass policy removes authentication for matched traffic. Bypass policies created for testing are a recurring source of unintended exposure.
• Clientless browser access provides no device posture signal, so policies requiring posture cannot be satisfied by contractors using it.
• Access protects the published path. Systems reachable by other network paths remain reachable; decommissioning the previous access method is part of the security benefit, not an optional final step.
• Latency compared with a previous VPN depends on user and application location. Measure it rather than asserting an improvement.
• Browser-rendered RDP and VNC availability has changed across releases and is entitlement dependent.

Interoperability

Access and Gateway are complementary parts of Cloudflare One: Access authorises inbound requests to internal applications, while Gateway filters outbound traffic from users and devices. They share the identity provider configuration, the WARP client and the device registry.

Cloudflare Tunnel is shared infrastructure. A tunnel that publishes an application to Access can also provide private network routes reachable through WARP.

WAF and DDoS protection apply to the public hostname in front of an Access application, so both controls operate on the same request.

Access policies can be used in front of applications that also perform their own authentication, in which case Access adds an authentication layer without the application being modified.

Audit logs export to SIEM platforms through Logpush on paid tiers, allowing correlation with identity provider and endpoint telemetry.

FAQ

Does a user need to install software? For web applications, a browser is sufficient. The WARP client is required for non-HTTP protocols and for device posture signals.

How is a departing employee's access terminated? Disable the account in the identity provider and revoke the user in the Zero Trust dashboard, or revoke existing tokens on the affected applications. The identity provider action alone leaves existing sessions valid.

Can applications that do not support SSO be protected? Yes. Access performs authentication and authorisation before the request reaches the application, so an application with no SSO support, or with only basic authentication, can be placed behind identity-based policy without modification.

References

• https://developers.cloudflare.com/cloudflare-one/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/policies/access/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/identity/users/session-management/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/integrations/identity-providers/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/team-and-resources/users/seat-management/, retrieved 2026-08-28.
• https://www.cloudflare.com/plans/zero-trust-services/, retrieved 2026-08-28.

Content snapshot: 2026-08-28.

Changelog