An IP allowlist is a network access control that permits connections only from an explicit list of approved IP addresses or address ranges and denies every other source by default. In network security it is one of the simplest ways to shrink an attack surface: an administrative interface, database, API or SSH service that answers only a handful of known networks is invisible to the rest of the Internet.
The older term IP whitelist means the same thing; allowlist is now the preferred wording in standards and vendor documentation. The opposite approach is a blocklist, which permits everything except listed addresses. An allowlist follows the principle of default deny, which makes it far stronger as a protective control.
How an IP allowlist works
An allowlist is evaluated against the source IP address of each incoming connection, usually when the first packet or the TCP handshake arrives. If the address matches an entry, the connection proceeds to the next layer of checks; if not, it is dropped or rejected before the protected service processes any data.
Entries are normally written in CIDR notation, so a single line can cover one host or a whole network. Because modern hosts often have both IPv4 and IPv6 addresses, an allowlist that covers only one protocol can either lock out legitimate users or, if the other protocol is unfiltered, leave a gap for attackers.
| Entry | Covers | Typical use |
|---|---|---|
| 203.0.113.10/32 | One IPv4 address | A single office gateway or bastion host |
| 198.51.100.0/24 | 256 IPv4 addresses | A partner’s or data center’s public range |
| 2001:db8:1200::/48 | One IPv6 site allocation | An organization’s IPv6 network |
| 10.20.0.0/16 | A private internal range | Access from internal networks only |
Where IP allowlists are enforced
An allowlist can be enforced at several layers, and the choice determines how early unwanted traffic is stopped and who can maintain the list. Enforcing it as close to the network edge as possible keeps unwanted traffic away from the application entirely.
| Enforcement point | Examples | Strength | Limitation |
|---|---|---|---|
| Network firewall or ACL | Perimeter firewall, router access lists, network ACLs | Stops traffic before it reaches servers | Changes often need the network team |
| Cloud security group | Instance or load balancer rules | Managed with infrastructure code | Must be kept consistent across regions |
| Host firewall | nftables, Windows Defender Firewall | Protects even inside a flat network | Must be maintained on every host |
| Web server or proxy | Reverse proxy rules, web application firewall | Can allow per path or per application | Must see the real client address |
| SaaS or application setting | Admin console IP restrictions | No infrastructure needed | Scope limited to that application |
When a service sits behind a proxy, load balancer or CDN, the address the server sees is the proxy’s, not the client’s. The allowlist must then be enforced at the proxy, or the server must trust a forwarded client address header only from known proxies; otherwise an attacker can simply forge that header.
IP allowlists compared with other access controls
An IP allowlist answers only one question: where does the connection come from? It says nothing about who the user is or whether the device is healthy, which is why it is compared with richer controls.
| Control | Decision based on | Main advantage | Main weakness |
|---|---|---|---|
| IP allowlist | Source address | Simple, fast, cheap to run | Network location is not identity |
| IP blocklist | Known bad addresses | Blocks known abuse sources | Misses every new attacker |
| VPN with authentication | User credentials, then network access | Encrypts and authenticates remote users | Grants broad network access once connected |
| Zero trust network access | User identity, device posture and context | Per-application, per-session decisions | More complex to deploy |
| Mutual TLS | Client certificates | Strong cryptographic identity of machines | Certificate lifecycle management |
In modern architectures, allowlisting is best treated as one layer of defense in depth. A common combination is an allowlist for service-to-service traffic between fixed addresses, plus identity-based controls for people, who move between networks constantly.
Designing and maintaining an allowlist
The value of an allowlist depends almost entirely on how carefully it is maintained. A list that grows without review gradually becomes a long record of forgotten exceptions.
- Keep entries as narrow as possible: a /32 for one gateway is better than a /24 that includes unknown neighbors.
- Record an owner and a reason for every entry, ideally with an expiry or review date.
- Manage the list as code in version control, so changes are reviewed and reversible.
- Cover IPv4 and IPv6 consistently for every exposed service.
- Prefer stable addresses: use static egress IPs or NAT gateways for partners and cloud workloads.
- Log denied connections to detect both attacks and legitimate users who were left out.
Cloud providers and SaaS vendors often publish the address ranges of their services and change them over time. Allowlists that depend on such ranges should be updated automatically from the provider’s published data rather than copied by hand once.
Limitations and common mistakes
The fundamental limitation of an IP allowlist is that an IP address is not a strong identity. Many users can share one address, and the same user changes address constantly.
- Shared addresses: allowing a CGNAT, mobile carrier or public cloud range admits thousands of unrelated parties.
- Dynamic addresses: home and mobile users change IPs, which leads to frequent exceptions and pressure to widen the list.
- Compromised allowed hosts: an attacker on an allowed machine or network passes the check automatically.
- Spoofing assumptions: spoofed sources cannot complete a TCP handshake, but UDP services remain exposed to spoofed requests.
- False confidence: services behind an allowlist still need authentication, patching and encryption.
The safe rule is to treat a match on the allowlist as permission to try, never as proof of identity. Strong authentication must still follow.
In simple terms
An IP allowlist works like a guest list at the door of a private event. The doorman does not care who you claim to be; he checks whether your name is on the list, and if it is not, you do not get in.
On a network, the name is the address the connection comes from. Only connections from approved addresses can even knock on the door of the protected system. It keeps most strangers out very cheaply, but anyone who gets onto an approved network can still reach the door, so a second lock is always needed.
A practical example
An online retailer hosts its customer database in a public cloud. A security review finds that the database’s management port is reachable from the entire Internet and receives thousands of automated login attempts every day, although only the application servers and two administrators need it.
The team changes the cloud security group to a default-deny allowlist: the application servers’ private subnet, plus the /32 address of a bastion host used by administrators. Administrators now connect to the bastion with SSH keys and multi-factor authentication, then reach the database from there. After the change, the external login attempts disappear from the database logs entirely, and the attack surface shrinks to one hardened bastion host.