← Patterns / SP-007

Wireless- Public Hotspot Pattern

The Wireless Public Hotspot pattern addresses the security architecture required when corporate users connect to organisational resources from wireless networks outside the organisation's control. This includes hotel WiFi, airport lounges, coffee shops, conference venues, co-working spaces, and any other environment where the wireless access point infrastructure is operated by a third party and must be treated as completely untrusted. The fundamental difference from the Private Network pattern is trust: in a public hotspot scenario, you must assume that the access point, the local network, and all traffic between the client and the internet are visible to adversaries. The wireless encryption (if any) is shared among all users of the hotspot and provides no meaningful confidentiality between them. Man-in-the-middle attacks, ARP spoofing, DNS hijacking, and traffic interception are all realistic threats on public networks. The security architecture must therefore provide its own confidentiality and integrity protections independent of the local network infrastructure. The core defence is a VPN tunnel from the endpoint device to the corporate network perimeter. All corporate traffic is encrypted within the VPN tunnel before it reaches the untrusted wireless network, rendering local eavesdropping ineffective. The VPN concentrator at the corporate end acts as the trust boundary, authenticating the user and device before granting access to internal resources. Modern implementations use always-on VPN configurations that activate automatically when the device detects it is on an untrusted network, eliminating the window of exposure when users forget to connect manually. Endpoint protection is equally critical. The client device itself is directly exposed to the hostile local network and must be hardened accordingly. Personal firewalls configured to silently drop all unsolicited inbound connections prevent network-based attacks from other hotspot users. Host-based intrusion detection provides an additional layer of defence. Endpoint security posture -- current OS patches, active antivirus, enabled disk encryption -- must be verified before VPN access is granted, either through NAC health checks or MDM compliance policies. Strong multi-factor authentication prevents credential theft from being sufficient for network access. Certificate-based authentication stored on hardware tokens (smartcards, USB keys) or device TPMs provides the strongest assurance. Time-based one-time password tokens remain a common alternative. The authentication mechanism must be resistant to replay attacks and phishing, as users on public networks are at elevated risk of credential harvesting through captive portal spoofing and man-in-the-middle attacks.

Release: 26.02 Authors: Aurelius, Vitruvius Updated: 2026-02-06

Assess

ATT&CK This pattern addresses 347 techniques across 13 tactics View on ATT&CK Matrix →

Click any control badge to view its details. Download SVG

Key Control Areas

Mobile Device and Remote Access Control

AC-19

This is the anchor control for the public hotspot pattern. AC-19 governs access control for portable and mobile devices, establishing the policy framework for which devices may connect from untrusted networks, what security requirements they must meet, and what resources they may access. Implementation requires defining minimum device security baselines (OS version, patch level, encryption status, personal firewall enabled), mandating VPN usage for all corporate connectivity from public networks, restricting which applications and data may be used on devices connecting from untrusted environments, and establishing device wipe or lock capabilities for lost or compromised mobile devices. MDM enrollment should be mandatory for any device connecting from public hotspots.

User Authentication and Credential Protection

IA-02

Strong user authentication is the primary gate preventing unauthorised access from public networks. IA-02 requires robust identification and authentication, which in the public hotspot context means multi-factor authentication for VPN access -- a static password alone is insufficient given the elevated risk of credential interception on untrusted networks. Preferred implementations include certificate-based authentication via smartcard or TPM-stored credentials, hardware security keys (FIDO2/WebAuthn), or time-based OTP tokens. The authentication process itself must be protected against man-in-the-middle attacks, which means mutual TLS authentication for the VPN connection and server certificate validation to prevent users from connecting to fraudulent VPN endpoints.

Cryptographic Protection of Communications

SC-08 SC-09 SC-13

These controls collectively ensure that all corporate data traversing the untrusted wireless network is encrypted and integrity-protected. SC-08 (transmission integrity) and SC-09 (transmission confidentiality) are implemented through the VPN tunnel, which must use current cryptographic standards: IKEv2/IPsec or WireGuard with AES-256-GCM or ChaCha20-Poly1305. SC-13 (use of cryptography) governs the overall cryptographic approach, requiring FIPS-validated modules for regulated environments and prohibiting weak algorithms. The VPN must be configured for always-on operation on untrusted networks to eliminate gaps in protection. Split tunnelling should be disabled or carefully controlled to prevent data leaking outside the encrypted tunnel.

