Skip to content

Changelog

New updates and improvements at Cloudflare.

New strict service token authentication setting for Access

The strict service token authentication setting applies consistent behavior to requests made with service tokens. When the setting is on for a Zero Trust organization, Access handles requests with service token headers as follows:

  • If authentication or authorization fails, Access always returns 401 or 403 instead of redirecting the client to the login page with 302.
  • Only Service Auth policies can authorize the request. Access ignores Allow policies and any CF_Authorization cookie sent with the request.
  • Access does not return a CF_Authorization cookie to the client after successful authentication. Subsequent requests should continue to use service token headers.
  • Failed requests for recognized service tokens appear in Access authentication logs.

Zero Trust organizations created on or after October 5, 2026 have strict service token authentication turned on by default and cannot turn it off. Cloudflare recommends that existing organizations turn it on as well.

Organizations created before October 5, 2026 can configure the setting in the dashboard or through the API.

  1. In the Cloudflare dashboard ↗︎, go to Zero Trust > Access controls > Access settings.

    Go to Access settings ↗
  2. Under Manage service tokens, turn on Strict service token authentication.

  3. In the confirmation dialog, select Enable.

To turn off strict service token authentication, turn off the setting and select Disable.

curl "https://api.cloudflare.com/client/v4/accounts/%7Baccount_id%7D/access/organizations" \
	--request PATCH \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"strict_service_token_auth": true
	}'

To turn off strict service token authentication, set strict_service_token_auth to false.

For behavior and configuration details, refer to Strict service token authentication.

Simplified permissions for tagging targets with Access for Infrastructure

You can now tag targets using only the Zero Trust Write API token permission. Previously, tagging targets through the API required both Zero Trust Write and Tag Write permissions on the API token.

This change applies to inline target tagging through the Infrastructure Access Targets API. Tagging resources through the general Resource Tagging API still requires the Tag Admin, Tag Write, or equivalent role.

For more information, refer to Tag targets.

Cloudflare One Client for Windows (version 2026.8.2033.1)

A new Beta release for the Windows Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

  • Fixed an issue that could briefly block traffic to split tunnel excluded resources while the client was connecting or reconnecting.
  • Improved reauthentication reliability and fixed an issue where a reauthentication could force a new registration.
  • Improved client reaction to the current network lowering its MTU.
  • Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
  • Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
  • Improved API reliability by retrying requests dropped when reusing pooled connections.
  • The client no longer requires the Windows WLAN AutoConfig service to be running.
  • Implemented a service recovery mechanism backed by Windows scheduler task to start WARP service on system unlock if not already started.
  • Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
  • Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
  • Fixed the client continuing to report 'No network' after a successful manual disconnect.
  • Fixed Digital Experience Monitoring (DEX) HTTP tests failing TLS validation on Windows.
  • Fixed the client UI crashing at startup when it could not write to the Windows registry.
  • Fixed latency spikes and traffic interruptions during TPM-backed API authentication when hardware-backed registration is enabled.
  • Fixed trailing whitespace in BIOS serial numbers causing serial-number and client-certificate device posture checks to fail.
  • Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
  • Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

  • None

For Zero Trust documentation, see: https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/ For Consumer documentation, see: https://developers.cloudflare.com/warp-client/

Role-based access control for Browser Isolation policies

Isolation policies support role-based access control (RBAC). Because isolation policies are Gateway HTTP policies with the Isolate action, Gateway's account-level and resource-scoped roles apply to them directly.

Use the Zero Trust HTTP Policies Admin account-level role to grant access to all HTTP policies in the account. You can also assign a resource-scoped role to let a team member manage a specific isolation policy without exposing other Gateway resources.

Policy settings such as copy/paste, file download/upload, keyboard, and printing are part of the policy object and follow the same permissions.

For setup instructions, refer to Granular permissions for Gateway.

Cloudflare One Client for Windows (version 2026.8.2028.1)

