It’s 2:47 AM, and an authentication system flags an unusual login. The source IP is unfamiliar. A security analyst, if one is available at that hour, begins the investigation. They check the IP against their threat intelligence feeds. They look up the geolocation. They investigate whether it’s associated with a VPN or proxy service. They cross-reference the ASN to understand what kind of infrastructure it belongs to.
Each lookup takes time. Even for an experienced analyst working efficiently, gathering enough context to make an informed decision takes three to five minutes. In that window, if the login is malicious, an attacker could be establishing persistence, moving laterally, or exfiltrating data.
The challenge isn’t a lack of information. IP intelligence services have spent years building databases that will tell you not only where an address is located, but whether it belongs to a VPN provider, a hosting company, or a residential proxy service. The data exists. The gap is between having it and acting on it.
The cost isn’t the minutes
Three minutes an alert sounds survivable. It isn’t, because the number that matters is the second one: hundreds of alerts a day.
Alert fatigue sets in. Analysts start making faster decisions with less information, because thoroughness isn’t sustainable at that volume. Some alerts get deprioritized and reviewed hours later, if at all. And the 2 AM alerts — the ones arriving when staffing is thinnest — reliably get the least attention, precisely when attackers are most likely to be working.
This is not a discipline problem, and no amount of care fixes it. The constraint is throughput. A team that processes alerts by hand has a ceiling set by how many humans are awake, and attackers are under no obligation to respect it.
Why the obvious fix doesn’t work
The standard answer is automation, and the standard automation is a rule. Block IPs on known-bad lists. Flag logins from certain countries. Deny anything tagged as a VPN.
Rules fail here in a specific and instructive way. Consider the VPN case, which is the one every security team argues about:
Block all VPN traffic, and you generate false positives from every employee who legitimately uses one while travelling. Allow VPN traffic, and you miss the threat actors renting space on the same commercial services your employees use. There is no third setting. The rule has to decide before it knows whose login it is.
That’s not a tuning problem to be solved with a better blocklist. It’s structural. A rule evaluates an attribute — is this a VPN — when the thing that determines the right answer is the situation: whose account, at what hour, from where, reaching what, against what pattern of past behaviour. The attribute is the same in both cases. The situation is not remotely the same.
So teams are left choosing which kind of wrong they prefer, and the tension between security and usability that everyone complains about is just this choice, made once, in a config file, months ago.
What an analyst actually does
Watch how a human resolves the same alert, and the thing they’re doing is not applying a more sophisticated rule.
They gather context until the situation resolves. A VPN exit node isn’t suspicious on its own. But a commercial VPN exit node, at 2 AM local time for that user, from a country they’ve never logged in from, reaching financial systems, is a different situation from the same user on the corporate VPN on a Tuesday afternoon — and an analyst reaches that conclusion by assembling geolocation, ASN, provider type, and the user’s own history into a picture.
Then they pick a proportionate response. Not block-or-allow, which is the only vocabulary a rule has, but the middle options that make up most of real security practice: challenge for step-up authentication, let the session run with elevated logging, watchlist the address for that user specifically, escalate to a human who knows the account.
The judgment is good. It just costs three to five minutes and doesn’t scale, so it gets applied to a shrinking fraction of the alerts that deserve it.
Moving the context-gathering, not the judgment
The useful question is which half of that to automate.
Automating the judgment is what rules already do badly, and doing it faster doesn’t help. Automating the context-gathering is different: it’s mechanical, it’s the part that consumes the three to five minutes, and it’s the part that gets skipped first under load.
A system that queries IP intelligence for full context — geolocation, ASN, privacy flags, provider type, ownership — then sets that against the user’s own history and the organization’s policy, is doing what the analyst does, in the order the analyst does it. It reaches a proportionate response rather than a binary one, because it has the same information the analyst would have had. And it reaches it in seconds.
What that buys is not primarily speed on any single alert. It’s consistency. The system applies the same criteria at 3 AM on a holiday weekend as at 2 PM on a Tuesday. It doesn’t get tired at the end of a long week, and it doesn’t triage the last hundred alerts more carelessly than the first hundred. For organizations that have never managed to staff 24/7 coverage, that consistency addresses a real and specific gap.
There’s an audit dimension too. Every decision is logged with the inputs that produced it. When someone asks how the organization responded to a particular event six months ago, the answer stops being “it depends who was on shift.”
What this doesn’t do
It doesn’t remove the analyst, and any pitch that says otherwise should be treated with suspicion.
It changes what the analyst spends the day on. Routine decisions — the overwhelming majority — resolve without them. What reaches a person is what actually needs one: the sophisticated attack that matches no known pattern, the ambiguous case that needs context from outside the data entirely, the strategic work of improving detection and understanding how adversaries are behaving this quarter.
That’s the trade being offered. Not fewer analysts. The same analysts, spending their attention on the alerts where human judgment changes the outcome.
The hard part isn’t the technology. It’s getting a security team to trust an automated decision on alerts they’ve triaged by hand for years, and that trust is earned incrementally — starting somewhere the blast radius is small, on a workflow the team already understands, with a response that challenges rather than blocks. Authentication monitoring is usually the right first move: the volume is high enough to show value quickly, and step-up authentication means an automation error costs a user thirty seconds rather than a locked account.
The tools exist today. IP intelligence is mature, and systems that reason over it are buildable now. The technology works. Whether your team is ready to let it is a different question, and it’s the one that actually determines whether any of this happens.