MAC Address Lookup
· Jondy

Four Ways MAC Randomisation Breaks NAC — and How to Fix Them in 2026

Enterprise networks
MAC randomisation NAC Captive Portal DHCP exhaustion RFC 9797 IEEE 802.11bh Passpoint OpenRoaming zero trust Persistent-Device-Id

For twenty years, enterprise Network Access Control (NAC) quietly rested on one unwritten premise: a device's MAC address stays stable for long periods. That single assumption underpins MAC Authentication Bypass (MAB, described in 802.1X and MAC Authentication Bypass), Captive Portal session caching, guest VLAN assignment by MAC, visitor footfall dashboards keyed on unique MAC counts — nearly every core feature of every major NAC vendor.

Per-network MAC randomisation, introduced as the default on iOS 14 (September 2020), iOS 18's Rotating mode (September 2024), Android 10 and Windows 10 2004, is systematically demolishing that premise. Purple.ai's industry briefing of May 2026 groups the failures into four simultaneous symptoms, while RFC 9797 (June 2025) and IEEE 802.11bh-2024 formalise the problem at the standards layer. This article breaks each symptom down, then covers the three dominant remedies for 2026 — and explains why "turn randomisation off" is neither realistic nor worth the fight.

Symptom 1: Captive Portal fatigue — endless re-authentication

The most immediate failure. Enterprises and retailers typically implement their Captive Portal's "remember me" feature by keying sessions on the MAC address. Next time the same MAC reconnects, it lands straight in. MAC randomisation means that key changes every time the SSID changes, every 24 hours under iOS 18 Rotating mode, and sometimes more. The portal never recognises a returning customer, so every visit forces them to re-enter name and email, click consent again, and sit through the splash page.

Purple.ai reports a chain reaction: one retail chain saw Captive Portal re-auth rates jump from 30% to 90% after the iOS 18 roll-out, and user tripling followed. Worse, the Portal backend's session table keeps inserting brand-new MACs that never match old rows for cleanup — the bloated table drags down the Portal's response time for everyone.

Why MAB collapses too. MAB fundamentally submits the MAC as both username and password to RADIUS. When the cache key rotates, RADIUS never hits the whitelist; every attempt falls through to the "unknown device" policy (rate-limited or quarantined VLAN), and the user still has to go to the portal to escalate manually. The division of labour between 802.1X and MAB stops working once MACs are randomised.

Symptom 2: DHCP pool exhaustion — one physical device steals multiple IPs

The most hidden and deadly failure. One phone with per-network randomisation that switches between three SSIDs in a day (shopping mall → coffee shop → another retailer) generates three MACs, requests three IPs, and opens three DHCP leases. Operators report chilling numbers: a DHCP scope originally sized for 200 devices with 2000 addresses exhausted on the day of the iOS 18 roll-out — new visitors could not obtain IPs and thought the Wi-Fi was broken.

Deeper still: a DHCP lease's Client Identifier is frequently the MAC itself in randomised times. Before a lease expires, the same physical device can reappear with a new MAC, and DHCP has no way to know it is the same host — so it issues yet another IP.

Troubleshooting the exhaustion starts by looking at the MAC OUI distribution in the lease table. Filter for locally administered addresses (starting with 02/06/AE — see the detection rule here); these are the randomised clients hopping addresses.

Symptom 3: NAC policy mismatch — whitelists bound to MACs stop working

