Why MAC Address Vendor Lookup Fails on Modern Phones

You pull the DHCP lease table off your router to work out what all those devices are, paste the MAC addresses into a vendor lookup, and half of them come back with nothing. The addresses are well-formed. The lookup works fine for your printer and your NAS. But the phones, laptops, and tablets — the devices you most wanted to identify — return no vendor at all. Nothing is broken. Since roughly 2019 the major operating systems have shipped randomized Wi-Fi MAC addresses by default, and a randomized address deliberately carries no manufacturer information. It is a privacy feature working exactly as designed.

There are actually four distinct reasons a lookup comes back empty, and the address itself tells you which one you’re in. Here’s how to read it.

What an OUI is, and what it is not

A MAC address is 48 bits, written as 12 hex digits. In a globally unique address, the leading bits identify a block the IEEE Registration Authority sold to an organization, and the rest is that organization’s to assign.

Blocks come in three sizes, and this is where most confusion starts. From the IEEE’s own guidelines document:

Block	Prefix	EUI-48 addresses	Notes
MA-L	24 bits (6 hex digits)	2^24 — 16,777,216	Includes assignment of the OUI; the classic “OUI lookup”
MA-M	28 bits (7 hex digits)	2^20 — 1,048,576	Available since Jan 1, 2014; does not include an OUI
MA-S	36 bits (9 hex digits)	2^12 — 4,096	Available since Jan 1, 2014; includes an OUI-36

So “the OUI” is only the whole story for MA-L holders. The IEEE spells out the search order that follows from this: “If the first 24 bits match an OUI assigned to the IEEE RA, then a search of the first 28 or 36 bits may reveal an MA-M or MA-S assignment.”

That sentence explains a result that looks like a bug: a perfectly ordinary address whose vendor comes back as “IEEE Registration Authority.” That is not an error and not a fallback — it means the first 24 bits are a block the IEEE kept for itself in order to subdivide into MA-M and MA-S assignments. The device is real, the manufacturer is real, and you need the MA-M or MA-S registry to name it. Our MAC vendor lookup ships the MA-L registry only (39,818 prefixes, of which 441 are these IEEE-held blocks), because bundling all three registries blew the page’s payload budget. When you see that name, read it as “small vendor, sub-24-bit block — look it up in the IEEE MA-M/MA-S registries directly.”

Two more things an OUI genuinely cannot tell you:

• It names whoever registered the block, not the brand on the case. Laptops, TVs, and routers routinely ship network chips from an ODM, so the OUI resolves to the silicon vendor while the product carries someone else’s logo. An OUI is evidence about the NIC, not a device identity.
• Some registrants are hidden. The IEEE lets an assignee suppress its name in the public listing; 182 entries in the shipped dataset are literally named Private. There is no lookup that resolves those, because the data does not exist publicly.

The bit that gives randomization away

Now the interesting case. Bit-level, the first octet of a MAC address carries two flags:

Flag	Position	Meaning
I/G	Least significant bit of octet 0 (mask 0x01)	0 = unicast, 1 = multicast/broadcast
U/L	Second least significant bit of octet 0 (mask 0x02)	0 = universally administered (IEEE-assigned), 1 = locally administered

The IEEE guidelines state it directly: the “second least significant bit of Octet 0 (the U/L bit) indicates universal (U/L=0) or local (U/L=1) administration of the address.”

Every randomization scheme sets that bit. Android’s platform documentation describes generating a random address by setting “the locally administered bit to 1, and the unicast bit to 0,” with the remaining 46 bits random. So a randomized address is not a mystery vendor — it is explicitly flagged as not-IEEE-assigned, and looking it up in a vendor registry is a category error.

Reading it by eye is easy, because those two bits live in the second hex digit:

Second hex digit	U/L	I/G	What it is
0 4 8 C	0	0	Globally unique unicast — a real OUI, look it up
1 5 9 D	0	1	Globally unique multicast — e.g. 01:00:5E… IPv4 multicast
2 6 A E	1	0	Locally administered unicast — randomized or manually set
3 7 B F	1	1	Locally administered multicast — e.g. 33:33:… IPv6 multicast

So 3C:22:FB:… is an Apple-registered hardware address. A6:1F:0C:… is a randomized or hand-assigned one, and no registry on earth will name it. Our lookup checks this before it searches, which is why it answers “No vendor — likely a privacy-randomized address” instead of a bare not-found: the U/L bit turns an unhelpful blank into a definite answer.

