Cloudflare One Updates & Release Notes

You can now define custom topics for AI prompt protection. Predefined AI prompt topics cover common content and intent categories such as PII, source code, and jailbreak attempts. Custom topics let you detect unique or proprietary concepts that are not included in predefined categories.

You describe a custom topic in natural language, and Cloudflare DLP detects whether a prompt matches that topic based on context rather than specific keywords. For example, a topic that describes confidential merger discussions matches a prompt that paraphrases the deal, even when the prompt never uses the word merger or names the companies involved. To detect literal values such as internal codenames or product identifiers, use a custom wordlist or pattern entry instead.

Custom topics run through the same application granular controls path as predefined AI prompt topics. Custom topics are available for ChatGPT, Google Gemini, Perplexity, and Claude.

Create a custom AI prompt topic

In the Cloudflare dashboard, go to Zero Trust > Data loss prevention > Detection entries.

Select AI prompt topics, then select Custom Prompt Topic.

Describe the topic in natural language. Be specific about the concept you want to detect. For example, describe unreleased product roadmap details or confidential customer contract terms.

Add this detection entry to an existing DLP profile, or create a new DLP profile.

Use the profile in a Gateway HTTP policy to log or block prompts that match the topic.

Note

Write the description as a concept to classify, not a list of keywords. For example, describe "internal financial forecasts and unreleased revenue figures" rather than listing specific document names.

For more information, refer to AI prompt topics.

Workers using a VPC Network binding with network_id: "cf1:network" now egress to public Internet destinations through Cloudflare Gateway.

This means your existing Zero Trust traffic policies — DNS, HTTP, Network, and egress — extend to traffic that originates from your Workers, the same way they do for WARP users today.

Worker

Calls env.EGRESS.fetch()
VPC binding ↓
Cloudflare Mesh
Bind via cf1:network
↓
Cloudflare Gateway
Policies applied:
DNS HTTP Network
↓
↗ Public Internet
Any public hostname or IP
Gateway logs DNS HTTP Network

What you get by default:

Visibility. Worker egress shows up in Gateway DNS, HTTP, and Network logs alongside your other traffic, so you can audit what your Workers are calling and when.

Enforcement. Any existing Gateway policy whose selectors match a Worker request will apply — including allow / block lists, DNS category filtering, and HTTP destination rules. If you have already blocked a category for your workforce, your Workers inherit that block.

wrangler.jsonc

{
"vpc_networks": [
{
"binding": "EGRESS",
"network_id": "cf1:network",
"remote": true,
},
],
}

wrangler.toml

[[vpc_networks]]
binding = "EGRESS"
network_id = "cf1:network"
remote = true

JavaScript

// Egress to a public destination — subject to your Gateway policies and logged
const response = await env.EGRESS.fetch("https://api.example.com/data");

TypeScript

// Egress to a public destination — subject to your Gateway policies and logged
const response = await env.EGRESS.fetch("https://api.example.com/data");

For configuration options, refer to VPC Networks. For policy authoring, refer to Cloudflare Gateway traffic policies.

Cloudflare Access now supports IdP federation, which allows organizations to share a single identity provider across multiple Cloudflare accounts.

Instead of configuring the same IdP (for example, Okta or Entra ID) separately in every account, you configure it once in a source account and share it with the other accounts in your organization. Each recipient account gets a read-only IdP connection that routes authentication back to the source account through a bridge — a hidden application in the source account that brokers the cross-account login. End users sign in with their existing IdP credentials, and each account's Access policies evaluate the resulting identity just like any other IdP login.

Key capabilities:

• One IdP, many accounts — Configure your IdP once and share it with all accounts in your organization.
• Lifecycle management — As accounts join or leave your Cloudflare organization, their IdP connections are provisioned and removed automatically — no manual cleanup required.
• Immutable recipient connections — IdP connections in recipient accounts cannot be accidentally modified or deleted.

To get started, refer to IdP federation.

Cloudflare Access now supports SAML assertion encryption for identity provider integrations. When turned on, your identity provider encrypts SAML assertions using a Cloudflare-managed certificate before sending them through the user's browser. Only Access can decrypt these assertions, protecting sensitive identity data even after TLS termination.

Without encryption, SAML assertions are transmitted in plaintext and could be visible to browser extensions or client-side malware.

SAML encryption includes built-in certificate lifecycle management:

• Automatic certificate generation: Access generates an encryption certificate when you turn on SAML encryption for an identity provider.
• Certificate rotation: Rotate certificates without downtime. The previous certificate remains valid until expiration, giving you time to update your IdP.
• PEM export: Copy the certificate in PEM format for manual upload to your IdP, or point your IdP to the SAML metadata endpoint for automatic retrieval.

