macadmin.fraserhess.com

macOS Sequoia 15 introduces a new privacy feature: randomized MAC addresses for Wi-Fi networks¹. Each Wi-Fi SSID gets a different random MAC address, instead of the network interface’s physical MAC address, in order to prevent tracking across public networks. This feature has been available on iOS since version 14.

The macOS 15 TCP/IP stack uses the randomized MAC address in at least three ways:

1. As the layer 2 address
2. As the DHCP client identifier
3. As the source address in 802.11 management frames

or to put this in meme form…

---

macOS: <randomizes Wi-Fi MAC address>
Network equipment:

---

Configuration and Limitations

If an organization would prefer to continue using the physical MAC address, there is a supported configuration to turn off MAC address randomization. Like iOS 14 and later, macOS 15 supports the DisableAssociationMACRandomization key in the Wi-Fi payload sent by MDMs. (Jamf added support for this in Jamf Pro 11.9, where it is labeled Disable MAC Address Randomization (macOS 15 or later).) There are limitations to deploying this key:

• This key will be safely ignored if deployed on macOS 14 or earlier. However, it will not be re-evaluated when a computer is upgraded to macOS 15.
• Therefore, a configuration profile using this key must be deployed after upgrading to macOS 15.
• This key can only be applied to SSIDs configured by MDM. In other words, there is no global off switch for MAC address randomization.

(As we are only discussing SSIDs configured by MDM, the rest of this post assumes the SSID in question is an organizational network of some kind.)

At this point, if one is thinking that the solution is to have two configuration profiles, with and without DisableAssociationMACRandomization, this has limitations too.

A Mac cannot have two configuration profiles for the same Wi-Fi network and successfully remove one without affecting the other. Therefore, the first configuration profile must be removed before installing the second. This may drop all connectivity when switching between the two profiles.

In an excellent talk at JNUC 2023, Brad Chapman discussed using an interim configuration profile and SSID to overcome this. But with MAC address randomization in play, there’s a fly in the ointment. And it’s illustrated by our meme. If MAC address randomization is turned off while connected to the specified SSID, the Wi-Fi connection’s layer 2 (MAC) and layer 3 (IP) addresses will be changed. Everything in the Mac’s network connection table is now meaningless. The same goes for network firewall tables, too. We’re not talking about a momentary blip; we’re talking about losing every existing connection. In testing on a WPA2 Enterprise network with EAP-TLS, switching MAC randomization on or off saw a drop of around eleven pings and killed any downloads in progress.

Possible effects on DHCP

As mentioned above, MAC address randomization changes the identifier sent to a DHCP server. A different identifier means the DHCP server will offer a different IP address. (Again, the meme makes the point.) In small numbers, this effect will go unnoticed. But upgrading hundreds or thousands of devices on the same network en masse could cause DHCP pools to run out of available addresses. (More below on when that may happen.)

This can be combated by configuring short DHCP leases before the mass upgrade begins. Leases of 8 hours or more will be problematic – they won’t expire during the work/school day. Leases of 1 hour or less will help.

While these effects on DHCP pools are temporary, they occur even if one plans to embrace randomized MAC addresses on their Wi-Fi network.

DHCP reservations, where an administrator assigns an IP address to a MAC address in the DHCP server, are obviously affected by MAC address randomization.

Is there any good news?

If MAC address filtering is in place on a Wi-Fi network, there is good news. After an upgrade to macOS 15, the Mac will fall back to using the physical MAC address if it fails to connect to a Wi-Fi network configured in macOS 14.

Also, testing with late betas of macOS 15 shows that in some circumstances WPA2 Enterprise Wi-Fi networks configured by MDM are not defaulting to randomized MAC addresses when upgrading from macOS 14—they continue to use the physical MAC address. However, testing with WPA2 Pre-Shared Key Wi-Fi networks, even those configured by MDM, are defaulting to randomized MAC addresses when upgrading from macOS 14.

Both of these helpful behaviors only apply to upgrades. If use of the physical MAC address is desired or required, one will still need to set DisableAssociationMACRandomization in the Wi-Fi configuration profile before provisioning computers with macOS 15.

Our approach

Before I describe our approach to randomized MAC addresses, I want to restate the cumulative limitations:

• Configuration profiles that include the DisableAssociationMACRandomization key must wait to be installed after the upgrade to/install of macOS 15 to be effective
• Problems occur when two configuration profiles configure the same Wi-Fi SSID
• Turning off MAC address randomization for an SSID changes both the MAC and IP (layers 2 and 3) addresses disrupting connectivity if connected to that SSID
• Many computers changing their MAC address while on a Wi-Fi network may exhaust DHCP pools

