For twenty years, network access control rested on an assumption nobody had to state out loud. People worked in the building. The building had a range of addresses. If a request arrived from that range it was probably one of ours, and if it did not, that was worth a second look.
A surprising amount of the security stack still runs on that assumption. Then the workforce scattered across cities, countries and kitchen tables, and the assumption quietly stopped being true without anything visibly breaking. Nothing went red. No alert fired to announce that a foundational control had become decorative. It simply stopped carrying information, and everything built on top of it inherited the problem.
What breaks first
Admin panels with IP allowlists. Someone travels, the allowlist rejects them, and the fastest path to getting work done becomes a support ticket asking for the allowlist to be widened. It always gets widened. Nobody ever narrows it again, because narrowing it means finding out which of the forty entries still matter and no one has the appetite for that conversation.
Vendor tools that restrict access by country. Payroll systems, banking portals and a good number of HR platforms still do this by default. A finance manager working from her sister’s house abroad for two weeks discovers it on the morning payroll runs, which is the worst possible morning to discover it.
Conditional access rules that flag unfamiliar locations. Sound in principle. In a distributed team every location is unfamiliar, so the rule fires constantly, and within a month the people approving those prompts have learned to approve without reading. A control that trains its users to ignore it has become worse than no control, because it also supplies false confidence.
And the audit log, which matters most and gets noticed last. A log full of addresses nobody recognises is not an audit trail. It is a list. When an incident review asks whether a given login was unusual, the honest answer becomes a shrug, and a shrug is not a finding.
The noise problem underneath all of it
Every item above produces the same second-order effect. When everything looks anomalous, nothing does.
This is the part that should worry anyone responsible for insider risk. Behavioural monitoring works by comparing what happened against what usually happens. It is a baseline technology. If the network layer of that baseline is pure noise, the comparison loses a large part of its value, and the genuinely unusual event arrives wearing the same clothes as the other four hundred alerts that week.
Teams rarely recognise this as a security problem. They experience it as alert fatigue, which is the same problem wearing a friendlier name, and they solve it by turning down sensitivity. That is a rational response to an unusable signal, and it quietly removes a detection capability the organisation believes it still has.
The compliance layer nobody planned for
There is a second consequence that tends to surface later and cost more.
Where an employee physically sits determines which rules govern how they can be monitored. A team spread across six countries is six regimes, not one. Consent requirements differ. Notice requirements differ. In several European jurisdictions workplace monitoring engages employee representation bodies with genuine co-determination rights, and rolling out a tool without going through them is not a technicality that gets waved through afterwards.
Which means knowing where someone actually works is no longer only a security question. It is a compliance input. An organisation that cannot say with confidence which country a given employee has been working from for the last quarter has a documentation problem waiting for the first complaint, and “we assumed they were at the registered office” has never been a satisfying answer to a regulator.
There is a tax version of the same problem, and finance departments have generally noticed it before IT does. Permanent establishment risk depends on where work physically happens. The people who can answer that question accurately are usually sitting on the data already and have not been asked.
Five answers that do not work
Drop IP rules entirely and lean on identity alone. Defensible for modern systems with strong authentication and device posture checks. Unworkable for the long tail of vendor tools that offer an IP allowlist and nothing else, which in most companies is precisely where the sensitive data sits.
Allowlist every address a worker might use. Home addresses change, sometimes weekly. Within a quarter the allowlist has three hundred entries, nobody knows which are still valid, and removing any of them feels risky enough that nobody does.
Force everything through one corporate VPN concentrator. This does produce a single exit address, which is why it survives. It also creates a bottleneck, a single point of failure, and a support queue every time somebody’s client drops mid-call. Teams route around it, and the routing around is invisible until it matters.
Rely on device certificates alone. Genuinely useful and a real improvement on passwords, and still silent about location. A certificate proves the laptop is yours. It says nothing about which country the laptop is in, which is the exact question both compliance and detection need answered.
Accept the noise and move on. The most common answer by a distance, and the reason so many monitoring programmes generate a great deal of data that nobody reads.
Giving distributed access a fixed shape
The useful reframe is to stop treating identity and location as competing controls. Identity establishes who someone is. Location decides how much friction that person meets and how much explaining an unusual event requires. Neither is sufficient on its own and neither makes the other redundant.
What that needs in practice is not a large pool of addresses. It is a small number of stable exit points, one per region or per team, that do not change from week to week and that somebody can name.
Static addresses registered to internet service providers achieve this without putting a concentrator in the middle of every connection. A team using premium isp proxies gets a fixed address per region that vendors can allowlist, that appears consistently in audit logs, and that keeps working when somebody’s home router is handed a new address overnight by their provider. The cost sits in the tens of dollars a month, which is comfortably below the threshold at which anyone asks for a business case.
The gain is not the access itself. It is that the network layer stops being random, which means an unfamiliar address in the log becomes information again rather than background.
What the first month looks like
Start by finding out what you actually have. Pull ninety days of authentication logs and count distinct addresses per user. Most organisations are surprised, and the surprise itself is the argument for doing the work.
Then list the systems that carry IP restrictions today and mark which ones genuinely need them. The list is usually shorter than the current configuration implies, because half of it was inherited from an office that no longer exists.
Pick one region and one team for the first fixed exit point. Run it for a fortnight and watch the alert volume for that group specifically. If it does not fall noticeably, something else is generating the noise and you have learned that cheaply.
Only then write the policy, because a policy written before the pilot describes a system nobody has tested.
Write it down as policy, not as a ticket
The failure mode in every organisation that gets this wrong is identical. Access decisions get made one exception at a time, by whoever happens to be on the support rota, under time pressure, with no record of the reasoning.
Three things belong in a document rather than in somebody’s memory. Which systems carry IP restrictions and which rely on identity alone. Which countries the company actually operates in, so that a login from outside them is a real question instead of a shrug. And who may approve an exception, with a review date attached to every one granted, because an exception without an expiry is a permanent change wearing a temporary label.
None of this is exotic. It is the same discipline any monitoring rollout needs to survive contact with a real workforce. Decide the rules in advance, apply them consistently, and make sure the people affected know what the rules are before they trip over one.
What to measure
Four numbers tell you whether the work landed. Distinct addresses per user per month, which should fall and then stay flat. Standing allowlist entries, which should fall and stop growing. Conditional access prompts per user per week, which is your alert fatigue proxy. And time to answer the question “was this login normal”, measured the next time somebody asks it in anger.
That last one is the real test, and it is the only one that cannot be gamed.
The short version
Distributed work did not remove the need for location as a signal. It removed the accident that used to supply that signal for free, and most organisations have not replaced it with anything.
Companies that replace it deliberately end up with quieter alerts, readable logs, fewer standing exceptions and a defensible answer when someone asks where an employee was working in March. Companies that do not end up with a monitoring programme that produces an enormous amount of data and very little attention.