802.1X EAP TLS vs MAB: Securing Ports for Devices Without Certificates

Every wired port that falls back to MAC Authentication Bypass (MAB) admits whoever can copy a MAC address, so the real security of a NAC estate is set by its weakest fallback, not by its strongest EAP method. 802.1X with EAP-TLS proves possession of a private key bound to a certificate; MAB only checks that an address the switch observed appears in a list. Both are needed in almost every network, because printers, cameras, badge readers, building controllers and medical devices often cannot run a supplicant. This guide treats the pair as a design decision: the threat model and failure modes of each, how they interact on the same port, which devices genuinely need MAB, and the compensating controls that make a MAB port tolerable. It is written for network and identity engineers who own switch and RADIUS policy. The mechanics of NAC are in the Network Access Control (NAC) Guide and building EAP-TLS is in the 802.1X and EAP-TLS Enterprise Wi-Fi Guide; this page goes deeper on the choice between them.

Key takeaways

• The short answer is EAP-TLS wherever a device can hold a key. MAB is a device allow list, not authentication, and belongs only on devices that cannot run a supplicant, with authorisation scoped to that device class.
• MAB access must be narrower than certificate access. A MAB accept should land in a restricted segment or carry a downloadable ACL that permits only the flows the device class needs, never a full user VLAN.
• The fallback path is where estates get breached. Ports configured to try MAB after a failed 802.1X attempt let an attacker unplug a printer, clone its address and inherit its access, so the permissions behind every MAB rule are the actual exposure.
• Profiling is the compensating control, not a second factor. Classification from DHCP, LLDP, HTTP and other signals should confirm that a MAC still behaves like the device it is registered as, and trigger a change of authorisation when it does not.
• The goal is to shrink MAB over time. Device certificates (IEEE 802.1AR DevIDs, EST or SCEP enrolment) are reaching more device classes, so track the MAB population as a metric and move each class to certificates as soon as its firmware allows.

The short answer and the comparison table

EAP-TLS and MAB are not two grades of the same control. EAP-TLS is mutual, cryptographic authentication: the RADIUS server presents a certificate, and the peer should present one too, with revocation checks on the chain. RFC 9190 (Standards Track, February 2022) updates RFC 5216 for TLS 1.3, makes forward secrecy the norm for full handshakes, protects the peer identity, requires support for OCSP stapling and caps resumption tickets at 7 days. MAB, by contrast, sends the MAC address the switch learned from the first frame as both User-Name and User-Password in a RADIUS Access-Request, with Service-Type set to 10 (Call-Check). Anyone who can transmit a frame with that source address produces an identical request.

EAP-TLS: threat model and how it fails

The attacker against an EAP-TLS port needs a private key that chains to a CA the RADIUS server trusts, plus whatever certificate attributes the authorisation policy checks. With keys held in a TPM or secure element that is hard, so attacks move to the edges of the system.

• Enrolment abuse: a SCEP or EST endpoint that issues certificates on a shared challenge lets an attacker mint a valid device identity. Tie enrolment to an MDM-asserted device record, as described in the IoT and Device Certificate Provisioning (EST, SCEP) Guide.
• Trust too wide: trusting a whole enterprise issuing CA for network access lets any certificate from that CA (web servers, code signing) authenticate. Restrict by issuing CA, template OID or extended key usage in RADIUS policy.
• Revocation not checked: a stolen laptop keeps network access until its certificate is revoked and the server actually checks. RFC 9190 makes chain revocation checking mandatory; confirm the server fails closed when the CRL or OCSP responder is unreachable, or at least alerts.
• Exportable keys: certificates issued with exportable private keys can be copied to an unmanaged machine. Use non-exportable keys and hardware-backed key storage.
• Operational expiry: an expired RADIUS server certificate or device certificate takes whole sites offline, which tempts teams to open fail-open policies. Monitor expiry, as covered in the 802.1X Authentication Troubleshooting Guide.

The residual threat EAP-TLS does not address is a rogue device placed behind an authenticated one, for example a small switch or bridge inserted between a desk phone and the wall port. Host modes that allow only one data device per port, and MACsec where hardware allows, close that gap. See the MACsec guide.

MAB: threat model and how it fails

The attacker against a MAB port needs only an address on the allow list and physical or logical access to the port. Printer and camera MAC addresses are printed on labels, broadcast in every frame and often listed in configuration pages. Cisco's own MAB deployment guide states plainly that MAC addresses can be spoofed and that MAB is not strong authentication; it also notes that MAB authenticates devices, not users, and that the MAC database is a prerequisite that is hard to maintain.

