Passive Visibility Into Private Networks
Cloudflare One makes it straightforward to connect a private network to Cloudflare, but keeping that network secure over time is a different challenge. Resources are created and retired constantly, users join and leave, and security teams are left with a perpetual cycle of discovering and securing applications. To address this, Cloudflare is opening a closed beta for Private Network Discovery, a Zero Trust tool that passively catalogs the resources being accessed and the users accessing them without requiring additional configuration, third-party tools, or manual commands.
Interested teams can sign up for early access to the closed beta.
How Private Network Discovery Works
Private Network Discovery operates in an observability mode, passively cataloging unique traffic destined for RFC 1918 or RFC 4192 address space. All applications surfaced by the tool are tagged with a base state of “Unreviewed.” The tool identifies origins as any unique IP address, port, or protocol combination, and presents them in a report for review.
From the discovered origins table, you can inspect the details of any origin and create a Cloudflare Access application to control access to it. Access applications can be composed of multiple origins, allowing you to group related resources logically.
Consider a privately hosted instance of the video conferencing service Jitsi, which Cloudflare uses internally to test new features. The service runs at 10.0.0.1:443, but because it's a conferencing application, it communicates over both tcp:10.0.0.1:443 and udp:10.0.0.1:10000. In the discovery report, you'd select the first origin, assign it an application name, then repeat the process for the second origin. This yields a logical grouping that accurately represents the service on your network.
During the closed beta, application names created this way appear only in the Application name column of the discovered origins table, not in the general Cloudflare Access application table. At general availability, applications you create will also appear under Zero Trust > Access > Applications.
Creating an application automatically changes the status of its individual origins from “Unreviewed” to “In-Review.” From there, you can drill into each origin to see the number of unique users and the total number of requests each user has made. That data can inform identity- and device-driven Zero Trust policies. Once you're comfortable with an application's usage pattern, you can manually update its status to “Approved” or “Unapproved.”
Securing the Path Between Users and Infrastructure
Cloudflare's private network setup has two sides. The infrastructure side is handled by Cloudflare Tunnel, a command-line daemon that runs in your environment and establishes secure, outbound-only connections to Cloudflare. This links your infrastructure — whether a single app or an entire network segment — to Cloudflare.
On the client side, the Cloudflare WARP device agent establishes a secure connection from end-user devices to the Cloudflare network. WARP can be deployed across an organization in minutes via in-house MDM tooling. With both infrastructure and users connected, you can tag applications and enforce identity- and device-based security controls on every request.
Roadmap to General Availability
The closed beta is an initial step. While it supports friendly names for private network applications, those names do not currently surface in the Cloudflare Zero Trust policy builder. The near-term priority for general availability is a unified workflow that lets you create Access applications directly from the Private Network Discovery report, reference those applications in Cloudflare Access, and create Zero Trust policies for them without leaving that flow.