The relevant details of our deployment are as follows:

• We have one configuration profile that provides a computer certificate issued by our internal CA, along with the configuration to use it for EAP-TLS/802.1x on Wi-Fi and on Ethernet
• Certificates are requested via Jamf AD CS Connector
• While we have a corporate building with a corporate Wi-Fi network, most of the employees work remotely most of the time

Our security and network teams have requested that we turn off MAC address randomization on the corporate SSID, primarily so that what the network equipment sees matches what we have in inventory.

The first part of our plan is:

1. Pick a date when macOS 15 upgrades will be allowed, and macOS 15 will be the standard when provisioning a Mac. (This may occur when purchasing new Mac models this fall.)
2. On that date, modify the single configuration profile to turn off MAC address randomization for the corporate SSID, but do not deploy the change to any computers.

If we did nothing else, our computers would eventually be configured to use the physical MAC address as configuration profiles containing certificates issued via Jamf AD CS Connector are re-sent ten days before the certificate expires. (There is a similar re-issuing mechanism for SCEP-issued certificates.)

Because we do not yet know if macOS 15 will randomize MAC addresses on our network at a later point in time, we will take advantage of our circumstances, especially remote work. After a computer upgrades to macOS 15, it will run a Jamf policy that will uninstall and reinstall the Wi-Fi configuration profile. We will only run this policy on remote networks, not on office networks.

Smart group

A smart group is used to scope the policy. It has the following criteria:

	Criteria	Operator	Value
	Operating System Version	greater than or equal	15
AND	Last Enrollment	before	<upgrade start date>

Policy

The policy details are as follow:

Name: Reinstall Certificates and Wi-Fi profile

Trigger: Recurring Check-in

Execution Frequency: Once per computer

Scope:

Targets	Limitation	Exclusions
Above smart group		<Office network ranges>

Payload

The payload of this policy is a script that reinstalls a configuration profile. The script requires Jamf Pro API credentials, and IDs of the configuration profile and a static group. When run, it calls the Jamf API to put the computer in that static group. The static group must be an exclusion in the scope of the Wi-Fi configuration profile. (I encourage you to check out the script and see all the safety checks it performs.)

Once the computer is added to the static group, the profile will be removed. Local and remote checks are performed to ensure the profile is removed. Then, the computer is removed from the static group, and the profile is reinstalled.

Can Ethernet help?

Yes*

* There is no MAC address randomization for Ethernet interfaces. Therefore it can be a safe medium for switching out Wi-Fi configuration. The script we’re using above can be run in an Ethernet-only policy from Jamf Pro. Jamf Pro policies support requiring Ethernet as a client-side restriction. I found one caveat: if both Wi-Fi and Ethernet are connected and Wi-Fi is ordered above Ethernet in the service order, the policy will run regardless.

If your Ethernet ports do not have authentication, this will be safe. If you have 802.1x or another access control for Ethernet, and your configuration profile also configures Ethernet, there may be dragons here. I tested removing our configuration profile while connected to our Cisco switches and encountered no disconnects².

I expect we will use an Ethernet-variant of the above policy when we perform white glove macOS 15 upgrades for our executives.

Be careful. Test everything. Your mileage may vary.

Conclusion

There is no “one size fits all” approach to MAC address randomization. Organizational networks and constraints vary widely. But the bottom line is that if an organization wants to continue using physical MAC addresses on their corporate Wi-Fi networks they must send a configuration profile that disables MAC address randomization. The timing and connectivity for that deployment depends on those networks and constraints. Hopefully this post will helps and inspires you with your approach.

UPDATE 9/30/24: Joel Bruner has found where macOS 15 sets the user preference for randomized MAC addresses. This can be set before a Mac is upgraded to macOS 15. I will probably use a combination of his approach and my own. Ultimately, I come to the same conclusion as before: if one wants to use physical MAC address they must deploy a configuration profile that disables MAC address randomization. Joel’s approach helps smooth the path to getting there.

---

1. In the UI this is called Private Wi-Fi Address and there are two forms: Fixed and Rotating. The fixed form randomizes the MAC address once per SSID. The rotating form is the default for low/no security Wi-Fi networks and randomizes the MAC address every two weeks or so. Because this article is focused around disabling this feature, it will simply refer to both as “randomization.” ↩︎
2. I’m pretty sure that after authentication our switch caches the MAC address of the Ethernet adapter until the port is disconnected or a timeout occurs ↩︎