802.1X at a Hospital: Closed Mode, MAB, and Devices That Cannot Change

Do not go to closed mode at go-live across 6,200 clinical ports. Sequence it.

Closed mode fails closed: an endpoint that cannot authenticate gets nothing. In a hospital the endpoints that fail are the ones that matter - infusion pumps, badge readers at locked doors, the label printer in theatre. The failure is silent to the network team and immediate to clinical staff, and it will be discovered by a nurse at 03:00, not by the pilot.

Recommended sequence, with explicit exit criteria per stage:

1. Monitor mode for two weeks per building: authenticate and log, permit everything. The output is the endpoint inventory you actually need - it will find device classes the pilot never saw.
2. Low-impact mode: auth-fail VLAN with limited access, and closed mode applied first to non-clinical port groups (offices, admin, wired guest). Exit criterion: fewer than N unexplained failures per week, with N agreed with clinical leadership.
3. Closed mode by building, with an exception list signed off by a named clinical owner.

Two controls that make fail-closed survivable:

• Distinguish authentication failure (endpoint is bad, fail closed) from server unreachable (network is bad, fail open to a critical VLAN). Configure access-session critical / critical VLAN, and tune RADIUS timeout and retries plus dead-server detection so a single PSN problem does not lock the building.
• The PSNs are in one data center reachable over the clinical WAN. That is a single point of failure for every port in the hospital. Either place a PSN locally or accept fail-open as the designed behaviour and say so in writing.

The judgement being tested: closed mode is a safety decision as much as a security one, and "security wants it" is not a risk acceptance for clinical availability.

Mechanism: MAB treats the MAC address as the identity, but the MAC is a property of the endpoint and a session is a property of the port. When a device's MAC appears on two ports - because a device was moved, because an intermediate device is bridging, or because the switch previously learned it in a different VLAN or session - the infrastructure sees a MAC move. Depending on platform and configuration the older session is torn down, the new one is denied, or both are bounced. The user-visible result is a device that worked yesterday and fails today, with a log line about a MAC move rather than an authentication failure. Six of 14 pilot tickets in one week is a signal, not noise.

Design changes for unmodifiable devices:

• Stop using MAC as the only identity. Enable device sensor (CDP/LLDP) on access ports and profile by what the device announces. Badge readers and printers usually identify themselves; a profile match plus a MAC allow-list is far more stable than MAC alone.
• Segment them. Put badge readers, printers and pumps into dedicated port groups and VLANs with explicit ACLs to their controllers only. Then the authentication question becomes "which port group is this" rather than "is this MAC known", and a MAC move no longer removes the device from service because the policy does not depend on it.
• Handle the vendor that forbids change. Treat that as a documented exception: fixed port assignment, dedicated VLAN, ACL to the imaging server, and a monitoring rule that alerts if the port's MAC changes. Write the expiry date on the exception. "No network change" from a vendor is a constraint on them, not an exemption for you.
• Tune MAC move behaviour explicitly rather than relying on platform defaults, and log moves at a severity the NOC actually looks at.

Judgement: MAB is a fallback, not an authentication method. Any design where 900 devices depend on it will produce a steady ticket stream forever.

The problem is real and ISE cannot solve it for you. A MAC address identifies a session. Two virtual NICs with the same MAC on the same or different ports create two sessions claiming one identity, and the switch will bounce or deny one of them. Multi-auth host mode does not help - it distinguishes multiple MACs per port, not one MAC appearing twice.

Options, ranked:

1. Fix the appliance's MAC assignment (correct answer). A virtualized appliance should draw from a unique MAC pool (VMware's vCenter-assigned or a vendor pool). If the vendor ships a fixed MAC per virtual instance, that is a vendor defect - raise it, get a per-instance MAC, and document the interim workaround. Three tickets in a 120-port pilot scales to roughly 150 in the full deployment; you do not want a per-port exception list at that size.
2. Isolate the appliance on a dedicated segment. Put the imaging appliance and its clients on their own VLAN with a port ACL. If both duplicate MACs live inside that segment and nothing else depends on that identity, the conflict stops affecting authenticated sessions elsewhere. This is the pragmatic interim choice and it is defensible in a clinical setting because it also shrinks the blast radius.
3. Static configuration for those ports. Bypass 802.1X on the appliance ports and rely on port security plus ACLs. Simple and auditable, but it is a permanent exception and should be labelled as one.

What I would not do: enable a loose MAC-move policy, extend the session timeout, or disable MAC-move detection to make the tickets go away. That converts a visible problem into an invisible one and weakens the control for every other endpoint on the switch.

Judgement: authentication cannot disambiguate two endpoints that claim one identity. The fix belongs at the virtualisation layer, and the network's job is to contain the damage while that is negotiated.