Many NAC policies are written directly on MAC addresses:

  • Only aa:bb:cc:dd:ee:ff (a printer's real hardware MAC) can join the IoT VLAN
  • Only prefix xx:xx:xx (an iPhone OUI) can join the guest VLAN
  • This MAC must be rate-limited to 1 Mbps

MAC randomisation invalidates all of them. IoT devices, because they use real hardware MACs, are fine — the failures hit BYOD users, whose MACs are randomised. The result: devices that should land in the IoT VLAN land there (they are fine), but devices that should land in the guest VLAN get dumped into an isolated "unknown device" VLAN — and every day an admin has to manually whitelist the new MACs, with no end in sight.

An amplifier in enterprise networks: Wi-Fi 7 MLO gives one device multiple per-link MACs (see Wi-Fi 7 MLD MAC vs per-link MAC). If the NAC recognises only one of them, link switching triggers a re-auth for the whole device — combining that with iOS 18 Rotating mode, a laptop can trigger fifteen different MACs in one day.

Symptom 4: Inflated analytics — "5000 unique visitors today" when only 1500 came

Retailers and hotels rely on visitor footfall, dwell time, returning-visitor rates and heatmaps, all built on the assumption that one MAC = one person. iOS 14+ per-network randomisation shattered that: one hotel chain reported that post-iOS 18, analytics dashboards inflated unique-visitor counts by 300–500%, returning-visitor rates crashed from 40% to 3%, and dwell-time statistics collapsed by half because sessions kept getting split across new MACs. Purple.ai calls this the most expensive failure — because marketers make budget and location decisions on flawed data, and that is not a technical issue, it is a business one.

Worse, Wi-Fi analytics platforms (Meraki Analytics, Aruba Central Guest Insights) de-duplicate by MAC by default. After the upgrade, all historical baselines are invalidated, so year-over-year comparisons break too.

What the standards say

RFC 9797 (June 2025, Network Working Group) is IETF's formal analysis of MAC randomisation's network impacts. It walks through each scenario — NAC, DHCP, visitor analytics, geofencing — and describes the failure modes in detail, essentially restating Purple.ai's four symptoms at the protocol layer. It does not prescribe solutions; it documents the problem for working groups to follow up.

IEEE 802.11bh-2024 (Secure Roaming and Session Continuity) confirms at the standards layer that session continuity does not require a fixed MAC. It introduces a Device Identifier Element (DIE) inside EAPOL-Key frames so the same device can maintain one 802.1X session even when its MAC changes. That is exactly why Wi-Fi 7 + 802.1X enterprise networks avoid false re-authentications when MACs rotate.

Three fixes

1. Move NAC from MAC identity to 802.1X + credentials / certificates. This is the unanimous top priority from Purple.ai, Cisco Live BRKOPS-2683 (February 2025), and arXiv 2603.16745 (March 2026, the RADIUS GUID framework). The core idea: the network stops authenticating "a MAC I recognise" and starts authenticating "a user or certificate I recognise". On authentication success, the device receives a GUID in the RADIUS Access-Accept (the Persistent-Device-Id attribute — IETF draft-seralathan-radext-persistent-devid-00, covered in recognising devices after MAC randomisation in the enterprise). All future sessions, accounting and policies bind to that GUID, not the MAC. The MAC is just a temporary carrier address.

Cisco ISE 3.3, Aruba ClearPass and Fortinet FortiNAC all introduced "randomisation-aware" logic in their 2025–2026 releases: they actively check whether a device is using randomisation (by comparing RADIUS Calling-Station-Id against the 802.1X DIE) and skip MAC-based policy evaluation when it is.

2. Move guest networks to Passpoint / OpenRoaming (Hotspot 2.0). This is the direct fix for Captive Portal fatigue. Passpoint lets devices discover compatible APs automatically and authenticate to an Identity Provider (hotel loyalty app, carrier, OpenRoaming federation) with 802.1X — the user never touches the portal. Passpoint does not care about MAC — identity is carried by the Subscriber Identity issued to the client by the IdP, entirely independent of layer-2 addresses. Purple.ai's 2026 report documents retail sites where Captive Portal re-auth rates dropped below 5% and returning-visitor detection recovered to pre-upgrade levels after enabling Passpoint.

3. De-bind NAC policies from MACs. IoT devices keep MAB — they truly have no supplicant and their real MACs are stable. BYOD and corporate devices must run 802.1X. Policies are written on user group / certificate type / device class, never on MAC. Device classification can still use MAC-prefix profiling (a 00:50:56 means VMware — run it through the lookup page), but the policy triggered by classification should bind to a class tag, not to a specific MAC.

In one sentence

MAC randomisation breaks NAC in four ways (Portal fatigue, DHCP exhaustion, policy mismatches, inflated analytics) that are not four independent bugs — they are four faces of one collapse: the assumption "MAC = stable device identity" is dead. RFC 9797 and IEEE 802.11bh-2024 formalised the reality at the standards layer, and Purple.ai together with Cisco gave the road map at the product layer: shift from identity-by-hardware to identity-by-credential. Move NAC from "allow by MAC" to "allow by certificate / username (MAC is just the carrier)", replace the Captive Portal with Passpoint, and de-bind NAC policies from MACs. Those three changes together make all four symptoms disappear. "Turn randomisation off" is neither realistic (privacy settings and compliance) nor worth it — iOS 18's Rotating mode makes the MAC rotate even when you force "fixed", because privacy-by-design is now baked in.

References

Related Articles
About the Author · Jondy

Network engineer with a background in enterprise network operations and security. Founded 7n4.cn in 2017. Questions or suggestions are welcome—get in touch.

← Back to Blog
MAC addresses are assigned by IEEE. Data from Wireshark
About  ·  Privacy Policy  ·  Contact Us
© 2017–2026   沪ICP备19020320号-5