VPNs and corporate networks break website visitor identification because they collapse hundreds or thousands of distinct people behind a single exit IP, and reverse-IP lookup, the mechanism most identification tools still lean on, can only resolve one company per IP. When that IP belongs to a VPN provider or a corporate security vendor instead of the visiting company, you get one of two bad outcomes: a confident match on the wrong company, or no match at all. Neither shows up as an error. Both look exactly like a normal, working result.

This is the single most common reason a visitor identification tool's match rate looks fine in aggregate but falls apart the moment you audit individual records. Here's what's actually happening under the hood, how to tell if it's corrupting your data right now, and what to do about it.

How Reverse-IP Lookup Breaks on VPN and Corporate Traffic

Reverse-IP identification works by matching a visitor's IP address against a database of known company IP ranges. That works well when a company owns a dedicated IP block and its employees browse from behind it. It breaks the moment the IP in the request headers doesn't actually belong to the visiting company.

Three traffic patterns cause that mismatch constantly in B2B traffic:

• Consumer VPNs. A visitor on NordVPN, ExpressVPN, or a similar service exits through the VPN provider's own IP range. Reverse-IP lookup correctly identifies that range, and correctly identifies it as belonging to the VPN company, not the visitor's employer. There is no company match to be found because the traffic genuinely didn't originate from the employer's network.
• Corporate SASE and ZTNA platforms. This is the one most GTM teams don't see coming. When a company routes employee traffic through Zscaler, Netskope, Cloudflare WARP, or a similar zero-trust security layer, every employee's traffic egresses through that vendor's shared IP pool, not the company's own range. Reverse-IP lookup does exactly what it's designed to do: it identifies the IP owner. It just identifies the security vendor instead of the actual prospect account.
• Cellular and CGNAT traffic. Carrier-grade NAT means large blocks of mobile users share a small pool of public IPs that rotate constantly. A B2B buyer researching your pricing page from their phone on a train looks, to a reverse-IP database, indistinguishable from thousands of other people on the same carrier.

None of this is a bug in any particular vendor's matching engine. It's a structural limit of IP-based identification, and it's why false positives in visitor ID data cluster so heavily around remote-heavy and security-conscious accounts.

Two Failure Modes, and Why the Silent One Is Worse

VPN and corporate-network traffic doesn't fail your identification tool one way. It fails it two ways, and the less obvious one does more damage.

The first is the silent miss: the session simply doesn't resolve, and it disappears from your reporting like it never happened. That's frustrating, but it's honest. Nobody acts on a null result.

The second is the false positive, and it's the expensive one. When a security vendor's IP range gets misread as a company match, or when a stale reverse-IP record points to the wrong tenant on a shared range, the tool doesn't return nothing. It returns a fully populated, confident-looking record: company name, industry, sometimes a named contact. Your SDR acts on it. It goes in the CRM. Three touches later, someone discovers the "hot account" was never actually there, and the entire tool's credibility takes the hit, not just that one record.

How Much Impact Depends on Which Kind of Traffic You're Getting

Not all VPN and corporate-network traffic is equally damaging. The impact scales with how much of the exit IP is shared and how far it sits from the visitor's actual employer:

• 🔴 Consumer VPN (NordVPN, ExpressVPN, Apple Private Relay) - resolves to the VPN provider itself, not any real company. Expect a miss or an ISP-level junk match on nearly every session.
• 🟠 Corporate SASE / ZTNA (Zscaler, Netskope, Cloudflare WARP) - all employee traffic exits through the security vendor's shared pool. Expect the vendor's name to show up where the prospect's company should be.
• 🟡 Large corporate NAT without a SASE layer - hundreds or thousands of employees behind one gateway IP. Company-level match usually holds, but person-level attribution collapses to "someone at this company."
• 🟢 Branch office or smaller corporate network - fewer people behind the IP, so company match holds and, with a strong identity graph behind the vendor, person-level match often does too.
• ⚪ Direct residential or named home-office IP - resolves to a residential ISP, which most identification tools filter out before it ever becomes a false positive.