Continuous Monitoring and Vulnerability Management

CA-07 RA-05 AU-02

Monitoring takes on additional importance when endpoints operate on untrusted networks. CA-07 requires continuous monitoring of VPN connections, authentication patterns, and endpoint health. Anomalous connection patterns (unusual geographic locations, simultaneous connections, off-hours access) should trigger alerts. RA-05 covers vulnerability scanning of VPN concentrators, endpoint VPN clients, and remote access infrastructure -- these are internet-facing services and priority targets. AU-02 defines auditable events: VPN connection establishment and teardown, authentication successes and failures, health check results, and traffic volume anomalies. All VPN gateway logs should feed into the SIEM for correlation.

Security Assessment of Remote Access

CA-02

Regular security assessments (CA-02) of the remote access infrastructure must include penetration testing of VPN endpoints from the internet, validation that split tunnelling policies are enforced correctly, verification that endpoint health checks cannot be bypassed, review of authentication mechanisms for resistance to current attack techniques, and assessment of the VPN kill switch functionality that blocks internet access if the VPN tunnel drops. Assessments should simulate the public hotspot threat model including captive portal bypass, DNS manipulation, and certificate validation attacks.

Incident Response for Remote Access Events

IR-02 IR-04 IR-05 IR-06 IR-07

Remote access from public networks generates specific incident scenarios. IR-04 should include playbooks for: compromised VPN credentials, endpoint compromise while on untrusted network, detection of man-in-the-middle attacks against VPN connections, lost or stolen devices with VPN access capability, and mass VPN authentication failures suggesting credential stuffing. IR-05 covers continuous monitoring of remote access infrastructure for signs of attack. IR-06 and IR-07 handle reporting and coordination, which is more complex for remote workers who may not have immediate access to IT support. IR-02 ensures users receive training on recognising and reporting suspicious behaviour while working from public networks.

Training for Remote and Mobile Workers

AT-01 AT-03 AT-04

Users who connect from public hotspots face unique threats requiring specific training. AT-03 should cover: recognising fake captive portals and WiFi impersonation, verifying VPN connection before accessing corporate resources, physical security of devices in public spaces (shoulder surfing, theft), understanding why split tunnelling restrictions exist, reporting lost or stolen devices immediately, and avoiding sensitive transactions on untrusted networks when VPN is unavailable. AT-01 establishes the policy framework and AT-04 ensures training completion is tracked, particularly for roles with frequent travel that rely heavily on public network access.

When to Use

Apply this pattern when corporate users need to access organisational network resources from wireless networks not controlled by the organisation: hotels, airports, conference venues, coffee shops, co-working spaces, or any other public or semi-public WiFi. This pattern is appropriate when the organisation cannot guarantee the security of the wireless infrastructure and must treat the entire local network as hostile. It also applies as a fallback for private wireless networks running weak encryption (WEP) where the wireless link itself cannot be trusted. This pattern does not cover Bluetooth, Infrared, or cellular connectivity.

When NOT to Use

This pattern is not necessary when connecting from the organisation's own managed private wireless network (use the Wireless Private Network pattern instead). It is not appropriate for highly sensitive operations where the risk of endpoint compromise on a hostile network is unacceptable -- in such cases, a dedicated secure facility with wired connectivity should be used. The pattern assumes a level of endpoint management that may not be achievable for BYOD scenarios where the organisation has limited control over the device; in those cases, consider virtual desktop infrastructure (VDI) or browser-based access that keeps data off the endpoint entirely.

Typical Challenges

User experience and compliance are the primary operational challenges. VPN connections introduce latency and may conflict with captive portal authentication flows common in hotels and airports, leading users to disable VPN or work without it. Always-on VPN with captive portal detection helps but is not foolproof. Strong authentication should be as frictionless as possible -- certificate-based authentication stored on smartcards or in device TPMs provides both strong security and seamless user experience compared to manually entering OTP codes. Endpoint configuration management is critical: OS patches, application updates, antivirus signatures, and personal firewall rules must be kept current on devices that may spend extended periods away from the corporate network and unable to reach internal update servers. Cloud-based patch management and MDM solutions address this but require reliable internet connectivity. Split tunnelling creates a tension between security (all traffic through the VPN) and performance (local internet breakout for non-corporate traffic). The security risk of split tunnelling is that malware or an attacker on the local network can access the device while it has a live VPN connection to the corporate network, creating a bridge. Bandwidth constraints at public hotspots can make VPN usage impractical for bandwidth-intensive work, pushing users toward workarounds.

