Changelog

Cloudflare Gateway can now detect software package downloads and give you policy control over supply chain traffic. When a developer or CI/CD pipeline downloads a package through Gateway, the proxy identifies the registry protocol from the request URL and extracts the package ecosystem, name, version, and namespace. You can then write HTTP policies using pkg.* selectors to allow or block package downloads.

Gateway detects package downloads for the following ecosystems:

In the dashboard, select Package Ecosystem to access the package registry selectors. After selecting a single ecosystem, nested fields for package name, version, and namespace become available. Five pkg.* selectors are available for HTTP policies with the Allow and Block actions:

Detection is based on the registry protocol rather than the hostname, so it works the same way whether traffic goes to a public registry, a corporate proxy such as Artifactory or Nexus, or a self-hosted mirror.

Package registry security requires TLS decryption to be turned on.

For more information, refer to Package registry security.

Cloudflare Gateway now automatically detects Model Context Protocol (MCP) ↗ traffic flowing through your network. MCP is the standard protocol used by AI agents to connect to external tools and data sources. Gateway identifies MCP requests by inspecting protocol-specific headers and payload characteristics.

A new Is MCP selector (experimental.is_mcp) is available in HTTP policies. Use this selector to build Gateway rules that allow, block, or isolate MCP traffic.

This selector is currently in beta and may change before general availability.

For example, the following policy blocks MCP traffic that does not arrive through an approved MCP portal:

A new AI security report dashboard under Insights & Logs > Dashboards provides visibility into MCP usage across your organization. The dashboard includes:

• Total MCP request volume, unique users, and unique MCP servers
• A timeseries chart of unique MCP servers observed over time
• A summary of Gateway policies that target MCP traffic

For more information, refer to HTTP policies.

Gateway HTTP and Network policies now include a Traffic Source selector that identifies how traffic reaches Cloudflare. This allows administrators to write policies that target specific on-ramp methods - for example, applying different rules to traffic arriving via the Cloudflare One Client compared to traffic routed through an MCP portal or a proxy endpoint.

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

A Browser Isolation selector is also available in Network and HTTP policies. This selector identifies whether the current session is running inside Remote Browser Isolation, allowing administrators to apply different policy behavior to isolated traffic.

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

Hostname routing ↗ is now generally available. Instead of managing static IP lists and routes, you can route traffic by hostname across multiple Cloudflare One connectors:

• Cloudflare Tunnel: route a private hostname (for example, wiki.internal.local) to a private application behind your tunnel, or a public hostname (for example, bank.example.com) to egress through a specific tunnel and anchor traffic to a dedicated exit node.
• Cloudflare Mesh: attract a private or public hostname's traffic to a Mesh node.

Alongside GA, the default IPv4 range used for initial resolved IPs (also called token IPs) is changing from a Carrier-Grade NAT (CGNAT) range to a public Cloudflare-owned range:

• IPv4: 172.64.128.0/20
• IPv6: 2606:4700:0cf1:4000::/64

This is the default range. You can configure a custom initial resolved IP range for IPv4 if it conflicts with your existing network.

Why this is changing: Starting with Chrome 142 ↗, Local Network Access (LNA) restrictions block background requests to CGNAT addresses (100.64.0.0/10), which included the previous initial resolved IP default (100.80.0.0/16). LNA is implemented at the Chromium engine level, so it affects all Chromium-based browsers (for example, Microsoft Edge, Brave, and Opera), not only Google Chrome. This could silently break hostname-based Gateway features for users of these browsers, and required Chrome Enterprise policy workarounds. The new default range is public Cloudflare address space, so it is not affected by this restriction.

What is affected: Initial resolved IPs are used by several features that associate a DNS query with the network connection that follows it:

• Private and public hostname routing for Cloudflare Tunnel
• Hostname routes for Cloudflare Mesh
• Access private applications on non-HTTPS ports
• Egress policy host selectors (Domain, Host, Application, and Content Categories)