If your buyers skew toward security, financial services, healthcare, or any industry that mandates SASE or ZTNA for remote work, you should expect your match rate to run lower than a vendor's blended benchmark, and you should expect more of your misses to cluster in exactly the accounts you most want to reach.

How to Tell If This Is Corrupting Your Data Right Now

You don't need a research team to check this. Pull 25 to 50 of your highest-confidence matches from the last 30 days and run this audit:

1. Check the resolved company against the industry. If a run of "matches" trace back to a company that sells VPN, proxy, or network security software, hosting, or telecom services, that's your tell. Those companies aren't suddenly your best-fit accounts; their infrastructure is showing up as the visitor.
2. Look for repeat "visits" from the same resolved company on unrelated pages. A security vendor's IP pool serving hundreds of unrelated customers will show up again and again across your traffic, usually with no coherent buying pattern.
3. Cross-check against known accounts. If a target account with a well-documented office location is instead resolving to a totally different geography or a data-center IP, that's a corporate VPN or SASE hop, not a data error on your end.
4. Segment your match rate by device and connection type if your tool exposes it. A blended match-rate number hides exactly this problem. Desktop-on-corporate-broadband and mobile-on-cellular should never be reported as one figure.

If you find even a handful of these patterns in a 50-record sample, don't wait for a quarterly review. Build a suppression list for the offending ASNs and revisit it every time you onboard a new identification vendor or your buyer mix shifts toward more security-conscious industries.

What Actually Compensates for This (and What Doesn't)

No identification vendor can turn a VPN provider's IP into your prospect's real company; that data genuinely isn't in the request. What separates a good outcome from a bad one is how the tool handles the gap.

Knock2 matches visitors against an identity graph built from a consent-based publisher network, not IP databases alone, which is what lets company-level identification hold up even when the IP itself is a dead end for a pure reverse-IP tool. Publicly, Knock2's benchmarks are 93%* account-level and 62%* person-level identification (US traffic) against engaged sessions. That gap between the two numbers is not a rounding error, it's largely VPN, corporate-NAT, and mobile-carrier traffic where a company-level signal survives but a clean person-level match doesn't.

*Identification rates measured against engaged sessions. Results may vary by traffic profile, geography, and industry.

The practical takeaway for a GTM team: don't chase a single blended match-rate number as your only success metric, and don't treat every miss as a vendor failure. Build your lead-scoring and routing rules to expect company-only matches from security-conscious accounts, and reserve person-level urgency scoring for the sessions where you actually got a name.

FAQ

Does a VPN completely hide a visitor from identification tools?

Not always. A consumer VPN almost always blocks company-level identification because the exit IP belongs to the VPN provider, not the visitor's employer. A corporate SASE platform is different: it can still yield a company-level match if the identification vendor recognizes the security vendor's range and works around it, though person-level accuracy typically drops.

Why does my match rate look fine overall but fail on my best accounts?

Your best-fit accounts are often the ones with the strictest security posture, which means the highest concentration of SASE, ZTNA, and mandatory VPN policies. A blended match rate averages that away. Segment your numbers by account tier before drawing conclusions.

Can I fix this by asking my vendor for a "VPN detection" feature?

Treat that claim skeptically. Detecting that traffic came through a VPN or proxy is straightforward; recovering the true company behind it usually isn't, since the identifying data simply isn't present in the request. The more useful question to ask a vendor is how they handle known SASE and security-vendor ranges, not whether they can "see through" a VPN.

Is it worth suppressing known VPN and SASE IP ranges entirely?

For SDR alerting, generally yes. Suppressing known offending ranges from real-time alerts protects rep trust. For aggregate pipeline-coverage reporting, keep the raw numbers visible but labeled, since even an unresolved session on a target account is a real signal that shouldn't just disappear.

Does this problem get worse or better over time?

Worse, on current trends. SASE and ZTNA adoption keeps climbing, especially in the security, financial services, and healthcare verticals that are often the most valuable B2B accounts. Any GTM team relying on a blended match-rate figure should expect that number to trend down for reasons that have nothing to do with vendor quality.

Ready to see how your own traffic mix holds up? Book a Knock2 demo and run your VPN-heavy segments against a live identity graph before you decide.