A new Beta release for the Windows Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

  • Fixed an issue that could briefly block traffic to split tunnel excluded resources while the client was connecting or reconnecting.
  • Improved reauthentication reliability and fixed an issue where a reauthentication could force a new registration.
  • Improved client reaction to the current network lowering its MTU.
  • Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
  • Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
  • Improved API reliability by retrying requests dropped when reusing pooled connections.
  • The client no longer requires the Windows WLAN AutoConfig service to be running.
  • Implemented a service recovery mechanism backed by Windows scheduler task to start WARP service on system unlock if not already started.
  • Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
  • Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
  • Fixed the client continuing to report 'No network' after a successful manual disconnect.
  • Fixed Digital Experience Monitoring (DEX) HTTP tests failing TLS validation on Windows.
  • Fixed the client UI crashing at startup when it could not write to the Windows registry.
  • Fixed latency spikes and traffic interruptions during TPM-backed API authentication when hardware-backed registration is enabled.
  • Fixed trailing whitespace in BIOS serial numbers causing serial-number and client-certificate device posture checks to fail.
  • Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
  • Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

  • None

Cloudflare One Client for macOS (version 2026.8.2028.1)

A new Beta release for the macOS Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

  • Fixed an issue that could briefly block traffic to split tunnel excluded resources while the client was connecting or reconnecting.
  • Improved reauthentication reliability and fixed an issue where a reauthentication could force a new registration.
  • Improved client reaction to the current network lowering its MTU.
  • Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
  • Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
  • Improved API reliability by retrying requests dropped when reusing pooled connections.
  • Fixed Extra Logging failing to capture packets across all interfaces.
  • Fixed an issue that could prevent remote diagnostics from completing.
  • Fixed DNS connectivity checks failing on IPv6-only networks.
  • Fixed the client service exiting when its route-monitoring socket was closed after sleep or wake.
  • Fixed DNS enforcement checks making the client service unresponsive on systems with large routing tables.
  • Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
  • Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
  • Fixed the client continuing to report 'No network' after a successful manual disconnect.
  • Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
  • Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

  • None

Identify Mesh, Workers VPC, and Cloudflare Tunnel replicas in network logs

You can now tell a person on a laptop apart from a Mesh node or an AI agent running on Workers, without matching on connector email addresses or Mesh IP ranges — and see exactly which Cloudflare Tunnel and cloudflared replica received each session.

Gateway network logs and Zero Trust Network Session Logs now identify two new kinds of traffic:

  • Mesh — Traffic sent from or delivered to a Cloudflare Mesh node. Previously, Mesh nodes were logged the same way as devices running the Cloudflare One Client, because Mesh nodes run the client in headless mode.
  • Workers VPC — Traffic sent by a Worker through a Workers VPC binding. Previously, Workers VPC sessions were not recorded in Network Session Logs.
Viewing Mesh and Workers VPC traffic in Gateway network logs

Gateway network logs

To view these values in the dashboard, go to Zero Trust > Insights & Logs > Logs > Network logs, select Columns, and turn on Traffic Source and Traffic Destination. Both values also appear under Network query details when you open a log entry.

Network Session Logs

The zero_trust_network_sessions dataset, available through Logpush, includes the following fields:

Field Description
OnrampType How the session entered Cloudflare One. Values: CF1_CLIENT, MESH, WORKERS_VPC, MAGIC, OTHER.
Offramp Where the session was routed. Sessions routed to a Mesh node report MESH.
SourceName Name of the Worker that started the session. Only populated for Workers VPC sessions.
SourceID Stable identifier of the Worker that started the session. Only populated for Workers VPC sessions.
DestinationReplicaID The replica that served the session, such as a specific replica of a Mesh node or a cloudflared replica of a Cloudflare Tunnel.

For example, OnrampType = 'WORKERS_VPC' AND Offramp = 'MESH' returns every session where a Worker reached a service behind a Mesh node, and SourceName tells you which Worker it was.

See which tunnel and replica received a session

With DestinationReplicaID, you can now confirm which Cloudflare Tunnel and which cloudflared replica received traffic for a specific session. Combine it with the existing DestinationTunnelID field to trace a session to an exact tunnel replica — or Mesh node replica — when you run multiple replicas for high availability. The replica ID matches the Connector ID shown in the dashboard, so you can stream that replica's logs with cloudflared tail --connector-id.

Sessions logged before this change are not backfilled. For all available fields, refer to Zero Trust Network Session Logs.

MCP server portals are now generally available

MCP server portals are now generally available to all Cloudflare customers. A portal gives users one endpoint for approved Model Context Protocol (MCP) servers. Cloudflare Access logs tool, prompt, and resource activity.

Since the open beta, MCP server portals have added:

To create a portal and connect an MCP client, refer to MCP server portals.

Traffic Destination selector in Gateway policies