To get started, refer to Encrypt SAML assertions.

When you connect third-party MCP servers through MCP server portals, you have no control over how the server author named tools or wrote descriptions. Unclear names make it harder for AI agents to select the right tool and harder for users to understand what is available.

You can now rename tools and prompts and rewrite their descriptions directly on the portal, without modifying the upstream server. For example, a tool named super_cool_tool can become search_customer_records with a description tailored to your organization.

Modified tools display a Modified label in the tools list so administrators can see which tools have been customized at a glance.

Aliases override the metadata that MCP clients receive. You can set them at two levels:

• Per portal: Applies only within a specific portal. Takes precedence over server-level aliases.
• Per server: Applies across all portals that use the server.

You can reset an alias at any time to restore the original upstream name.

For more information, refer to Tool and prompt aliases.

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

This release introduces the new Cloudflare One Client UI for macOS! You can expect a cleaner and more intuitive design as well as easier access to common actions and information. Here are some of the many things we have found our users appreciate:

• Right click context menu to access the most common client actions quickly
• Built-in captive portal login experience

Additional Changes and improvements

The client now applies DNS search suffixes configured in your device profile / network policy. Administrators can push a list of DNS search domains that the client appends to single-label queries, alongside any system-configured suffixes. See DNS search suffixes for details.

Administrators can now control which virtual networks (VNETs) are available to which users via WARP device profile settings in the Zero Trust dashboard. Previously, every VNET in the organization was visible to every device; you can now scope the VNET picker per profile so users only see the networks relevant to them. See VNET availability for details.

Added a local-file signal source for Emergency Disconnect. In addition to the existing HTTPS polling mechanism, administrators can now configure WARP to monitor for a file on disk; the presence of the file triggers an emergency disconnect even if both Cloudflare and your own infrastructure are unreachable. Either signal being asserted triggers disconnect; both must be cleared for normal operation to resume.

Added new warp-cli debug commands for interactive connection diagnosis. See Extra debug logging for details.

The local DNS proxy now supports DNSSEC passthrough. DNSSEC-signed responses are forwarded to the application intact (including DO/AD bits and RRSIG records), so applications that validate DNSSEC locally — including resolvers and the dig/drill tooling — work correctly through the client.

Added a new MDM format for organization-wide settings, including a cleaner way to configure the compliance environment (e.g. FedRAMP). The previous per-configuration approach still works, but the new format is now recommended. See the updated Cloudflare One MDM documentation for details.

Client Certificate device-posture checks now support template variables (e.g. ${serial_number}, ${device_uuid}) in the Subject Alternative Name field, matching what the documentation has always claimed. Previously only the Common Name field accepted variables, which broke posture rules that pinned identity to a SAN entry.

Fixed the in-client captive-portal browser rendering a blank "Success" page on some airline Wi-Fi networks (United inflight Wi-Fi was the reported case). The browser now reliably loads the airline's real portal page so users can complete sign-in from inside the client instead of having to open a separate browser.

Fixed an issue in proxy mode where hostnames containing underscores (e.g. ai_app.com) were rejected, breaking apps that depend on such hostnames (notably ChatGPT sandbox apps). The local proxy now accepts underscore-containing hostnames in CONNECT requests.

Known issues

Registration may hang at "Checking your organization configuration" due to IPC errors. A system reboot should resolve the error, allowing registration to proceed.

Split tunnel list configuration is not available in the new UI. Management of split tunnel entries is currently only possible via warp-cli tunnel ip and warp-cli tunnel host. UI support will be added in a future release.

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

This release introduces the new Cloudflare One Client UI for Windows! You can expect a cleaner and more intuitive design as well as easier access to common actions and information. Here are some of the many things we have found our users appreciate:

• Right click context menu to access the most common client actions quickly
• Built-in captive portal login experience

Additional Changes and improvements

The client now applies DNS search suffixes configured in your device profile / network policy. Administrators can push a list of DNS search domains that the client appends to single-label queries, alongside any system-configured suffixes. See DNS search suffixes for details.

Administrators can now control which virtual networks (VNETs) are available to which users via WARP device profile settings in the Zero Trust dashboard. Previously, every VNET in the organization was visible to every device; you can now scope the VNET picker per profile so users only see the networks relevant to them. See VNET availability for details.

Added mandatory authentication. When enabled via MDM, the Cloudflare One Client blocks all Internet traffic from the moment the machine boots until the user authenticates, closing the visibility gap on newly deployed devices and during re-authentication. See the announcement blog and documentation for details.