• Unplug and clone: the classic attack is to disconnect a printer in a meeting room, configure a laptop with its address and plug into the same port. If the printer's authorisation is a general user VLAN, the attacker has a general user VLAN. This maps to MITRE ATT&CK T1200 Hardware Additions.
• Fallback after failed 802.1X: flexible authentication can run MAB when a supplicant presents bad credentials, if the supplicant fails open and sends traffic. That turns every EAP failure into a MAB attempt, so a laptop with a broken certificate can be admitted as whatever MAC it claims.
• Request confusion: if RADIUS policy does not check Service-Type 10, a MAC address submitted as a username and password in an ordinary authentication request could be treated like a credential. Cisco recommends filtering on Service-Type so MAC addresses cannot be used that way.
• Stale database: entries for decommissioned devices stay valid indefinitely. Each one is an address an attacker can borrow without anyone noticing a duplicate on the network.
• Randomised addresses: phones and laptops use private Wi-Fi addresses by default. Apple, for example, uses a different address for each network, fixed on WPA2 or stronger networks and rotating every two weeks on weak or open ones. MAC allow lists cannot follow these devices, so they need 802.1X or a portal, not MAB.

MAB has protocol limits too. Cisco notes that the switch learns the address from the first frame other than CDP, LLDP, STP or DTP, that packets sent during the 802.1X timeout are discarded, that RADIUS reauthentication does not end MAB sessions, and that endpoints do not notice a VLAN change without a link flap. Each of these matters when you try to quarantine a suspect MAB device.

How the two interact on the same port

Most switches can run both methods on one port, and the order is a design decision with security consequences.

The safe principle is that the authorisation result, not the authentication method, decides exposure. A MAB accept should be identifiable in policy (Service-Type 10, or the method attribute your RADIUS server exposes) and mapped to a device-class rule, so that a cloned printer address gets printer access and nothing else. RFC 3580 describes the standard way to return a VLAN in the Access-Accept: Tunnel-Type 13 (VLAN), Tunnel-Medium-Type 802 and Tunnel-Private-Group-ID carrying the VLAN ID.

Compensating controls for MAB ports

Where a device class must stay on MAB, layer controls so that a spoofed address gains little and is noticed quickly.

1. Restrictive authorisation per class: return a downloadable ACL or a dedicated segment that permits only the device's flows (a printer to print servers on its print protocols, a camera to its recorder). This is the single most important control. See the Identity Segmentation vs Network Segmentation guide for the wider design.
2. Service-Type enforcement: accept a MAC as an identity only in requests with Service-Type 10, so MAC values never work as passwords elsewhere.
3. Profiling and change of authorisation: classify devices from DHCP options, the vendor OUI, LLDP or CDP, HTTP user agents and SNMP, and send a change of authorisation when a MAC registered as a camera starts behaving like a laptop. Treat a profile change as an incident signal, not a cosmetic update.
4. Single host mode: use the most restrictive host mode the port allows, so one authenticated MAC does not open the port for others behind it.
5. First-hop protections: enable DHCP snooping, Dynamic ARP Inspection and IP Source Guard on access VLANs, which Cisco lists among MAB mitigations and which also blunt ARP Cache Poisoning (T1557.002). The Layer 2 Attacks Guide covers these.
6. Duplicate and location checks: alert when the same MAC is seen on two ports or switches at once, or moves from its expected closet or floor.
7. Database hygiene: give every MAC entry an owner, a device class and an expiry, and remove entries not seen for a set period. Use OUI wildcards only where a vendor prefix maps to a single device class.
8. Accounting: enable RADIUS accounting for MAB sessions so investigations can place an address on a port at a time.

Cisco's MAB guide also advises against port security on MAB ports because the features conflict, and recommends an inactivity timer, preferably sent by RADIUS as Idle-Timeout, so sessions end when a device leaves.

When to use each

• Managed Windows, macOS, Linux and mobile devices: EAP-TLS with certificates from MDM or auto-enrolment. Never MAB, and never MAB fallback on ports these devices use routinely.
• Modern IoT that supports certificates: EAP-TLS with an LDevID provisioned over EST or SCEP, or with the manufacturer IDevID where your RADIUS server can trust the manufacturer chain. IEEE 802.1AR-2018 defines IDevIDs as manufacturer-installed, protected identifiers and LDevIDs as administrator-created identifiers bound to the device; the 802.1AReg-2026 amendment adds ML-DSA support.
• Legacy devices with no supplicant: MAB with every compensating control above, on ports dedicated to that class where possible, and an entry on the replacement plan.
• Devices that support only password methods: a password EAP method on a separate policy is still better than MAB for devices that can run a supplicant; see EAP-TLS vs PEAP.
• Clinical and OT devices: often MAB for years because certification limits firmware changes. Combine MAB with strict zone segmentation, as in the NAC for OT Networks Guide.

