Cloudflare Access extends ZTNA to private IPs and hostnames

Cloudflare has updated its Zero Trust Network Access (ZTNA) service, Cloudflare Access, to natively support applications defined by private IP addresses and hostnames. Previously, Access applications had to be tied to public hostnames; private network access was routed through the network firewall component of Cloudflare Gateway, a workaround that presented a handful of operational challenges. The new release also brings reusable access policies and a refreshed administrative UI.

The change means that self-hosted, privately routable applications can now be defined and protected directly within Access, using the same workflows and feature set that apply to public-hostname web applications. This includes granular identity-aware authorization, per-application session management, and support for non-browser clients like SSH and RDP.

Background: how private applications were handled

A private application, in this context, is any application reachable only through a private IP address (per RFC 1918) or a private hostname resolved by internal DNS. These addresses are scoped to a specific network and can be reused across networks, making them practical for ephemeral infrastructure. Access outside that network requires a VPN, a forward proxy, or a device client such as Cloudflare WARP that adds a virtual network interface and routes specific requests to the remote private network.

Cloudflare Zero Trust historically used two separate components for application protection:

  • Cloudflare Access — an identity-aware proxy for internal applications. Until now, it required that an application be defined with a public DNS record. Administrators would map internal resources to public URLs via Cloudflare Tunnel, then create Access policies for those URLs. This approach could not serve organizations with strict no-public-exposure requirements, nor could it support non-browser protocols like SSH, where an SSO flow cannot easily be completed.
  • Cloudflare Gateway — a secure web gateway that filters DNS and web traffic, and also acts as a forward proxy into private networks. Access Private Network applications were previously implemented as a thin wrapper that auto-generated two Gateway block policies. However, Gateway's network firewall is a general-purpose tool, and using it for application access control had drawbacks: private applications were intermingled with general firewall rules, no Terraform support existed for defining them, application access logs were lost among all Internet traffic logs, enforcement lacked granular identity context, and Access-specific features like Rule Groups were unavailable.

A unified application model in Access

Cloudflare's engineering goal was to unify the application definition in Access so that any application — public or private — could be protected the same way. To accomplish this for private resources, they needed to bridge a platform gap: Access itself cannot route private traffic. That remains Gateway's job via the WARP client.

The solution was to add an application-aware phase to Gateway's network firewall. This new phase checks whether a user's traffic matches a defined application and, if so, hands that traffic to Access for authentication and session authorization. Administrators can configure where in their overall network firewall policy stack this application evaluation occurs.

For private applications accessed over HTTPS in a browser, the session flow mirrors public applications: users authenticate via single sign-on, and Access issues a JWT for that specific domain. For non-HTTPS or non-browser traffic, where cookies are not an option, Gateway's firewall now maintains per-application sessions tied to a specific device, tracking when the user must re-authenticate before another application access attempt is permitted. Non-HTTPS clients will receive a pop-up prompting re-authentication when their application session expires.

Reusable access policies and UI refresh

The release addresses a long-standing operational pain point: access policies were nested objects under each individual application, forcing administrators to either lean on Access Groups or copy identical configurations across many applications. Cloudflare now offers Reusable Policies, which let administrators define standard policy tiers — e.g., high, medium, or low risk — and attach them to multiple applications. A single edit to a reusable policy propagates to every application that uses it. Cloudflare anticipates that this will let many customers consolidate from hundreds of granular policies down to a small handful.

Alongside this functional change, "Access Groups" has been renamed to "Rule Groups" to better reflect their role and avoid confusion with identity provider (IdP) groups. The Access UI has been redesigned to present more information at a glance and to make workflows for defining and managing applications more consistent.

Current limitations and roadmap

At launch, private hostname support is limited to port 443 with TLS inspection enabled. Cloudflare has indicated that support for arbitrary private hostnames on any port and protocol is planned for later in 2025.