The mystery MACs on your UniFi network
New unknown clients appearing on your UniFi controller each day, doing nothing, then disappearing — and you never invited them. If there are Apple devices in the house, there is a strong candidate explanation before you go looking any further: Apple's Private Wi-Fi Address feature, doing exactly what Apple designed it to do.
The symptom: new clients appearing and vanishing.
On a UniFi controller, every device that joins your Wi-Fi gets an entry on the Client Devicespage. The entry is keyed by the device's MAC address — the 48-bit hardware identifier the device used to associate with the network. When a client's MAC changes, the controller has no way to know it's the same device; it logs a brand new client.
The pattern looks like this: a new client name — sometimes a generic fingerprint label like “Apple iPhone”, sometimes just a raw MAC address — appears on the network, sits idle for a few minutes or hours, then disappears. Sometimes it shows up again the next day with a different last-four. Nothing visible was added to the house. Nothing left the house. Nothing on the network was reconfigured.
If that's what you're seeing, the next three sections cover the why and what to do about it.
Apple's Private Wi-Fi Address feature.
Beginning with iOS 14, iPadOS 14, and watchOS 7 — all released in 2020 — Apple added a feature called Private Wi-Fi Address.¹ The feature generates a software-defined MAC address that the device uses on each Wi-Fi network it joins, instead of the fixed hardware MAC burned in at manufacturing.
The setting is per-network and per-device. You can see it on an iPhone or iPad at Settings → Wi-Fi → ⓘ → Private Wi-Fi Address. The toggle has been expanded across Apple's OS releases — newer versions offer additional behavior, including the option to rotate the private address periodically rather than holding it stable for the network.¹
The result: a single iPhone can quietly produce multiple distinct MAC addresses over the course of a week, depending on its OS version and per-network setting. Each new address looks, to the controller, like a brand new client joining and leaving the network.
Why Apple does this
Apple's stated rationale is privacy.¹ Wi-Fi clients send their MAC address in clear at every probe, association, and roam. Without randomization, that address is a stable identifier that can be read by any nearby Wi-Fi infrastructure — venues, advertisers, anyone running a scanner — and used to track devices as they move across networks. Randomizing the MAC per network breaks that tracking. Other vendors (Google, Microsoft) have rolled out similar features for the same reason.
The locally-administered bit.
Every MAC address is six bytes — usually written as six hexadecimal pairs separated by colons, like 50:99:5a:aa:85:9b. The first byte (the leftmost pair) carries two flag bits that say what kind of address this is.² The bit we care about is the U/L bit — Universal vs. Locally-administered.
0x50 = 50
0x56 = 56
The U/L bitis the second-least-significant bit of the first octet. When it's 0the address is universally administered — assigned from a real vendor's registered OUI. When it's 1 the address is locally administered — generated by software.
In practice, an easier rule than reading bits: look at the second hex digit of the first byte. If it's one of 2, 3, 6, 7, A, B, E, F, the U/L bit is set — software-generated. Anything else, the U/L bit is zero — real vendor MAC.
On your UniFi Client Devicespage, sort by MAC and scan the first byte. If the second hex digit lands in that set above, the device almost certainly isn't reporting its real hardware MAC.
The MAC is fake. The fingerprint isn't.
Even when a client's MAC is software-generated, the controller can often still identify the manufacturer and model. UniFi (and most modern network controllers) doesn't rely on the MAC's OUI alone. It correlates several other signals the client emits on every join:
- DHCP fingerprinting. When a device requests a DHCP lease, it includes a parameter request list (DHCP option 55) and often a vendor class identifier (option 60). These option fingerprints differ per operating system and vendor.³
- mDNS / Bonjour broadcasts. Apple devices in particular advertise hostnames and service strings over multicast DNS (
_airplay._tcp,_companion-link._tcp, hostnames likeTahirs-iPhone), which UniFi reads off the wire. - User-agent strings on captive-portal or unencrypted HTTP traffic, where present.
- Hostname returned by the client during DHCP (option 12).
The result is that a randomized MAC like 56:05:9b:6c:00:76can still show up on the controller with a model label such as “Apple iPhone” — because the controller never needed the OUI to identify it in the first place. That is what lets a review separate “these are household Apple devices” from “these are clients on the network we cannot account for” — without trusting the MAC alone.
Usually nothing. Sometimes a per-network toggle.
Apple's default is to leave Private Wi-Fi Address on, and we generally agree with the default. The privacy benefit is real, and the cost — a noisier Client Devices view — is cosmetic.
When you might turn it off, per network
There are a few legitimate cases for switching it off on your own trusted networks (it stays on everywhere else):
- Static DHCP reservations that you want pinned to a specific device, like an Apple TV that needs a stable IP for AV routing.
- MAC-based firewall or VLAN policies — uncommon in homes, but used in some commercial Wi-Fi deployments.
- Parental-control or access-time enforcementthat's keyed to a child's device by MAC.
To turn it off on an iPhone or iPad, on the network in question: Settings → Wi-Fi → ⓘ next to the network name → Private Wi-Fi Address → Off.¹ On a Mac that supports it, the equivalent setting is in System Settings → Wi-Fi → Details… → Private Wi-Fi Address. The device will rejoin the network with its real MAC the next time it associates.
The workflow on a residential review
When a homeowner reports “mystery devices” on the controller, the workflow is straightforward: pull the full tracked-client list, filter for MACs with the U/L bit set, and cross-reference each one against the device-fingerprint label the controller already has alongside the MAC. That tells you, device by device, whether each locally-administered MAC corresponds to an Apple device the household actually owns, or to a client on the network you cannot account for. The result, whichever way it lands, gets written down so the homeowner has the answer in writing instead of in conversation.
If a locally-administered MAC cannot be matched to a household device, that is a different conversation — and one worth having promptly.
// REFERENCES
- [1]Apple Support, Use private Wi-Fi addresses on iPhone, iPad, Apple Watch, and Vision Pro. Documents the Private Wi-Fi Address feature, supported OS versions, rotation behavior, and per-network toggle path. support.apple.com/en-us/102509
- [2]IEEE 802 standards family defines the format of 48-bit MAC addresses, including the Individual/Group (I/G) and Universal/Locally-administered (U/L) flag bits in the first octet. The U/L bit is bit 1 (the second-least-significant bit) of that octet. standards.ieee.org — IEEE Registration Authority
- [3]IETF RFC 2132, DHCP Options and BOOTP Vendor Extensions, defines option 55 (Parameter Request List), option 60 (Vendor Class Identifier), and option 12 (Host Name). These are the option fields network controllers read to fingerprint a client independently of its MAC address. datatracker.ietf.org/doc/html/rfc2132