Secure Hospital Wi-Fi: Separating Guest Access From Clinical Systems

Hospital Wi-Fi carries three populations that must never meet: patients and visitors streaming video, staff on managed laptops, and clinical devices that cannot be upgraded. Most estates separate them by SSID and assume that is segmentation. It is not — an SSID is a name, and without corresponding network policy all three land in the same broadcast domain.

An SSID is not a security boundary

The separation has to exist in the network, not the name. Each SSID needs its own VLAN, its own address space, and firewall policy that states explicitly what it may reach. The test is simple: from the guest network, can you reach anything other than the internet gateway? On most hospital networks the honest answer is yes.

The legacy device problem, handled honestly

Some clinical devices support only WPA2-Personal with a pre-shared key, or worse. You cannot fix that, so contain it:

• Put them on a dedicated SSID and VLAN, never the staff or guest one
• Use a long, unique PSK that is not written on a whiteboard, and rotate it when staff turn over
• Restrict by MAC as a speed bump, while accepting MAC addresses are spoofable
• Firewall tightly — these devices should reach two or three destinations
• Monitor closely, because the compensating control is detection

Rogue and evil-twin access points

A hospital is a public building. Anyone can walk in with a battery-powered AP broadcasting your staff SSID and collect credentials from devices that connect automatically.

Defences worth having:

• Wireless intrusion detection on the controller, alerting on an unknown BSSID advertising a known SSID
• Server certificate validation enforced on managed clients, so a device will not hand credentials to an AP that cannot present the right certificate — this is the control that actually defeats evil twins
• 802.11w management frame protection to blunt deauthentication attacks
• Periodic physical walk-throughs of clinical areas

Roaming, and why clinical devices drop

Security and clinical reliability collide most often at roaming. A nurse walks a medication cart from one wing to another; the device re-authenticates at each access point, and if full 802.1X re-authentication runs every time, the session stalls. Staff then report that "security broke the carts", and the usual response is to move the devices to an open PSK network — undoing the control.

The fix is in the wireless configuration, not the security policy:

• Enable fast roaming (802.11r, or the vendor's opportunistic key caching) so re-authentication does not run in full at every handoff
• Tune minimum data rates to stop distant clients clinging to a far access point instead of moving to a near one
• Survey for coverage in the places care happens — stairwells, lifts, supply rooms — not just corridors
• Separate the RF problem from the security problem when triaging complaints, because they present identically to the user

What to verify

Where to start

Sit on the guest Wi-Fi with a laptop and try to reach a clinical subnet. That one test usually settles the argument about whether the SSIDs are really separated. Then enforce server certificate validation on managed clients — it is a policy change, and it is what stops credential theft from a lobby.

Wireless is one segment of a wider picture; see IoMT security for the wired and device-level equivalent.

GuardsArm runs wireless assessments in clinical environments, including rogue AP detection and 802.1X design for mixed legacy estates. Book a scoping call.