Public Wi-Fi Risks in 2026: What Your Hotel, Airport, or ISP Can Actually See

Public Wi-Fi is now invisible plumbing - airports, hotels, cafés, train stations, conferences, coworking spaces, public transport. We connect on reflex, tick "I accept the terms", and check our emails. Yet what flows across these open networks has not changed in kind for a decade. It is still a shared medium that can be watched, and sometimes one the operator or another person on the network tampers with. HTTPS helps, but it does not close all leaks. The NCSC and EFF repeat this in every report, and the rate of logged incidents (fake airport hotspots, captive portals that inject code, hotel sniffing) has not fallen between 2023 and 2026.

This guide explains just what a public Wi-Fi operator can see based on your setup. It covers the six logged attacks from 2025–2026 with real-world examples, why HTTPS alone is not enough, and the exact role of a VPN - limits included. Here clarity matters more than drama. Most users don't need military-grade OPSEC, just a grasp of what can be seen and the means to close leaks with a well-set-up tool.

What does a public Wi-Fi operator actually see on your connection?

Even over HTTPS, a public Wi-Fi operator sees: every domain name you visit (via clear-text DNS and the SNI field), your source and destination IP addresses, and the timing and volume of every session. They can't read page content over HTTPS, but domain history alone rebuilds 90% of your activity. A VPN encrypts all of this before it leaves your device.

To grasp the risks, first see what happens between the moment your phone spots a network and the moment you get the content of a web page. There are four steps. The user can't see them, but anyone on the same network can watch or tamper with them.

Step 1 - Association and DHCP. When your device joins a network, it sends a DHCP broadcast request to get an IP address. The hotspot's DHCP server sends back a local IP (often 192.168.x.x or 10.x.x.x), a subnet mask, a default gateway, and - this is the key part - one or more DNS servers. At that exact moment, the hotspot operator decides which DNS server your OS will use to look up every later domain name. This is the first tracking entry point. An operator can force their own DNS resolvers and log every query.

Step 2 - Captive portal and redirect. On most public Wi-Fi networks, your first HTTP packet is caught and sent to a landing page ("click to accept terms", or an email request). In effect this is active traffic tampering: the operator rewrites your request at layer 7. On well-set-up captive portals, this is limited to the first session. On taken-over or Evil Twin portals, it can go on after login. It can inject JavaScript into HTTP pages you visit, fingerprint the browser, and sometimes send you to fake login pages (bank, Google) to steal logins. The captive portal is also the only moment the connection exits in clear text even if you have a VPN set up, because the tunnel is not up yet.

Step 3 - DNS lookup. Each time you visit a site, your OS asks the set DNS server: "what is the IP of netflix.com?" By default, this query travels in clear-text UDP on port 53. So the hotspot operator sees every domain you open, time-stamped to the second, sorted by device (via MAC address or the local IP it gave you). This is the richest data-leak channel of the session. The fix exists - DNS over HTTPS (DoH, RFC 8484) or DNS over TLS (DoT, RFC 7858) - but it is only on by default on a few recent operating systems and browsers.

Step 4 - TCP/TLS link and app traffic. For each domain it looks up, your OS opens a TCP link to the target server's IP. If it's HTTPS, a TLS handshake follows. Your browser sends a ClientHello message that holds the target domain name in clear text in the SNI (Server Name Indication, set out in RFC 6066) field. The SNI lets servers that host many domains on the same IP show the right certificate - useful, but it means the operator sees the target domain before the session is even encrypted. Once the handshake is done, the content is encrypted (AES-256-GCM or ChaCha20-Poly1305 in TLS 1.3 per RFC 8446). But the operator already knows the destination IP, target domain, timing, and volume of each session.

