Hotel Wi-Fi security on a Mac: what actually matters

Hotel Wi-Fi is reasonably safe for ordinary use on an up-to-date Mac, and considerably safer than its reputation suggests. The classic warning, that someone two rooms away is reading your passwords out of the air, is close to obsolete: virtually all traffic that matters is encrypted end to end before it leaves your machine, and macOS plus a current browser handle that without you doing anything.

That is the plain version. The nuance is that encryption protects content, not context. Nobody on the hotel network reads your email, but the network can still see that your Mac contacted a particular mail provider, a particular cloud drive, and a particular company VPN, at 6:40 in the morning, every morning, for five days. Over a long stay that adds up to a behavioural record, and none of it required breaking a single connection.

Two things separate a hotel from a café. The first is identity: the login page usually asks for your surname and room number, so the operator can link every device and connection to a named guest rather than an anonymous person with a coffee. The second is duration: a café visit is forty minutes, a hotel stay is days of automatic reconnection and background sync running while you are nowhere near the machine.

So the honest threat model is not interception of secrets. It is three other things: a Mac exposed to a flat network full of strangers for days, a detailed traffic timeline attached to your name, and the possibility of joining a network that only looks like the hotel's. All three have straightforward answers, and none of them require panic.

Everyone in the building is on one flat network. Hotel guest Wi-Fi is frequently deployed without client isolation, which puts the guest in 412 and the guest in 118 on the same broadcast domain as you. Your Mac advertises itself over Bonjour with whatever name you gave it, very often your real first name and the model of the machine, and any sharing service left on from a past project is reachable by everyone else. Some chains do isolate clients properly, but you cannot tell which from the outside, so assume they do not.

The captive portal ties traffic to a guest identity. Room number and surname, sometimes a loyalty number or an email address for the faster tier. That is not sinister; it is how the hotel enforces one account per room, and in several jurisdictions the operator is obliged to retain connection logs anyway. It just means the phrase anonymous public network does not apply here. Whatever the network records, it records against you by name.

The equipment is often old and rarely touched. Hotel Wi-Fi is usually installed once by a contractor, managed remotely, and left alone for years because it works. Access points and gateway appliances go unpatched, firmware sits several versions behind, and default configurations survive. That is not an attack in itself, but it means the network's own protections, including whatever isolation the brochure promised, may be misconfigured or simply broken.

Portals interfere with DNS by design. For the login page to appear at all, the gateway has to intercept your first requests and redirect them, which means intercepting DNS. Some portals keep doing it after you have authenticated, and some resolve names to their own answers for the whole stay. This is also why encrypted DNS causes trouble in hotels: if your Mac is set to a private DNS profile or a custom resolver, the portal frequently cannot redirect you and the login page never loads, which is the single most common hotel Wi-Fi complaint.

And then you stay. Auto-join means the Mac reconnects on every lid open without asking. Multiply the normal background activity of macOS and a dozen installed apps by four or five days of that, and the exposure is not one session on an untrusted network but a continuous residency on one.

Start with the good news, because it is substantial. HTTPS encrypts the content of a connection: page contents, form fields, passwords, message bodies, API payloads. Browsers now default to HTTPS and refuse to quietly downgrade, TLS 1.3 is the norm, and the large majority of Mac apps encrypt their own traffic. Someone sitting on the hotel network with a packet capture sees ciphertext. The old party trick of harvesting logins from an open network stopped working years ago.

What encryption does not hide is the fact and shape of every connection. The destination IP address is always visible, because the packets have to be routed. DNS lookups are visible unless you are using encrypted DNS, which portals often block. The server name in the TLS handshake is visible on most connections today, since Encrypted Client Hello is still far from universal. And the timing, size and frequency of every exchange are visible to anyone on the path, no matter how strong the cipher.

Assembled over a multi-night stay, that metadata is more revealing than people expect. It shows which services you use, when you woke up, when you left the building and came back, how long your video calls ran, and which employer's network you dialled into. A mail client polling every five minutes is a precise presence signal. None of that requires reading a single message. Metadata is the real exposure on a hotel network, not content.

There is also a residue of traffic that is not protected at all. A few older or abandoned apps still check for updates over plain HTTP, and local network discovery is unencrypted by nature, so mDNS and Bonjour broadcasts announce your device name and its services to the whole guest network. Printer discovery, media sharing and anything that expects a trusted home LAN behaves exactly the same way in a hotel, because your Mac has no idea the network changed character.

