Why VPNs Belong in a RevOps Security Conversation
VPN decisions usually land on a RevOps or sales operations desk by accident. IT procures a licence, a rep asks why they keep getting logged out of the CRM, and suddenly someone has to explain what the connection is actually doing. That someone is often the person who owns the CRM’s access model, not the person who bought the software. Understanding what a VPN protects, and what it leaves exposed, matters because pipeline data, contact records and deal values are exactly the kind of information that travels over home wifi, hotel networks and shared coworking connections every working day.
A VPN is one control in a wider access stack, not a replacement for the rest of it. Treating it as a single silver bullet is how gaps appear: a rep protected on the network layer but still vulnerable to a phishing email that harvests their CRM password directly.
What Actually Travels Between a Rep’s Laptop and Your CRM
When a rep opens their CRM, several things happen in sequence: a DNS lookup resolves the CRM’s domain, a TLS handshake establishes an encrypted session with that server, and an authentication token or session cookie confirms who they are for the duration of that session. HubSpot and Salesforce both encrypt this traffic by default over HTTPS, so the CRM connection itself is already protected against casual interception, VPN or no VPN.
What a VPN adds on top of that is protection at the network layer below the CRM’s own encryption: it hides the rep’s IP address and traffic pattern from whoever controls the local network, whether that is a coffee shop router, a hotel gateway, or an internet service provider logging connection metadata. This matters most on networks the business does not control, where an attacker on the same wifi segment could otherwise see which domains a device is talking to and attempt to intercept unencrypted parts of the exchange, such as DNS queries.
What a VPN does not touch is anything that happens on the device itself. A malicious browser extension that reads session cookies, a credential-stuffing attempt against a reused password, or a rep clicking a convincing phishing link all bypass the network layer entirely. A tunnel around the connection does nothing to stop a leak that originates on the endpoint, which is why a VPN rollout that stops there leaves the more common attack paths untouched.
Consumer VPN Habits Do Not Scale to a Sales Team
A single rep installing a personal VPN app on their laptop creates a visibility gap for whoever manages CRM access: there is no way to see which servers they are exiting through, no way to revoke access centrally when they leave the business, and no audit trail if something goes wrong. This is shadow IT with an encrypted tunnel attached, and it tends to spread quietly across a sales team once one person recommends an app to a colleague.
There is also a concrete operational failure mode. Both HubSpot and Salesforce apply login anomaly detection based on the geographic location implied by a user’s IP address. A rep whose consumer VPN app rotates exit servers between countries, or between cities within the same session, can trigger an impossible travel flag and get bounced into step up authentication or a locked session mid call. Reps often assume the CRM is broken; the real cause is an uncoordinated VPN choice generating IP behaviour the CRM’s own security model was never designed to expect from a genuine user.
Offboarding is the other gap. If a departing rep’s CRM seat is deprovisioned but their personal VPN subscription is not tied to any company system, there is no lever to pull to shut that connection down. A business VPN tied to the same identity provider as the CRM closes this gap by construction, because removing the employee from the identity provider removes both at once.
Five Criteria for Evaluating a Business VPN
Choosing a VPN for a sales team is a different exercise from choosing one for personal streaming or browsing. Five criteria matter more than any headline speed or server count claim.
Encryption Protocol and Independent Audits
Look at which protocol underpins the service. WireGuard has become the modern default for business VPNs because its codebase is small enough to audit properly, in contrast to older protocols like OpenVPN, which carry more legacy code and configuration surface. The protocol’s own documentation is a useful reference point when comparing vendor claims against how the underlying mechanism actually works.
Verified No-Logs Policy
A “no logs” claim on a marketing page is not the same as a verified one. Ask specifically what is logged: connection timestamps, bandwidth totals, and originating IP are common even under a “no activity logs” policy, and the difference between activity logs and connection metadata is where most of the ambiguity in vendor claims sits. An independent third party audit report, rather than a self-published statement, is the only reliable way to check what a provider actually retains.
Single Sign On and Identity Integration
A business VPN should authenticate through the same identity provider as the CRM, whether that is Azure AD, Okta or Google Workspace. This is what closes the offboarding gap described above: one deprovisioning action removes VPN access and CRM access together, rather than leaving a personal login floating unattached to any employee record.
Split Tunnelling and CRM Allowlisting
Split tunnelling routes only defined traffic, such as connections to the CRM and internal tools, through the encrypted tunnel, while general browsing goes direct. This keeps latency low for everyday use and avoids routing an entire team’s Netflix or video call traffic through a corporate gateway unnecessarily, while still guaranteeing that CRM sessions specifically are always tunnelled. Full tunnel mode, where all traffic passes through the VPN, is the stricter alternative and suits teams handling regulated data that requires every connection to be logged and controlled centrally.
Centralised Device and Session Management
An admin dashboard showing which devices are currently connected, and a remote kill switch for individual sessions, turns a VPN from a passive tunnel into an active control. Without this, a lost laptop or a compromised device stays connected until someone manually changes credentials, rather than being cut off the moment it is reported.
VPN or Zero Trust Network Access: Choosing the Right Model
A traditional VPN grants network level access: once connected, a device can typically reach a broad slice of the internal network, and access to individual systems is controlled after the fact by application-level permissions. This creates a lateral movement risk. If a connected device is compromised while the tunnel is active, an attacker inherits whatever network reach that tunnel provides, not just access to the one application the rep actually needed.
Zero Trust Network Access services, such as Cloudflare Access or Twingate, take a different approach: every request to every application is authorised individually, and no device gets broad network reach just by connecting. For a team using only a handful of SaaS tools with no legacy on-premises systems, a well configured business VPN with SSO is often sufficient. For a team that mixes SaaS CRM access with legacy internal servers, multiple contractor accounts, or a wider set of internal tools, the narrower per-application model of ZTNA reduces the blast radius of a single compromised device considerably.
Rolling Out a VPN Policy Without Breaking Sales Workflows
Pilot with a small group before a full rollout, and specifically watch CRM login behaviour during that pilot. This surfaces anomaly detection issues, such as impossible travel flags from exit server switching, while the group is small enough to fix quickly rather than after the whole sales team is affected.
Document an exception process for travel. A rep genuinely working from two countries in the same week needs a known path to confirm that behaviour with IT, rather than discovering a locked CRM session on a call with a prospect. Set up alerting on login patterns that fall outside that documented exception process, so unusual activity gets reviewed rather than either ignored or treated as routine.
Train reps on what the VPN does and does not cover. A team that believes the VPN makes them immune to phishing is more likely to click a convincing link than one that understands the tunnel protects the network hop, not their judgement about what they click.
Data Protection Obligations That Shape the Decision
Under UK GDPR, organisations must implement appropriate technical and organisational measures to protect personal data, which is the legal basis most businesses cite for encrypting connections that carry contact and deal data. A VPN can be one of those measures, but the Information Commissioner’s Office guidance for organisations is clear that encryption in transit is only part of a wider set of obligations covering access control, retention and breach reporting. The National Cyber Security Centre publishes broader guidance on remote access and network security that is worth reading alongside any specific vendor’s claims, since it sets out the baseline expectations regulators and auditors will assess a business against, independent of which product is in use.
None of this replaces basic CRM configuration work. HubSpot’s own documentation covers permission sets and session controls that sit on top of, not instead of, network level protection, and the same is true of Salesforce’s session security settings. A VPN choice should be made alongside a review of those in-platform controls, not as a substitute for checking them.
Related Reading
For more on this, see more RevOps strategy posts, including How SaaS Companies Should Count RFP Wins in Sales Quotas, PPC vs Organic Growth in SaaS: Balancing ROI and RevOps Strategy, and SaaS Webinar Strategies: Boost Engagement & Pipeline in 2025.
Frequently Asked Questions
Does a VPN fully protect CRM data on its own?
No. A VPN protects the network hop between a device and the wider internet, hiding traffic from local networks and ISPs. It does not stop phishing, credential theft, malicious browser extensions or anything else that happens on the device itself, so it needs to sit alongside CRM-level permission controls and endpoint security rather than replace them.
What is the difference between a VPN and Zero Trust Network Access for a sales team?
A traditional VPN grants broad network level access once a device connects, while Zero Trust Network Access authorises each request to each application individually without giving a connected device wide network reach. Teams with only a handful of SaaS tools often manage fine with a well configured VPN, while teams mixing legacy on-premises systems with multiple SaaS tools benefit more from the narrower access model of ZTNA.
Why do reps get logged out of the CRM when using a VPN?
This usually happens when a consumer VPN app rotates exit servers between locations mid session. Both HubSpot and Salesforce apply login anomaly detection based on IP geolocation, and rapid location changes can trigger step up authentication or a locked session, even though the rep has done nothing wrong.
Should every sales rep use a personal VPN app instead of a company one?
No. Personal VPN apps create a visibility gap for whoever manages CRM access, since there is no central way to see connections, revoke access on departure, or tie the VPN login to the same identity provider as the CRM. A business VPN with single sign on closes that offboarding gap by removing both accesses in one action.
Is a VPN enough to meet UK GDPR requirements for a sales team?
A VPN can count as one of the appropriate technical measures required under UK GDPR, but it does not cover the full set of obligations. The Information Commissioner’s Office guidance for organisations covers access control, retention and breach reporting requirements that sit well beyond network encryption alone.
Leave a Reply