How to implement MAC address filtering

MAC address filtering lets your router or switch decide who gets on the network based on each device's hardware address. It's one of the oldest access-control mechanisms in networking, and one of the most misunderstood: it is not meaningful security against an attacker, but it remains genuinely useful as an inventory-enforcement and accident-prevention layer.

This guide covers setting it up properly, the MAC randomization problem that breaks naive deployments, and an honest assessment of what you're actually buying.

What MAC filtering does and doesn't do

A MAC filter is a list of hardware addresses your network equipment checks before allowing a device to associate (Wi-Fi) or pass traffic (switch port). Two modes:

• Allowlist: only listed MACs get access. The useful mode.
• Denylist: listed MACs are blocked, everything else gets in. Nearly useless: an attacker just shows up with a different MAC.

The fundamental weakness: MAC addresses are transmitted in cleartext in every 802.11 frame, even on encrypted networks; frame headers aren't covered by WPA encryption. Anyone within radio range running a passive capture sees every MAC currently allowed on your network. Spoofing one of those MACs is one command:

# Linux
sudo ip link set dev wlan0 down
sudo ip link set dev wlan0 address AA:BB:CC:DD:EE:FF
sudo ip link set dev wlan0 up

So a competent attacker bypasses MAC filtering in minutes. What it does stop: casual freeloaders, devices joining with a leaked Wi-Fi password but no intent, employees plugging unauthorized gear into a wall port, and the slow entropy of unknown devices accumulating on a small-business network. If you need security against an actual adversary, the answer is 802.1X / WPA-Enterprise with per-user credentials; MAC filtering is not a substitute, and pretending otherwise is the main way it does harm.

Step 1. Compile the authorized-device list

This step is the real work, and it's also the main payoff: you end up with an asset inventory whether or not you keep the filter on.

Gather the MAC of every device that should be on the network. Sources:

• The router's current client / DHCP lease list (the fastest bulk source)
• arp -a from a machine on the segment after a ping sweep
• Device labels (most IoT gear prints the MAC on a sticker)
• OS network settings on laptops and phones

For each MAC, run it through the MAC Address Lookup tool and record the vendor next to it. This catches transcription errors immediately (a "Dell laptop" whose MAC resolves to Espressif is a typo or a mystery), and it makes the list legible to whoever maintains it after you. Anything in the current client list that you can't identify needs resolving before you enable the filter; see how to identify unknown network devices for that process.

Store the list as a table: MAC, vendor (from OUI), device description, owner, date added. This document outlives the filter.

Step 2. Deal with MAC randomization first

This is where most home and small-office deployments fall over. iOS, Android, and Windows all support per-network MAC randomization, and on modern iPhones and Android phones it's on by default. Two consequences:

1. The MAC you copied from the phone's settings screen may be the hardware MAC, while the phone presents a different, randomized MAC to your specific Wi-Fi network.
2. On some configurations the randomized MAC can change over time, so a phone you allowlisted today gets blocked in a few weeks.

You have two workable options per phone:

• Disable randomization for your network only. iOS: Settings → Wi-Fi → tap the network → turn off Private Wi-Fi Address. Android: network details → Privacy → Use device MAC. The phone keeps randomizing on every other network, so the privacy cost is limited to your own LAN.
• Allowlist the randomized MAC and accept that it may rotate. Fragile; not recommended.

Either way, capture the MAC the phone is actually presenting: read it from the router's client list while the phone is connected, not from the device's about screen. Randomized MACs are recognisable: the second hex digit of the first octet is 2, 6, A, or E.

Step 3. Enable filtering on the router or AP

Log into the admin interface. The feature lives under names like Wireless MAC Filter, Access Control, or Wi-Fi MAC Authentication depending on vendor, typically under wireless or security settings.

1. Set the mode to allow listed devices only.
2. Enter the MACs from your list. Most consumer routers want one entry per line or a per-device add dialog; business APs (UniFi, Omada, Aruba Instant) usually support importing or selecting from currently-connected clients, which is faster and less typo-prone.
3. Before you apply it, confirm the device you're administering from is on the list. Locking yourself out of the admin interface over Wi-Fi is the classic self-inflicted wound. If possible, apply the change while connected over Ethernet.
4. Apply.

On managed switches, the wired equivalent is port security (switchport port-security on Cisco IOS): bind allowed MACs to specific ports, with a violation action of shutdown or restrict. Same concept, same caveats.

Step 4. Test both directions

A filter you haven't tested in the blocking direction isn't configured, it's decorative.

• Authorized devices: reconnect each one. Anything that fails is usually a transcription error or a phone presenting a randomized MAC; check the router's log for the rejected address and compare.
• Unauthorized devices: take a phone not on the list (or re-enable randomization on one that is, which gives it a fresh MAC) and attempt to join with the correct Wi-Fi password. It should associate and then fail, or be refused association outright, depending on the equipment.

While you're in testing mode, verify your network services still behave: a quick pass with the Port Checker against your router and any internal servers confirms nothing else got toggled while you were in the admin UI.

Step 5. Document and define the exception process

The filter dies the first time it blocks the owner's new tablet and nobody remembers how to add it. Write down:

• Where the allowlist lives (router page and the master document)
• Who can add devices, and what they record when they do (MAC, vendor via OUI lookup, owner, date)
• How guests get access: the right answer is a separate guest SSID with no MAC filter and client isolation, not punching holes in the allowlist

Review the list quarterly and remove departed devices. An allowlist full of dead entries is an inventory that lies to you.

Honest assessment

Worth restating plainly: MAC filtering raises the bar from "knows the Wi-Fi password" to "knows the Wi-Fi password and can spoof a MAC," which is barely a bar at all for anyone who'd genuinely target you. Its real value is operational: it forces you to build and maintain a device inventory, it stops unauthorized-but-innocent devices cold, and it makes every new device an explicit, logged decision instead of a silent appearance. Run it as an inventory-enforcement tool layered under WPA2/WPA3 (or 802.1X if you have the infrastructure), and it earns its keep. Run it instead of strong Wi-Fi auth and it's theatre.

TL;DR

1. Build the authorized list first: MAC, vendor (via the MAC Address Lookup tool), device, owner.
2. Handle phone MAC randomization before enabling anything: disable Private Wi-Fi Address per network, or allowlist the presented MAC.
3. Enable allowlist mode on the router/AP; confirm your admin machine is listed before applying.
4. Test that allowed devices connect and that an unlisted device is refused.
5. Document the add/remove process; use a guest SSID for visitors.
6. Treat it as inventory enforcement, not security; MACs are cleartext and spoofable. 802.1X is the real access control.

Related

• How to identify unknown network devices: clear the unknowns before you enable the filter
• MAC Address Lookup tool: vendor-tag every entry on your allowlist
• MAC address forensics: why MACs are weak identifiers in the first place