Who randomizes, and how often

The behavior differs enough between platforms that “it’s random” is too coarse to debug with:

Platform	Default	Rotation behavior
iOS/iPadOS 14+	On	A distinct private address per network
iOS/iPadOS 18+, visionOS 2+	Off / Fixed / Rotating per network	Fixed by default on WPA2-or-stronger networks; Rotating by default on weak or open networks, changing “to a different private address every 2 weeks”
Android 10+	On (persistent)	Address derived per network — by SSID, security type, or FQDN — and stable “until factory reset,” surviving forget-and-rejoin
Android 12+	Non-persistent mode for some networks	Re-randomizes at connection when the DHCP lease has expired and 4+ hours have passed since disconnect, or when the current address is over 24 hours old
Windows 10/11	Off, user-enablable	Global toggle plus a per-network toggle; the option only appears if the Wi-Fi adapter supports it

Two consequences that matter operationally.

Apple’s default is now security-dependent, which is a nice detail to know. On a properly secured network your iPhone presents a stable private address, so per-device DHCP reservations and MAC-based policies keep working; it is the coffee-shop-grade open network where the address starts moving. If a device on your WPA2 network is changing addresses, randomization is probably not why.

Android’s persistence is per-network, not per-device. The same phone shows a different address on each SSID, and each one is stable. So a device that “appears twice” in your inventory across two SSIDs is one device, and the two addresses will never correlate — that is the entire point of the design.

Ethernet is mostly unaffected: randomization is a Wi-Fi privacy feature, aimed at the probe requests a device broadcasts while scanning for networks. A wired device generally still presents its burned-in address.

What this breaks, and what to do instead

MAC-based identity was never strong, and randomization removed the last of its convenience:

• MAC allowlists on a Wi-Fi network now require every user to pin their address per network. This was already weak security — MAC addresses travel in the clear in every frame, and are trivially spoofable — but it is now weak and high-maintenance. Use WPA2/WPA3-Enterprise or a per-device PSK instead.
• DHCP reservations for phones need the private address for that SSID, taken from the device’s own Wi-Fi details screen, not the hardware address printed in system info.
• Device counting and presence analytics based on probe requests are essentially dead by design, which was the explicit goal.
• Captive portals and “remember this device” should key on an account or a cookie, never on an address that is contractually allowed to change.

Debugging an address in ninety seconds

When something on your network is unidentified, work in this order — it maps exactly to the four failure causes:

1. Read the second hex digit. 2, 6, A, or E means locally administered: randomized or manually set. Stop; no vendor exists. 3, 7, B, or F means multicast — you are looking at a group address like 33:33:…, not a device.
2. Otherwise look up the OUI. Paste the address into the MAC vendor lookup; it normalizes any separator style (:, -, ., or none), flags both bits, and accepts a list for bulk work.
3. “IEEE Registration Authority”? The block was subdivided — search the IEEE MA-M and MA-S registries on the first 7 and 9 hex digits.
4. A vendor you don’t recognize? Remember it names the NIC’s registrant, not the product brand. Cross-check against what the device actually is — an IP scan or reverse DNS on the lease usually settles it faster than more MAC archaeology.

Need test addresses that behave predictably? The MAC address generator produces both globally unique and locally administered forms, which is a fast way to confirm your parser handles the U/L bit the way you expect.

If tracking resistance is the thread you’re pulling: randomized MACs remove one identifier while the browser leaks a pile of others — browser fingerprinting explained covers what remains identifiable after the address stops being useful.

The short version

The assumption	The mechanism
”The lookup is broken — no vendor found”	The U/L bit is set: it’s a locally administered address, and by design no vendor is encoded in it
”MAC addresses identify a device”	On Wi-Fi they identify a device-network pair, and only until the platform decides to rotate
”Randomized addresses look random”	They’re marked: second hex digit 2, 6, A, or E for unicast local addresses
”The OUI tells me the brand”	It names whoever registered the block — often the chip ODM; 182 registrants are listed only as Private
“‘IEEE Registration Authority’ is a lookup bug”	It’s a 24-bit block the IEEE subdivides into MA-M (2^20) and MA-S (2^12) assignments — real vendor, different registry
”MAC allowlists secure my Wi-Fi”	Addresses are unencrypted in every frame and freely spoofable; randomization just made the maintenance worse too