IP Blocking Is Broken -- What Zero Trust Actually Replaces It With

The Assumption That No Longer Holds

IP blocking was built on a reasonable assumption: a bad actor operates from a known bad location, and that location has an IP address you can identify and block. The assumption worked well enough when attackers operated from datacenters, botnets of hijacked machines, or Tor exit nodes. All of those are identifiable. All of them show up in threat intel feeds. Block the known-bad ASNs, block Tor exit nodes, block the datacenter ranges that nobody has legitimate business connecting from, and you have meaningfully reduced your attack surface.

That assumption collapsed under two developments that happened simultaneously: the rise of residential proxy networks, and the universal adoption of cloud services that forced organizations to whitelist enormous swaths of IP space they cannot effectively scrutinize.

---

How Residential Proxy Networks Broke IP Reputation

Residential proxy networks route traffic through IP addresses assigned to real residential devices by real ISPs. Comcast addresses. AT&T addresses. Vodafone addresses. The device on the other end is a phone or a router in someone's living room, and the IP shows up clean on every reputation database because it is, technically, a clean residential address. No Spamhaus listing. No datacenter ASN. No Tor exit node flag. Just a normal home internet connection.

The scale of these networks is significant. Major commercial providers advertise global pools of tens of millions of addresses with per-request rotation. An attacker can send one request from a Comcast address in Oklahoma, the next from a Verizon address in Florida, the next from an AT&T address in Oregon, cycling through fresh residential IPs indefinitely. Each individual IP has a clean history. None of them trigger your blocklists. Rate limiting fails too, because each IP may only appear once in your logs before the rotation moves on.

And it is not just opportunistic attackers using these networks. Nation-state groups and organized cybercriminal operations use residential proxy infrastructure specifically to launder their traffic and exfiltrate data, because they know it evades the IP reputation controls that most organizations still depend on as a first line of defense.

---

The Cloud CIDR Problem

The second development is something most infrastructure teams created themselves. Over the last decade, cloud adoption forced organizations to whitelist IP ranges belonging to AWS, Azure, and GCP. Your SaaS vendors, your CI/CD pipelines, your monitoring services, your third-party integrations. They all run in cloud regions that publish their IP ranges. And at some point, someone opened up those ranges in the firewall because something needed to work and the right answer was not obvious at 2am.

The attacker approach here is straightforward: spin up a VPS in the same AWS region as a service your target trusts, use that as a forward proxy, and your traffic arrives at the target from a clean cloud IP that is already whitelisted. Cloud providers do run abuse teams. They catch some of this. But as the r/sysadmin thread pointed out, cloud abuse teams are watching for malware deployments and obvious violations, not for forward proxies that could plausibly be legitimate infrastructure. And even when they act, it is reactive. Someone always takes that gamble they can score a hit before the response comes.

---

The Behavioral Paradox

Here is the part of the r/sysadmin discussion worth pulling out of the thread and into a broader conversation. One commenter noted that when someone tries to mask their IP, that specific action often triggers a flag in behavioral detection engines anyway. The harder they try to hide, the more unnatural their patterns look.

This is the core insight of behavioral detection: it does not care where the traffic comes from. It cares what the traffic does. A human user has characteristic patterns: realistic timing between actions, logical navigation paths, typing rhythm, request sequences that make sense in context. A bot running through a residential proxy pool has different patterns: mechanically regular timing, atypical navigation sequences, requests arriving in bursts followed by silence, user agents that do not match browser fingerprints.

Residential proxies solve the IP reputation problem. They do not solve the behavioral pattern problem. In trying to evade detection through IP rotation, attackers often make their behavioral signatures more distinctive, not less. The rotation itself becomes a signal.

---

What Zero Trust Actually Means Here

Zero Trust is often discussed at the architectural level: microsegmentation, least-privilege access, identity verification. But the principle has a direct and practical application to this specific problem. Never trust, always verify, and verify identity not location.

IP addresses are location data. They tell you where a connection originated, not who is making it. Zero Trust says location is not a sufficient basis for trust decisions. Identity is. A verified, authenticated identity with an appropriate access token should be trusted. A clean IP address on its own should not.

That reframe changes the control set significantly.

Identity-First Access Controls

If you are still using IP allowlists as the primary control for access to sensitive resources, replace them with identity-based access controls. Every user authenticating to internal systems should have a verified identity, strong authentication (hardware MFA where it matters), and session-level visibility. A connection from a residential proxy anywhere behind a stolen credential should fail at the authentication layer, not the IP layer. A connection from your CEO's laptop on a trusted corporate IP should still fail if the credential is invalid. One of those two controls works. One does not.

