What are randomized and locally-administered MAC addresses?

One bit decides whether a MAC address has a vendor at all

Every MAC address is 48 bits, and the very first byte carries two special-purpose bits rather than part of the OUI itself. The one that matters for identifying a device’s manufacturer is the universal/local bit (the X bit), defined in RFC 9542 §2.1.1 (which obsoletes the older RFC 7042 that defined the same bit): zero means the address is global, drawn from a block IEEE assigned to a specific manufacturer; one means IEEE itself classifies the address as local, generated outside any vendor assignment entirely. In practice, you can read this straight off the hex: if the second hex digit of a MAC address is 2, 3, 6, 7, A, B, E or F, the local bit is set and the address has no registered vendor by definition — not because a lookup failed to find one, but because there was never a manufacturer assignment to find in the first place. This is the same bit AdminKit’s MAC vendor lookup checks to decide whether to attempt a vendor match at all, as covered in how to read a MAC vendor lookup result.

IEEE 802c gives the local address space its own structure

Before IEEE 802c-2017, the entire “local” half of the address space (every address with the universal/local bit set) was just one undifferentiated pool, free for anyone to generate addresses into with no coordination against collisions. 802c’s Structured Local Address Plan (SLAP) adds that coordination by using two further bits (Y and Z, per RFC 9542 §2.1.1) to split the local space into four quadrants:

Y bit	Z bit	Quadrant	Intended use
0	0	Administratively Assigned	Manual, ad-hoc local assignment (e.g. a lab’s own test addresses)
0	1	Extended Local	A larger local space for holders of an IEEE-assigned Company ID (CID)
1	0	Reserved	Not currently assigned a use
1	1	Standard Assigned	Addresses an IEEE 802 protocol itself specifies

SLAP is optional, not mandatory: an implementation that sets the local bit but has no reason to coordinate with anyone else’s local address space is free to randomize the remaining bits without following the quadrant structure at all, and most consumer MAC randomization does exactly that.

Why phones randomize, and what it actually changes

Android’s own documentation describes its approach plainly: the locally-administered bit is set to 1, the unicast (group) bit is set to 0, and the other 46 bits are randomized, with no mention of following a specific SLAP quadrant. Android 10 and later does this by default, generating a MAC address tied to the network’s SSID and security type that stays stable for that specific network (so it won’t change every time you reconnect) but differs from the address used on every other network. Apple’s Private Wi-Fi Address feature (iOS/iPadOS 14+, and extended to more OS versions since) works the same way by default: a different private address per Wi-Fi network, with iOS/iPadOS 18 and later letting a user instead choose a fixed-per-network address that never rotates, or one that rotates every two weeks regardless of network. Windows offers an equivalent, opt-in “random hardware addresses” setting for the same purpose. None of this is MAC spoofing in the deceptive sense — it’s a documented, vendor-shipped default aimed specifically at defeating the kind of cross-network tracking a stable, vendor-identifiable MAC address would otherwise enable.

The practical effect for anyone reading a MAC vendor lookup result or a router’s device list is the same regardless of which OS produced the address: a randomized address has no manufacturer to find, it may look different on every network the device joins, and on newer OS versions it can even rotate periodically while staying on the same network. None of that indicates a problem with the device, the network, or the lookup — it’s the privacy feature working exactly as documented.

What this means for identifying devices on a network

Fixed infrastructure — routers, access points, switches, printers, most IP cameras and other IoT gear — generally has no reason to randomize and keeps shipping with its real, factory-assigned MAC address, so OUI-based vendor identification continues to work reliably for exactly the device category it’s most useful for: unfamiliar hardware with no hostname to go by. Consumer Wi-Fi clients are the category where it has quietly stopped working over the last several years. If you’re trying to build something that depends on recognizing a specific phone or laptop reliably — a MAC-based allow-list, or an inventory built from OUI matches — don’t rely on randomized clients cooperating; options that don’t depend on a stable hardware address, such as 802.1X/WPA2-Enterprise per-user authentication, hold up where MAC-based identification increasingly does not.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.