Small organisations: with a few hundred ports, start with EAP-TLS on user ports and put all non-supplicant devices on MAB into a single tightly filtered device segment; the operational cost of per-class ACLs may outweigh the gain. Large organisations: use per-class authorisation, profiling with automated change of authorisation, and a quarterly review of the MAB population by business owner.

Worked scenario: an illustrative hospital campus with 9,000 ports

A hospital runs 802.1X in monitor mode on 9,000 wired ports. RADIUS logs show 5,200 managed endpoints with machine certificates, 2,900 non-supplicant devices (printers, phones, infusion pump gateways, cameras, building controllers) and around 400 unknown addresses. The network team had planned "802.1X first, MAB on failure" everywhere with all MAB devices in the clinical VLAN.

The review changed three things. First, the failover-after-EAP-failure option was removed from user ports, because a laptop with a broken certificate would otherwise be admitted under any cloned clinical address. Second, MAB accepts were split into seven device-class profiles, each with its own downloadable ACL: phones to call managers, printers to print servers, pump gateways only to their management server, cameras only to recorders. Third, ports in clinical areas used MAB first for speed, because some devices lost DHCP during the 90-second 802.1X timeout, but profiling changes on those ports triggered a change of authorisation to a quarantine segment and a ticket. The 400 unknown addresses were traced through purchasing records and switch port descriptions before enforcement; 60 were never claimed and were left without access. After a year, two device classes moved to certificates after firmware updates, cutting the MAB population by 18 per cent.

Implementing the design

1. Monitor first: run 802.1X and MAB in monitor or open mode and collect RADIUS logs for at least one full business cycle to see which devices authenticate how.
2. Build the MAC database with owners: seed it from purchasing records, voice platform lists and monitor-mode logs, then assign a device class and owner to every entry.
3. Write authorisation by class: define the downloadable ACLs or segments per device class and test them on a pilot floor before any enforcement.
4. Set port order per port role: 802.1X only on user ports, MAB first on dedicated device ports, multi-domain on phone ports. Tune timers against DHCP and PXE behaviour.
5. Turn on profiling and change of authorisation: start in alert-only mode, review false positives, then enable automatic quarantine for high-confidence profile changes.
6. Enforce in rings: move to closed mode floor by floor, with a rollback that returns a switch stack to monitor mode by template change, and a documented break-glass procedure for clinical or production areas.
7. Retire MAB by class: for each device class, record whether firmware supports 802.1X, which EAP method and which enrolment protocol, and schedule migration.

Detection and measurement

Log RADIUS authentication and accounting for both methods, with method, Service-Type, Calling-Station-Id, NAS and port, authorisation result and profile. Alert on the same MAC active on two ports, a profile change for a MAB device, MAB accepts on ports designated 802.1X only, bursts of EAP failures followed by MAB accepts on the same port, and MAB entries that authenticate after long inactivity.

Common failure patterns

• MAB devices in the user VLAN: the printer's address grants the same access as a managed laptop, so one cloned label defeats the whole NAC programme.
• Global MAB fallback: MAB enabled as a fallback on every port, including user ports where no legitimate non-supplicant device exists.
• No Service-Type check: RADIUS policy matches the MAC in the username without confirming the request is a Call-Check, widening the ways a MAC can be used.
• A MAC list nobody owns: years of additions, no removals, OUI wildcards that admit a whole vendor's product range including laptops.
• Profiling as display only: profile changes are visible in the console but never trigger enforcement or a ticket.
• Fail-open after certificate outages: an expired server certificate leads to a temporary "permit all" or MAB-for-all rule that is never removed.

Framework mapping

Practitioner checklist

• Inventory every port role and decide 802.1X only, MAB first or multi-domain for each.
• Remove MAB failover after EAP failure from user ports.
• Require Service-Type 10 in every RADIUS rule that accepts a MAC as identity.
• Give every MAB device class its own restrictive ACL or segment; no MAB device in a user VLAN.
• Assign an owner, class and expiry to every MAC entry and purge entries unseen for 90 days.
• Enable profiling with change of authorisation on profile change for MAB devices.
• Turn on DHCP snooping, Dynamic ARP Inspection and IP Source Guard on access VLANs.
• Restrict EAP-TLS trust to the issuing CA and template used for network access, with revocation checks.
• Track the MAB population as a KPI and schedule each device class for certificates.

Standards and references

• IETF: RFC 9190 EAP-TLS 1.3
• IETF: RFC 3580 IEEE 802.1X RADIUS Usage Guidelines
• IEEE 802.1: 802.1AR Secure Device Identity
• Cisco: MAC Authentication Bypass Deployment Guide
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Hardware Additions
• Apple: Use private Wi-Fi addresses on Apple devices

Related NHI Mgmt Group resources: Network Access Control (NAC) Guide · 802.1X and EAP-TLS Enterprise Wi-Fi Guide · 802.1X Authentication Troubleshooting Guide · IoT Security Guide