Threat Resistance

This pattern provides strong resistance against network-level eavesdropping and traffic interception by encrypting all corporate traffic within a VPN tunnel, making local network monitoring ineffective. Multi-factor authentication resists credential theft and replay attacks that are elevated risks on untrusted networks. Personal firewalls block network-based attacks from other users on the same hotspot. Endpoint health verification prevents compromised or unpatched devices from establishing corporate connections. The pattern mitigates man-in-the-middle attacks through mutual VPN authentication and server certificate pinning. It provides partial resistance against captive portal spoofing and DNS hijacking through VPN DNS enforcement. It does not fully mitigate physical theft of devices (addressed by disk encryption and remote wipe), targeted endpoint exploitation by sophisticated adversaries with local network access, or RF-level denial of service against the wireless medium.

Assumptions

The organisation provides managed endpoint devices with pre-configured VPN clients, personal firewalls, and endpoint protection software. A VPN concentrator or gateway is deployed at the corporate network perimeter with capacity for the expected remote user population. Multi-factor authentication infrastructure (certificate authority, token management, or FIDO2 server) is operational. The organisation has the ability to enforce device compliance policies and remotely manage or wipe devices. Users have been trained on VPN usage and public network risks. Network intrusion detection is deployed on the corporate side to inspect traffic arriving through VPN tunnels.

Developing Areas

Passpoint (Hotspot 2.0) adoption remains limited despite being designed to solve the fundamental insecurity of public hotspot authentication. Passpoint enables WPA2/WPA3-Enterprise authentication on public networks using existing operator credentials, eliminating captive portals and providing per-user encryption. However, deployment requires coordination between venue operators, mobile carriers, and identity providers -- a multi-stakeholder alignment challenge that has slowed rollout to a small fraction of public venues, primarily airports and large hotel chains.
DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) are undermining network-layer security controls that organisations have traditionally relied upon for public hotspot protection. When endpoint DNS traffic is encrypted directly to third-party resolvers (Google, Cloudflare), captive portal detection fails, DNS-based threat intelligence feeds are bypassed, and corporate DNS filtering policies become unenforceable. The tension between user privacy (encrypting DNS) and corporate security (inspecting DNS for threats) is unresolved, and browser vendors continue to enable DoH by default regardless of enterprise policy preferences.
VPN-always-on enforcement faces growing challenges on mobile platforms. iOS and Android impose restrictions on background VPN connectivity that can cause tunnels to drop silently, creating unprotected windows that users are unaware of. Battery optimisation features kill VPN processes, app-based VPN configurations do not cover all traffic, and captive portal detection logic in mobile operating systems necessarily bypasses VPN to complete network authentication. Vendors are working around these limitations with OS-level integrations, but reliable always-on VPN on mobile devices connected to public hotspots remains a persistent operational challenge.
The convergence of ZTNA and traditional VPN is creating a new generation of remote access solutions that handle public hotspot scenarios more gracefully. Unlike VPN, which places the device on the corporate network after authentication, ZTNA solutions broker per-application access with continuous device posture evaluation. For public hotspot users, this means compromised local networks cannot be leveraged to pivot through the VPN tunnel. However, ZTNA client software must still negotiate with captive portals, and the transition from VPN to ZTNA for the full application portfolio typically takes 12-24 months.

Related Patterns

Patterns that operate within or alongside this one. Click any to view.

SP-001 Client Module SP-006 Wireless Private Network SP-015 Consumer Devices for Enterprise SP-016 DMZ Module SP-024 iPhone Pattern SP-025 Advanced Monitoring and Detection

AC: 1AT: 3AU: 1CA: 2IA: 1IR: 5RA: 1SC: 3

AC-19 Access Control For Portable And Mobile Devices

AT-01 Security Awareness And Training Policy And Procedures

AT-03 Security Training

AT-04 Security Training Records

AU-02 Auditable Events

CA-02 Security Assessments

CA-07 Continuous Monitoring

IA-02 User Identification And Authentication

IR-02 Incident Response Training

IR-04 Incident Handling

IR-05 Incident Monitoring

IR-06 Incident Reporting

IR-07 Incident Response Assistance

RA-05 Vulnerability Scanning

SC-08 Transmission Integrity

SC-09 Transmission Confidentiality

SC-13 Use Of Cryptography