Per-Device-Class 802.1X Design for a Regional Hospital
A 2,400-staff regional hospital runs WPA2-PSK with a single shared passphrase on all clinical WLANs. An auditor requires unique credentials and per-user revocation. Assets: 1,900 domain-joined Windows laptops (certificate deployment available through GPO and SCEP), 600 MDM-managed iPads that can hold a client certificate, 350 infusion pumps and 120 label printers that support only WPA2-PSK (a few only TKIP), and 90 physician personal phones. Two NPS servers provide RADIUS. An internal enterprise CA exists but currently issues only server certificates. Clinical staff move between buildings and expect the same SSID everywhere.
1. Propose an authentication design for each device class and justify the EAP choice for each.
Read the worked answer
Windows laptops and iPads - EAP-TLS. Certificates are already issuable at scale (GPO/SCEP and MDM respectively), so there is no operational reason to accept a password-based method. EAP-TLS gives per-device credentials, clean revocation through CRL/OCSP, and immunity to the evil-twin credential-harvesting problem. Use machine plus user certificate for laptops so the device authenticates before anyone logs in.
Infusion pumps, printers - MPSK or per-device PSK. These devices cannot do EAP and cannot be given EAP-TLS without a firmware project. If the WLAN platform supports multiple PSKs, map each device PSK to its own VLAN/role so revocation is per-device. Where it does not, a single PSK on a segregated medical-device SSID with strict ACLs is the fallback, and that residual risk must be documented.
Physician personal phones - EAP-TLS via MDM onboarding if the MDM can provision a certificate at enrolment; otherwise a separate limited-access SSID, not the clinical SSID.
Rejected: PEAP-MSCHAPv2 for anything. It is only as strong as the user password and, unless the supplicant strictly validates the server certificate and name, is trivially defeated by an evil twin. If it is retained for a pilot, enforce server-certificate validation by policy and verify it on the endpoint.
2. The pump vendor says 802.1X is unsupported. The CIO asks whether MAC filtering plus a hidden SSID is an acceptable substitute. Respond with the reasoning you would give.
Read the worked answer
No - but the answer is nuanced rather than a flat refusal.
- MAC filtering is identification, not authentication. MAC addresses are transmitted in the clear in every frame and are trivially spoofed; the RADIUS server cannot distinguish an attacker from the device. Hidden SSIDs are equally cosmetic: the SSID appears in probe requests and association frames and is discovered by any monitor-mode capture within minutes.
- What MAC filtering is good for is limiting the blast radius once combined with real controls: put the pumps on their own SSID/VLAN, apply an ACL that permits only the pump management subnet and its server ports, rate-limit, and alert on any MAC seen on that SSID that is not in the inventory. That converts a weak control into a detection control.
- Push the vendor. Ask for a firmware roadmap date for WPA2-Enterprise, and ask whether the device supports EAP-TLS with a provisioned certificate or, failing that, a per-device PSK.
- If a shared secret is unavoidable, use MPSK so each device has a unique key that can be revoked individually, and record the residual risk, the compensating controls, and the review date in the security policy.
The auditor's requirement is per-entity revocation; a design that cannot revoke one device without rekeying all 470 is not a compensating control for that requirement.
3. Before rollout, what would you test and monitor to avoid an outage caused by the certificate and RADIUS infrastructure itself?
Read the worked answer
The failure modes that cause clinical outages are almost never in the crypto; they are in the supporting services.
- CRL/OCSP reachability. If the RADIUS server cannot reach the revocation point, EAP-TLS either fails closed (outage) or is configured to fail open (silent security hole). Test with the distribution point deliberately unreachable and decide which behaviour you want.
- Server certificate chain and name. Supplicants must trust the issuing CA and must be configured with the expected server name; a mismatch throws an interactive prompt that clinical users will click through or abandon.
- Clock skew. Certificate validity and TLS both depend on time. Roaming clinical carts that have been asleep are a common offender.
- RADIUS redundancy and failover behaviour. Verify that a single NPS failure causes a re-authentication delay, not a disconnect, and size the re-authentication timer against roaming patterns.
- Pilot by cohort. Roll out to one ward and one device class at a time, watching authentication failure reason codes (bad certificate, unreachable, timeout, unknown CA) as distinct alarm categories.
Plan the cutover so that the PSK SSID remains available in parallel for two weeks, then decommission it - and change the shared passphrase at decommissioning regardless, because it has been shared.