Field notes · 26 October 2026 · Network and segmentation

IP address or identity: what should actually let someone in?

In plain words: Where a knock on the door comes from is a clue, not proof; who is knocking matters more, and the fence just makes the gate easier to guard. Network and segmentation, explained simply

In short

• An IP address tells you where a request came from, or at least where it last left a network. It does not tell you who is behind it. Identity answers that question, which is why access decisions have been moving towards it for a decade.
• Neither is a protection on its own. An allowlist is only as good as your knowledge of who else shares those addresses; identity is only as good as your sign-in, your sessions and your handling of the accounts nobody owns.
• My own rule of thumb: identity is the gate, the network is a fence that makes the gate easier to guard. Use addresses to shrink what can be reached, never as the reason to trust a request.

Why IP allowlists are still everywhere

Ask most teams how their admin portal, their supplier connection or their internal reporting tool is protected and the first answer is often "it is only reachable from our IP range". It is easy to see why. An allowlist is cheap, every firewall and cloud service supports it, nobody has to change the application, and it works for things that cannot authenticate at all, such as an old database, a building controller or a file transfer partner from twenty years ago.

It also does something real. A service that cannot be reached from the internet cannot be attacked from the internet. That is not nothing, and I will come back to it.

The trouble starts when "reachable only from our addresses" quietly turns into "anyone from our addresses is one of us".

Where IP addresses let you down

Addresses are shared. Behind one public address there may be a whole office, a whole home broadband customer base behind carrier-grade NAT, or every customer of a cloud provider in a region. If a supplier asks you to allowlist "our AWS range", you may be allowing anyone who can rent a server in that region. The ranges cloud providers publish change often, too, so a list copied once goes stale.

Attackers can borrow good addresses. Residential proxy networks sell traffic that appears to come from ordinary home connections in whatever country you like. When Microsoft described the Midnight Blizzard intrusion in January 2024, it noted the attackers routed their password spraying through residential proxies precisely so that their traffic came from addresses also used by legitimate users. Blocking "bad" addresses or allowing "home country" addresses does little against that.

Being inside proves very little. An allowlist trusts every device and every person behind the address. One infected laptop on the office network, one compromised VPN account, one supplier with a flat network, and the attacker inherits all of that trust. This is the lateral movement problem in a sentence, and it is why NIST's zero trust architecture says no implicit trust should be granted based solely on network location.

The edge itself becomes the target. If a VPN concentrator or a firewall is what puts people "inside", then that box is the prize. Internet-facing VPNs and management interfaces have been among the most exploited systems of the last few years, which is why CISA's Binding Operational Directive 23-02 told US federal agencies to take management interfaces off the public internet or put them behind a separate zero trust access point.

Where identity lets you down

Moving the decision to identity fixes the "who" question, but it brings problems of its own, and I think they are underplayed.

Sign-in has to resist phishing. If the identity check is a password and a text message code, it can be phished in real time. Identity-based access is only stronger than an allowlist when sign-in uses passkeys, security keys or certificates on managed devices.

Sessions outlive the check. Most identity systems judge the moment of sign-in and then hand out a token. Steal the token and you skip the sign-in entirely. Short session lifetimes, re-checking on sensitive actions and alerts on tokens used from a new device or place all matter as much as the login.

Not everything can take part. Single sign-on works well for modern web apps. Older thick clients, embedded devices, operational technology and many supplier integrations cannot speak it. Those are often exactly the systems still protected by an allowlist, and they stay that way unless someone puts an identity-aware proxy in front of them.

The identities nobody owns. Service accounts, API keys and the credentials AI agents use do not do multi-factor authentication and rarely have an owner who reviews them. I wrote about this in Identity is the perimeter, so what guards identity?: the accounts on the edge, not the main staff sign-in, are where intrusions tend to start.

One system to rule them all. Concentrating every access decision in one identity provider makes that provider, and its administrators, the most valuable target in the estate. It needs the strongest protection you have, its own monitoring and a plan for the day it is unavailable.

Internet-facing services

