CNEn study materials
CNEn study resources

802.1X Closed Mode in a Hospital with Non-Supplicant Devices

CNEn · Put your knowledge to work in context.

All case studies

802.1X Closed Mode in a Hospital with Non-Supplicant Devices

A 900-bed hospital has 1,400 access ports across 60 wiring closets, all currently in VLAN 1 with no port authentication. The CISO has mandated 802.1X in closed mode on every port within six months. The estate includes 900 managed laptops that can run a supplicant, 250 printers and cameras with no supplicant, and 180 regulated medical devices (infusion pumps, imaging consoles) that cannot run 802.1X; 30 of those use static IPs and their vendors refuse any configuration change. Two RADIUS servers are available, but there is no NAC appliance and no formal device-profiling system. Clinical engineering has stated that any authentication failure that isolates a life-support device is unacceptable. A pilot on 40 ports produced a 15% MAB failure rate, later traced to printers sitting behind unmanaged 5-port switches and to a MAC-format mismatch between the switches and RADIUS. The change window is 02:00–05:00, and no downtime is allowed on clinical floors.

1. Recommend an enforcement model that satisfies the CISO and clinical engineering. Be explicit about exceptions and how they are bounded.

Read the worked answer

A blanket "closed mode everywhere, no exceptions" policy does not survive contact with clinical engineering, and an open guest VLAN bypass defeats the CISO's intent. The defensible middle is closed mode with a narrowly bounded, auditable fail-open path.

Model.

  • Default: closed mode. Unauthenticated or failed devices land in a registration/quarantine VLAN with an ACL permitting only the onboarding portal and the two RADIUS servers. No internet, no clinical subnets.
  • Exception: a critical-authorization VLAN scoped to the clinical device groups (by switch port range and by RADIUS filter-ID or a device-group attribute). If RADIUS is unreachable, the port falls back to this VLAN, which has an ACL to only the EHR and imaging servers, not to the internet or user VLANs.
  • Never use a shared unrestricted guest VLAN as the fail-open target.

Phasing. Four to six weeks in monitor mode per closet, resolving the MAB failures found in the pilot; then closed mode on non-clinical ports; clinical floors last, one closet pair per night, with an engineer on the floor and a rollback command pre-staged. Clinical engineering signs a written risk acceptance for the critical VLAN, and every fail-open event generates a P1 alert with the port, MAC and timestamp so the exception cannot silently become the norm.

2. How do you handle the 180 non-supplicant devices and the 15% MAB failure rate?

Read the worked answer

Fix the pilot failures first - they are engineering defects, not design limits. The MAC-format mismatch (case and delimiter differences between switch and RADIUS) is a configuration standard: pick one canonical format (lowercase, colon-separated) and enforce it in the switch templates and the directory. Devices behind unmanaged 5-port switches fail because a single port sees multiple MACs; either replace those switches with managed ones (strongly preferred for clinical areas) or configure the port for multi-auth so each MAC is authenticated separately rather than multi-domain, which authenticates only the first.

Then place each device class deliberately.

  • Laptops: EAP-TLS with machine and user certificates, so authentication succeeds before login and roaming is smooth.
  • Printers and cameras: MAB with a per-device dACL allowing only their required print or NVR endpoints.
  • Medical devices: MAB with static MAC entries for the 30 fixed-IP devices, a dedicated device VLAN, and a dACL to EHR/imaging only.

Compensate for MAB's weakness. MAB is spoofable, so pair it with port security, DHCP snooping, dynamic ARP inspection and IP source guard on those ports, and alert on MAC moves between closets. Treat MAB as low-assurance and keep those devices in a zone that cannot reach user or payment networks, so a spoofed MAC buys an attacker very little.

3. What must you validate in a 40-port pilot before scaling, and which findings would stop the rollout?

Read the worked answer

Validate.

  • RADIUS failover: pull one server and measure how long a new authentication takes; the interim authenticator timeout and reauthentication timers must not create a visible outage.
  • CoA/Disconnect support end to end; without it you cannot re-authorize or quarantine a device that is already connected.
  • Certificate provisioning for EAP-TLS, including machine authentication before user login and certificate renewal at 12 months.
  • Per-device behavior: Wake-on-LAN, printer sleep and wake, imaging console boot from PXE, IP phone power-cycle (multi-domain voice VLAN must still work), and badge readers that reboot nightly.
  • Switch firmware behavior for MAB and multi-auth; test the exact model and version in each closet type.
  • Log volume and NTP accuracy - 1,400 ports generate a lot of events, and out-of-sync timestamps make correlation useless.

Stop-the-rollout findings.

  • Any clinical device landing in fail-open more than once without a logged root cause.
  • RADIUS authentication latency above about 2 seconds, which will time out slow-booting devices.
  • No CoA support on any access-switch model in scope.
  • PCRF-style quarantine VLAN reachable from clinical networks due to a misapplied ACL.
  • A pilot port that fails closed on a life-support device with no exception path configured.