MAC Randomization is not a new term in the network industry. It has existed for several years and involved randomizing client MAC addresses when sending Probe Requests to prevent location tracking of devices that are not associated to the network. During association, a device would have used its “real” hardware MAC address. This however is changing with the upcoming release of iOS 14 / WatchOS 7, Android 10+, and even a few recent versions of Windows 10. The new shift in the mobile device industry is to randomize MAC addresses not only during the network discovery phase, but also during association phase. Let’s find out what these changes entail for enterprises and networking vendors.
Why MAC Randomization?
The intent from device manufacturers like Google and Apple is to “reduce a privacy risk” associated with an ability to track a device from a network usage or location perspective using a device unique MAC address. This problem can certainly be looked at from different angles (MAC Address from Google or Apple’s perspective provides different tracking options versus a typical enterprise or even a home user).
The new MAC randomization algorithm applies to network connectivity and is now used for all communications.
How to Identify a Randomized MAC Address?
Fortunately it is easy to identify randomized MAC addresses. There is a bit which gets set in the OUI portion of a MAC address to signify a randomized / locally administered address. The quick synopsis is look at the second character in a MAC address, if it is a 2, 6, A, or E it is a randomized address. In the iOS screenshot above, we know Wi-Fi Address 92:B1:B8:42:D1:85 is a randomized address, because the second character is a 2.
How will the new MAC Randomization logic work?
There are a number of resources that will provide details on the MAC Randomization algorithm specifics, which you can find in the references. This blog will focus on practical elements of the randomization logic.
The following table provides a summary of how different mobile devices will implement MAC randomization logic by default. By default is a crucial piece here, as unless these devices will be managed by an enterprise, these default settings will likely persist, as no one would likely to change them.
| OS | MAC Randomization Supported | Enabled by Default | Enabled per SSID / Hotspot2.0 profile | Randomise Daily |
|---|---|---|---|---|
| Windows 10 | Yes | No | Yes | Optional* |
| iOS 14 / WatchOS 7 | Yes | Yes | Yes | No |
| Android 10+ | Yes | Yes | Yes | Optional (Android 11 only) |
| macOS | No (as of 9/20) | No | No | No |
Note: for any Android device that was upgraded to Android 10, existing saved Networks (SSIDs) will not have Private MAC enabled by default
Which network services might be affected by this change?
Since the beginning of the network industry, every network infrastructure device operates by looking at the MAC address as the single L2 device identifier. Think broadly starting from MAC tables on the switch, ARP tables on the router, DHCP Binding list on the DHCP server and so on. With the new changes which elements would be affected?
- MAC Association Lists – This is something customers should have planned to stop using a long time ago, enabling MAC randomization on a per SSID level today will not directly affect MAC ACLs functionality, unless a user would enable daily MAC rotation in the device settings. Still, this is an item to consider in the future should random MAC rotation become a norm.
- Banned Client List – Many InfoSec systems today rely on client banning or quarantine functions that are typically tied to a MAC address of a client. To overcome a ban, a user could just forget and rejoin a network to get a new MAC address generated, thus overcoming any restrictions. Potential security issue.
- Guest Portals with MAC Registration – Most Guest Captive Portals leverage MAC based registration to prevent frequent browser re-login and smoothen user experience by only requiring “one time sign up”.If a user would enable daily MAC randomization (currently available on Windows and Android 11, and is turned off by default), a guest user would see a captive portal sign up page on a daily basis. A potential long term solution to this issue would be to move to Hotspot 2.0, which not only provides a secure end-to-end communication for the user and automated network discovery, but also a more granular user-based identification. This however goes against the original notion of “more privacy with random MAC enabled”.
- DHCP Servers – It is probably time to start using shorter DHCP lease timers, just to be safe whenever somebody decides to turn on periodic MAC rotation. DHCP Lease time should not be higher than 24 hrs, rather aiming at the lower timers.
- Wi-Fi Analytics and Troubleshooting – With the current default behavior we should not be too worried about randomized MAC addresses for analytics, unless a client is switching SSIDs frequently, in which case it will be more difficult to identify SSID hopping. However, should a user enable Daily MAC Address rotation, troubleshooting a client historically or looking at network analytics for a specific client would be much more challenging. It would require user-based device identity tracking and correlation techniques to combine multiple random MAC addresses into a single device connection experience history. Typically a MAC is used to identify a user when any connectivity problems are reported, so instead of a typical “can you tell me your MAC address, please?” you may hear “do you happen to know your MAC address at the time when the issue occured?”
- Wi-Fi-based Location Tracking and Analytics – With the previous randomized MAC for Probe frames, it was already difficult to use Wi-Fi based Locationing for passive location analytics. Now with new randomized MAC addresses implementations it might be even harder to track a device just relying on Wi-Fi alone. This is yet another reason for BLE based user engagement via a mobile app.
How can enterprises react to this change? Should they?
Overall, for any enterprise managed mobile device park (iOS, Android) it is possible to disable Private MAC Address functionality for a given SSID, for example by using an existing MDM solution. Also, in Android 10/11 for any existing SSID or Network profile the “real” hardware MAC addresses will be used as before. Only new Network profiles will have randomized MAC turned on by default. In iOS 14, randomization is turned on for existing SSIDs upon upgrade.
Ok, now it sounds like it will not really have any dramatic effect, so why the blog post?
The fact that this time we got away with randomized MACs on a per-SSID basis without daily or even per-session randomization, does not mean that it will not happen in the future. As our prior testing showed earlier beta versions of both Android 11 and iOS 14 did randomize MAC address in a much more aggressive manner (up to a point of randomizing it on a per-session basis). These early betas showed a potential glimpse into the future, which is to randomize the MAC as often as currently possible. Most likely we are not too far away where device manufacturers would choose to randomize MAC addresses on a daily basis by default. Which would mean that all the items outlined above will matter even more.
Is there anything good out of this change?
Finding your current MAC address has never been easier. Both iOS and Android now provide information on the current random MAC used for a given SSID:
What can vendors do about it?
In general, vendors should provide better correlation techniques between usernames, client hostnames (for example supplied in DHCP option 12) and actual client MAC addresses. In general user-based identification will provide better network visibility. It is in a sense ironic that by providing a seemingly better privacy by enabling randomized MAC addresses, this change will slowly force everyone to move to a user-based identification, which may cause an opposite effect on privacy, especially with Guest networks.