What is an OUI, and why it is not a permanent vendor ID

Short answer: an OUI (Organizationally Unique Identifier) is the first three bytes of a MAC address, and the IEEE assigns each block to exactly one manufacturer. Run those three bytes through a MAC vendor lookup and you get the maker — not the model, not the owner, just who built the hardware. Two things make that answer narrower than it first looks: sub-block registrations mean three bytes are sometimes not enough to identify the holder, and registry entries change hands.

Where the OUI sits in a MAC address

A MAC address is six bytes, written as twelve hex digits:

A4:83:E7:2C:1B:90

• A4:83:E7 is the OUI — assigned to a manufacturer, fixed across every device that maker builds.
• 2C:1B:90 is the network interface controller (NIC) portion, a serial-style value the manufacturer hands out from its own block.

So the address has one part chosen by the IEEE’s registry and one part chosen by the vendor. Neither part is chosen by whoever installed the device on your network.

The IEEE registry, and why it works

The IEEE Registration Authority runs the master list. A hardware maker applies for a block, pays for it, and receives a 24-bit OUI it can stamp into firmware. That block is public, so anyone can query it. This is why a vendor directory can list “44:38:39 → Cumulus Networks” or “3C:5A:B4 → Google” and be right every time the address is genuine. ssid.ai re-fetches the registry daily and holds 40,345 records from it.

It is really five registries

The classic 24-bit OUI is only one of them, and 24-bit space ran short years ago. A lookup has to resolve against all of these, longest prefix first:

The practical consequence is that two devices can share the same first three bytes and belong to different companies, because the prefix was subdivided. A tool that checks only MA-L returns nothing for those addresses. An empty result and an unregistered address look the same from outside, and they are different things.

OUI blocks are not permanent

This is the part most lookup tools quietly get wrong, because the IEEE publishes current state only. It overwrites oui.csv in place and keeps no change log, so a rename, an acquisition or a withdrawal leaves no trace in the file anyone downloads today.

Across dated captures of the registry from 2017 to 2026, ssid.ai has observed 2,353 changes to blocks that already existed:

Every row carries the timestamp it was first observed, and 2,318 of the 2,353 also carry the Internet Archive URL of the capture it was read from, so the claim is checkable rather than asserted. Counted by prefix rather than by event, 1,867 of the 40,345 prefixes in the directory (4.6%) name a different organisation today than they did when first captured. The record is published as an open dataset under CC BY 4.0, with the analysis in the OUI registry churn report.

What that means when you are reading a device inventory: a lookup tells you who holds the block today. If the hardware shipped in 2019 and the block was renamed in 2022, the vendor string you get back is the current registrant, not the company whose logo is on the case. For 2,067 blocks that gap is real, and nobody who started keeping copies later can reconstruct it.

From OUI to an actual device

An OUI alone tells you the manufacturer, not the model. Getting further takes context:

• The vendor itself narrows things. Espressif or Realtek usually means an IoT board. Sonos or Roku means a speaker or streaming box.
• Hostname and connection pattern add the rest. A device that appears every night at 11pm and disappears by 7am reads differently from one that is always online.
• Cross-referencing against a router’s connected-device list helps when you are staring at several unfamiliar entries at once, as covered in identifying an unknown device on your network.

It will not tell you the badge on the box either. A device maker that buys chips from a supplier often ships under the supplier’s registered OUI rather than its own, so the lookup returns the chipset vendor. That answer is correct and still not the one you wanted.

The randomized-MAC caveat

Modern phones and laptops often don’t broadcast their real, vendor-assigned MAC at all. iOS, Android, and Windows now generate a random address per network by default, specifically so a vendor lookup can’t be used to track the device across locations. You can tell one apart by checking a single bit: if the second hex digit of the first byte is 2, 6, A, or E, the locally-administered bit is set, and there’s no manufacturer to find. The full mechanics are in randomized MAC addresses, explained; the short version of why this exists at all is in why devices hide their MAC.

This is the single most common reason an OUI lookup comes back empty. The address isn’t wrong or unregistered — it was never a real OUI to begin with.

The test is arithmetic, not a database query:

const isRandomized = (mac) => (parseInt(mac.slice(0, 2), 16) & 0x02) === 0x02;

A service charging separately for randomized-address detection is charging for one bitwise AND. The thing worth comparing is the failure case: a lookup that answers HTTP 404 for a private address returns the same thing it returns for an unregistered prefix, so the caller cannot tell a phone apart from a registry gap.

Using OUI lookups at scale

Checking one MAC by hand is a quick job for the vendor lookup tool. Checking hundreds is a different problem: a device inventory, a captive portal, a fleet of IoT sensors. The lookup API takes a MAC and returns the vendor, whether the address is randomized, and a confidence value, so you can batch the work instead of pasting addresses one at a time. The same data is available to agents through an MCP server.

Three things worth checking before trusting any OUI service with an inventory:

1. Does it resolve sub-blocks? Give it an address inside an MA-S range. If it returns nothing, it is reading the 24-bit registry only.
2. Does it separate a private address from a gap? A 404 for both means you cannot tell which happened.
3. Does it say when it last verified? A registry re-fetched daily and one downloaded once in 2021 look identical in the response body.

The same question, asked of router credentials

Sourcing is the other half of identifying hardware on a network, and it is testable in the same way. The ssid.ai router directory holds 525 models, each row transcribed from the manufacturer’s own documentation across 209 distinct official domains, with 217 of those pages also captured in the Internet Archive. 406 rows are marked high confidence and 119 medium, with the reason stated per row.

The figure that comes out of it: 69% of the 525 tracked models no longer ship a universal default password. 139 make you create one during setup, 169 print a unique password on the device itself, and 53 have no web login at all. 164 models do still ship a shared default, and each is listed with its source. A list that prints admin / admin for the other 361 is guessing, and it sends someone to factory-reset a working router for nothing.

An OUI answers one question: which organization currently holds this block in the IEEE registry. It does not name the model, the owner, or the company whose logo is on the case, and if the locally-administered bit is set it is not answering about a manufacturer at all.