802.1X Enforcement Deadline in a Hospital With Non-Supplicant Medical Devices
A 640-bed hospital has 2,300 access ports across 41 wiring-closet switches. The estate includes about 1,400 managed workstations, 800 medical devices - infusion pumps, patient monitors, imaging modalities - 300 printers, and roughly 900 guest devices per day. Network access control is being introduced with 802.1X. The pump and imaging vendors state in writing that their firmware cannot run a supplicant and will not be updated before next year. Clinical systems are under a change freeze except for a two-hour Sunday maintenance window. The project sponsor proposes enabling closed-mode enforcement on all access ports next Monday so the rollout is finished before an audit. The security team has one engineer trained on the NAC product and no spare switch hardware for a pilot closet.
1. Evaluate the sponsor's Monday closed-mode plan. State your recommendation and the reasoning that supports it.
Read the worked answer
Recommendation: Reject the plan. Move to monitor mode on a defined pilot set of closets first, with a written exit criterion for each phase.
Reasoning: Closed-mode enforcement on 2,300 ports with 800 non-supplicant clinical devices means the first failed authentication takes a pump or a monitor off the network. That is a patient-safety event, not an IT outage, and it will occur during a change freeze when the fix cannot be applied. Monday also gives the single trained engineer no capacity to triage more than a handful of failures before clinical staff escalate.
Structure I would propose: Phase one, monitor mode on two non-clinical closets plus one clinical closet, collecting the identity of every device and its observed authentication behaviour. Phase two, closed mode on wired ports for managed workstations only, in the pilot closets. Phase three, extend by closet with a rollback command pre-tested and a named on-call engineer per window. Each phase has a measurable exit criterion - for example, fewer than one percent of devices failing authentication for two consecutive weeks.
On the audit: the audit asks for evidence of a controlled access-control programme, and a documented phased plan with monitoring data is stronger evidence than an unfinished enforcement deadline that produced an incident.
2. Describe how you would admit the 800 non-supplicant medical devices without weakening enforcement for everything else.
Read the worked answer
Approach: Use MAC authentication bypass as a fallback for identified devices, backed by a device inventory and a dedicated authorization policy, rather than creating a blanket open VLAN.
Reasoning: The devices cannot prove identity with a supplicant, so the only trustworthy attribute available is the MAC address, combined with switch port and, where the switch supports it, a profiling signal such as DHCP fingerprint or OUI. That combination is weak on its own - MAC addresses can be spoofed - so it must be constrained by port binding: the device is authorized only on the port where it is expected.
Policy design: Build an allowlist from biomedical engineering's asset register, mapping MAC to switch, port, and device owner. Place authenticated medical devices in a clinical VLAN with access limited to the specific servers and protocols each device class needs. Unrecognized MACs on clinical ports should be denied, not silently admitted.
Process that keeps it honest: a documented onboarding path so new or replaced devices can be added within one business day, and a quarterly reconciliation against the biomedical register so the allowlist does not grow stale. Without that process, the exception list becomes the actual access policy within a year and nobody notices.
3. A core switch loses its connection to the RADIUS servers for 20 minutes during a shift change. What behaviour do you design for, and what do you verify afterwards?
Read the worked answer
Design decision: Configure fail-open behaviour for clinical VLANs and fail-closed for guest and general-purpose ports, and make that choice explicit and documented rather than accepting a vendor default.
Reasoning: Fail-closed during a RADIUS outage removes clinical devices from the network at exactly the moment staff cannot work around it. Fail-open admits devices that have not been authenticated, which is a real risk on guest and general-purpose ports where an attacker could induce the outage. Splitting the behaviour by port profile matches the consequence of each failure to the risk of each population.
Residual risk to state to the sponsor: during fail-open, an unauthenticated device plugged into a clinical port is admitted. Mitigate by keeping those ports in a restricted VLAN with limited east-west reachability, so admission does not equal broad access.
Post-incident verification: confirm from switch logs how many ports entered the fallback state, correlate with any device that appeared on the network during the window, check that the fallback reverted cleanly, and confirm the RADIUS servers did not fail together for a shared cause such as a common upstream link or an expired certificate. Then test the failover path deliberately in the next maintenance window so the next occurrence is rehearsed rather than discovered.