Added a local-file signal source for Emergency Disconnect. In addition to the existing HTTPS polling mechanism, administrators can now configure WARP to monitor for a file on disk; the presence of the file triggers an emergency disconnect even if both Cloudflare and your own infrastructure are unreachable. Either signal being asserted triggers disconnect; both must be cleared for normal operation to resume.

Added new warp-cli debug commands for interactive connection diagnosis. See Extra debug logging for details.

The local DNS proxy now supports DNSSEC passthrough. DNSSEC-signed responses are forwarded to the application intact (including DO/AD bits and RRSIG records), so applications that validate DNSSEC locally — including resolvers and the dig/drill tooling — work correctly through the client.

Added a new MDM format for organization-wide settings, including a cleaner way to configure the compliance environment (e.g. FedRAMP). The previous per-configuration approach still works, but the new format is now recommended. See the updated Cloudflare One MDM documentation for details.

Client Certificate device-posture checks now support template variables (e.g. ${serial_number}, ${device_uuid}) in the Subject Alternative Name field, matching what the documentation has always claimed. Previously only the Common Name field accepted variables, which broke posture rules that pinned identity to a SAN entry.

The UseWebView2 registry value (HKLM\SOFTWARE\Cloudflare\CloudflareWARP\UseWebView2 = y) is once again honored by the new GUI for authentication, so administrators who prefer the embedded WebView2 browser for sign-in can opt back in. This setting was effectively ignored in the previous release; the default browser was always used. This key is now also honored for re-authentications.

Fixed a crash in the authentication browser when navigating to a site that prompts for browser permissions (microphone, camera, notifications, etc.). The same fix had previously landed for the captive-portal browser; this extends it to the auth browser.

Fixed an issue in proxy mode where hostnames containing underscores (e.g. ai_app.com) were rejected, breaking apps that depend on such hostnames (notably ChatGPT sandbox apps). The local proxy now accepts underscore-containing hostnames in CONNECT requests.

Known issues

Registration authentication for devices via the integrated WebView2 browser is unavailable in this version as a temporary measure. As a result, the client will utilize the default browser on the device to complete the authentication process.

An error indicating that Microsoft Edge can't read and write to its data directory may be displayed during captive portal login; this error is benign and can be dismissed.

Registration may hang at "Checking your organization configuration" due to IPC errors. A system reboot should resolve the error, allowing registration to proceed.

Split tunnel list configuration is not available in the new UI. Management of Split Tunnel entries is currently only possible via warp-cli tunnel ip and warp-cli tunnel host. UI support will be added in a future release.

Windows ARM may prompt the user to close running applications while trying to install this version. Simply click “Ok” with the default highlighted option.

DNS resolution may be broken when the following conditions are all true:

• The client is in Secure Web Gateway without DNS filtering (tunnel-only) mode.
• A custom DNS server address is configured on the primary network adapter.
• The custom DNS server address on the primary network adapter is changed while the client is connected.

To work around this issue, please reconnect the client by selecting "disconnect" and then "connect" in the client user interface.

The Cloudflare Mesh dashboard now shows per-replica details for high availability nodes. You can see which replica is active, view each replica's Mesh IP and connection details, and manually trigger failover — all from the node detail page.

What's new

Replica tabs on the node detail page — switch between replicas to see each one's Mesh IP, edge data center, origin IP, platform, version, and uptime.

Active/passive badges identify which replica is currently routing traffic.

Manual failover — promote a passive replica to active with a single click. The previous active replica switches to standby.

HA badge in the overview table identifies nodes running multiple replicas.

Active replica IP shown in the overview table — the dashboard now resolves which replica is active and displays the correct Mesh IP.

Manual failover

To manually promote a passive replica:

In the Cloudflare dashboard, go to Networking > Mesh.

Select an HA-enabled node.

Select the passive replica tab.

Select Promote to active and confirm.

Traffic reroutes to the promoted replica immediately. Refer to High availability for details on failover behavior.

Cloudflare Gateway policy selectors which support regular expressions can now be authored in the dashboard using natural language.

When building a policy with a regex-based selector (like matches regex), you can describe what you want to match in plain English and the Cloudflare Agent will generate and validate a corresponding regular expression.

To get started, select a regex-compatible selector in the Gateway policy builder and select the icon. You'll see an input field for natural language, such as "any URL starting with /api/v1" or ".com, .net, and .app hosts which contain gooogle in the host."

You can also use the tool to explain existing regular expressions. If a policy already contains a regex pattern, you can instantly generate a plain-language description.

A built-in feedback mechanism allows you to rate each interaction to help improve output quality over time.

For more information, refer to Cloudflare One firewall policies and expect to see the same functionality supported soon in Data loss prevention profiles.

