Support Library
MAC Authentication Bypass (MAB) Explained
MAC Authentication Bypass (MAB) lets a switch admit devices that cannot run 802.1X by using their MAC address as their identity. The switch sends the MAC to a RADIUS server, which looks it up and decides what access the device gets.
The short answer
Many devices on a network have no 802.1X client: printers, IP cameras, badge readers, medical devices, building controllers and older equipment. If 802.1X is enforced on every port, those devices are locked out. MAB is the usual fallback. When a device does not answer the switch's 802.1X requests, the switch reads the source MAC address from the device's first frame and asks the RADIUS server whether that MAC is allowed.
MAB is a vendor feature, not part of the IEEE 802.1X standard, and the name varies: Cisco calls it MAC Authentication Bypass, while other vendors call it MAC authentication or MAC-based RADIUS authentication. The behavior is broadly the same everywhere.
Every frame a device sends carries its MAC address, and most operating systems let a user change it. Anyone who can read a label on a printer or watch traffic on a port can copy it. MAB says "a device claiming to be this printer is here", never "this is definitely the printer", so it must be paired with tight limits on what MAB devices can reach.
How MAB works
In the 802.1X-first fallback configuration shown here, the switch starts MAB after receiving no EAPOL response. Other configurations can run MAB first or apply different actions after an authentication failure. Method order, priority and failure handling depend on vendor and policy; verify them explicitly. The diagram follows a printer on a port configured for 802.1X with MAB fallback.
What the switch sends to RADIUS
A MAB request is an ordinary RADIUS Access-Request. The device has no credentials, so the switch builds them from the MAC address:
| Attribute | Typical value | Notes |
|---|---|---|
| User-Name | The MAC address | The format is configurable on most switches: 001a2b3c4d5e, 00-1A-2B-3C-4D-5E or 00:1a:2b:3c:4d:5e. It must match how the server stores MACs |
| User-Password | The MAC address again, or a shared password on some platforms | Not a secret either way |
| Calling-Station-Id | 00-1A-2B-3C-4D-5E | RFC 3580 recommends upper-case hex separated by hyphens for 802.1X sessions |
| Service-Type | Call-Check (10) on Cisco switches | Lets the server tell a MAB request from a user signing in with a password. Other vendors may send a different value |
| NAS-Port-Id, NAS-IP-Address | The port and switch | Useful in policy, for example only allowing a camera's MAC on camera ports |
A server that accepts any request whose password equals its user name would let anyone in who types a MAC address at a password prompt. That is why the server should treat MAB requests as their own policy, matched on Service-Type or the vendor's equivalent, and never check them against the same rules as user logins.
Profiling: knowing what the device really is
A static list of allowed MAC addresses goes stale quickly. Network access control products add profiling: they collect clues about each device and classify it, then apply policy by device type rather than by individual address.
- Manufacturer prefix. The first three bytes of a MAC address, the OUI, are assigned to a manufacturer by the IEEE. 00-1A-2B belongs to one vendor, which narrows the device down.
- DHCP fingerprints. The list of options a device asks for in its DHCP request, and its vendor class, differ between operating systems and device families.
- Discovery protocols. LLDP and CDP announcements often include the model and software version.
- Traffic. HTTP user agents, the services a device talks to, and active scans can confirm a classification.
Profiling also catches spoofing. If a MAC registered as a printer starts making remote desktop or file sharing connections, the profile no longer matches, and the server can use Change of Authorization to re-authenticate the port or move it to a quarantine VLAN.
Limiting the damage of a spoofed MAC
Because MAB can be fooled, the design goal is that a spoofed MAC gets an attacker very little:
- Give each device type the least access it needs. Printers need the print servers, cameras need the video recorder, and neither needs the user VLAN, the internet or each other.
- Use single-host or multi-auth mode so a second device behind the first cannot share its session.
- Tie MACs to locations where that is practical, so a camera's MAC is only accepted on ports where cameras are installed.
- Watch for duplicates. The same MAC authenticating on two ports at once, or from a new location, is a strong sign of cloning.
- Move devices to certificates when you can. Many current printers, phones and access points support EAP-TLS. Each device moved off MAB is one less address to spoof.
Timing and order
By default many switches try 802.1X first and only fall back to MAB after several unanswered identity requests. With some vendors' default timers that takes around 90 seconds, which can be longer than a device waits for DHCP before giving up. There are two common fixes:
- Shorten the 802.1X timers on ports that host devices without supplicants, so the switch gives up sooner.
- Run MAB first, then let 802.1X take over if the device later starts talking EAPOL. Switches that support this order still prefer 802.1X when both succeed.
Randomized MAC addresses
Phones, tablets and laptops now hide their hardware MAC address for privacy. Apple devices use a private Wi-Fi address for each network, which can rotate every two weeks on iOS 18 and later, Android has randomized addresses per network by default since Android 10, and Windows offers random hardware addresses as an option.
A randomized address has the "locally administered" bit set, so its second hex digit is 2, 6, A or E, as in x2-xx-xx-xx-xx-xx. That makes it easy to spot, but impossible to match against an inventory list. Do not use MAB for user devices; put them on 802.1X, where the identity comes from a certificate or account rather than the MAC address.
Troubleshooting
| Symptom | Likely cause |
|---|---|
| Device never gets an address | It gives up on DHCP before the switch falls back to MAB; shorten timers or run MAB first |
| Server log shows an unknown user that looks like a MAC | The MAC format the switch sends does not match the format stored on the server |
| Known device rejected after a hardware change | A replacement network card or docking station has a different MAC |
| Phone or laptop rejected every few weeks | It uses a randomized or rotating MAC; move it to 802.1X |
Commands on a Cisco IOS XE switch:
| Command | What it shows |
|---|---|
| show access-session interface Gi1/0/5 details | Whether 802.1X or MAB succeeded, the MAC, and the VLAN and access list applied |
| show access-session mac 001a.2b3c.4d5e details | The same session found by MAC address instead of port |
| show mac address-table interface Gi1/0/5 | Which MAC addresses the switch has learned on the port |
FAQ
Is MAC Authentication Bypass secure?
Not on its own, because a MAC address can be read and copied by anyone. It is acceptable for devices that cannot run 802.1X when each MAB device is limited to the few destinations it needs, profiled to confirm it is what it claims to be, and monitored for duplicates.
Is MAB part of the 802.1X standard?
No. IEEE 802.1X only covers EAP-based authentication. MAB is a vendor feature that reuses the same switch port controls and RADIUS server, which is why its name, timers and attribute formats differ between vendors.
Why does it take so long for a printer to come online?
The switch usually tries 802.1X several times before falling back to MAB, which with some default timers takes around 90 seconds. Shortening the timers or configuring MAB to run first on those ports fixes it.
Does MAB work with phones that use private Wi-Fi addresses?
Not reliably. Randomized addresses differ for each network and some rotate over time, so they cannot be matched against a list. User devices should authenticate with 802.1X instead.
Sources and further reading
- RFC 2865: Remote Authentication Dial In User Service (RADIUS): the User-Name, User-Password and Service-Type attributes
- RFC 3580: IEEE 802.1X RADIUS Usage Guidelines: section 3.21 on the Calling-Station-Id format
- RFC 5176: Dynamic Authorization Extensions to RADIUS
- Cisco: MAC Authentication Bypass Deployment Guide: Service-Type Call-Check and fallback timing; an older guide, so check current platform docs
- IEEE Registration Authority: how OUIs and locally administered addresses are assigned
- Apple Support: Use private Wi-Fi addresses on Apple devices
- Android Open Source Project: MAC randomization behavior