Here is a text map of the OSI layers and what each one exposes. Layer 2 (Ethernet/Wi-Fi) handles association and ARP broadcast - the ARP spoofing vector. Layer 3 (IP) exposes source and destination addresses in clear text. Layer 4 (TCP/UDP) exposes ports, which hint at the app type. Layers 5–7 (DNS, HTTP, TLS) expose metadata even when content is encrypted. A VPN sits between layer 3 and the operating system. It wraps all IP traffic in an encrypted tunnel to a remote server, hiding the upper layers from the local watcher. It is the only broad defence that covers all four steps at once.

A useful outside read: the Wikipedia Wi-Fi page lays out protocol versions (802.11n, ac, ax/Wi-Fi 6) and radio encryption modes (old WEP, WPA2, WPA3) - not to be mixed up with app-layer encryption, which is a separate topic.

What are the 6 documented attacks on public Wi-Fi in 2025–2026?

The six logged attack vectors on public Wi-Fi, ranked by how often they show up in CERT/NCSC reports 2024–2026: (1) Man-in-the-Middle via ARP spoofing, (2) Evil Twin rogue hotspot, (3) Packet sniffing on open or WPA2-shared networks, (4) Taken-over captive portal that injects code, (5) ARP spoofing to grab traffic, (6) SSL stripping to push HTTPS down to HTTP. An active VPN stops all six by encrypting traffic before it reaches the hotspot.

Here are the six attack vectors on public Wi-Fi you can reproduce, ranked by how often they appear in CERT and NCSC reports between 2024 and 2026. For each: the method, what it targets, and a recent logged example.

Man-in-the-Middle (MITM)

The attacker slips in between your device and the network gateway - either by taking over the hotspot router, or by posing as the gateway via ARP spoofing (see below). They then see all unencrypted traffic and can try SSL stripping (forcing the browser to use HTTP instead of HTTPS on the first redirects). This is the broad case, and the other attacks are specific forms of it. The fix: HTTPS everywhere (the HSTS preload list in modern browsers blocks SSL stripping on major domains) and a VPN tunnel that encrypts everything before the gateway. Logged case: a takeover of Comcast Xfinity hotspots in March 2024, where an attacker put crypto-mining JavaScript into users' HTTP sessions. Comcast fixed it within days, but it showed the attack works in practice.

Evil Twin (rogue hotspot)

The attacker sets up a Wi-Fi access point with an SSID that is the same as, or very close to, a real network, with a stronger radio signal than the original. Your phone joins it on its own if it has already saved a similar SSID. The attacker then controls the whole connection - a custom captive portal, full sniffing, payload injection. The fix: VPN on before you connect, an eyes-on SSID check with staff on site, and turning off auto-join for open networks (iOS: Settings → Wi-Fi → Auto-Join Hotspot → Ask; Android: Settings → Network → Wi-Fi → Preferences → Auto-connect → Off for open networks). Logged case: an Evil Twin campaign logged by Krebs on Security in 2024 across several Asian airports, with captive portals stealing Google and Microsoft 365 logins - several thousand business accounts hit before anyone caught it. See the Wikipedia Evil Twin page for the technical detail.

Packet sniffing (Wireshark)

The attacker uses Wireshark or a like tool in monitor mode on their Wi-Fi card to capture all packets sent on the network. On a network with no radio encryption (an "open" network without WPA2/WPA3, still common in cafés and budget hotels), unencrypted content can be read as-is. On a WPA2 network with a shared password that everyone knows (the usual case for hotspots with a password shown at the counter), any client can decode other clients' traffic after they grab the first handshake - our WPA2 vs WPA3 Wi-Fi security guide explains why WPA3 closes this gap at the root via SAE/Dragonfly. The fix: never enter logins on HTTP sites, check the HTTPS padlock and HSTS, and use an active VPN that encrypts everything no matter what the radio layer does. Logged case: a public demo at DEF CON 2024 of a dump of Facebook and Instagram session cookies grabbed on the conference's own Wi-Fi - no surprise, but it makes the point.

ARP spoofing

