For decades, network architecture operated on a foundational assumption: every physical network card possesses a fixed, globally unique MAC address burned into its EEPROM at the factory. Systems administrators built network management strategies around this assumption, relying on static MAC addresses for DHCP reservation pools, captive portal authentication, MAC address filtering lists, and device inventory tracking.
The widespread introduction of MAC address randomisation in modern mobile and desktop operating systems has permanently broken those assumptions. Driven by privacy concerns over passive location tracking, operating systems now routinely substitute fake, dynamically generated MAC addresses during Wi-Fi scanning and active network connections.
Understanding how MAC randomisation behaves across different operating systems—and how to identify randomized addresses—is now an essential requirement for managing contemporary local area networks.
Why MAC Randomisation Was Introduced
Before randomisation became standard, mobile devices continuously broadcast 802.11 Probe Request frames to discover nearby Wi-Fi access points. These probe requests contained the device’s true, unvarying burned-in MAC address (Universally Administered Address).
Third-party analytics firms and commercial venue operators capitalised on this behaviour by deploying networks of passive Wi-Fi sensors in shopping malls, airports, and public spaces. By recording probe request timestamps and signal strength (RSSI) from distinct MAC addresses, trackers could construct detailed physical movement profiles of individuals without their knowledge or explicit consent.
Passive Wi-Fi Sensor Network (Legacy Unrandomized Probe Requests)
Sensor A [Location 1] ──> Logs MAC 00:11:22:33:44:55 @ 10:00 AM
Sensor B [Location 2] ──> Logs MAC 00:11:22:33:44:55 @ 10:15 AM
Sensor C [Location 3] ──> Logs MAC 00:11:22:33:44:55 @ 10:30 AM
└─► Analytics Engine reconstructs exact physical walking path
To block passive tracking, standards bodies (including IEEE 802.11aq and 802.11bh working groups) and major OS vendors implemented software mechanisms to randomize Layer 2 addresses.
Two Stages of Randomisation: Scanning vs Connection
MAC address randomisation operates across two distinct operational phases:
1. Probe Request Scanning Randomisation
When a smartphone or laptop is disconnected from Wi-Fi and actively searching for networks, it transmits probe requests using a temporary, randomly generated MAC address. This scanning address changes periodically (often every few minutes or whenever the device changes location). Because probe scanning addresses change continuously, passive sensors cannot correlate separate probe requests to a single physical device.
2. Connected / Per-Network Private Address Randomisation
When a device connects to a specific Wi-Fi network (SSID), it generates a randomized MAC address dedicated to that particular network.
Instead of presenting its factory burned-in address, the device calculates or generates a pseudorandom MAC address specific to that SSID. Depending on OS configuration and user settings, this randomized address may remain persistent for that specific network or rotate periodically (e.g., every 24 hours or upon rejoin).
OS Implementation Differences and Evolution
MAC randomisation rules vary significantly across operating system versions and continue to evolve:
+------------------+-----------------------+---------------------------------------+
| Operating System | Default Behaviour | Rotation / Persistence Policy |
+------------------+-----------------------+---------------------------------------+
| Apple iOS 14+ | Private Wi-Fi Enabled | Persistent per SSID; option to rotate |
| Android 10+ | Randomized MAC Default| Persistent per SSID by default |
| Windows 10/11 | Optional / Configurable| Disabled by default; toggle per Wi-Fi |
| macOS Sequoia | Rotating Private Address| Changes periodically per network |
+------------------+-----------------------+---------------------------------------+
- Apple iOS & iPadOS: Starting in iOS 14, Apple enabled “Private Wi-Fi Address” by default for all Wi-Fi networks. The OS assigns a unique randomized MAC address to each saved SSID. In iOS 15 and later, users can enable “Rotate Private Address,” which changes the MAC address periodically.
- Android: Google introduced randomized MACs for probe scanning in Android 8 and made randomized MACs the default connection mode in Android 10. By default, Android generates a persistent randomized MAC per SSID. If a user chooses “Use device MAC” in advanced Wi-Fi settings, the phone reverts to its factory address.
- Windows: Microsoft introduced “Random Hardware Addresses” in Windows 10. Unlike iOS and Android, Windows leaves this feature disabled by default, but permits users or enterprise policies to enable randomisation globally or for specific Wi-Fi networks.
- Linux: NetworkManager supports
wifi.scan-rand-mac-addressandwifi.cloned-mac-addresssettings, allowing administrators or desktop users to configure randomisation behaviour viaNetworkManager.conf.
Technical Signature: The U/L Bit Setting
Regardless of which operating system generates a randomized MAC address, all standard implementations comply with IEEE 802 rules by setting the Universal/Local (U/L) bit to 1.
As detailed in The Anatomy of a MAC Address, setting Bit 1 of Octet 0 to 1 marks the address as Locally Administered (LAA). When operating systems generate a randomized address, they choose a random byte sequence for Octet 0 where the U/L bit is explicitly 1 and the I/G bit is 0 (unicast).
In hexadecimal, this means the second digit of the first octet in any standard randomized MAC will always be one of four characters: 2, 6, A, or E.
Standard Randomized MAC Examples:
x2:xx:xx:xx:xx:xx (e.g., 92:a1:3b:4c:5d:6e)
x6:xx:xx:xx:xx:xx (e.g., 46:1b:2c:3d:4e:5f)
xA:xx:xx:xx:xx:xx (e.g., dA:5e:6f:7a:8b:9c)
xE:xx:xx:xx:xx:xx (e.g., fE:12:34:56:78:9a)
If a host appears in a switch CAM table or DHCP binding table with a MAC address starting with 02, 06, 0A, 0E, 12, 16, 1A, 1E, etc., an administrator can immediately confirm that the host is utilizing a randomized or software-generated address.
Impact on Local Network Administration
The shift to randomized addresses created major operational challenges for legacy network management workflows:
1. DHCP IP Reservation Exhaustion
Traditional DHCP servers reserve specific IP addresses for clients based on their MAC address. When a device with rotating MAC randomisation connects to a network, the DHCP server perceives each rotated address as a completely new physical client. The server issues a new IP address from its active lease pool for every new MAC, quickly exhausting available IP pools on busy subnets.
2. Captive Portal and Re-Authentication Friction
Guest Wi-Fi networks in hotels, corporate offices, and venues rely on MAC address caching to keep authenticated devices logged in for a set duration (e.g., 24 hours). If a mobile device rotates its private MAC address while connected, the captive portal software fails to recognize the device, forcing the user to complete the login sequence again.
3. Failure of MAC Filtering as Security Control
Some legacy network administrators historically implemented MAC address whitelisting on enterprise Wi-Fi networks as a rudimentary access control measure. MAC randomisation renders whitelisting impractical, while spoofing tools make MAC filtering trivial for unauthorized actors to bypass anyway.
Recommended Network Adaptation Strategies
Network administrators should adapt infrastructure to account for randomized endpoints:
- Shift to 802.1X Enterprise Authentication: Replace MAC-based access controls and simple pre-shared keys (PSK) with WPA3-Enterprise or WPA2-Enterprise using EAP-TLS or PEAP. Authentication is tied to user credentials or digital certificates rather than volatile Layer 2 MAC addresses.
- Shorten DHCP Lease Times on Guest Subnets: Reduce lease durations (e.g., to 1 or 2 hours) on public guest networks to reclaim abandoned leases rapidly when clients rotate addresses.
- Use DHCP Option 61 (Client Identifier) or Option 12: Configure DHCP servers to identify clients using persistent high-layer identifiers (such as DUIDs or client hostnames) rather than MAC addresses alone.
- Educate Users on Managed Networks: Provide guidelines for corporate-owned BYOD users to disable “Private Wi-Fi Address” selectively for trusted internal enterprise networks where static DHCP mapping is required.