Remote employees on public Wi-Fi should use company-managed endpoint protection, a secure remote access method, and DNS and web filtering that blocks known malicious sites. Traffic should be encrypted end to end, authentication should require MFA, and device posture should be checked before access. Disable split tunnelling where policy requires inspection of sensitive traffic.
How public Wi-Fi changes the web security problem
Public Wi-Fi changes the trust model, not just the transport medium. A remote employee may be on a network they do not control, with unknown peers, potentially hostile access points, and weaker visibility into who is observing or redirecting traffic. That makes browser sessions, DNS lookups, and login flows more valuable targets than the Wi-Fi connection itself.
The practical issue is that the web stack becomes the enforcement point. If the device can reach the internet directly without inspection, malicious domains, phishing pages, drive-by downloads, and policy-bypassing proxies have a much easier path. A secure remote access design therefore needs to control both where traffic goes and how it is authenticated before it is trusted.
For teams designing that layer, the most useful starting point is a Secure Web Gateway and Web Filtering Guide, because web filtering is only effective when URL policy, DNS behavior, proxy handling, and exception logic are considered together.
Which controls matter most on unmanaged networks?
The highest-value controls are the ones that reduce exposure before the browser can reach a risky destination. DNS filtering blocks many known-bad domains early, while web filtering and secure proxying can classify content, enforce policy, and stop access to uncategorized or suspicious sites. Encryption is also essential, but encryption alone does not prevent a user from reaching a hostile destination.
Remote access should add an authenticated control point, not just a tunnel. Company-managed endpoint protection helps by enforcing local security state, and MFA makes stolen passwords less useful. Device posture checking adds another gate, so the organisation can require a managed, healthy endpoint before allowing access to internal applications or sensitive web traffic.
If the environment depends on remote connectivity, the remote access path itself should be built around strong identity checks and endpoint trust. The Remote Access Identity Guide is a useful reference when you need to align VPN, ZTNA, MFA, and device posture as one control chain.
Where the exposure is especially browser-driven, a remote employee’s endpoint should be validated against a Web Application Security Testing Guide mindset, because the same controls that defend web applications also matter when users are reaching them from untrusted networks.
What to harden in the browser path and the access path
There are two distinct places to harden. First is the access path: require encrypted transport end to end, enforce MFA, and inspect traffic where policy requires it. If sensitive web traffic can bypass corporate inspection, split tunnelling becomes a policy decision with a security consequence, not just a performance setting. Second is the browser path: limit risky sites, downloads, and unknown destinations with filtering and endpoint controls.
Do not treat “on VPN” as a complete answer. A tunnel that bypasses inspection may protect confidentiality while leaving malware delivery, phishing, and command-and-control reachability less visible. Likewise, a web filter without endpoint protection can reduce destination risk but still leave the device vulnerable to malicious downloads or script-based compromise.
For broader browser-side risk reduction, the Client-Side Security Guide is relevant where third-party scripts, browser extensions, and page-level abuse become part of the attack path.
Risk and Threat Considerations
Public Wi-Fi creates an exposure window where attackers can try phishing, captive-portal abuse, rogue access points, DNS manipulation, and session interception. The biggest practical danger is not the Wi-Fi signal itself, but the way a weak remote-access design can let a user reach harmful content or disclose credentials before the organisation can apply policy.
Failure mechanism: If DNS, web traffic, or login flows are allowed to bypass inspection or strong identity checks, an attacker can redirect the user to a malicious destination, harvest credentials, or deliver malware before the endpoint or gateway can intervene.
Impact: The result can be account compromise, malware infection, data exposure, or unauthorized access to internal systems, especially when a compromised browser session is reused to reach work applications.
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 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Remote workers need strong user authentication before access on untrusted networks. |
| IA-5 — Authenticator Management | The answer depends on protecting passwords, tokens, and MFA authenticators used remotely. | |
| SC-7 — Boundary Protection | Secure remote access, filtering, and split-tunnel decisions are boundary-control issues. | |
| Recommendation — Require strong user authentication with MFA before granting remote web access. Manage credential lifecycle and rotate or revoke exposed authenticators promptly. Route sensitive remote traffic through controlled inspection points and restrict bypass paths. | ||
Practitioner Guidance
What to prioritise: Start with the controls that reduce blast radius before focusing on convenience features. Managed endpoints, MFA, posture checks, and web filtering should be in place before you debate whether split tunnelling is acceptable for a role.
What to verify: Confirm that remote access policies actually enforce inspection for the traffic classes you care about, that DNS filtering cannot be trivially bypassed, and that the endpoint cannot be used as a trusted path when posture is unknown or stale.
Decision rule: If the traffic can reach sensitive internal or SaaS resources, default to full inspection and strong authentication; if performance requires exceptions, treat them as explicit risk acceptances with narrow scope and monitoring.
Practitioner takeaway: On public Wi-Fi, the control objective is not “make the connection look secure”, it is “make untrusted networks irrelevant by forcing every meaningful request through trusted identity, policy, and inspection points.”
Related resources from NHI Mgmt Group
- How should security teams handle public Wi-Fi risk for remote users?
- Why do public Wi-Fi networks create such a high risk for travelling employees?
- What happens when employees use public Wi-Fi without extra protections?
- How should organisations reduce public Wi-Fi risk for remote workers and travelling staff?