- What an IP restriction actually protects
- Where it fits and where it does not
- How to budget for the running cost
- Pairing it with MFA and a VPN
The short answer
IP address restrictions work on systems with a fixed set of connection points: an admin panel only used from the office, a server only touched from one site. Apply the same rule to something people use from home or on the road, and the cost of locking out your own staff outweighs what you gained. Decide by asking who connects from where, not by asking how sensitive the data is.
What it actually protects
An IP restriction sits at the door and checks where the request came from. Anything outside the allowed range never reaches the login screen, even if the password has leaked. In other words, it protects the step before authentication.
The part people miss: if the address matches, nothing else is examined. A laptop on your allowed office network that has picked up malware still gets straight through. You have cut off the anonymous login attempts arriving from everywhere else, but the weaknesses in the application itself are untouched.
Where it fits, and where it does not
A good fit
- The office has a static IP, and the target is limited to internal systems such as an admin panel or an accounting server.
- A data exchange with a business partner, where their server address is written into the contract.
- A contractor's working account, restricted to their office for the length of the project.
That last one is worth copying. Narrowing by scope and by time is far easier to live with than applying the rule to every system forever.
A poor fit
Trouble starts as soon as the connection point moves.
- Consumer internet lines can change address depending on the plan. It worked yesterday, someone rebooted the router, and now it does not.
- Mobile and tethered connections get their addresses from the carrier's equipment. Clocking in from a job site does not sit well with an allowlist.
- Registering each home worker's address means you have started running a register. Every house move, every change of provider, every swap of home equipment becomes a request someone files and someone else applies.
- Hotel Wi-Fi, airport lounges and a client's meeting room cannot be known in advance.
Apply IP restrictions to everything and the people most likely to be locked out are the ones who need to check something during an incident. An on-call engineer who cannot get in from home at midnight is a business risk in itself.
Budget for the running cost
When you weigh this up, look past the initial configuration to what comes after. Three questions are enough.
| What to check | The question |
|---|---|
| Rate of change | How many times a month will someone edit the allowlist? |
| Who can edit it | Who holds that access, and what happens when they are away? |
| The way back | If you lock yourself out, who undoes it and how? |
The third is the one that gets skipped. If the settings page itself sits behind the restriction, you cannot fix it from outside. Write down the procedure for asking your hosting provider to lift it, and keep that note somewhere offline.
Pairing it with MFA and VPN
For systems where the connection point cannot be pinned down, strengthen the authentication instead. Multi-factor authentication asks for something beyond the password — an app on a phone, a hardware key — so a leaked password alone is not enough. That works with staff who move around.
A VPN makes every employee appear to connect from the same place, which does let you use IP restrictions again. But that only moves the question: if the VPN credentials leak, the attacker is inside the allowed range, and the VPN appliance itself needs patching like anything else. No single one of these is sufficient on its own.
A sensible order is: remove unused accounts and tidy permissions first, then turn on multi-factor authentication, and only then add IP restrictions to the systems whose connection points really are fixed.
How this looks in practice
Take an architecture practice with ten staff. The accounting server and the internal file server holding drawings are used from the office and nowhere else, so the office's static IP is the only entry allowed. Time tracking and expense claims are filed from sites and from home, so those get no IP restriction and multi-factor authentication instead.
Groupware is used from outside by everyone, so IP restrictions were dropped for it. In their place, disabling accounts for departing staff became part of the month-end routine. With that split, the allowlist only needs touching when the office moves.
In summary
IP address restrictions are a solid move for systems with fixed connection points. Bring dynamic addresses, mobile connections and home working into the picture and the maintenance burden arrives before the security benefit. Narrow the scope, decide in advance how you get back in, and cover the moving parts with multi-factor authentication. Judged that way, the decision stays consistent.