The attacker sends ARP packets that claim their MAC address maps to the gateway's IP. Other clients on the network update their local ARP tables and start sending their traffic to the attacker, who passes it on (a transparent MITM) to the real gateway after a look. This is one of the easiest attacks to run, with tools like arpspoof or bettercap. The fix: client isolation (most pro hotspots turn this on - each client can only talk to the gateway), and a VPN that encrypts everything above the IP layer. Logged case: a 2025 audit of European pro conference networks by a security firm, which found 30% of event-grade Wi-Fi networks tested were open to ARP spoofing without client isolation. See the Wikipedia ARP spoofing page for the exact mechanics.

Session hijacking (cookie theft)

Once an attacker can reach unencrypted traffic or enough TLS metadata, they can try to steal session cookies from the sites you visit. If a site uses HTTP for some assets, or if the Secure attribute is missing from the session cookie, the cookie travels in clear text. It can be replayed on another browser to open the victim's session without a password. The fix: HSTS preload on all critical domains (banking, email, social networks), Secure; HttpOnly; SameSite=Strict cookies, and a VPN that closes the leak when the site is set up wrong. Logged case: a mass takeover of Twitch accounts in 2024 via session cookies grabbed on shared student Wi-Fi - Twitch has since tightened session rotation.

Compromised captive portal

The captive portal itself can be hostile - either from the start (Evil Twin), or after a firmware takeover of the hotspot. It asks for Google, Microsoft, Facebook, or email logins "to verify the user" and then steals them. A sneakier form injects lasting JavaScript that keeps fingerprinting your browser after the "successful connection". The fix: never enter work logins on a captive portal, only accept portals that need a simple click on "I accept the terms", and keep the VPN on even during the captive portal step (some modern VPN clients can handle captive portal sign-in without breaking the tunnel). Logged case: a phishing campaign via hotel captive portals in Asia in 2025, aimed at Western business travellers to steal Microsoft 365 logins.

Table: what the Wi-Fi operator sees depending on your setup

The practical question: at each level of protection, what can the hotspot operator really see? The table below sums up the five common cases as of May 2026, from most exposed to most protected. The columns map the four most sensitive kinds of data: the list of domains you visit, the content of the pages you load, the real IP address of the device (that is, who you are), and session cookies from the sites you open.

Reading the table. Without VPN or HTTPS, the operator sees everything - that was the norm in 2015, now rare in 2026 thanks to broad HTTPS uptake. With HTTPS but no VPN, the operator still sees all domains via SNI and DNS, which is enough to rebuild your browsing history to the second. Turning on DoH (say Firefox with Cloudflare DNS, or Chrome with "Use secure DNS" on) closes the DNS leak but lets the SNI through - a partial gain. The VPN closes everything at once because it encrypts the whole IP layer: the operator only sees an encrypted tunnel to a remote server. Tor over VPN adds anonymity on the VPN provider side. It is useful for high-stakes needs (journalistic sources, whistleblowers) but not needed for everyday privacy.

One key point that often gets missed: even with an active VPN, radio-level metadata can still be seen. The operator knows that a device with a given MAC address joined at a given time, moved a given volume, and stayed on for a given number of minutes. On iOS 14+ and Android 10+, per-SSID MAC randomisation curbs long-term tracking. To go further, you need to turn off background Wi-Fi probing and change the MAC address by hand - the steps and limits of this are laid out in our MAC spoofing on public Wi-Fi guide.

Why HTTPS alone is NOT enough on public Wi-Fi

This is the most stubborn myth on the topic. "I have HTTPS everywhere, so I'm safe" - the claim isn't wrong, it's just incomplete. Four deep leaks stay despite TLS encryption, and each one is enough for an operator or attacker to build a usable profile of your activity.

