Is it safe for a hotel to run a single Wi-Fi network for guests and staff?

No. An unsegmented Wi-Fi network lets a compromised guest device, or a malicious guest, attempt to reach printers, the PMS, cameras and other administrative equipment that should be isolated. The minimum standard is three separate networks (guest, administrative and infrastructure/IoT), each on its own VLAN.

Is an open guest Wi-Fi network without a password a security risk?

Yes. A fully open network with no authentication makes it easier for one guest's device to attack another guest's device on the same network, and harder to trace the source of any misuse. A captive portal with a unique password per booking keeps the connection simple while isolating guests from each other.

Should the PMS sit on the same Wi-Fi network guests use?

No, never. The PMS, payment terminals and any administrative system should sit on a VLAN isolated from the guest network, with no possible route between the two, even if they share the same physical access points. This stops an attack originating from a guest device from reaching booking or payment data.

Should security cameras and electronic locks sit on the guest network?

No. Cameras, electronic locks and other IoT devices should sit on their own VLAN, separate from both the guest and administrative networks. These devices commonly run outdated firmware and a factory default password that was never changed, which makes them an easy target if reachable from the public network.

How do you know if a hotel's Wi-Fi is already segmented correctly?

The most direct test is to try, from a device connected to the guest network, to reach the IP address of a known administrative device, such as the reception printer. Any response indicates segmentation is not working. A technical network audit confirms this fully, including the VLAN configuration and the firewall rules between them.

Guest Wi-Fi in Hotels: The Network Segmentation Most Are Missing

Key takeaways

A single Wi-Fi network for guests, reception and cameras is the most common infrastructure failure in mid-size hotels
The minimum standard is three isolated networks on separate VLANs: guest, administrative and infrastructure/IoT
Security cameras and electronic locks rarely get firmware updates and are the easiest target inside the network
A captive portal with a unique password per booking protects guests from each other without complicating the connection
Testing isolation is simple: a device on the guest network should never be able to reach an administrative device

How a network becomes a risk without anyone noticing

Few mid-size hotels designed their Wi-Fi network from scratch. In most cases it grew in stages: guest access came first, then reception plugged the PMS computer into the same network because it was the nearest cable, and later someone installed security cameras using whatever Wi-Fi signal was available in the corridor. None of these decisions were made carelessly. The result, all the same, is a single flat network where a guest's laptop and the terminal that processes booking payments sit, from a technical standpoint, in the same environment.

This isn't a minor technical detail. It's the difference between a compromised guest device being able only to browse the internet, and that same device being able to see and attempt to reach the reception printer, the PMS server or a hotel security camera. On an unsegmented network, that second possibility is always open, even if it has never been exploited so far.

The minimum standard: three isolated networks

Any hotel, regardless of size, should run at least three logically separate Wi-Fi networks:

Guest network: internet access, with no visibility of any other hotel equipment, ideally behind a captive portal with a password per booking.
Administrative network: the PMS, reception computers, payment terminals and management systems, fully isolated from the guest network.
Infrastructure and IoT network: security cameras, electronic locks, building automation and other connected devices, isolated from both the guest and administrative networks.

In practice, this is implemented with VLANs configured on the switch and the Wi-Fi controller, with explicit firewall rules that block any traffic between the three networks except what's strictly required for operations. A central camera monitoring system, for example, might need a specific, documented exception, not free access between networks.

Why cameras and locks deserve their own network

IoT devices, cameras, electronic locks and automation sensors share two recurring problems: firmware that rarely gets updated, and a factory default password that was never changed at installation. That consistently makes them the easiest thing to compromise on any corporate network, hospitality or otherwise.

Important

If a camera or electronic lock is reachable from the same network guests use, it is, in practice, exposed to the public internet. Isolating these devices on their own VLAN, with internet access restricted to the minimum required, is one of the highest-return controls for the effort it takes.

Captive portal: security without friction for the guest

Segmenting the network doesn't have to make Wi-Fi harder to use. A captive portal with a unique password per booking, generated automatically from the room number and the guest's surname, keeps the connection simple while better isolating guests from each other within the network itself. That makes it harder for a compromised device in one room to attack the laptop belonging to the guest next door.

Fully open networks with no password at all, still common in smaller hotels and guesthouses, remove even that basic layer of isolation and make it harder to trace the source of any misuse of the network, should an investigation later be needed.

How to implement segmentation without stopping operations

Map what exists today

List every device connected to the current Wi-Fi network (PMS, payment terminals, cameras, locks, printers) and which network each one is on right now. Most hotels discover, at this stage, equipment nobody remembered was on the same network.

Configure the VLANs on the switch and Wi-Fi controller

Create the three logical networks (guest, administrative, infrastructure/IoT) at the switch layer and replicate the separation on the Wi-Fi access points, using distinct SSIDs mapped to each VLAN.

Write explicit firewall rules between the networks

The default should be to deny all traffic between VLANs, opening only specific, documented exceptions, never the other way round.

Implement the captive portal with a password per booking

Ideally integrated with the PMS, so the password is generated and expires automatically with the length of stay, with no manual work for reception.

Migrate one segment at a time

Move infrastructure and IoT devices first, then the administrative network, leaving the guest network for last. This limits the impact of any unexpected issue during the migration.

Test isolation before calling the project done

From a device on each network, confirm it cannot reach equipment on the other two. Without this test, a misconfigured firewall rule can go unnoticed for months.

How to know if your network is already exposed

A quick test, which doesn't replace a full audit, is to connect a laptop to the guest network and try to reach the IP address of a known administrative device, such as the reception printer. Any network response, even without being able to use the device, indicates segmentation isn't working as it should. A formal technical audit reviews the VLAN configuration and the firewall rules between them, and tests this isolation systematically, including the physical access points and their individual configuration.

The guest and administrative networks are just one of the four attack surfaces hospitality operates simultaneously. For a broader view of the risks, see our analysis of the cybersecurity risks hotels need to address.

Guest Wi-Fi in hotels: the network segmentation most are missing