Gateway HTTP and Network policies now include a Traffic Destination selector that identifies how traffic exits Cloudflare. This allows administrators to write policies that target specific off-ramp methods - for example, applying different rules to traffic destined for the public Internet compared to traffic routed through Cloudflare Tunnel or Cloudflare WAN.

Available traffic destination values

UI name API value Description
Internet internet Traffic to the public Internet
Cloudflare WAN cloudflare_wan Traffic through a Cloudflare WAN connection
Cloudflare Tunnel cloudflare_tunnel Traffic to a private origin through Cloudflare Tunnel
Cloudflare One Client device_client Traffic to another device running the Cloudflare One Client
Mesh mesh Traffic through a Cloudflare Mesh node

The selector uses the net.offramp.type API field in both HTTP and Network policies.

UI name API example
Traffic Destination net.offramp.type == "internet"

For more information, refer to HTTP policies and Network policies.

Add Mesh participants with guided onboarding

Cloudflare Mesh now makes it faster to add and manage participants from the dashboard. Select Add participant from Networking > Mesh to deploy a Mesh node or find the information needed to connect a client device.

Adding a Cloudflare Mesh node through the guided dashboard workflow

The updated dashboard includes the following improvements:

  • More Mesh node deployment options — Install a node on Linux, Kubernetes, Docker Compose, or Docker CLI. The dashboard provides requirements, commands, configuration, and links for each method. Refer to Run Mesh in Docker / Kubernetes for container deployment details.
  • Client device installation guidance — Access platform-specific Cloudflare One Client installers, mobile QR codes, and your Cloudflare One organization name. Use the organization name to log in from the client after installation.
  • Unified participant management — View Mesh nodes and enrolled client devices in one table. Search devices, filter participants by type or status, open device details, and load additional results from each participant source. If one source fails, participants from the other source remain available while you retry the request.

You must still install the Cloudflare One Client, log in to your organization, and test the connection.

For complete setup instructions, refer to Get started with Cloudflare Mesh.

Automatically manage inactive Access service tokens

Cloudflare Access administrators can now automatically disable or delete inactive service tokens. Administrators can set an inactivity period from 30 to 365 days and choose what Access does when a token reaches that limit.

To be eligible for cleanup, a token must be older than the configured period, must not have successfully authenticated during that period, and must not be directly referenced by an Access policy rule. Cleanup runs gradually in the background, so eligible tokens may not be disabled or deleted immediately.

For configuration instructions, refer to Manage inactive service tokens.

Private MCP server support for MCP server portals

MCP server portals can now connect to MCP servers available only on your private network. The portal uses Cloudflare Gateway to reach private hostnames and IP addresses without exposing the MCP server to the public Internet.

Connect the server network to Cloudflare with Cloudflare Tunnel, Cloudflare Mesh, or another Cloudflare One connector. Configure a private hostname or CIDR route, then turn on Route traffic through Cloudflare Gateway when you add the server. OAuth authorization server endpoints, such as the authorization and token endpoints, must be accessible on the public Internet. If Cloudflare automatically registers the OAuth client through Dynamic Client Registration (DCR), the registration endpoint must also be accessible on the public Internet.

For setup instructions, refer to Connect a private MCP server.

Cloudflare One Client for macOS (version 2026.8.1755.1)

A new Beta release for the macOS Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

  • Fixed an issue that could briefly block traffic to split tunnel excluded resources while the client was connecting or reconnecting.
  • Improved reauthentication reliability and fixed an issue where a reauthentication could force a new registration.
  • Improved client reaction to the current network lowering its MTU.
  • Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
  • Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
  • Improved API reliability by retrying requests dropped when reusing pooled connections.
  • Fixed Extra Logging failing to capture packets across all interfaces.
  • Fixed an issue that could prevent remote diagnostics from completing.
  • Fixed DNS connectivity checks failing on IPv6-only networks.
  • Fixed the client service exiting when its route-monitoring socket was closed after sleep or wake.
  • Fixed DNS enforcement checks making the client service unresponsive on systems with large routing tables.
  • Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
  • Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
  • Fixed the client continuing to report 'No network' after a successful manual disconnect.
  • Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
  • Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

  • None

Cloudflare One Client for Windows (version 2026.8.1755.1)