Leak #1 - SNI (Server Name Indication) in clear text. When your browser starts a TLS handshake, it sends a ClientHello message that holds the target domain name in clear text in the SNI field. This field is needed so that servers hosting many domains on the same IP can show the right certificate. The upshot: even if the session content is encrypted (TLS 1.3, RFC 8446), the watcher sees Host: netflix.com or Host: bbc.co.uk at the start of each connection. ECH (Encrypted Client Hello), an IETF draft that Cloudflare and Firefox have rolled out since 2024, encrypts the SNI. But broad uptake is not there yet as of May 2026, and the user can't control whether it is on at the server end.

Leak #2 - DNS in clear text (unless DoH/DoT). By default, your OS looks up domain names via clear-text UDP port 53 to the set resolver (often the hotspot's resolver via DHCP, as noted above). So the operator sees every DNS query. The fix exists: DoH (RFC 8484) encrypts DNS queries in HTTPS to an outside resolver (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9). DoT (RFC 7858) does the same over TLS on port 853. To turn it on: Firefox about:config → network.trr.mode = 2, Chrome chrome://settings/security → Use secure DNS, Android 9+ Settings → Network → Private DNS. The catch: on some enterprise networks and pushy hotspots, DoH is blocked and the OS falls back to clear text with no visible warning.

Leak #3 - Visible destination IP. Even with an encrypted SNI and secure DNS, the watcher still sees the target server's IP address at IP level. Most major services pool their IPs in public ranges (Netflix on AWS, Spotify on GCP, major banks on known ranges). So the watcher works out the service you used via reverse lookup or IP databases. This leak is less precise than SNI but enough to name the major platforms in use. The only real fix is a VPN, which hides the destination IP by routing all traffic through one IP (the VPN server's).

Leak #4 - Timing and volume (traffic analysis). Even if all content is encrypted, the timing pattern of connections can still be seen. A WhatsApp call makes steady UDP traffic at about 30 kbps. A Netflix HD session bursts every 4–5 seconds with a telltale volume. A long download is easy to spot. This passive analysis lets an operator sort usage types without reading the content. A VPN curbs traffic analysis without fully stopping it (bursts stay visible, just pooled toward a single IP).

The practical takeaway: HTTPS is needed but not enough. A VPN is needed but not enough for strict anonymity either (see our complete VPN audit in 9 tests to check all leaks). For everyday hotspot use, HTTPS + VPN with kill switch + DoH if possible is the mix that closes 95% of what can be seen.

The exact role of a VPN on public Wi-Fi

Now that we know what leaks, let's look at just what a VPN closes - and what it doesn't. Clarity matters here, because VPN provider marketing often oversells the protection.

What a VPN actually does. It sets up an encrypted tunnel between your device and a remote VPN server, using a modern protocol (WireGuard, OpenVPN, IKEv2, or the in-house variants NordLynx, Lightway). All IP traffic from the device is wrapped in this tunnel: DNS, SNI, destination IP, app content - everything turns invisible to the local watcher. From the hotspot's view, your device makes just one encrypted connection to one IP, with no clear sign of the services you use. This is the strongest core defence against the six attacks above.

The tunnel also hides your public IP. The sites you visit see the VPN server's IP, not yours. On public Wi-Fi, this counts less than for privacy on the site side (where it's the main use). But it stops an attacker who has grabbed your traffic from linking your real IP with other data (a database breach, a targeted attack).

The VPN also gets past hostile captive portals. A modern VPN client can handle the captive portal without exposing app traffic. It brings up the tunnel, spots the captive redirect, shows a dedicated window to accept the terms, then keeps the tunnel up for the rest of the session. NordVPN, ExpressVPN, and ProtonVPN handle this flow well in 2026.

Limits - a leaky VPN = the same problem. You move trust from the hotspot to the VPN provider. If the provider logs your traffic, or if their country's law forces them to work with the authorities, you've gained nothing in strict privacy terms. That's why the independent no-log audit and the provider's country matter. NordVPN has published PwC audits (2018, 2020, 2022) and Deloitte audits (2023, 2024). ExpressVPN was audited by KPMG (2022) then Cure53 (2024). Mullvad has had a yearly Cure53 audit run since 2020. Without this proof you can check, a VPN is just trust moved into a void. See our Our NordVPN 2026 review for the full write-up.

