IP Allowlisting
Before identity, before certificates, before zero-trust — the first and fastest way to reduce your attack surface is to make your services unreachable to everyone except the people and systems that need them.
The Core Principle
IP allowlisting is a network-layer control that restricts which source IP addresses can connect to a service at all — before any application code runs, before any authentication is attempted. It is the bluntest and most effective first line of defence for services that don't need to be publicly accessible.
Not fine-grained, but that's the point. Entire networks of attackers are excluded before any application logic is touched.
A firewall rule or security group change takes minutes and instantly removes the service from the view of everyone outside the allowed range.
No certificates, no PKI, no identity infrastructure. A list of IPs in a security group or WAF rule is understandable by any team member.
IP filtering is not a substitute for identity — it's the outer boundary that everything else sits inside. Stage 2 (mTLS) goes inside this perimeter.
IP allowlisting doesn't prove who someone is. It proves they're in the right place. That's still enormously valuable — and it's where every enterprise should start.
entityOS Security Framework — Stage 1
How It Works
IP allowlisting is implemented at the network layer — typically as cloud security group rules, firewall policies, or WAF IP restrictions. No application changes required.
AWS Security Groups, Azure NSGs, and GCP Firewall Rules all support inbound IP restrictions at the infrastructure level. A rule denying all inbound traffic except from specific CIDRs is the foundation.
# AWS Security Group — allow only office CIDR
aws ec2 authorize-security-group-ingress --group-id sg-xxxxxxxx --protocol tcp --port 443 --cidr 203.0.113.0/24Web Application Firewalls (AWS WAF, Cloudflare, Azure Front Door) can enforce IP allowlists at the edge — before traffic even reaches your infrastructure. Effective for APIs and web services that run behind a CDN or load balancer.
# AWS WAF IP Set — allowlist rule
Type: IP_SET
Addresses:
- 203.0.113.0/24 # office
- 10.0.0.0/8 # internal VPC
- 52.x.x.x/32 # CI/CD NATThe strongest form of IP control: remove public endpoints entirely. AWS PrivateLink, VPC peering, and Azure Private Endpoints make a service reachable only from within designated private networks — no public IP exists to attack.
# RDS — disable public access entirely
PubliclyAccessible: false
VpcSecurityGroups:
- sg-internal-only
SubnetGroup: private-subnet-groupScope & Fit
IP allowlisting excels in constrained, well-defined environments. It struggles when infrastructure becomes dynamic or teams become distributed. Knowing the boundary is as important as knowing the capability.
Scenario Matrix
IP allowlisting alone — no cryptographic identity, no mTLS. Assessed against real enterprise access scenarios.
| Scenario | IP Allowlisting (Stage 1) | Coverage Level | Notes |
|---|---|---|---|
| Admin API — office only | ✓ Effective | Strong | Office CIDR + VPN IP — static, predictable |
| Database — app servers only | ✓ Effective | Strong | Private subnet, no public endpoint |
| CI/CD — fixed NAT gateway | ✓ Effective | Strong | Single known IP per pipeline |
| Webhook from SaaS provider | ✓ Effective | Strong | Provider publishes static IP ranges (e.g. GitHub, Stripe) |
| Internal API — VPC only | ✓ Effective | Strong | PrivateLink / VPC endpoint — no public route |
| Remote worker API access | ⚠ Partial | Moderate | Requires VPN with fixed egress IP — adds operational overhead |
| Autoscaling microservices | ⚠ Limited | Low | CIDR block works within known subnets; per-pod not feasible |
| Third-party partner integration | ⚠ Partial | Moderate | Only if partner has static egress IPs — often not the case |
| Lateral movement within allowed range | ✗ No protection | None | Attacker already inside CIDR — Stage 2 (mTLS) required |
Implementation
Best Practices
IP allowlisting is simple to implement but easy to mismanage. These rules keep it working as a real security control, not just a checkbox.
Allowlist rules must be in Terraform, CloudFormation, or Pulumi — never managed through the console. Manual rules become stale, undocumented, and unauditable within months.
Each allowed IP range must be annotated with: who owns it, why it's allowed, when it was added, and when it should be reviewed. Untagged entries are the most common source of allowlist sprawl.
Avoid /16 or /8 ranges unless genuinely required. A /32 (single IP) is always preferable. Overly broad CIDRs defeat the purpose of the control.
Enable VPC Flow Logs, NSG flow logs, or WAF logging for all denied traffic. Denied connection logs are your threat intelligence feed — they show who is probing your perimeter.
Staff leave, contractors finish, infrastructure changes. Every entry older than 90 days without a confirmed active use case should be removed. Build this into your security calendar.
Security group default should be 0.0.0.0/0 DENY for all inbound traffic. Allowlists only work if the baseline is denial — partial restriction leaves gaps.
Allowing a broad office /16 when only 5 machines need access exposes you to every other device on that network, including compromised ones.
An allowed IP only means the packet arrived from the right place — not that the caller is authorised. Always combine with authentication for sensitive operations.
Allowlists that only ever grow become meaningless. A contractor's home IP from two years ago is as dangerous as no allowlist at all.
If you're not monitoring denied connections, you have no visibility into who is probing your perimeter. Set alerts for sustained denial patterns.
The Road Ahead
IP allowlisting gives you a strong outer boundary. The next stages layer cryptographic identity on top — so that even traffic from allowed networks must prove who it is.
Restrict network reachability. Deny all by default. Allow only known, trusted source IPs and CIDRs. Eliminate public exposure for private services.
Layer cryptographic proof of identity on top of the network boundary. Every connection requires a valid certificate. Services prove who they are, not just where they are.
Start with IP allowlisting for every non-public service — today, before anything else. It is fast to deploy, immediately effective, and creates the outer boundary that all subsequent security layers depend on. A service with no public endpoint cannot be directly attacked from the internet.