What Is IP Allowlisting?

IP allowlisting restricts access to a service so that only connections from approved source addresses are accepted. A firewall, load balancer, or application checks the address a connection arrives from against a list of permitted addresses or ranges, and accepts or rejects the connection accordingly.

It is a common control for admin panels, internal APIs, and business applications that should only be reachable from known offices or partner networks. It is also one of the simpler controls to misconfigure, because the address a service sees is not always the address you expect.

How does IP allowlisting work?

An administrator configures a list of addresses or CIDR ranges considered trusted. Cloud platforms expose this as a firewall construct: AWS security groups and Google Cloud firewall rules both let you permit inbound traffic only from specified source ranges.

When a connection arrives, the enforcing device reads the packet’s source address and compares it against the list. A match is allowed through to the next check; everything else is dropped or rejected before it reaches the application.

What does an allowlist actually check?

Only the source address on the arriving packet. It does not inspect who is using the device behind that address, what credentials they hold, or whether the traffic is legitimate. A rule matching 203.0.113.10 permits anything arriving from that address, including a compromised device on the same network.

Treat allowlisting as one layer, paired with authentication that identifies the actual user or service.

Why does IP allowlisting break in practice?

Two everyday network behaviors undermine a naive allowlist.

The first is NAT. Devices behind a shared gateway all appear to the outside as one translated address. Our NAT guide explains the mechanism; the consequence here is that allowlisting a partner's office network means allowlisting whatever address their gateway happens to present, not the individual employee's machine.

Carrier-grade NAT, or CGNAT, compounds this. A mobile or residential ISP can share one public address across many unrelated customers using the shared address space defined in RFC 6598. Allowlisting a CGNAT address you observed once can inadvertently permit other customers on the same provider, and the address you observed may not even belong to the same customer next time you check.

The second is dynamic assignment. An address that is not fixed can be reassigned to a different customer after the original one releases it. See Static vs Dynamic IP Addresses for how that reassignment happens. An allowlist entry written against a dynamic address can quietly stop matching the intended party and start matching someone else.

Allowlisting is not authentication

An address identifies a network path, not a person. It can be shared by many users, reassigned over time, or in some attack scenarios spoofed at the network layer. Relying on source address alone to establish identity conflates a routing detail with an identity claim.

Use allowlisting to narrow where connections may originate, and pair it with the application's own authentication: credentials, tokens, or mutual TLS, depending on the service. An approved address should reduce the attack surface, not replace proof of who is connecting.

What is a stable egress address, and why does a partner ask for one?

A partner enforcing allowlisting on their side needs a source address that will not change. This is typically a dedicated outbound (egress) address: one address reserved for your organization's outgoing connections, rather than a shared or dynamically assigned one. Our dedicated vs shared IP guide covers this exclusivity model, and Cloudflare's dedicated egress IP documentation describes a managed version of it.

Before sending a partner an address to allowlist, confirm it is the address they will actually see, not an internal or NAT’ed address upstream of the real gateway.

How does this relate to BYOIP?

Organizations that bring their own IP address space keep the same public addresses when they change infrastructure providers. That matters directly for allowlisting: a partner's rule referencing your address range does not need to be updated every time you migrate cloud providers or move workloads, because the address itself has not changed. Our BYOIP introduction covers how that portability works.

Without BYOIP, migrating providers commonly means adopting a new address range, which means every partner allowlist referencing the old range has to be reissued, often on a schedule you do not control.

A practical checklist before relying on an allowlist

1. Confirm the address a partner actually sees. Ask them to log or report it rather than assuming it matches your internal configuration.
2. Prefer a dedicated, static range over a single observed address. A single dynamic address is fragile; a documented range under your control is not.
3. Document the CIDR ranges you send to each partner, and review them when infrastructure changes.
4. Combine with authentication. Do not treat address matching as sufficient proof of identity on its own.
5. Re-verify after a migration. Confirm the new egress address matches what every partner has on file before decommissioning the old one.

FAQ

Related resources