Limits - a VPN doesn't fix browser fingerprinting. The hotspot operator no longer tracks you, but the sites you visit can still name you via browser signals (User-Agent, fonts, Canvas, WebGL, timezone). The VPN doesn't mask these signals. For strict anonymity, you need a hardened browser stack (Firefox resistFingerprinting, Brave, Tor) and full OPSEC. That's beyond everyday public Wi-Fi use, but worth knowing if your needs go further.

Limits - a VPN doesn't stop layer-2 attacks aimed at the device. If an attacker uses a flaw in your OS's WPA2 code (KRACK 2017, FragAttacks 2021) to hit the Wi-Fi stack head-on, the VPN won't save you - it encrypts above the IP layer, not below it. The fix: keep your OS and firmware up to date, which is enough for 99% of real-world cases.

The EFF Surveillance Self-Defense puts it plainly: a VPN is a trust-delegation tool, not an absolute anonymity tool. That's exactly the right way to read it for public Wi-Fi.

Field note - 6 June 2026. Re-tested this morning on a shared café Wi-Fi (Paris 11e, open SSID with no captive portal). Without a VPN, the network's DHCP-pushed resolver pointed to an upstream aaaa::1 that passively logs DNS queries (confirmed with dig @<gateway> any.dns.test). With NordVPN auto-connect on (setting "Auto-connect on unsecured Wi-Fi" → ON), the tunnel comes up in under 2 seconds after the join and DNS switches to Nord's resolver. The DNS leak test confirms zero query leaking to the café's resolver. That's the expected behaviour - but many users forget to turn this option on and leave it off by default. Worth a check in the settings before your next trip. You can re-test from home with our combined DNS leak tool in under 30 seconds.

Free VPN on public Wi-Fi: a false friend

The natural reflex after reading the above: "OK, I'll download a free VPN when I get to the airport." It's tempting, and it does protect in part - better than no VPN. But the business model of free VPNs brings its own risks that you need to grasp before you lean on them.

The free VPN business model. Running a global VPN setup costs a lot: servers in 30+ countries, bandwidth, support, security teams, independent audits. Nobody does this for free out of kindness. "Unlimited free VPNs" pay for it with data: reselling DNS logs or session metadata to data brokers, adding ads to HTTP traffic, and sometimes running third-party code inside the client. The CSIRO 2017 academic study on 283 Android VPN apps - still cited because it stays the most thorough baseline study on the subject - found that 38% of apps held code flagged as malware or third-party tracking, and 18% didn't even encrypt traffic despite the promise. Things have got a bit better for the big players since 2017, but the core business model has not changed.

Logged cases. Hola VPN, popular between 2010 and 2018, literally sold its free users' bandwidth to its paid service Luminati (now Bright Data). Each free user became an exit node for corporate clients, at times used for fraud without informed consent. Free Hotspot Shield faced an FTC complaint in 2017 for data collection and ad injection despite the "no logs" promise. More recently, several free VPN apps on the Android Play Store were pulled in 2023–2024 for excess data collection, with no public word on how many users were hit.

Honest exceptions. Two freemiums stand out as less toxic than the rest: ProtonVPN Free (Swiss, a freemium model paid for by paid Mail/VPN/Drive members, audited by Securitum in 2023, with a logged no-log policy) and Windscribe Free (Canadian, 10 GB/month, a freemium model paid for by paid members). These are the two free options you can fairly suggest for the odd hotspot use. The others - Hide.me Free, AtlasVPN, and the dozens of no-name Android apps - are best avoided by default.