You can check your account's current range, or configure a custom range, at any time from Zero Trust > Team & Resources > Devices > Device profiles, or using the Initial Resolved IP Subnet API.

For full instructions, refer to Configure initial resolved IPs. The IPv6 range (2606:4700:0cf1:4000::/64) is unchanged and is not affected by this restriction.

If you were relying on a Chrome Enterprise policy workaround (such as LocalNetworkAccessRestrictionsTemporaryOptOut) while your account was still on the legacy CGNAT-based range, refer to Google Chrome restricts access to private hostnames for next steps.

You can now set a maximum time-to-live (TTL) for DNS responses returned by Gateway. When an upstream DNS record has a TTL that exceeds the configured maximum, Gateway caps it to your specified value. This ensures that DNS policy changes - such as blocking a newly identified malicious domain - take effect faster across all clients.

The setting is available at two levels:

• Account level - In Traffic Policies > Traffic Settings, under Proxy and inspection. This sets the default cap for all DNS locations.
• Per-location - Each DNS location can inherit the account setting, disable the cap, or override it with a custom value.

Two new fields are also available in DNS logs: upstream_record_ttls (the original TTL from the upstream response) and applied_max_ttl (the cap Gateway applied). These appear in the DNS logs column picker and in Logpush datasets.

For more information, refer to Maximum DNS TTL.

Cloudflare Gateway now supports advanced header control on Allow policies. Administrators can add, overwrite, or delete headers on matching requests using static values or dynamic variables.

Gateway HTTP policies using the Allow action support three operations in rule_settings:

Gateway applies operations in order: delete, then overwrite, then add.

Header values can include dynamic variables using the @{...} syntax. Gateway resolves variables at request time from identity, device, and network context.

You can mix static text and dynamic variables in a single header value. For example, user-@{identity.email} resolves to user-jdoe@example.com.

For more information, refer to Custom headers.

Internal DNS is now generally available. Internal DNS provides authoritative and recursive DNS for private networks on the same global network and control plane you already use for public DNS, Zero Trust, and application services.

• Consolidate DNS operations. Public and private DNS run on one platform, with one API, one audit trail, and one place to set policy.
• Simplify split-horizon DNS. Internal and external resolution are defined as separate views over shared zones, managed from a single control plane — so there is no drift to chase down.
• Extend Zero Trust to DNS. Resolver policies decide which users and devices resolve against which view, enforced by the same Gateway that already governs the rest of your traffic.

Setting up Internal DNS takes three steps: create a zone, create a view, and define a resolver policy.

POST /zones
{
  "account": {
    "id": "<ACCOUNT_ID>"
  },
  "name": "corp.internal",
  "type": "internal"
}

Internal DNS is included with Cloudflare Gateway for Enterprise customers. To get started, refer to the Internal DNS documentation.

You can now assign granular, resource-scoped roles for Cloudflare Gateway firewall policies and Zero Trust lists. Administrators can delegate access to specific policy types or list management without granting account-wide or product-wide control.

When you add a member or create a permission policy, the following resource-scoped roles are now available:

These roles allow you to:

• Grant a network engineer write access to Network policies only, without exposing DNS or HTTP policy configuration.
• Allow a security analyst to view all Gateway policies in read-only mode for auditing purposes.
• Delegate list management to a team that maintains block and allow lists without giving them access to policy configuration.

You can also now assign Resource-scoped roles. These roles are complementary to existing account-level roles, and allow you to grant access to a specific resource, like an individual Gateway policy or Cloudflare One list. Existing account-level roles continue to work. A member with the Cloudflare Gateway or Cloudflare Zero Trust role retains full access to all Gateway resources. This ensures backward compatibility for existing automation and API tokens.

• Review the resource-scoped roles on the Cloudflare role reference.
• Learn how to create permission policies that use these roles.

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.

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.

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

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

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

// 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 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.

