The problem
Why port scanning is not enough to minimize attack surface
Traditional infrastructure hardening focuses on scanning IP ranges to close unused ports. This provides an incomplete picture. In most enterprise environments, asset inventories are compromised by forgotten subdomains, temporary staging environments accidentally exposed to the public Internet, and stale firewall rules.
Published measurements show the limits of that approach.
- Exploitation of a vulnerability is now the leading initial access vector for breaches: 31%, up from 20% the previous year, ahead of credential abuse which has fallen to 13% (Verizon, 2026 Data Breach Investigations Report, figure 10, n = 20,023).
- Remediation is not keeping pace: 26% of critical vulnerabilities in the CISA Known Exploited Vulnerabilities catalogue were fully remediated in 2025, down from 38% a year earlier, with a median 43 days to full resolution (same source).
- Remote access has become a commodity: 44% of the connection types resold by initial access brokers are VPN, followed closely by a remote desktop application (same source, figure 49).
- Direct Internet exposure of administration tooling remains widespread: 26% of organisations leave a MySQL database reachable from the Internet, 16% a Postgres database, 8% a phpMyAdmin instance, and 60% at least one web administration panel (Intruder, 2026 Attack Surface Management Index, 3,000 organisations over twelve months).
To minimize attack surface effectively and permanently, organisations must go beyond stacking firewall rules. You have to remove an attacker's ability to reach origin servers directly. As long as a public IP address responds to inbound TCP handshakes, the infrastructure remains vulnerable to edge security bypasses.
The framing
The three exposure layers: origin, exposed assets, and inventory
Structured attack surface reduction on Cloudflare operates across three distinct operational layers.
01
The origin infrastructure
Physical servers, cloud instances and container clusters hosting backend application logic and databases.
02
Intentionally exposed assets
Public endpoints, meaning web applications and APIs, that must remain reachable by legitimate users and clients.
03
Continuous visibility
The ability to audit configured assets and confirm that exposed entry points stay properly protected over time.
Origin lockdown
Three levels of origin lockdown
If an attacker discovers an origin server's public IP address, they can strike it directly. Edge protections, including WAF, DDoS mitigation and Bot Management, are completely bypassed. Progressive origin lockdown removes this vector.
Level 1: restrict IP ranges (network ACLs)
This level restricts origin firewall rules, via iptables, AWS Security Groups or Azure NSGs, to accept traffic exclusively from Cloudflare IP ranges, automated from the official ips-v4 and ips-v6 feeds.
Limitation: any other Cloudflare tenant can still send traffic to your origin IP address through the Cloudflare edge. Isolation between tenants is not enforced at this layer. In practice, an attacker opens an account, declares your IP address as the origin of their own zone, and their traffic reaches you from a range you allow, without passing through your WAF rules, because it is not your zone carrying them.
Level 2: network ACLs and Authenticated Origin Pulls (mTLS)
Level 2 combines network ACLs with authenticated origin pulls using a custom mTLS client certificate unique to your Cloudflare zone, validated by your web server through NGINX ssl_client_certificate and ssl_verify_client on. The encryption mode has to be set to Full (Strict) on the Cloudflare side, otherwise the chain is not verified end to end.
Benefit: authenticated origin pulls block inter-tenant abuse. Only traffic routed through your specific Cloudflare zone is accepted by the origin.
Limitation: the origin still maintains a publicly routable IP address, so it continues to appear in scan results and vulnerability advisories.
Level 3: Cloudflare Tunnel (zero inbound ports)
The cloudflared daemon runs directly on the origin host, establishing outbound-only connections to the Cloudflare edge over QUIC by default, falling back to HTTP/2, with several concurrent connections for availability. The host requires no public IP address and listens on zero inbound ports. The same tunnel can publish routes to your private ranges (RFC 1918), which is how Cloudflare Access and the Cloudflare One Client reach internal resources with no route existing on the public Internet.
Benefit: Cloudflare Tunnel security eliminates the inbound network attack surface entirely. Origin hosts become invisible to Internet port scans.
The matrix
Protection matrix: what remains exposed and the corresponding products
Eliminating direct network exposure does not make an application immune to attack. Legitimate traffic still traverses the tunnel. WAAP filters what arrives; attack surface reduction ensures there is nowhere to arrive.
What remains exposed, and what takes over
Every product stays at the function its documentation describes. No row extrapolated.
| Exposure vector | Closed by Tunnel? | Cloudflare product taking over |
|---|---|---|
| Port scanning on the public IP | Yes | No additional product required |
| Direct origin bypass attacks | Yes | Authenticated origin pulls (if a public IP remains) |
| Application-layer HTTP/HTTPS DDoS | No | DDoS Protection, Smart Shield |
| Volumetric L3/L4 DDoS attacks | No | Magic Transit, with Network Flow for detection |
| OWASP web vulnerability exploitation | No | WAF, managed rulesets, virtual patching |
| Brute-force attacks and credential stuffing | No | Rate Limiting |
| Automated bot traffic | No | Bot Management, Turnstile |
| API abuse and schema violations | No | API Shield |
| Client-side malicious scripts | No | Page Shield (PCI DSS 6.4.3 and 11.6.1) |
| Non-HTTP protocols (SSH, RDP, arbitrary TCP) | Partially | Spectrum, Cloudflare Access |
| Exfiltration of sensitive data | No | Data Loss Prevention (DLP) |
| Outbound email domain spoofing | No | DMARC Management |
That inspection layer is covered in detail in the managed WAAP use case. Staying online under volumetric attack is the subject of the DDoS mitigation services playbook.
Two modes
Public route vs private route: one architecture, two behaviours
A cloudflared connector transports traffic without inspecting payloads. A single origin server can host both public and private routes through the same tunnel connector, enforced by entirely different security controls.
| Feature | Public route | Private route (ZTNA / SASE) |
|---|---|---|
| Target audience | All Internet users, customers and prospects | Designated employees and contractors |
| Edge authentication | None, publicly accessible | Mandatory, identity provider plus posture check |
| Supported protocols | HTTP / HTTPS | HTTP, SSH, RDP, databases, arbitrary TCP |
| Security controls | WAF, Bot Management, API Shield | Cloudflare Access and Zero Trust policies |
| Internet visibility | Domain resolves publicly | Authentication barrier, resource hidden |
| Client requirement | Standard web browser | Web browser or Cloudflare One Client |
| Scope of use case | Covered on this page | Covered in ZTNA solutions |
In both modes, the origin's inbound network surface is closed identically. The operational difference lies in what guards the gateway once traffic enters the tunnel: public routes rely on application inspection, while private routes require identity verification before the resource is reached.
Private routes belong to the wider architecture, managed SASE on Cloudflare One.
The inventory
Configuration audit with Cloudflare Security Center
Attack surface monitoring requires continuous tracking of configuration drift across your account.
Cloudflare Security Center, through its Security Insights module, evaluates the configurations declared across your Cloudflare tenant, including DNS records, SSL/TLS settings, WAF rules and Access policies.
Security Insights alerts on specific external attack surface risks.
Dangling A / AAAA / CNAME records
DNS entries pointing to a resource or address you may no longer control, exposing the domain to subdomain takeover.
Unproxied A / AAAA / CNAME records
DNS entries resolving directly to an origin IP without proxying through Cloudflare. The documentation puts it plainly: Cloudflare cannot protect that origin, because it is exposed to the public Internet.
Unprotected Cloudflare Tunnels
Applications served by a Cloudflare Tunnel but lacking an associated Cloudflare Access policy, which flags private resources accidentally published without identity checks.
Security Insights is not an external crawler scanning the whole public Internet. It provides an authoritative configuration audit of your declared Cloudflare footprint. A server stood up on a cloud account IT does not know about will not appear in it.
The boundary
Platform boundaries and endpoint integration
An effective security posture requires clear boundary definitions. Cloudflare secures transit and access control, but it does not manage host-level systems engineering. The platform does not perform:
- operating system or application-level patch management;
- local privilege management or privileged access management (PAM);
- host middleware and web server hardening;
- endpoint detection, antimalware or host-based incident response (EDR/XDR).
Connecting Cloudflare to endpoint security
While Cloudflare does not replace an EDR or MDM solution, it integrates directly with them. Through Cloudflare One posture checks, Cloudflare Access policies query third-party endpoint agents, including CrowdStrike, SentinelOne, Microsoft Endpoint Manager, Tanium, Uptycs, Workspace ONE and Kolide, with a custom integration path also available.
An Access policy can therefore deny access to an internal application if the endpoint agent reports an elevated risk score or a missing security client. The tool Brixio does not operate becomes a condition inside the rule Brixio does operate. In the same way, your Cloudflare logs reach your SIEM through Logpush.
Those providers are named because they appear in Cloudflare's integration documentation. This is not a purchase recommendation.
The operator
Brixio: assessment and continuous operation
Brixio operates as a Cloudflare-only partner to design, lock down and maintain your origin infrastructure.
Initial attack surface assessment
- Non-intrusive evaluation of exposed origin IPs, DNS configurations, certificate chains and potential origin bypass vectors.
Zero-inbound migration
- Deployment of Cloudflare Tunnel connectors and mTLS certificate validation without service interruption.
Managed operations
- Ongoing WAF tuning, periodic Security Center reviews, and lifecycle management for Zero Trust access policies.
Coordination at the boundary
- Advice on which category to bring in, the criteria to choose it on, and how it articulates with the Cloudflare plan, then coordination with the team or provider that operates it.
This runs on Brixio's standing posture
Cloudflare
Authorized Service Delivery Partner (ASDP)
Cloudflare only
no other vendor in delivery
ISO 27001:2022
certified
4 hubs
Luxembourg · Paris · Dubai · Singapore