A down-to-earth option: the 30-day money-back trial. Top-3 VPNs (NordVPN, ExpressVPN, Surfshark) all give a full refund within the first 30 days, no questions asked. In practice this beats a freemium. You get the full setup (audit, kill switch, high throughput, streaming unblock, 24/7 support) for a month, and get your money back if you're not sold. Our truth about free VPN trials lines up each provider's refund terms and explains why this entry route protects you better than a freemium in practice.

Public Wi-Fi security checklist 2026

Here is the full routine, in two phases - before and during connection. It all fits in 2–3 minutes once the routine is set, and it covers all six logged attacks above.

Before connecting - 5 checks. First, check the SSID with staff: at the hotel front desk, conference sign-in, café counter. Refuse any SSID whose name differs, even a little (an extra space, different case, an unannounced _Free or _Guest suffix). Second, turn on the VPN before you join the Wi-Fi: launch the client, wait for the visual sign that the tunnel is up, then join the network. The VPN will be set to encrypt from the first request out. Third, check the kill switch is on in system mode (not just "per app" mode, which lets traffic from other apps through). Fourth, turn off auto-connect to open networks: iOS Settings → Wi-Fi → Auto-Join Hotspot → Ask; Android Settings → Network → Wi-Fi → Preferences → Auto-connect → Off for open networks. Fifth, turn off file sharing and network discovery: Windows in "Public Network" mode, macOS AirDrop on Contacts Only, Linux check that avahi-daemon and Samba are not listening on the Wi-Fi interface.

During connection - 5 checks. First, check the tunnel status in the VPN client: no error notice, no surprise server switch. Second, test for leaks in 30 seconds with our DNS Leak Test tool, which covers DNS, WebRTC, and IPv6 in one pass. The per-OS fix details are laid out in our DNS leak test guide. Third, confirm the visible IP with our My IP tool: it should show the VPN server's IP, not the hotspot's. Fourth, never enter any logins on the captive portal beyond a simple "I accept" click. If the portal asks for an email, Google login, or phone number, close it at once and try another network. Fifth, keep the VPN on for the whole session, never turn it off "just to quickly grab a file". A one-second drop is enough to leak a session cookie or a sensitive DNS query. Our quick method to verify your VPN is working lists the bare-minimum checks to run at the start of each session to confirm the tunnel holds.

Useful internal tools to keep handy. My IP tool to check the real exit point seen. DNS Leak Test tool for DNS + WebRTC + IPv6 in 30 seconds. Our published testing methodology lays out the full steps we run in-house before each review.

Special cases: airport, hotel, conference, café

Not all public hotspots carry the same risks. Here is a map of the four most common settings, with the vectors specific to each and the actions to take first.

Airport - captive portal and HTTPS hurdle. Airport Wi-Fi is famously tricky on the tech side: very heavy traffic, a captive portal that often asks for an email or boarding card, and some protocols blocked (standard OpenVPN on port 1194 is sometimes blocked). Best practice: use a VPN that can switch on its own to hidden protocols (WireGuard on port 443 dressed up as HTTPS, or Stealth mode on Mullvad and ProtonVPN). NordVPN's "Obfuscated Servers" work even on the strictest hotspots. Side risk: Evil Twin campaigns logged by Krebs on Security in 2024 at several Asian airports - always check the SSID with reception staff.

Hotel - internal tracking and ad profiling. Hotel chains lean hard on managed Wi-Fi gear - Cisco Meraki, Aruba Networks, Ruckus. These tools include analytics modules that log session times, data volumes, and the sites you visit at DNS level, then tie this to the guest profile (room number, length of stay, how often you visit). This is rarely used for harm, but it is often resold to third-party marketing firms. An active VPN closes this leak - the hotel only sees an encrypted tunnel to a remote server, not the sites you visit. Side risk: at hotels with a shared-password Wi-Fi (one password for all guests), any connected client may sniff other guests' traffic in promiscuous mode - a VPN is a must.