Cloudflare Gateway now supports natural language policy creation for DNS, HTTP, and Network firewall policies. Administrators can describe the outcome they want in plain language, and Cloudflare will generate a complete policy rule that populates the policy builder form.

To create a policy with natural language, select Create with AI on any Gateway firewall policy tab. Choose a policy type, describe what the policy should do, and a fully configured rule will appear in the policy builder for review. You can edit any field before saving, or re-generate with a different prompt.

The generated policy incorporates your account context - including lists, DLP profiles, applications, and device posture checks - so that references to your existing resources resolve automatically.

A built-in feedback mechanism allows you to rate each generated policy and provide optional comments, which Cloudflare uses to improve output quality over time.

For more information, refer to Gateway firewall policies.

The Gateway Authorization Proxy and hosted PAC files are now generally available for all plan types.

Authorization proxy endpoints add an identity-aware option alongside the existing source IP proxy endpoints, using Cloudflare Access authentication to verify who a user is before applying Gateway filtering — without installing the Cloudflare One Client. Cloudflare-hosted PAC files let you create and distribute PAC files directly from Cloudflare One on Cloudflare's global network.

These features are ideal for environments where deploying a device client is not an option, such as virtual desktops (VDI) or compliance-restricted endpoints.

To get started, refer to the proxy endpoints documentation.

Zero Trust Network Session Logs are now generated for all traffic proxied through Cloudflare Gateway, regardless of on-ramp type. This includes traffic from proxy endpoints (PAC files) and Browser Isolation egress — on-ramps that previously did not generate session logs.

Customers who already consume the zero_trust_network_sessions dataset via Logpush or Log Explorer may see increased log volume if they use these on-ramps.

For field definitions, refer to Zero Trust Network Session Logs. For traffic analysis, refer to Network session analytics.

The new Network session analytics dashboard is now available in Cloudflare One. This dashboard provides visibility into your network traffic patterns, helping you understand how traffic flows through your Cloudflare One infrastructure.

• Analyze geographic distribution: View a world map showing where your network traffic originates, with a list of top locations by session count.
• Monitor key metrics: Track session count, total bytes transferred, and unique users.
• Identify connection issues: Analyze connection close reasons to troubleshoot network problems.
• Review protocol usage: See which network protocols (TCP, UDP, ICMP) are most used.

• Summary metrics: Session count, bytes total, and unique users
• Traffic by location: World map visualization and location list with top traffic sources
• Top protocols: Breakdown of TCP, UDP, ICMP, and ICMPv6 traffic
• Connection close reasons: Insights into why sessions terminated (client closed, origin closed, timeouts, errors)

1. Log in to Cloudflare One ↗.
2. Go to Zero Trust > Insights > Dashboards.
3. Select Network session analytics.

For more information, refer to the Network session analytics documentation.

You can now configure how sensitive data matches are displayed in your DLP payload match logs — giving your incident response team the context they need to validate alerts without compromising your security posture.

To get started, go to the Cloudflare dashboard ↗, select Zero Trust > Data loss prevention > DLP settings and find the Payload log masking card.

Previously, all DLP payload logs used a single masking mode that obscured matched data entirely and hid the original character count, making it difficult to distinguish true positives from false positives. This update introduces three options:

• Full Mask (default): Masks the match while preserving character count and visual formatting (for example, ***-**-**** for a Social Security Number). This is an improvement over the previous default, which did not preserve character count.
• Partial Mask: Reveals 25% of the matched content while masking the remainder (for example, ***-**-6789).
• Clear Text: Stores the full, unmasked violation for deep investigation (for example, 123-45-6789).

Important: The masking level you select is applied at detection time, before the payload is encrypted. This means the chosen format is what your team will see after decrypting the log with your private key — the existing encryption workflow is unchanged.

Applies to all enabled detections: When a masking level other than Full Mask is selected, it applies to all sensitive data matches found within a payload window — not just the match that triggered the policy. Any data matched by your enabled DLP detection entries will be masked at the selected level.

