From IP Lists to Identity: A Transitional Step for Zero Trust

Moving toward Zero Trust means replacing static, network-based security assumptions with continuous validation tied to identity. In practice, that transition rarely happens overnight. For organizations that have spent years hardening access around specific IP addresses, shifting every origin to certificate-based authentication is a large undertaking. Cloudflare's answer is Aegis: dedicated egress IPs that let enterprises lock down their networks at the firewall level while they work through a longer-term Zero Trust migration.

Aegis is available through Early Access for Enterprise customers. The core idea is simple: Cloudflare reserves a small set of IP addresses that it uses exclusively for one customer's traffic. Those addresses are not shared and not publicly listed as Cloudflare egress ranges, which makes them both a practical allowlisting mechanism and a harder target for spoofing.

Why mTLS Isn't Always the First Step

Cloudflare already offers strong Zero Trust enforcement through mTLS, API Shield, Cloudflare Access, and Cloudflare Tunnel. These products ensure that only authenticated, authorized clients reach an origin. But deploying them across a large estate is not a quick project. An organization with hundreds or thousands of applications must configure each one individually, and in many cases the security team cannot even enumerate every service that needs protection. The long tail of unprotected origins remains exposed while the rollout proceeds.

Aegis addresses that gap. Instead of requiring per-application configuration, it gives an organization a single, dedicated egress IP that can be enforced at the network layer. Firewall rules can be narrowed to allow only traffic from that one address, blocking everything else regardless of application. It's a blanket protection that holds while mTLS or Access is deployed incrementally.

Consider a fictional large bank with 900 applications spread across on-premise and cloud infrastructure. A security audit halts new feature development until those applications are protected against external traffic. The bank uses Cloudflare for CDN, DDoS, WAF, and bot management, but has not implemented mTLS. Allowlisting Cloudflare's public IP ranges is not sufficient, since any Cloudflare customer could route traffic through Workers to reach the bank's services outside prescribed APIs and data flows.

Deploying mTLS to 900 services could take years. Aegis reduces the ingress surface from millions of possible source IPs to one dedicated address. The firewall before Aegis accepts traffic from broad ranges:

BLOG-1665 Embedded Image - ZJHtCB

With Aegis, the same firewall can be configured to admit only the single reserved IP:

BLOG-1665 Embedded Image - yrAuz0

The bank can resume development knowing that its endpoints are protected behind a strictly allowlisted network path until per-origin mTLS is fully in place.

Pairing Aegis with Existing Cloudflare Products

Aegis does not replace other Cloudflare security features; it complements them to add an IP-level control layer for traffic leaving Cloudflare's edge toward the customer's origin.

Access and Network Interconnect

Combining Aegis with Cloudflare Access and Cloudflare Network Interconnect (CNI) produces a fully private application access path. Access enforces authorization policies and caching at the edge. Aegis guarantees that all requests come from dedicated IPs assigned to the customer. CNI provides the private transport from Cloudflare to the customer's network, where L3 firewall policies can be applied to complete the isolation.

This setup achieves many of the same goals as Cloudflare Tunnel, which shifts protection to a daemon installed on origin-side machines. The difference is that Aegis plus CNI does not expose public endpoints the way Tunnel does, and it avoids the need to configure JWT or install daemons at each origin. A firewall policy at the network edge is easier to roll out across a large organization than per-server software.

Workers and the Developer Platform

When paired with Aegis, traffic initiated by Cloudflare Workers or other developer platform services toward a customer's endpoints will use the dedicated IPs. That allows the customer to restrict origin access to only those specific workloads. Firewall rules can be written so that only assigned Workers—not arbitrary third-party code running on Cloudflare's network—can reach protected services.

An Extra Layer While the Migration Runs

Aegis is not presented as a replacement for mTLS or a permanent endpoint security strategy. It addresses the difficult middle phase of a Zero Trust journey: protecting assets that cannot yet enforce certificate-based authentication. With dedicated, unlisted egress IPs, organizations can reduce their network attack surface immediately and close the spoofing risk that comes from broad allowlisting. Customers interested in the Early Access program should contact their account team.