Consumer VPN vs Digital Nomad Security: Client Guidance
Use this when a client or MSP partner asks whether a consumer VPN (PIA, Nord, etc.) "secures" their remote workforce. The short answer is no. This article gives the reasoning, the correct stack to recommend, and the travel-router guidance for the one narrow problem a VPN does address.
Overview
A consumer VPN encrypts traffic between the user's laptop and the provider's exit node so someone on the same Wi-Fi cannot read or tamper with it. That is the entire security benefit, and TLS already covers most of it for normal web use. Making a digital nomad safe is an identity, endpoint, and access problem, none of which a consumer VPN touches.
Item | Value |
Bottom line | Consumer VPN is a privacy product, not a security program |
The real problem | Identity, endpoint, and access. Not a VPN purchase |
Correct internal-access answer | Uplevel ZTNA, not a flat tunnel |
Travel router (fastest) | |
Travel router (balanced) | |
Travel router (smallest/economical) | |
Router setup video | GL.iNet first-time setup (YouTube) |
What a Consumer VPN Does Not Do
- Does not authenticate the user to client resources. The tunnel has no idea whether the device on the other end is the corporate laptop or a compromised personal machine.
- Does not check device posture. By contrast, Uplevel ZTNA can gate access on patched OS, disk encryption, EDR running, screen lock, and geo-location, allowing or denying per resource based on device posture.
- Does not provide access to internal resources. The user still needs file shares, LOB apps, and RDP. A consumer VPN drops them onto the public internet from a foreign exit IP and nothing more.
- Does not stop phishing, credential theft, session hijacking, or endpoint compromise. If the laptop is owned, the VPN tunnels the attacker's traffic along with everything else.
- Gives zero visibility. No logs, no alerting, no per-user revocation, no audit trail.
The Real Digital Nomad Threat Model
In order of impact:
- Phishing and credential theft.
- Endpoint compromise.
- Lost or stolen devices.
- Lateral movement once one credential is stolen.
- Local Wi-Fi snooping.
Local Wi-Fi snooping, the one thing a consumer VPN addresses, is at the bottom of the list, and TLS already handles most of it.
The Recommended Security Stack
This is what to put in front of a client. The VPN question is a distraction from these controls.
- SSO with strong MFA in front of everything. Passkeys or TOTP, never SMS.
- ZTNA for internal access. Per-application access brokered by identity instead of a flat tunnel onto the LAN, so a stolen credential exposes one app, not the whole network. This is exactly what Uplevel ZTNA does and it is the correct answer to remote access for the client base.
- Managed endpoints. Disk encryption, EDR, patching, screen lock, restricted admin rights. Device posture gates the ZTNA connection so a non-compliant machine cannot get in.
- DNS filtering on the device, since the digital nomad is rarely behind the office gateway.
- Company-provisioned travel router for high-mobility staff. See the next section. This is a situational add for travelers, not a baseline control for everyone.
- Backup, so a lost device or a ransomware hit is an inconvenience instead of a disaster.
- Phishing awareness training, since that is the number one vector and the cheapest control to deploy.
Travel Router Guidance
A travel router is the correct way to address the one bottom-tier risk a VPN aims at. A laptop VPN client is the weak way to do it: the laptop is still directly on the hostile LAN, so ARP spoofing, rogue DHCP, rogue DNS, and mDNS or LLMNR poisoning all reach it at layer 2 before or alongside the tunnel.
A GL.iNet travel router fixes that properly:
- Every device sits behind the router's own NAT. The hostile network only ever sees the router's MAC and an opaque tunnel.
- The user's actual devices never broadcast on the hostile segment.
- The kill switch is enforced at the gateway instead of per app.
- Captive portal auth happens once on the router instead of leaving each device naked on the LAN while a client negotiates.
- It collapses the entire layer 2 attack surface and gives consistent egress protection and logging.
It still does nothing for the four risks above local Wi-Fi snooping.
Model Selection
Vendor throughput figures below are local-network lab maximums. Real-world VPN speeds are lower and depend on the upstream link and exit.
Model | Class | WireGuard (vendor max) | OpenVPN (vendor max) | Notes |
| Fastest, Wi-Fi 6, quad-core | ~550 Mbps | ~120 Mbps | Best pick for users who need near-gigabit with the tunnel up |
| Balanced, Wi-Fi 6, 2.5G WAN | ~300 Mbps | ~150 Mbps | Good all-rounder, smaller than Slate AX |
| Smallest, cheapest, 2.4GHz only | ~45 Mbps | ~11 Mbps | Good all-rounder, smaller than Slate AX |
The Beryl AX or Slate AX class are the larger but faster models. The Mango is the smallest and cheapest and is sufficient for typical work plus a ZTNA tunnel, but it caps out well short of gigabit.
The router becomes the trust boundary once deployed, replacing the role PIA or Nord would have played. Keep firmware current. Stale GL.iNet OpenWrt firmware has known CVEs.
Setup is straightforward. Hand field techs or the end user the
GL.iNet first-time setup video. It covers Ethernet, Repeater, Tethering, and Cellular WAN modes.
Client Summary and Talking Points
Use this framing directly with the client:
- A consumer VPN protects against a technical adversary at a cafe or hotel snooping on internet traffic. That matters, but TLS already covers the majority of that threat.
- A travel router does that same job properly. Both still only protect against someone on the cafe or hotel network.
- Making a digital nomad safe is an identity, endpoint, and access problem. None of those words are on the PIA or Nord website, though their marketing uses language designed to make you feel like they are.
- If the client wants the local-network protection, they can run a travel router, but it rides on top of the real controls, not in place of them.