For more information, refer to DLP logging options.

We're announcing the public beta of Organizations for enterprise customers, a new top-level Cloudflare container that lets Cloudflare customers manage multiple accounts, members, analytics, and shared policies from one centralized location.

What's New

Organizations [BETA]: Organizations are a new top-level container for centrally managing multiple accounts. Each Organization supports up to 500 accounts and 5000 zones, giving larger teams a single place to administer resources at scale.

Self-serve onboarding: Enterprise customers can create an Organization in the dashboard and assign accounts where they are already Super Administrators.

Centralized Account Management: At launch, every Organization member has the Organization Super Admin role. Organization Super Admins can invite other users and manage any child account under the Organization implicitly. Shared policies: Share WAF or Gateway policies across multiple accounts within your Organization to simplify centralized policy management. Implicit access: Members of an Organization automatically receive Super Administrator permissions across child accounts, removing the need for explicit membership on each account. Additional Org-level roles will be available over the course of the year.

Unified analytics: View, filter, and download aggregate HTTP analytics across all Organization child accounts from a single dashboard for centralized visibility into traffic patterns and security events.

Terraform provider support: Manage Organizations with infrastructure as code from day one. Provision organizations, assign accounts, and configure settings programmatically with the Cloudflare Terraform provider ↗.

Shared policies: Share WAF or Gateway policies across multiple accounts within your Organization to simplify centralized policy management.

For more info:

• Get started with Organizations
• Set up your Organization
• Review limitations

Access authentication logs and Gateway activity logs (DNS, Network, and HTTP) now feature a refreshed user interface that gives you more flexibility when viewing and analyzing your logs.

The updated UI includes:

• Filter by field - Select any field value to add it as a filter and narrow down your results.
• Customizable fields - Choose which fields to display in the log table. Querying for fewer fields improves log loading performance.
• View details - Select a timestamp to view the full details of a log entry.
• Switch to classic view - Return to the previous log viewer interface if needed.

For more information, refer to Access authentication logs and Gateway activity logs.

Cloudflare Gateway now supports OIDC Claims as a selector in Firewall, Resolver, and Egress policies. Administrators can use custom OIDC claims from their identity provider to build fine-grained, identity-based traffic policies across all Gateway policy types.

With this update, you can:

• Filter traffic in DNS, HTTP, and Network firewall policies based on OIDC claim values.
• Apply custom resolver policies to route DNS queries to specific resolvers depending on a user's OIDC claims.
• Control egress policies to assign dedicated egress IPs based on OIDC claim attributes.

For example, you can create a policy that routes traffic differently for users with department=engineering in their OIDC claims, or restrict access to certain destinations based on a user's role claim.

To get started, configure custom OIDC claims on your identity provider and use the OIDC Claims selector in the Gateway policy builder.

For more information, refer to Identity-based policies.

The Gateway Authorization Proxy and PAC file hosting are now in open beta for all plan types.

Previously, proxy endpoints relied on static source IP addresses to authorize traffic, providing no user-level identity in logs or policies. The new authorization proxy replaces IP-based authorization with Cloudflare Access authentication, verifying who a user is before applying Gateway filtering without installing the WARP client.

This is ideal for environments where you cannot deploy a device client, such as virtual desktops (VDI), mergers and acquisitions, or compliance-restricted endpoints.

• Identity-aware proxy traffic — Users authenticate through your identity provider (Okta, Microsoft Entra ID, Google Workspace, and others) via Cloudflare Access. Logs now show exactly which user accessed which site, and you can write identity-based policies like "only the Finance team can access this accounting tool."
• Multiple identity providers — Display one or multiple login methods simultaneously, giving flexibility for organizations managing users across different identity systems.
• Cloudflare-hosted PAC files — Create and host PAC files directly in Cloudflare One with pre-configured templates for Okta and Azure, hosted at https://pac.cloudflare-gateway.com/<account-id>/<slug> on Cloudflare's global network.
• Simplified billing — Each user occupies a seat, exactly like they do with the Cloudflare One Client. No new metrics to track.