For anything the public uses, an allowlist is not an option: you cannot know your customers' addresses. Identity carries the load, helped by rate limiting, bot management and a web application firewall that judge behaviour rather than origin.

The interesting cases are the internet-facing services that are not for the public: admin consoles, partner portals, remote access, APIs for a handful of suppliers. Here I would use both, in this order:

1. Do not publish what does not need publishing. A management interface should not answer on the internet at all. Put it behind an identity-aware proxy or a zero trust access service, so the interface itself is not reachable until the person has signed in.
2. Require a strong identity for every request. Phishing-resistant sign-in for people; mutual TLS, signed requests or short-lived tokens for machines.
3. Add addresses as a narrowing signal. A partner API that only ever receives calls from two known, dedicated addresses can reasonably refuse everything else. That reduces noise and attack surface. It does not replace the credential check.

Internal applications

"Internal" is itself a network claim, and it is the one that has aged worst. With staff at home, applications in several clouds and suppliers connected in, the internal network is no longer a place you can point at. The question to ask of an internal application is the same as for an external one: who is allowed to use it, and how does it know?

What changes inside is the role of the network. Segmentation is still worth a great deal: it decides how far an intruder can travel after the first foothold. But the most useful segmentation rules are written about what a workload is, not what its address happens to be this week, which is the argument in Labels before rules. For traffic between services, workload identity (mutual TLS with certificates issued to each service, as SPIFFE describes) lets one service check which service is calling, so a rule can say "the payments service may call the ledger" rather than "10.4.0.0/16 may reach 10.9.2.14".

What needs to be in place

For IP-based controls to mean anything:

• You own the addresses, or know exactly who shares them. Dedicated egress for your own services; no allowlisting of a provider's whole range.
• The list has an owner, a reason for each entry and a review date. Entries for suppliers that left three years ago are a classic finding.
• It is one layer among several, written down as such, so nobody later assumes it is the authentication.

For identity-based controls to mean anything:

• One directory, with single sign-on in front of every application that can take it, and an identity-aware proxy in front of the ones that cannot.
• Phishing-resistant sign-in, at least for administrators and anyone who can move money or change access.
• Device checks, so a valid account on an unknown laptop is treated differently from the same account on a managed one.
• Session controls: short lifetimes, re-authentication for sensitive actions, and alerts on token reuse.
• An owner for every non-human identity, with managed or short-lived credentials instead of stored passwords.
• Logs that record who did what, not only which address connected. This is the part that pays off on the day you need to investigate.

So which is it?

Both, but not as equals. Network controls decide what can be reached; identity decides who may use it. When the two are confused, an allowlist ends up doing a job it was never able to do. Google's BeyondCorp work, published in 2014, made the same point by removing the privileged corporate network altogether and checking user and device on every request. Few organisations need to go that far in one step, but the direction is right.

What to do on Monday

• List the services, internal and external, whose only protection is an IP allowlist. For each, ask what an attacker on one of those addresses could do.
• Find every allowlist entry that is a cloud provider's or supplier's broad range rather than a dedicated address, and ask the supplier for something narrower or for a credential instead.
• Check that no management interface answers on the internet. If one does, put it behind an identity-aware proxy before anything else.
• Pick one internal application that people reach "because they are on the VPN" and put it behind single sign-on with a device check.

Sources

• NIST, SP 800-207: Zero Trust Architecture (2020).
• Rory Ward and Betsy Beyer, BeyondCorp: A New Approach to Enterprise Security, ;login: (December 2014).
• CISA, Binding Operational Directive 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces (June 2023).
• Microsoft Threat Intelligence, Midnight Blizzard: Guidance for responders on nation-state attack (January 2024).
• Amazon Web Services, AWS IP address ranges (documentation).
• SPIFFE, Secure Production Identity Framework for Everyone: overview (documentation).

• Earlier on this topic: Blast radius belongs in the board pack
• Later on this topic: Email was built to trust everyone: TLS, SPF, DKIM and DMARC, and what each one breaks

Follow with the feed

Personal work and my own view, not my employer's. Sources are public.