Why a MAC Address Lookup Returns Nothing or the Wrong Vendor
You enter a MAC address and get "not found", or the vendor that comes back bears no relation to the device in your hand. Both are common, and the cause is usually not a problem with the database. Here are the common causes.
One: it is a locally administered address, outside the allocation space
This is a common cause when modern devices use privacy features.
Look at the second hex character of the first byte. If it is 2, 6, A or E, the locally administered bit is set. Locally administered addresses are chosen by a device or software and cannot reliably be identified using IEEE vendor allocations. The rule is in reading the first byte of a MAC address.
Situations that produce them include phones with WiFi privacy enabled, virtual adapters in VMs and containers, bridge and VPN tunnel interfaces, and any device whose address was changed by hand.
A failed lookup can be a troubleshooting clue, but does not establish that a device is mobile or rule out a security issue. Compare address randomisation settings and actual network records.
Two: the prefix has not been allocated
The 24-bit OUI space is large, and whatever the IEEE has not yet assigned will not resolve. Some ranges are explicitly reserved as well. Addresses starting 01:80:C2 belong to IEEE bridging protocols and represent no vendor, while 01:00:5E and 33:33 are the result of multicast address mapping and likewise have no manufacturer.
Three: the data lags behind
After a vendor receives a new OUI it has to be published by the IEEE, picked up by the Wireshark project, and then synchronised here. This site syncs every 30 days, so a prefix that entered production a few weeks ago genuinely may not resolve yet. Check the IEEE listing directly while waiting for upstream synchronisation.
Four: you found the contract manufacturer or module supplier
This explains the puzzle of a name that does not match the brand on the box.
IEEE records identify the registrant, not the brand of the finished product. In reality a great many devices use network modules supplied by third parties, and the brand owner simply uses the MAC address that came with the module. So looking up a router may return a Taiwanese module maker, and a branded camera may return a chipset vendor. That is not necessarily a data error; it can reflect how the supply chain works.
For the same reason, mergers and divestitures leave historical prefixes registered to old company names. Getting back a company that no longer exists is normal.
Five: you did not enter enough digits
Some prefixes are allocated at 28 or 36 bits, the MA-M and MA-S tiers. That means one 24-bit prefix can cover several different companies, and the first three bytes alone cannot distinguish them.
This site performs longest-prefix matching at the 24-, 28- and 36-bit boundaries, so entering all twelve digits is more accurate than entering six. The tiers are explained in the IEEE OUI registry.
Six: a formatting problem
Colon-separated, hyphen-separated and unseparated forms are all accepted. A complete address must contain twelve hexadecimal digits. A registered prefix may contain six, seven or nine digits. Colon, hyphen and dotted separators are supported, but stray characters or other lengths are rejected rather than silently matched. Check whether copying from a log brought something else along with it.
Confirming further
If you need to cross-check, the IEEE's own allocation records are the authoritative source. The data here comes from the manuf file maintained by Wireshark, which normalises names on top of the raw IEEE data. It occasionally differs from the official records in wording, though the allocation itself agrees.
To see which prefixes a particular company has accumulated, search by name in the vendor directory.
A worked check (illustrative addresses)
These examples are for understanding the lookup; they are not a report from a customer's network.
02:00:00:00:00:01: the second hexadecimal digit is2, so the local bit is set. Do not infer a hardware manufacturer from this address.40:6C:8F:18:2C:03: a complete unicast address. This site's current database matches the Apple registration; that does not identify a model or owner.40:6C:8F:ZZ:00:00: invalid input. Correct the copied text before querying; a familiar first six digits must not hide malformed trailing input.
For an unexpected result, record the matched prefix, check its allocation size against the registry, and compare the interface with your own inventory. Do not publish a complete device address when requesting help unless necessary.