Starting with cloudflared version 2026.5.2, Cloudflare Tunnel automates the entire connectivity pre-checks workflow directly inside the binary. Previously, customers had to install dig and netcat and run those commands by hand to verify their environment. Now cloudflared does it natively at startup — and surfaces actionable remediation when something is blocked.

On every cloudflared tunnel run (and cloudflared tunnel diag), the binary now natively checks:

• DNS resolution — region1.v2.argotunnel.com and region2.v2.argotunnel.com resolve to valid Cloudflare IPs.
• Transport connectivity — outbound UDP (QUIC) and TCP (HTTP/2) on port 7844.
• Management API — outbound TCP/443 to api.cloudflare.com for software updates.

Results are printed in a scannable CLI table with three states:

• ✅ Pass — the check succeeded.
• ⚠️ Warn — a non-blocking issue, for example the Management API is unreachable so automatic updates will not work, but the tunnel will still come up.
• ❌ Fail — a blocking issue, with a specific remediation hint (for example, Allow outbound UDP on port 7844).

If DNS is unresolvable, or both UDP and TCP fail on port 7844, cloudflared exits early with the failure rather than looping on opaque failed to dial errors.

Pre-checks now run automatically on every start, which also catches regressions like overnight firewall policy changes — no need to remember to rerun the troubleshooting guide.

To get the new behavior, upgrade cloudflared to version 2026.5.2 or later. For more details, refer to the Connectivity pre-checks documentation.

Network Analytics is now fully supported for accounts using Unified Routing mode. Traffic that traverses Unified Routing onramps and offramps is now visible in Network Analytics with the same dimensions and filters as traffic on the standard data plane.

This closes a parity gap for customers who had moved tunnels onto Unified Routing and lost visibility into their dataplane traffic in the Network Analytics dashboard. No configuration change is required — analytics data is collected automatically for all accounts with Unified Routing enabled.

For the remaining beta limitations, refer to Traffic steering beta limitations.

New Magic Transit and Cloudflare WAN accounts are now assigned a single IPv4 anycast address by default.

Cloudflare handles failures on its network automatically by advertising your endpoint IP from multiple nodes across many globally distributed data centers. To handle failures on your network, configure two tunnels from separate routers.

To request additional anycast IP addresses for your account, contact your account team.

For tunnel configuration guidance, refer to Configure tunnel endpoints for Cloudflare WAN or Configure tunnel endpoints for Magic Transit.

You can now scope Cloudflare permissions to individual Cloudflare Tunnel instances and Cloudflare Mesh nodes. Administrators can delegate access to specific Tunnels or Mesh nodes without granting account-wide control over private networking.

What is new

When you add a member or create a permission policy, the resource picker now lists Cloudflare Tunnel instances and Cloudflare Mesh nodes as scopable resource types. You can:

• Grant a read-only role on a single Cloudflare Tunnel instance to a support operator for log streaming and diagnostics — without exposing other Tunnels or destructive actions.
• Grant a write role on a specific Cloudflare Mesh node to an application team — without giving them access to the rest of your private network.
• Scope a single policy to one or many Tunnels and Mesh nodes at once.

How it works

Granular permissions are a parallel layer to existing account-level roles — they do not replace them.

Existing account-level roles continue to work. A member with Cloudflare Access or Cloudflare Zero Trust retains write access to every Tunnel and Mesh node in the account. This ensures backward compatibility for existing automation and tokens.

Granular permissions are additive. For any API request on a specific Tunnel or Mesh node, access is granted if the principal has either the account-level role or a granular permission for that resource.

Resource enumeration is authorization-aware. Listing endpoints (GET /accounts/{id}/cfd_tunnel, GET /accounts/{id}/warp_connector) return only the resources the principal has at least read access to.

Get started

Configure granular permissions for Cloudflare Tunnel.

Configure granular permissions for Cloudflare Tunnel and Cloudflare Mesh in Cloudflare One.

Review the resource-scoped roles on the Cloudflare role reference.

Cloudflare Access now supports using Cloudflare itself as an identity provider. If you publish an Access application and select Cloudflare as the login method, users can sign in with their existing Cloudflare account — no one-time PINs, no third-party IdP configuration, and no shared email inboxes. Authentication is backed by Cloudflare's own account security (including multi-factor authentication), making it both simpler to set up and more secure than OTP-based login for most use cases.

Cloudflare is now the default identity provider for all newly created Zero Trust accounts, replacing One-time PIN.

This also enables two new capabilities:

• Cloudflare Account Member selector — A new policy selector that matches users based on their membership in a Cloudflare account. You can target the current account or specify a different account ID for cross-account access scenarios.
• Restrict to account members — An identity provider configuration option that limits authentication to users who are members of your Cloudflare account.

To get started, add Cloudflare as an identity provider in your Zero Trust settings.