A new Beta release for the Windows Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

  • Fixed an issue that could briefly block traffic to split tunnel excluded resources while the client was connecting or reconnecting.
  • Improved reauthentication reliability and fixed an issue where a reauthentication could force a new registration.
  • Improved client reaction to the current network lowering its MTU.
  • Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
  • Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
  • Improved API reliability by retrying requests dropped when reusing pooled connections.
  • The client no longer requires the Windows WLAN AutoConfig service to be running.
  • Implemented a service recovery mechanism backed by Windows scheduler task to start WARP service on system unlock if not already started.
  • Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
  • Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
  • Fixed the client continuing to report 'No network' after a successful manual disconnect.
  • Fixed Digital Experience Monitoring (DEX) HTTP tests failing TLS validation on Windows.
  • Fixed the client UI crashing at startup when it could not write to the Windows registry.
  • Fixed latency spikes and traffic interruptions during TPM-backed API authentication when hardware-backed registration is enabled.
  • Fixed trailing whitespace in BIOS serial numbers causing serial-number and client-certificate device posture checks to fail.
  • Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
  • Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

  • None

Unified Routing generally available

Unified Routing is generally available for Cloudflare WAN and Magic Transit.

Unified Routing improves the integration between Cloudflare One and the standard connectivity onramps supported by Cloudflare WAN. It is capable of many new features including Automatic Return Routing, BGP and custom client subnets.

We recommend Unified Routing for all new accounts.

For details, refer to Cloudflare WAN traffic steering and Magic Transit traffic steering.

cloudflared to deprecate 32-bit Windows and Intel-based macOS builds in 2027

Starting in 2027, Cloudflare will deprecate 32-bit Windows and Intel-based macOS builds of cloudflared. After the deprecation takes effect, Cloudflare will no longer publish new cloudflared releases for either architecture.

Windows 10, the last Windows release to support 32-bit systems, reached end of support in October 2025. Apple has also deprecated Intel-based Mac computers. macOS 26 Tahoe, released in September 2025, was the final macOS release to support Intel-based Macs. macOS 27, released in September 2026, no longer supports them.

Focusing development on currently supported architectures allows cloudflared to align with operating system support and continue receiving updates on supported platforms. For available downloads and supported platforms, refer to the Cloudflare Tunnel downloads documentation.

Access for Infrastructure now supports tagged targets and tag-based target criteria

Access for Infrastructure now integrates with Resource Tagging. You can attach key-value tags to infrastructure targets and use them in access policies.

You can manage tags on targets inline when you create or edit a target or through the central Resource Tagging API. Cloudflare keeps tags in sync across both methods.

Infrastructure applications also support a target criteria model with include, require, and exclude operators. Each operator can match targets by hostname, tag, or both.

  • Include matches targets that have any of the specified values.
  • Require matches targets that have all of the specified values.
  • Exclude rejects targets that have any of the specified values.
Infrastructure application builder showing target criteria with an included tag, port 22, and SSH as the selected protocol

For more information, refer to Add an infrastructure application.

Require fresh authentication for SAML identity providers

Cloudflare Access can now request fresh authentication from a SAML identity provider for every login. Turn on Require reauthentication in the Cloudflare dashboard, or set force_authn to true through the API. Access will then set ForceAuthn to true in signed and unsigned SAML authentication requests.

This option is useful when an application requires users to reauthenticate at the identity provider instead of relying on an existing identity provider session. The default value is false.

For configuration details, refer to Require fresh authentication at the identity provider.

Discover where sensitive data goes before you create a Data Loss Prevention policy

Passive Detection for Cloudflare Data Loss Prevention (DLP) lets you learn from your Gateway traffic before deciding what to log or block. Discover the sensitive data types in sampled traffic, explore their destinations, and use the findings to build policies around your organization's needs.

The dashboard brings together detections from sampled HTTP request and response bodies. Select an entry to follow its detections over time, review destinations, and check policy coverage. You do not need a Gateway DLP policy to get these insights, and existing Gateway policies continue to apply.

Passive Detection dashboard showing detection totals, data type distribution, policy coverage, and detection entries

Passive Detection is generally available. The detection entries available to your account depend on your Zero Trust plan.

To get started, refer to the Passive Detection documentation.

Cloudflare One Client for macOS (version 2026.8.1290.1)