The one situation where HTTPS genuinely fails is when a person overrides it. If a certificate warning appears, do not click through it, and if any network asks you to install a profile or a root certificate before granting access, decline and use cellular instead. A hotel needs your room number to let you online. It does not need the ability to issue certificates your Mac will trust.

Keep the Mac's firewall on and stop sharing anything. This is the highest-value step because it targets the flat network directly. Turn the firewall on under System Settings, Network, Firewall, and enable stealth mode in its options so the Mac stops answering unsolicited probes. Then open System Settings, General, Sharing and confirm that File Sharing, Screen Sharing, Printer Sharing, Remote Login and Remote Management are all off, and set AirDrop to Contacts Only. Note what the macOS firewall does not do: it filters incoming connections only, and nothing in it restricts what your own apps send out.

Cut background sync for the length of the stay. Turn on Low Data Mode for the hotel network specifically, under System Settings, Wi-Fi, Details next to the network you joined. It reliably pauses Apple's own background work: software update downloads, App Store downloads, iCloud Photos syncing and various deferred tasks. For third-party apps it is only an advisory flag that many developers never implemented, so also quit or pause your cloud sync clients and set Time Machine to back up manually. Less background traffic means less metadata and fewer surprises if the hotel meters or throttles the connection.

Use a VPN for the encryption you do not otherwise get. A VPN wraps everything, including DNS and the connection metadata discussed above, in a single tunnel to a single address, so the detailed timeline collapses into one encrypted session. Two honest caveats: you are moving trust from the hotel to the VPN operator rather than eliminating it, so choose one whose logging policy you have actually read, and a VPN does not stop any app from connecting. It changes the path, not the participants. Connect it after you clear the captive portal, and turn on a kill switch if the client offers one.

Decide which apps may reach the network at all. This is the part a VPN cannot do. Encryption is about the transport; app control is about scope. On a network you will be on for days, most of what is installed on your Mac has no reason to talk: a browser, a mail client and the VPN client usually cover everything you intend to do. Everything else can stay silent until you check out, which shrinks both the metadata trail and the number of processes exposed to whatever else is on that network.

Join the right network, and leave it properly. Ask reception for the exact network name rather than guessing from the list, because a rogue access point broadcasting a plausible hotel name costs almost nothing to set up and is one of the few genuinely common attacks left. Treat a hotel-branded network with no portal, or a portal that asks for a card number instead of a room number and surname, as a reason to stop. Prefer a guest network with a WPA2 or WPA3 passphrase over a fully open one. On checkout, open System Settings, Wi-Fi, Details and choose Forget This Network, otherwise your Mac will silently rejoin any network with that name anywhere in the world.

A closed lid is not the same as being offline. macOS wakes periodically for network access, runs scheduled maintenance, checks for updates, and lets apps refresh in the background. Over four nights that is hundreds of connections you never initiated, made while you were asleep or out, on a network you would call untrusted if anyone asked. Nothing about it is malicious. It is macOS assuming every Wi-Fi network is your own, which is the right default at home and the wrong one in room 412.

That is why per-app control is the shape of answer this problem wants. A VPN encrypts the tunnel but every app still talks, and Low Data Mode asks politely while many apps decline. What actually reduces the exposure is deciding, before you connect, which handful of apps are allowed out, and having that decision applied automatically rather than remembered each evening.

This is the case NetMute was built for. Its hotspot protection detects that you have joined an unknown or untrusted network and applies a strict profile immediately, without waiting for you to think of it, and it handles captive portals so the hotel login page still loads instead of being blocked along with everything else. Network profiles are keyed to the Wi-Fi name, so the hotel profile comes back on its own the next time you check into that network, and your normal home profile returns the moment you get home.

Day to day, the controls stay simple. Any app can be blocked with one click, temporary rules expire by themselves so letting an updater out for ten minutes does not leave a permanent hole, and whitelist mode inverts the whole thing: nothing reaches the network except what you named. If the hotel meters or throttles its connection, per-app data limits cap the offenders before they become a problem.

The part people find most useful after a trip is the evidence. The real-time traffic monitor and domain-level logging answer the question this whole article circles around: what exactly talked while you slept. It is worth checking once, because the list is usually longer than anyone expects, and it makes the next stay's profile easy to write.