Public WiFi creates risk because it often lacks encryption and can expose traffic to interception, session hijacking, or device compromise. When employees use a company device on open networks, the organisation inherits the consequences of weaker connection security. A secure VPN helps protect data in transit, but teams still need strong endpoint controls and user awareness.
Why public WiFi changes the threat model for a work device
Public WiFi is not just “less convenient” than a trusted office network. It places a work device onto an untrusted transport path where nearby attackers, rogue hotspots, and hostile network operators can observe or manipulate traffic if the connection is not strongly protected. That changes the risk from simple connectivity to exposure of corporate data, credentials, and active sessions.
Even when applications use encryption, the network still matters because DNS lookups, device metadata, portal logins, and weak or misconfigured traffic protections can reveal useful information. A work device also tends to hold higher-value access paths than a personal device, so any compromise can have a wider blast radius than the same behaviour on a consumer laptop.
For a useful comparison of real compromise patterns involving credentials, sessions, and exposed secrets, see The 52 NHI Breaches Report, which shows how attackers often turn a single exposed access path into broader movement or reuse.
What attackers and weak networks can actually do
The main dangers are interception, session theft, and trust abuse. On an open or poorly secured network, an attacker may try to capture unencrypted traffic, force a victim onto a fake access point, or exploit login flows that do not enforce strong transport protection end to end. If the device or application session is already authenticated, the attacker may not need the password again.
That is why a public network can become a stepping stone rather than the final target. Once an adversary gets a foothold in the connection path, they may attempt man-in-the-middle interception, token replay, portal spoofing, or malicious redirection to a lookalike service. For practitioners tracking active threat patterns and exploitation behaviour, CISA cyber threat advisories are a useful source for current attack trends and defensive context.
Public WiFi also increases exposure when users accept captive portals, install certificates, or override warnings to “get online quickly.” Those shortcuts can turn a temporary access decision into a persistent security problem if the device trusts the wrong network, the wrong certificate, or the wrong login prompt.
How organisations should reduce the risk without pretending it disappears
A VPN can protect traffic in transit, but it is not a full control by itself. It mainly reduces interception risk for data that is actually tunneled, while leaving endpoint compromise, malicious downloads, and user interaction risks in place. The safest pattern is to combine encrypted transport with device posture checks, patched endpoints, strong authentication, and restrictions on what a device can do off trusted networks.
Teams should verify three things before treating public WiFi as acceptable: the device is fully managed, remote access is strongly authenticated, and the connection is still protected if the user leaves the VPN or switches applications. The network is only one layer; the endpoint and the identity session are what determine how far a compromise can spread.
For a practical control baseline on endpoint hardening, access restriction, and monitoring, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control catalogue most teams map to device, access, and monitoring requirements. If you want the network-design principle behind reducing implicit trust, NIST SP 800-207 Zero Trust Architecture is the clearest reference for designing around least trust and verified access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Work-device public WiFi risk hinges on strong user authentication to limit session abuse. |
| IA-5 — Authenticator Management | Public WiFi increases exposure of credentials and sessions, making authenticator handling material. | |
| AC-17 — Remote Access | The question is about using a work device off-network, which is a remote access control problem. | |
| Recommendation — Enforce strong user authentication before granting remote access from untrusted networks. Rotate and protect authenticators so intercepted traffic cannot be reused easily. Restrict remote access paths to managed devices and approved secure tunnels. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Using work devices on public WiFi directly raises trust-boundary and verification concerns. |
| Recommendation — Design access so every request is verified rather than trusting the network location. | ||
Practitioner Guidance
What to verify: Confirm that managed devices enforce full-disk encryption, auto-lock, patch compliance, and a trusted VPN or equivalent secure access path before allowing public WiFi use. If those checks are not visible in policy and telemetry, assume the control is too weak for mobile work.
Common mistake: Treating “the user used a VPN” as the end of the control decision. That ignores whether the device itself is healthy, whether split tunnelling is acceptable, and whether sensitive apps still expose session risk outside the tunnel.
Decision rule: If the work device can reach production systems, customer data, or privileged admin tools, public WiFi should be treated as a higher-risk condition that requires stronger endpoint enforcement, not just user caution.
Practitioner takeaway: The real issue is not the WiFi name, it is whether an untrusted network can influence a trusted corporate session, and that must be bounded by encryption, managed endpoints, and access controls that fail safe.
Related resources from NHI Mgmt Group
- Why do public MCP servers increase risk in developer environments using local AI tools?
- Why do SEC cybersecurity rules increase personal risk for CISOs at public companies?
- Why do public-facing remote work logins increase security risk for identity teams?
- Why does using JWTs directly for public clients increase operational risk?