Device Trust and Posture Checks

Beyond identity, Zero Trust adds device trust: a verified identity on an unmanaged, unknown device should not be granted the same access as the same identity on a managed, compliant corporate device. Modern identity platforms (Okta, Entra ID with Conditional Access, Google BeyondCorp) enforce this at authentication time. An attacker operating from a residential proxy is by definition on an unknown device. That alone should trigger step-up authentication or access restriction regardless of whether the IP is clean.

Behavioral Analytics at the Session Level

The behavioral detection the Reddit thread describes is available in practical form through modern SIEM and UEBA tooling. User and Entity Behavior Analytics looks at session-level behavior: time between actions, request sequences, access patterns relative to the user's historical baseline, volume anomalies, geographic impossibilities. A session that navigates like a bot gets flagged regardless of whether it came from a residential IP. This is not magic. It generates false positives, requires tuning, and needs a baseline of normal behavior to measure against. But it is measurable, improvable, and works against the attack class that IP blocking cannot touch.

TLS and Protocol Fingerprinting

At the network layer, TLS fingerprinting gives you signal about what is actually making the connection, independent of source IP. When a client initiates a TLS handshake, it sends a Client Hello message containing details about its supported cipher suites, extensions, elliptic curves, and protocol version. Different software stacks produce distinctly different Client Hello profiles. A connection claiming to be Chrome 120 on Windows 11 that presents a TLS handshake profile consistent with a Python requests library is lying about what it is. That mismatch is detectable before any HTTP data is exchanged.

The original fingerprinting standard here was JA3, developed in 2017. Since 2023, major browsers began randomizing TLS extension order in their Client Hello messages, which reduced JA3's reliability for identifying specific browsers. The current standard is JA4, developed specifically to be resistant to that randomization and now supported by Cloudflare, Fastly, and other major platforms. Modern WAFs and bot management platforms perform this analysis automatically. It is not a silver bullet, but it closes a detection gap that IP blocking cannot address.

---

Where IP Blocking Still Has a Role

Discarding IP blocking entirely would be overcorrecting. There are still situations where it provides real value.

Known-malicious ASN blocking. Blocking connections from Tor exit nodes, known hostile ASNs, and documented command-and-control infrastructure still reduces noise and raises the cost for less sophisticated attackers. It is a cheap, low-maintenance control worth keeping in the stack.

Geographic access restrictions with a legitimate business basis. If your application has no legitimate user base in certain regions, geographic IP blocking reduces attack surface even knowing it is bypassable. Treat it as one signal in a layered defense, not a trust boundary.

Rate limiting at the edge. IP-based rate limiting still works against volumetric attacks where the attacker is not using residential rotation, and against unsophisticated bots that do not rotate. Pairing it with behavioral rate limiting gives you better coverage against the sophisticated cases.

The problem is not that IP blocking provides zero value. The problem is when it is treated as the primary or sufficient control. When a firewall rule allowing broad cloud CIDR ranges is the thing standing between your data and an attacker, the control is not doing what you think it is.

---

The Practical Transition

Moving from IP-centric to identity-centric access controls is not a one-sprint project. It is a direction. Here is a reasonable way to prioritize the work:

Priority	Action	What it addresses
Do this week	Audit and minimize cloud CIDR whitelists. Remove any range that cannot be justified by a current, named service dependency.	Cloud IP laundering against overly broad firewall rules.
Do this week	Enforce MFA on every external access point. Phishing-resistant hardware MFA (FIDO2 and passkeys) for privileged access.	Credential attacks arriving via clean residential IPs.
Near-term	Deploy Conditional Access or equivalent: require managed device posture for access to sensitive resources.	Unknown device attacks regardless of credential validity.
Near-term	Enable UEBA or behavioral alerting in your SIEM. Start with impossible travel and anomalous session volume detection.	Behavioral patterns that residential proxy rotation cannot mask.
Medium-term	Deploy a WAF or bot management platform with JA4 TLS fingerprint analysis for public-facing applications.	Bot traffic and credential stuffing that rotates through residential IPs.
Ongoing	Treat IP allowlists as technical debt. Document every IP-based trust rule, assign an owner, set a review cadence.	Accumulated firewall rules that expand attack surface invisibly over time.

The CIDR audit and phishing-resistant MFA are the two things that move the needle most immediately and cost the least relative to what they protect. Everything else in the table builds on those two. If you do nothing else from this article, do those two things.

The CIDR audit and phishing-resistant MFA are the two things that move the needle most immediately and cost the least relative to what they protect. If you do nothing else from this article, do those two things first.