I85PREP
⌘ K
Aruba Network Security Associate study materials
Aruba Network Security Associate study resources

802.1X Failure on a Medical Device VLAN

Aruba Network Security Associate · Put your knowledge to work in context.

All case studies

802.1X Failure on a Medical Device VLAN

A hospital deploys Aruba ClearPass with 802.1X (PEAP-MSCHAPv2) for wired access on 3,000 switch ports. Clinical workstations authenticate fine. A fleet of 45 infusion pumps cannot run an 802.1X supplicant; they only support MAC authentication. The security team configured MAC auth as a fallback on the same ports, with the MAC database in ClearPass. After go-live, 12 of the 45 pumps intermittently land in a quarantine role with no network access, while the other 33 work. Switch logs show the failing pumps sending EAPOL-Start but never completing; the working pumps show only MAC auth. All 45 MACs are present and correctly formatted in ClearPass. Ports are configured with both 802.1X and MAC auth enabled, with a 30-second MAC auth delay.

1. Diagnose the most likely cause of the 12 intermittent failures and explain why only some pumps are affected.

Read the worked answer

The key clue is the split behavior: failing pumps emit EAPOL-Start; working pumps do not.

With both 802.1X and MAC auth enabled and a MAC-auth delay, the switch first listens for EAPOL. A device that sends EAPOL-Start but has no usable supplicant puts the port into an 802.1X authentication attempt that never completes. Depending on the switch's behavior, the port may not fall back cleanly to MAC auth, or the fallback occurs after the delay and races with the failed 802.1X state, producing intermittent quarantine placement.

The 33 working pumps likely have a firmware variant or NIC setting that does not send EAPOL-Start, so they go straight to MAC auth after the delay. The 12 that do send EAPOL are the ones tripping the 802.1X path.

This is a protocol-behavior mismatch, not a ClearPass database problem - all MACs are present and formatted, so authorization data is not the fault. The intermittent nature fits a race between the EAPOL attempt and the MAC-auth timer rather than a hard misconfiguration.

2. Propose a remediation that keeps the pumps on the clinical VLAN without weakening security for the workstations sharing those switches.

Read the worked answer

Remediation: separate the authentication method from the port, not the security posture.

  1. Identify the 12 pumps' firmware/NIC behavior and confirm the EAPOL-Start observation with a packet capture on one failing port. Document it.
  2. Move pumps to dedicated access ports (or a dedicated switch/stack member where feasible) configured for MAC authentication only, with 802.1X disabled on those ports. This removes the EAPOL race entirely.
  3. On those pump ports, keep the MAC-auth delay short (or zero) since there is no 802.1X to wait for, and enforce MAC auth + port profile in ClearPass so a rogue device plugging into a pump port still fails authorization.
  4. Do not disable 802.1X globally on shared switches - workstations must retain PEAP-MSCHAPv2.
  5. Add profiling in ClearPass (DHCP fingerprint, OUI) as a secondary check so a spoofed MAC on a pump port is less likely to succeed, and alert on MAC-auth successes from unexpected OUIs.
  6. If dedicated ports are impossible, set the switch to MAC auth with 802.1X as an optional method and verify the fallback timer behavior in a lab before rolling out.

Residual risk: MAC auth is spoofable; compensating controls are port security (MAC limit of 1), profiling, and physical port control in clinical areas.