Corporate VPNs and Secure Web Gateways: Avoiding B2B False Positives

A rule that challenges datacenter traffic looks sensible on a dashboard. Real people browse from home and office ISPs, and scripts run from cloud servers. Then your biggest customer rolls out a secure web gateway, and on Monday morning four hundred of their employees hit a challenge on your login page.

This is the most common source of false positives in B2B SaaS. The traffic really is coming from a datacenter. It’s just that the datacenter belongs to the customer’s security vendor, and the people behind it are exactly who you want using your product.

What a secure web gateway does to your signals

Cloud security products such as secure web gateways, zero-trust network access tools and corporate VPNs proxy employee traffic through the vendor’s own network. From your side, that changes several signals at once:

• IP and ASN. The source IP belongs to the security vendor’s network, which IP intelligence correctly classifies as hosting or datacenter.
• Sharing. Many employees, and often many different companies on the same vendor, come out of the same pool of egress IPs.
• Location. IP geolocation reflects the vendor’s point of presence, which may be in another city or country from the user, and can shift between sessions.
• TLS. Some gateways inspect TLS, so the handshake your server sees can come from the gateway rather than the user’s browser.

Individually, each of these looks like a fraud signal. Together they look like a bot farm in a cloud region. The difference is the device: the people behind a gateway use ordinary laptops, with ordinary browsers, that come back day after day.

How Prynt scores it by default

Two design choices in Prynt’s risk scoring already soften this.

The anonymized-egress family isn’t summed. VPN, datacenter and proxy usually describe the same fact. A corporate egress IP may trip all three. Prynt counts the family as its strongest single member rather than adding them up, so a clean device on a corporate gateway doesn’t get pushed into a block by network signals alone.

Device signals still carry their own weight. Bot, tampering and virtual-machine detection come from the device itself, not from the IP. A real employee on a real laptop behind a gateway shows clean device signals, while a script running inside the same cloud region usually doesn’t.

Default scoring alone won’t prevent a false positive if you add rules that hit network signals hard. That’s where most of the damage comes from.

Rules that cause the problem

Each console rule is a single condition: a field, an operator, a value and an action. The classic mistake:

Priority	Rule	Action
10	asnType eq datacenter	block

asnType is datacenter for hosting networks, which includes every major security vendor’s egress. This rule blocks scrapers, and it also blocks your enterprise customers.

A softer variant causes subtler damage:

Priority	Rule	Action
10	vpn eq true	challenge

A challenge is a floor in Prynt’s rules engine. Once a rule challenges, a later allow rule can’t undo it, though a later block still wins. So a broad challenge rule at a high priority quietly caps every gateway user at “challenge,” no matter how trustworthy the rest of the session looks.

A better rule set for B2B

Lead with device evidence, tag network evidence, and save hard actions for when they agree:

Priority	Rule	Action
10	bot eq true	block
20	tampering eq true	block
30	virtualMachine eq true	challenge
40	distinctAccounts30d gte 4	challenge
90	asnType eq datacenter (named hosted-egress)	tag
91	vpn eq true (named vpn-egress)	tag

A tag rule adds its name to the decision’s tags without changing the outcome. On the server-side event they appear in risk.tags, next to risk.asnType. Your server can then combine them with context the rules engine doesn’t have:

const ev = await prynt.getEvent(requestId);
const tags = ev.risk?.tags || [];
const corpLike = ev.decision === 'allow' &&
  (tags.includes('hosted-egress') || tags.includes('vpn-egress'));

if (corpLike && isKnownAccountOnKnownDevice(user, ev)) return allow();
if (corpLike && isNewSignup && !ssoVerifiedDomain(req)) return requireEmailVerification();

The point is that the network tells you where the traffic came from, and the device and account tell you who it is. For B2B, the second question decides the outcome. ISP vs datacenter classification explains how the network labels are assigned in the first place.

Trust the device, not the IP

The most reliable way to stop challenging your own customers is to anchor trust on things a gateway doesn’t change:

• A known device on a known account. Pass the user id to identify({ linkedId }) after login. When a returning employee shows up on the same visitorId they’ve used for months, the egress IP is irrelevant.
• Verified company identity. SSO through a domain you’ve verified is stronger evidence than any IP classification.
• Account age and history. A long-lived account with consistent devices is not the same risk as a signup from a fresh device.

Use lists carefully

It’s tempting to allowlist a big customer’s IP ranges. Three reasons to resist:

1. Allowlists skip everything. An allowlist hit returns allow with the ALLOWLIST reason code before any rule runs, bot and tampering checks included.
2. Gateway IPs are shared. The egress IP your customer uses is also used by other companies on the same vendor, including any attacker who signs up for it.
3. IP entries match exact addresses. Gateway pools are large and change over time, so IP allowlists go stale quietly.

If you need an override for a specific enterprise account, allowlist its linkedId instead, and keep the list short and reviewed.

Watch impossible travel and velocity

Two behavior signals also need care for gateway users. Impossible travel can fire when an employee’s egress moves between points of presence. IP-level velocity looks extreme when a whole company shares one address. Prynt computes velocity and travel per device, which helps, but any IP-keyed rate limits in your own stack will hit gateway customers first. Key your own limits on account or device, not IP.

Find out who you’re challenging

Before changing anything, pull a week of challenged and blocked events for logged-in users and group them by organization or email domain. If one paying customer accounts for a big share, you’ve found a gateway. Then look at the reason codes: if it’s mostly DATACENTER and VPN with no device-level codes, your rules are over-weighting the network. Reducing false positives and datacenter IP detection cover the wider process.

Demote network rules to tags, add a device-first rule set, and re-check that customer’s challenge rate a week later. For a deeper look at the network signals themselves, see VPN and proxy detection.