How do you read a MAC address vendor lookup result?

A result is one of three outcomes, not a single yes/no

AdminKit’s MAC vendor lookup takes the MAC address you enter and checks its first three bytes — the OUI — live against AdminKit’s own copy of the IEEE OUI registry via its Check API (GET /v1/tools/mac-vendor). The result you get back is always one of three distinct things, and reading it correctly means telling them apart rather than treating “no vendor shown” as a single catch-all failure:

1. A matched vendor name — the OUI prefix is a real, IEEE-registered assignment, and the result shows the company it was issued to.
2. No match on a prefix that looks like it should be real — the first byte’s addressing bits look globally-assigned, but the specific prefix isn’t in the published registry (yet, or at all).
3. A locally-administered or randomized flag — the address was never drawn from an IEEE-assigned block in the first place, so there is nothing to look up.

Each of these points to a different conclusion about the device the address came from, covered below.

A matched vendor: the registered owner of a prefix, not a specific device

Every Ethernet or Wi-Fi interface’s MAC address starts with three bytes (24 bits) assigned by the IEEE Registration Authority to the manufacturer that requested them — the OUI, or in IEEE’s current naming, an MA-L (MAC Address Block Large) assignment. IEEE also issues two smaller block sizes for manufacturers needing fewer addresses: MA-M (28-bit prefix) and MA-S (36-bit prefix, drawn from an OUI-36). AdminKit’s lookup matches against all three sizes, so a hit tells you which exact tier of assignment the prefix came from as well as the registered company name.

What a match does not tell you is which specific physical device the address belongs to. A manufacturer can, and routinely does, reuse the identical OUI across an entire product catalog — routers, switches, cameras, printers, smart plugs — since IEEE assigns the prefix to the company, not to a product line. If a lookup tells you “Vendor X” and your network has three devices showing that same prefix, you’ve learned the maker of all three, not which one is the router versus the camera versus the printer. Combine the vendor name with other context you already have — IP address, hostname, DHCP lease name, or where the device physically sits on your network — to pin down which device is which.

No match on an address that looks genuine

Sometimes a lookup returns no vendor even though the address’s addressing bits look like a normal, globally-assigned prefix (the universal/local bit is zero, so it isn’t locally-administered — see below). This almost always means the specific prefix simply isn’t in IEEE’s published registry: IEEE adds new MA-L, MA-M and MA-S assignments on an ongoing basis, and AdminKit’s copy reflects whatever the registry publishes, so an address using a very recently issued block can briefly show no match even though it’s a perfectly genuine, factory-assigned address. This is a gap in registry coverage, not evidence that the address itself is fake or suspicious.

A locally-administered or randomized address has no vendor — by design

The second-least-significant bit of a MAC address’s first byte is the universal/local (U/L) bit, defined in RFC 9542 (§2.1.1, formerly RFC 7042): a zero means the address is a global one under the control of whoever owns the IEEE-assigned prefix, while a one means IEEE itself classifies it as a local identifier, generated outside any vendor assignment. IEEE 802c’s Structured Local Address Plan further subdivides that local address space into ranges for different uses. A locally-administered address was never drawn from a manufacturer’s registered block in the first place, so when AdminKit’s lookup flags one, reporting no vendor is the correct answer, not a failed lookup — there is genuinely nothing to find.

This is also exactly what happens with randomized MAC addresses, which set the same U/L bit to mark themselves as local: Android 10 and later randomizes the Wi-Fi MAC address used per network by default, and iOS/iPadOS 14 and later does the same with its Private Wi-Fi Address feature (as of iOS/iPadOS 18, users can additionally choose a fixed-per-network or rotating-every-two-weeks private address), with Windows offering an equivalent opt-in “random hardware addresses” setting. These defaults exist specifically to stop the kind of passive tracking an OUI lookup enables — a modern phone presenting a different, vendor-less address to every network it joins is working as intended, not malfunctioning. Fixed infrastructure like routers, switches, printers and most IP cameras still ships with its real factory-assigned MAC and has no reason to randomize it, which is why OUI lookup remains reliable for identifying that kind of device on your network even as it becomes unreliable for personal phones and laptops. See randomized and locally-administered MAC addresses explained for how that per-network randomization actually works.

What this lookup doesn’t, and can’t, confirm

A MAC address never leaves the local network segment it was sent on — routers replace the source MAC with their own at every hop — so a MAC address is only ever meaningful for identifying a device on the same local network you’re checking it from, never for a device several hops away or one you only saw mentioned in a remote server’s logs. It’s also easy to change in software (MAC spoofing) on most operating systems, so a vendor match is informative, not a cryptographic guarantee of origin. Use a MAC vendor lookup to get an honest, well-sourced hint about the maker of an unfamiliar device sitting on your own LAN — a router, a camera, an IoT gadget with no helpful hostname — not as proof of exactly which product, or whose, it is.

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.