Ask a security team whether they could restrict a published service to a known set of source addresses and the answer is almost always yes. Ask whether they do, and it is usually no.
That gap is not a gap in the technology. Allowlists were abandoned for operational reasons, and operational reasons can be fixed.
The control itself is sound
Deciding whether to answer a connection based on where it comes from is the earliest decision available. It happens before a handshake completes, before a credential is offered, before any application code runs. Nothing downstream has to be trusted for it to work, and nothing downstream has to change for it to be added.
It also fails safe in a way most controls do not.
A control that inspects a request can be wrong about the request. A control that never answers an unrecognized source has nothing to be wrong about.
The maintenance is what breaks
Here is what actually happens to an allowlist.
Somebody writes it on a Monday, accurately. It reflects the offices, the VPN egress ranges, and the handful of home addresses that were called in. By Friday a salesperson is working from an airport, two people have moved to a new broadband provider, and a contractor has started who was on nobody's list.
Each of those is a ticket. And the cost is asymmetric in the worst possible direction:
- An address left in the list too long is invisible risk that nobody is measuring.
- An address missing from the list is an outage somebody is escalating within minutes.
So the pressure runs one way. Ranges get widened rather than corrected. Entries get added and never removed. Within a few months the list either covers so much of the internet that it has stopped being a control, or it is narrow, accurate, and generating enough tickets that somebody proposes turning it off.
Why the usual workarounds do not work
Three things are commonly tried, and each trades the problem for a different one.
| Workaround | What it fixes | What it costs |
|---|---|---|
| Widen to provider ranges | Ends the tickets | Ends the control. Those ranges contain everybody, including whoever is scanning you. |
| Push everyone through a VPN | One egress address to allow | Moves the exposure to the concentrator, which now answers the internet. |
| Rely on what comes after | Nothing to maintain | MFA and monitoring engage after contact, so the exposure returns in full. |
None of these is a mistake. They are reasonable responses to a maintenance problem with no obvious answer.
The list is a snapshot of the wrong thing
Notice what the list is actually trying to express. Not "these addresses are safe" -- an address is not safe or unsafe. What it is trying to say is: people we trust are connecting from here right now.
That is a fact about people and devices, and it changes whenever somebody moves. A list of addresses is a snapshot of it, taken by hand, going out of date from the moment it is written.
Which suggests the fix is not a better list, or a better process for maintaining one. It is to derive the list from something that already knows the answer, and to keep deriving it.
If a device can attest that it is still the device you trusted, and the network it is connecting from can be observed rather than declared, then the set of trusted origins becomes a computed value rather than a maintained document. A trusted origin is the network that device is connecting from, in practice its public address, paired with the fact that the device behind it is still trusted right now.
It updates when somebody changes network, because that is what changed. Nobody files a ticket, because there is nothing for anybody to do.
What stays exactly as it is
The control at the edge does not change at all. It is the same address group your policies already reference, on the same equipment, enforced the same way. What changes is where its contents come from.
Worth being equally clear about what this is not. It does not replace authentication, authorization, or any gateway you already run. Those answer what an arrival may do. This answers whether the arrival should have been possible, which is a different question and an earlier one.
The allowlist was always the right idea. It was just asking somebody to keep a document current about a world that would not hold still.