Conference and event - set-up Evil Twin and fingerprinting. Pro conference Wi-Fi draws hacker demos - not always hostile, sometimes for teaching, but the Evil Twin risk is high. At DEF CON and BlackHat for years, the "Wall of Sheep" event shows in public the logins grabbed on the conference's own Wi-Fi. At calmer events (corporate conferences, trade shows), the risk drops but doesn't vanish. The fix: an active VPN is a must, check the SSID with the organisers (often on the badge), and refuse any other SSID you spot with the same name. At some events, a corporate VPN (Cisco AnyConnect, enterprise OpenVPN) takes the place of the commercial one - check the IT policy before you arrive.

Café and restaurant - plain sniffing and weak setup. The most ordinary and most common case: Starbucks Wi-Fi, an indie café, a restaurant. The password is shown at the counter, or there is none. Risk #1: packet sniffing by another client there. Risk #2: low build quality in general (no client isolation, no security watch, router firmware rarely updated). Risk #3: the session often runs long (people work on site for hours), which widens the window of exposure. The fix stays the same: VPN with kill switch, file sharing off, and avoid entering sensitive logins where you can. This is the case where a VPN with "auto-connect on unsecured Wi-Fi" (a setting on NordVPN, ExpressVPN, ProtonVPN mobile) helps the most. You no longer think about it; the tunnel comes up on its own.

Going further

Public Wi-Fi in 2026 is still a medium that can be watched by its very nature - it shares radio waves among all clients in the same cell. HTTPS has cut content readability a lot, but it lets enough metadata through to rebuild your activity. A VPN with a kill switch closes the deep leaks, as long as it is set up right and run by an open provider. For most cases - travel, café, hotel, airport - the mix top-3 VPN + system kill switch + auto-connect on unsecured Wi-Fi is more than enough and invisible once set up.

For high-stakes uses (a journalist in a sensitive zone, a protected source, political research), you need to stack Tor over the VPN, a dedicated machine, and a hardened browser - an OPSEC level beyond the scope of this guide. And to check often that your VPN is really doing its job, our complete audit in 9 tests stays the go-to run to apply once a quarter.

If you want to pick the right VPN for this mobile setup without getting lost in fifteen comparisons, our guide to choosing a streaming and travel VPN covers the criteria we use ourselves and ties each one to measurements you can reproduce. To compare the two most popular options for this use, our Surfshark vs NordVPN comparison covers kill switch and auto-connect behavior. To dig into the provider pick, our detailed NordVPN review lays out the criteria (throughput, leak tests, kill switch) behind the call. On the tech side, understanding how the kill switch physically closes leaks when the tunnel drops is useful before you travel - it's the part that turns an "active" VPN into a "leak-tight" one. And to check DNS and WebRTC leaks on the ground, our integrated tool runs the full sweep in 30 seconds from any device on the tunnel.

Complete your security: the password manager

On public Wi-Fi, the VPN cuts passive capture of your network flows, but it doesn't guard a reused password on a breached site or one leaked by a phishing site. NordPass rounds out the stack: 256-bit XChaCha20 encryption, Cure53 audit 2024, sync across devices, and a free plan to start. Premium at $1.69/month on a 2-year plan. Think of it as a VPN companion - not a stand-in.

Going further. Related reading on these topics: the juice jacking risk at public USB ports, what a firewall actually does and what to do when your IP is exposed.

See also. Related: VPN on hotel WiFi.

Article published on 29 May 2026. Methodology: analysis based on NCSC 2023–2026 public documentation, CERT-EU 2024–2025 reports, EFF Surveillance Self-Defense, and Krebs on Security tracking of logged public Wi-Fi incidents. Technical checks run on three typical hotspot types (an international airport, a European hotel chain, an indie café) between March and May 2026 with a controlled Wireshark + SNI analysis + DNS leak test setup. Logs and captures are kept in-house, available on editorial request via contact.