Securing Hosted Apps Without Server-Side Changes
Cloudflare Access has long let organizations enforce Zero Trust policies on hosted applications by verifying user identity before a request reaches the app. Acting as a proxy in front of a hostname, Access can check identity, device posture, hardkey MFA, and more — no SSO or authentication logic needs to be baked into the application itself.
But enforcing at the hostname level leaves a gap: the origin server's IP address. Anyone who discovers that IP can bypass Access and talk directly to the application. Two established mitigations exist, each with tradeoffs.
Cloudflare Tunnel
Cloudflare Tunnel creates an outbound-only connection from the origin to Cloudflare, so no origin IP is exposed. The catch: a daemon must be installed in the origin's network.
JWT Validation
Access issues a JWT after successful authentication; application code can then validate the token on every inbound request. Signature-based verification makes spoofing difficult, but modifying legacy application logic is often impractical or impossible.
A New Path: CNI and Aegis
Cloudflare now offers a way to block origin-IP bypass without any installed software or code changes. The approach combines Cloudflare Network Interconnect (CNI) with Cloudflare Aegis. With these in place, the only required configuration is an IP allowlist rule on the origin — Cloudflare guarantees all traffic from that address has passed through Access and other security layers like DDoS protection and the Web Application Firewall.
This differs from a traditional VPN-based IP allowlist. Even though access control is enforced at the network layer, Zero Trust policies still apply to every inbound request. Cloudflare also ensures the Aegis IP cannot be used by anything other than Cloudflare services.
Why the Network Path Matters
An application secured by Access can have its hostname pointed to a Cloudflare Tunnel, a load balancer, or a direct IP. The network path between Cloudflare and the origin, however, varies. Cloudflare Tunnel assumes the public Internet and encrypts traffic accordingly — secure, but still traversing a network many organizations prefer not to expose their services to at all.
CNI provides a completely private path from Cloudflare to your infrastructure. Instead of relying on encryption over a shared network, the connection itself is dedicated. Combined with Access, you get protected application access over a private link. Aegis adds a dedicated IP that lets you apply network-level firewall rules, effectively airgapping the solution: no traffic reaches the application unless it comes from Cloudflare-protected Access calls originating from that specific IP.
Even a request that somehow reaches the application over the CNI would be blocked by the firewall if it did not traverse Access. This yields security at both Layer 7 (application) and Layer 3 (network).
Infrastructure Overview
Cloudflare Network Interconnect lets organizations connect their on-premises or cloud infrastructure directly to Cloudflare's network. Cloudflare peers directly with over 11,500 networks and is present in more than 285 cities, creating ample opportunity for low-latency private interconnection.
Aegis provides a reliable, static IP address for Cloudflare-originated traffic destined for your infrastructure. Because the IP is bound to a specific account, you can confidently configure your origin to verify that all inbound requests come from that known address.
Availability
Access, Cloud CNI, and Aegis are generally available to all Enterprise customers. Organizations interested in protecting private applications without additional server-side software or code should contact their account team to enable the feature set.
