IP allowlisting is an access rule that accepts connections only from a list of approved IP addresses and rejects everything else. It is also called IP whitelisting, and it is one form of IP access control. It works well for fixed offices, servers, and API integrations. It works poorly for remote staff, and it never replaces logins and multi-factor authentication. This guide explains how it works, how to set it up without locking out real users, and how an insurance agency should think about it when choosing software that holds client data.
TL;DR
- An IP allowlist permits listed addresses or address ranges and denies all other traffic by default.
- It suits fixed locations, servers, and system-to-system connections, such as an API that should accept requests from only a few known hosts.
- It does not verify who the user is. IP addresses can be spoofed, and a known address is not automatically a trusted one.
- Setup comes down to finding the correct public IP, adding it as a single address or CIDR range, testing from every expected environment, and keeping the list current.
- Agencies should treat it as one layer next to strong passwords, multi-factor authentication, and role-based access in their CRM.
Table of Contents
- What IP allowlisting is
- How IP access control works
- Common uses
- How to set up and maintain an IP allowlist
- Limits of IP allowlisting
- Best practices for IP access control
- When allowlisting fits an insurance agency
- Perspective: how we see allowlisting
- Software for agencies that handle client data
- FAQ
- Sources
What IP allowlisting is
An allowlist is a list of approved items. Depending on the system, the items can be email addresses, IP addresses, domain names, or applications. Anything not on the list is denied. TechTarget describes an allowlist as approving specified entities while denying all others, and notes that administrators apply allowlists to network appliances, servers, desktop software, or operating systems. Requests are then checked against the approved list.
IP allowlisting applies that idea to the source address of a connection. If a request arrives from an address on the list, it proceeds. If it arrives from any other address, it is stopped before a person or program gets a chance to log in.
The older term is whitelisting. Many vendors and security teams now say allowlisting. The two mean the same thing, and both appear in product settings and documentation.
Allowlist and blocklist
A blocklist works the other way. It denies listed addresses and permits everything else. A blocklist is easy to start but never complete, because new addresses appear constantly. An allowlist is stricter: access is closed unless it has been opened on purpose. That default is the reason the method is used for sensitive systems.
How IP access control works
IP access control is usually built from an access control list, or ACL. Microsoft Learn explains that an IP-based ACL is a set of criteria and actions. The criteria can match IP addresses and ports. The actions either permit or deny the traffic. The same page states that an ACL can list the addresses allowed to traverse a network and block the others, with policy applied to both addresses and ports.
Three details explain most real-world behavior.
- Rules are checked against the source of each request. The system reads the address the request came from and compares it with the list.
- Unlisted traffic is denied. Cisco documents an implicit deny at the end of an ACL, so traffic that is not explicitly permitted is dropped.
- Placement matters. The same Cisco guide says an ACL has no effect until it is applied to a router interface, and recommends applying it as close to the traffic source as practical.
A single address, such as one office connection, and a block of addresses are both valid entries. Blocks are written in CIDR notation, for example a base address followed by a slash and a prefix length. A larger prefix number means a smaller block.
How it relates to firewalls
An allowlist and a firewall are not the same thing, but they overlap. A firewall controls traffic between networks or hosts with different security policies. According to a NIST bulletin on firewalls, packet filters use network-layer rulesets, stateful firewalls track connections, and application firewalls inspect higher-layer protocols. Firewalls may also be combined with routing, NAT, content filtering, and intrusion prevention.
An IP allowlist is usually one rule set inside that larger system. The firewall evaluates a broad policy. The allowlist narrows one part of it to a short list of trusted sources. For background on how filtering and access controls protect customer data on marketing and sales sites, website security basics cover the wider picture.
Common uses
IP allowlisting is most useful where the set of legitimate sources is small and stable.
- Office-only access. A business limits an admin panel or internal tool to the public address of its office network.
- Server-to-server connections. A partner system or integration is the only thing that should call a particular endpoint, so only its fixed addresses are permitted.
- API protection. OpenAI’s documentation gives a clear example. Requests from listed IP addresses or CIDR ranges are accepted, and requests from other addresses are rejected even when the API key is valid.
- Port and application limits. Microsoft notes that an IP ACL can define which applications and ports receive traffic, such as allowing web traffic to a web service, and that it can reduce risks such as denial-of-service attacks.
- Restricting devices and users. Cisco describes IP ACLs as packet filters that control which packets move through a network, which helps restrict user and device access and keeps unwanted traffic from leaving a network.
The common thread is predictability. If the same few addresses make every legitimate request, an allowlist removes the rest of the internet from the picture.
How to set up and maintain an IP allowlist
The steps below follow the process described in OpenAI’s documentation and Cisco’s configuration guidance. They apply to most platforms, even though the screens differ.
Step 1: Find the correct public address
The address that matters is the public egress address, the one the destination sees after NAT, VPN, firewall, or proxy processing. An internal address such as one starting with 192.168 is not visible outside the network and will not work on an allowlist. Ask the network provider or check from a device inside the network what public address it presents.
Step 2: Check whether the address is fixed
Many small offices have a dynamic address that the internet provider can change. A dynamic address on an allowlist works until it changes, and then everyone is locked out. A static address, which most providers offer for a fee, avoids that problem.
Step 3: Add addresses or ranges
OpenAI documents two formats: individual IP addresses and CIDR ranges. Use single addresses where possible. Use a range only when a provider publishes one and it covers real, expected sources. Ranges that are wider than needed let in more traffic than intended.
Step 4: Pilot before applying broadly
The guidance is to test on a non-critical project first, keep a tested permitted request path, and test requests from each expected environment before applying the allowlist more widely. Environments usually include the office, any staging systems, and any cloud servers that call the protected service.
One more detail from the same documentation: when both project-level and organization-level policies are active, the project-level policy takes precedence. Check which level a platform applies first, because a rule set at one level can silently override the other.
Step 5: Keep the list current
Addresses change. Offices move, vendors change infrastructure, and staff leave. A short review on a regular schedule, with a named owner, keeps stale entries from becoming open doors and keeps new legitimate sources from being blocked.
Step 6: Keep a recovery path
A misconfigured list can block the administrator who made the change. Before saving a rule, confirm that a second route exists, such as a second approved address or a documented support process.
Limits of IP allowlisting
Allowlisting is simple, and that simplicity has costs.
An address is not an identity
Microsoft states that IP addresses can be spoofed and that a known IP is not necessarily trustworthy. It also says ACLs should not replace authentication, authorization, and application-layer validation. OpenAI says the same in practical terms: an allowlist does not replace secure API-key storage, key rotation, or account security. It is an additional control.
In plain terms, anyone on an approved network, including a compromised laptop in an approved office, passes the address check. The list cannot tell whether the person is the account owner.
Remote work breaks the model
A Zscaler security white paper lists several weaknesses of source-IP controls. They recognize a device rather than its user, they complicate least-privilege enforcement, and a misconfigured range can lock out users. They also work poorly when staff work from changing locations. The paper adds that remote users may have to route through VPN infrastructure to get a known egress address, which adds latency, and that spoofing can undermine controls in compromised or weakly secured networks.
The paper comes from a security vendor with its own approach to the problem, so it is best read as a list of known weak points rather than a verdict. The weak points are real for any agency with agents who work from home, from client homes, or on the road.
Over-restriction causes outages
Cisco notes that protocols such as UDP may need explicit permission in an ACL, and that an overly restrictive list can drop required traffic such as DHCP requests. Blocking too much is as common a failure as allowing too much.
Best practices for IP access control
A joint cybersecurity advisory from agencies in the United States, Canada, and New Zealand, Modern Approaches to Network Access Security, points to several habits that fit allowlisting:
- Apply least privilege. Give each user and system only the access the job requires.
- Verify users and devices on every request instead of trusting a network location.
- Deny connections by default unless explicitly allowed for a specific function, for example by IP address and port.
- Centralize management and segment networks.
- Use phishing-resistant multi-factor authentication.
- Maintain and rehearse incident-response plans.
Put together, the advice is a layered approach. Use the allowlist to shrink who can reach a system. Use identity checks to decide who gets in once they reach it.
When allowlisting fits an insurance agency
An insurance agency holds names, contact details, health information, and policy data. That makes access control a daily concern. Allowlisting can help in a few specific places:
- Admin and billing consoles. Limit these to the office address.
- Integrations. If a dialer, website, or calendar tool connects to an internal system, permit only that tool’s published addresses.
- Shared databases or file storage. Restrict access to known locations where the agency controls the network.
It fits poorly for the main sales workflow of a distributed team. Agents who log in from home, on mobile, or while traveling would be blocked or forced onto a VPN. For those users, strong passwords, multi-factor authentication, and role-based permissions do more.
When evaluating a CRM, the questions that matter go beyond whether a product offers an allowlist. Where is the data hosted? Who can see which records? How are logins protected? How are exports controlled? The CallBack blog covers these questions in cloud security in CRM, four controls for agencies on Google Cloud, and what secure cloud CRM means for small businesses. For compliance angles, see CRM data privacy for insurance agencies and the SOC 2 evidence items to verify. Good hygiene inside the CRM also reduces exposure, as covered in three data hygiene moves.
A short checklist before turning it on
| Question | Why it matters |
|---|---|
| Is the office address static? | A changing address locks everyone out. |
| Who works remotely? | Remote staff will be blocked unless another route exists. |
| Which integrations call in? | Each needs its own addresses on the list. |
| Who owns the list? | Stale entries become open doors. |
| Is there a recovery path? | A bad rule should not lock out the only administrator. |
| Is multi-factor authentication on? | The allowlist does not confirm identity. |
Perspective: how we see allowlisting
We build CallBack for insurance agents, agencies, and IMOs, and the same question comes up often: how should access to client data be controlled when the team is spread out?
Our view is that an IP allowlist is a useful narrow tool and a poor main defense. Agents in final expense, Medicare, and mortgage protection work from many places. They log in from phones and home offices. A strict address rule for every user would slow that work down and push people toward workarounds, which is a security risk in itself.
So we put the weight on the controls that follow the person: unique logins, multi-factor authentication, and limited permissions by role. Our platform is hosted on Google Cloud, and more detail on how we handle protection is on our security page. Allowlisting makes sense in the places where the sources really are fixed, such as an admin area or a system integration.
A practical rule we give agency owners: write down who needs to reach what, from where. If the answer is “a handful of fixed locations,” an allowlist helps. If the answer is “anyone, anywhere,” invest in identity controls first.
— Kyle
Software for agencies that handle client data
CallBack is an AI-powered CRM and sales automation platform for insurance agents, agencies, and IMOs. It covers pipelines, automated follow-up by text, email, and voicemail, funnels, websites, and reporting in one place.
The Professional plan costs $97 per month and can be started on the Professional signup page. Agencies with several licensed agents can look at the Enterprise plans: $297 per month for 10 full CRM accounts, $397 per month for 25, and $497 per month for 60. Usage fees for items such as phone numbers, which cost $2.30 per month per number, are listed on the fees page.
Agencies that send marketing messages should also check the rules for opt-outs and email practices, covered in the posts on CAN-SPAM for insurance emails and the email marketing checklist for agents.
FAQ
Is IP allowlisting the same as IP whitelisting?
Yes. Allowlisting is the newer term, and whitelisting is the older one. Both describe a list of approved addresses that are permitted access while all others are denied.
Is IP allowlisting enough to secure a system?
No. IP addresses can be spoofed, and a trusted address does not prove who is using it. Microsoft says ACLs should not replace authentication, authorization, and application-layer validation. Use the allowlist alongside logins and multi-factor authentication.
Can remote employees use a system that has an allowlist?
Only if they connect from an approved address. Common routes are a VPN that exits through the office address or a fixed address per person. Both add effort and, for VPNs, latency. Teams with many mobile users often rely on identity-based controls instead.
What is a CIDR range?
CIDR notation describes a block of IP addresses with a base address and a prefix length, such as an address followed by a slash and a number. Platforms like OpenAI accept both single addresses and CIDR ranges. Keep ranges as narrow as the real sources allow.
What happens if the office IP address changes?
Everyone relying on that address is blocked until the list is updated. A static address from the internet provider prevents this, and a second approved route gives administrators a way back in.
Sources
- whitelist (allowlist), TechTarget
- What is an IP based access control list (ACL)?, Microsoft Learn
- Configure IP Access Lists, Cisco
- IP allowlist, OpenAI developer documentation
- Protecting Information Systems with Firewalls, NIST ITL Bulletin
- Transform Application Access Security, Zscaler white paper
- Modern Approaches to Network Access Security
- Website Security: Safeguarding Brands and Customer Trust