Retiring a Shared PSK in a Hospital Without Taking a Ward Offline

Transition mode does not close the audit finding. WPA3-Personal transition mode advertises SAE and WPA2-PSK together with the same passphrase; any device, or any attacker with the passphrase, can use the WPA2 path. The shared secret still opens the clinical VLAN. You would also be running a downgrade-capable SSID in a regulated environment.

Real options for the pump fleet:

• 802.1X EAP-TLS: strongest, but 10 percent of the fleet cannot do it, so it cannot be the only method.
• Multi-PSK (MPSK): a unique pre-shared key per device, bound to the device MAC, issued and revoked centrally (ClearPass, or local MPSK on ArubaOS 8.4 and later). A stolen key is useless on any other device and can be revoked without touching the other 399 pumps. This is the only approach that covers 100 percent of the fleet on WPA2-PSK.
• Per-device key with MAC-based registration achieves a similar effect if MPSK is not licensed; the residual risk is MAC spoofing, which you mitigate with monitoring rather than pretending it is device attestation.

Recommendation: a dedicated pump SSID with MPSK, and a separate tablet SSID on WPA3-Enterprise with EAP-TLS. Do not mix the two device classes on one SSID.

Segmentation must be derived from device identity, not from the SSID alone, or every device on the SSID gets the same access.

• Pump SSID: MPSK authentication, and the AAA profile must return a server-derived role such as pump-role per device, so the role follows the pump wherever it roams. Do not rely on the VAP default role, which is identical for all clients.
• pump-role policy: permit DHCP, DNS and NTP to infrastructure; permit only the pump-management server on its required ports (for example 10.20.5.10 tcp 443 and udp 514); implicit deny at the end of the policy. No internet, no clinical workstation VLAN.
• Tablet SSID: WPA3-Enterprise with EAP-TLS, role tablet-role, policy permitting clinical applications and internet but explicitly denying the pump subnet.
• If 192-bit mode is proposed, confirm the certificate chain and supplicant support first; it will break anything without Suite-B certificates.
• Enforce the pump-to-clinical deny on the gateway or controller policy as well, not only in the wireless role.
• Alert on any pump presenting an unknown key or unexpected MAC; with MPSK that event is now meaningful, whereas with a shared PSK it was invisible.

With a five-minute cap and no second attempt permitted, everything must be pre-built and rehearsed.

Before production:

• Build the new SSID/VAP in a test AP group.
• Enrol three pumps end-to-end through the MPSK workflow and confirm the pump-management server sees them as connected and reporting.
• Write and test the rollback: re-enable the old VAP for that one AP group only.
• Identify pumps with static configuration that must be re-keyed on site, and any device that randomises its MAC and therefore cannot be MAC-bound.

Per ward:

• Remove the old SSID from one AP group at a time.
• Move that ward's pumps to the new SSID.
• Confirm success from the pump-management server's active-connection list, never from user reports.
• Keep the old SSID configured but not broadcast until the final ward is done.

Watch for the TKIP-only pumps: those will not run on a modern WPA2-AES SSID. They either get their own tightly scoped legacy SSID with a compensating control, or they are replaced. That decision must be made before the first ward, not during it.