1. In Cloudflare One ↗, go to Networks > Resolvers & Proxies > Proxy endpoints.
2. Create an authorization proxy endpoint and configure Access policies.
3. Create a hosted PAC file or write your own.
4. Configure browsers to use the PAC file URL.
5. Install the Cloudflare certificate for HTTPS inspection.

For more details, refer to the proxy endpoints documentation and the announcement blog post ↗.

Gateway Protocol Detection now supports seven additional protocols in beta:

These protocols join the existing set of detected protocols (HTTP, HTTP2, SSH, TLS, DCERPC, MQTT, and TPKT) and can be used with the Detected Protocol selector in Network policies to identify and filter traffic based on the application-layer protocol, without relying on port-based identification.

If protocol detection is enabled on your account, these protocols will automatically be logged when detected in your Gateway network traffic.

For more information on using Protocol Detection, refer to the Protocol detection documentation.

Zero Trust has again upgraded its Shadow IT analytics, providing you with unprecedented visibility into your organizations use of SaaS tools. With this dashboard, you can review who is using an application and volumes of data transfer to the application.

With this update, you can review data transfer metrics at the domain level, rather than just the application level, providing more granular insight into your data transfer patterns.

These metrics can be filtered by all available filters on the dashboard, including user, application, or content category.

Both the analytics and policies are accessible in the Cloudflare Zero Trust dashboard ↗, empowering organizations with better visibility and control.

We have previously added new application categories to better reflect their content and improve HTTP traffic management: refer to Changelog. While the new categories are live now, we want to ensure you have ample time to review and adjust any existing rules you have configured against old categories. The remapping of existing applications into these new categories will be completed by January 30, 2026. This timeline allows you a dedicated period to:

• Review the new category structure.
• Identify any policies you have that target the older categories.
• Adjust your rules to reference the new, more precise categories before the old mappings change. Once the applications have been fully remapped by January 30, 2026, you might observe some changes in the traffic being mitigated or allowed by your existing policies. We encourage you to use the intervening time to prepare for a smooth transition.

Applications being remappedd

For more information on creating HTTP policies, refer to Applications and app types.

To give you precision and flexibility while creating policies to block unwanted traffic, we are introducing new, more granular application categories in the Gateway product.

We have added the following categories to provide more precise organization and allow for finer-grained policy creation, designed around how users interact with different types of applications:

• Business
• Education
• Entertainment & Events
• Food & Drink
• Health & Fitness
• Lifestyle
• Navigation
• Photography & Graphic Design
• Travel

The new categories are live now, but we are providing a transition period for existing applications to be fully remapped to these new categories.

The full remapping will be completed by January 30, 2026.

We encourage you to use this time to:

• Review the new category structure.
• Identify and adjust any existing HTTP policies that reference older categories to ensure a smooth transition.

For more information on creating HTTP policies, refer to Applications and app types.

Admins can now create scheduled DNS policies directly from the Zero Trust dashboard, without using the API. You can configure policies to be active during specific, recurring times, such as blocking social media during business hours or gaming sites on school nights.

• Preset Schedules: Use built-in templates for common scenarios like Business Hours, School Days, Weekends, and more.
• Custom Schedules: Define your own schedule with specific days and up to three non-overlapping time ranges per day.
• Timezone Control: Choose to enforce a schedule in a specific timezone (for example, US Eastern) or based on the local time of each user.
• Combined with Duration: Policies can have both a schedule and a duration. If both are set, the duration's expiration takes precedence.

You can see the flow in the demo GIF:

This update makes time-based DNS policies accessible to all Gateway customers, removing the technical barrier of the API.

We have added three new domain categories under the Technology parent category, to better reflect online content and improve DNS filtering.

New categories added

Refer to Gateway domain categories to learn more.