Five Minutes and an Empty Port Part 8: 802.1X, MAB, and the NAC Platforms Behind the Curtain

Part 7 covered controls that key off a MAC address: learn it, trust it, keep answering the same question every time that address shows up. That’s useful, and it’s also exactly the layer a spoofed MAC address defeats. 802.1X moves the question up a level, from “is this the device I already saw” to “can this identity prove who it is,” and it’s the control that would have stopped several of the vectors in this series outright rather than just making them harder.

The three roles

802.1X involves three parties. The supplicant is the client device trying to get on the network, running client software that speaks the protocol. The authenticator is the switch or wireless access point the device is plugged or associated into, which does not itself decide who gets access, it just relays authentication traffic and enforces whatever decision comes back. The authentication server is a RADIUS server, Cisco ISE, FortiNAC, Aruba ClearPass, or a plain FreeRADIUS instance, that actually makes the call.

Until authentication succeeds, the port stays in an unauthorized state and passes nothing except EAPOL, the Extensible Authentication Protocol over LAN traffic the 802.1X exchange itself runs over. Plug an unauthenticated device into a properly configured 802.1X port and it doesn’t get an IP address, doesn’t see a DHCP offer, doesn’t see anything at all beyond the authentication conversation it’s failing to complete.

The actual credential exchange runs over EAP, and the method matters. EAP-TLS, certificate-based on both sides, is the strongest common option and the one worth aiming for on managed corporate devices. PEAP-MSCHAPv2, username and password inside a TLS tunnel, is far more common in practice because it doesn’t need a certificate deployed to every endpoint, at the cost of being weaker than EAP-TLS if the underlying credential itself is compromised.

MAB: the fallback that’s also the weak point

Printers, IP phones, badge readers, and plenty of IoT devices can’t run an 802.1X supplicant at all. MAC Authentication Bypass exists for exactly that case: the switch falls back to authenticating the device by its MAC address against a known-good list, the same mechanism Part 7 already flagged as spoofable. MAB is a necessary compromise, not a flaw in the protocol, but it’s worth being honest that a port configured for MAB fallback is only as strong as the assumption that nobody’s presenting a cloned MAC address from a device they found on the same LAN segment. Device profiling, using DHCP fingerprinting, LLDP/CDP details, and behavioral signals to build a higher-confidence picture of what a MAB device actually is, is how NAC platforms narrow that gap rather than close it outright.

Dynamic policy, not just a yes/no

The payoff for doing 802.1X properly is that the authentication server’s response can carry more than a pass/fail. RADIUS can return a VLAN assignment, a downloadable ACL, or, on Cisco gear, a TrustSec Security Group Tag, meaning the same physical port hands a corporate laptop one set of access and a guest device a completely different one, decided dynamically at authentication time rather than by which cable happened to be plugged in where.

A minimal Cisco IOS-XE dot1x port looks like this:

interface GigabitEthernet1/0/12
 switchport mode access
 authentication port-control auto
 authentication order dot1x mab
 authentication priority dot1x mab
 dot1x pae authenticator
 mab

authentication order dot1x mab tries 802.1X first and falls back to MAB only if the device never responds to an EAPOL identity request. FortiSwitch does the equivalent through FortiLink’s config switch-controller security-policy 802-1X, pointed at a RADIUS server defined under config user radius, typically FortiNAC or a FortiAuthenticator instance. Junos EX configures it under [protocols dot1x authenticator], with a mac-radius stanza providing the MAB-equivalent fallback.

The NAC platform behind the RADIUS server

The RADIUS response itself is usually only the visible tip of a full Network Access Control platform. Cisco ISE adds posture assessment (checking a device’s patch level, AV status, or disk encryption before granting full access), device profiling, and TrustSec policy. FortiNAC ties the same functions into Fortinet’s Security Fabric, feeding device visibility back to the FortiGate estate this site has covered extensively elsewhere. Aruba ClearPass and Juniper’s Mist Access Assurance play the equivalent role in their respective ecosystems, cloud-native in Juniper’s case.

None of this is a single-control fix. 802.1X with a real NAC platform behind it is the strongest thing covered in this series so far specifically because it composes with everything in Part 7 rather than replacing it, a spoofed MAC still has to get past port security’s learned-address limit, and a device that clears MAB still only gets whatever narrow VLAN and ACL a profiling engine decided a MAB-authenticated printer should have.

Part 9 closes the defensive arc: MAC OUI and vendor filtering with an honest look at its real limits, USB device control at the OS level for the vector Part 3 built its whole argument around, and wireless IDS for the deauthentication attacks Part 4 confirmed still work regardless of MAC randomization.