A new Beta release for the macOS Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

  • Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
  • Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
  • Improved API reliability by retrying requests dropped when reusing pooled connections.
  • Fixed Extra Logging failing to capture packets across all interfaces.
  • Fixed an issue that could prevent remote diagnostics from completing.
  • Fixed DNS connectivity checks failing on IPv6-only networks.
  • Fixed the client service exiting when its route-monitoring socket was closed after sleep or wake.
  • Fixed DNS enforcement checks making the client service unresponsive on systems with large routing tables.
  • Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
  • Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
  • Fixed the client continuing to report 'No network' after a successful manual disconnect.
  • Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
  • Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

  • None

Cloudflare One Client for Windows (version 2026.8.1290.1)

A new Beta release for the Windows Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

  • Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
  • Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
  • Improved API reliability by retrying requests dropped when reusing pooled connections.
  • The client no longer requires the Windows WLAN AutoConfig service to be running.
  • Implemented a service recovery mechanism backed by Windows scheduler task to start WARP service on system unlock if not already started.
  • Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
  • Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
  • Fixed the client continuing to report 'No network' after a successful manual disconnect.
  • Fixed Digital Experience Monitoring (DEX) HTTP tests failing TLS validation on Windows.
  • Fixed the client UI crashing at startup when it could not write to the Windows registry.
  • Fixed latency spikes and traffic interruptions during TPM-backed API authentication when hardware-backed registration is enabled.
  • Fixed trailing whitespace in BIOS serial numbers causing serial-number and client-certificate device posture checks to fail.
  • Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
  • Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

  • None

Improved iOS tap-to-type experience for Browser Isolation

Browser Isolation has improved the tap-to-type experience for users on iOS devices.

Previously, Browser Isolation displayed a full-screen overlay with the message tap to type when users focused a text field. The prompt now appears inline over the focused text field, reducing disruption when users enter text in isolated sessions.

If the focused text field is too small to display the full prompt, Browser Isolation displays a keyboard icon in the center of the text field instead.

Inline tap-to-type prompt over a focused text field in Browser Isolation

iOS users should tap twice to begin entering text. This update applies automatically to Browser Isolation sessions on iOS.

For more information on why this interaction is required, refer to iOS limitations.

New CASB integration for Zoom

Cloudflare CASB now integrates with Zoom. The integration connects through Cloudflare's pre-built OAuth application — no manual app setup in Zoom is required. After an initial scan, CASB continuously scans your Zoom account to surface new findings as your environment changes.

Zoom is widely used for meetings, webinars, and collaboration. Misconfigurations in account settings, meeting security controls, and recording access can expose organizations to data leakage, unauthorized access, and compliance risk. Cloudflare CASB ingests Zoom account data via API to surface security findings across these areas.

Key capabilities

Starting today, security teams can scan for security findings across the following assets:

  • Account settings — Detect weak password policies, unlocked security controls, and two-factor authentication gaps across your Zoom account
  • User accounts — Identify users not enforcing SSO, accounts with insecure host keys, unverified or inactive users, and unsafe overrides of account-level security settings
  • Meetings — Surface meetings without passwords or waiting rooms, meetings using Personal Meeting IDs (PMIs), and meetings with external domain hosts
  • Recordings — Detect publicly accessible cloud recordings, recordings without passcodes, and weak recording password configurations
  • Content — Identify sensitive information in meeting and recording content via DLP Profile matching

Learn more

This integration is available to all Cloudflare Zero Trust customers today. New customers can sign up and start with their first two integrations for free. Existing customers can enable the integration directly in the Cloudflare One dashboard under Cloud & SaaS findings > Integrations. The integration begins scanning immediately and surfaces findings in the dashboard within minutes.

Define custom applications for breakout and prioritized traffic from the Cloudflare One Appliance dashboard

You can now define custom applications for breakout and prioritized traffic on the Cloudflare One Appliance directly from the dashboard, without calling the API.

Adding a custom application by hostname, IP subnet, and source subnet from the Traffic Steering tab of an appliance profile
  • In Traffic Steering > Breakout traffic or Prioritized traffic, select Assign application traffic > Add to create a custom application matched by Hostnames, IP subnets, and/or the new Source subnets field, alongside Cloudflare-managed applications.
  • Edit or delete an existing custom application from the same panel, no API round-trip required.
  • Source subnets lets you match traffic by its source IP range, complementing the existing source LAN interface breakout criteria.

This complements the existing API and Terraform workflow for managing applications.

For details, refer to Breakout traffic and Prioritized traffic.