ssid.aiAPI

ssid.ai research · 2026-09-09

A MAC prefix is not a permanent vendor ID: measuring OUI registry churn, 2016 to 2026

1,848 of the 40,115 MAC address prefixes in the IEEE OUI registry, 4.6%, resolve to a different organisation today than they did in 2016. The prefix did not move. What it resolves to did.

This is the 2026-09-09 edition, n = 86 observations of the registry. The figures are recomputed from the observation record daily, so this page and the published CSV always agree.

The record is append-only: a figure here only ever grows, and an earlier edition is never contradicted, only extended. Every row is downloadable with the archive URL it came from. github.com/Drumworks/oui-change-history · CSV

4.6%
of the registry resolves to a different organisation than in 2016 (1,848 of 40,115)
2,044
rename events observed across 1,843 prefixes
5
withdrawals in 10 years, which is why one is worth investigating

Why this number did not exist before

The IEEE publishes the OUI registry as a single file at standards-oui.ieee.org, and it overwrites that file in place. There is no change log, no version history and no archive on the IEEE side. Ask what prefix 08:00:30 resolved to in 2019 and the registry has no answer, because the registry only knows what is true now.

Every OUI repository on GitHub is a copy of that current file. The largest one has over a hundred stars and is a snapshot dump of the thing everyone already has. Nothing published the diff, because the diff can only be produced by someone who was already keeping copies, and it cannot be reconstructed later by anyone who was not.

This record is built from 86 dated captures: 45 Internet Archive copies of that exact URL going back to 2016-07-29, and a daily observation of the live file since 2026-07-17. Third-party mirrors are deliberately not used. Wireshark's manuf file and the various oui.txt derivatives carry their own edits, and presenting a curated derivative as IEEE history would break the only discipline that makes the record worth citing.

What actually changes

Renames dominate. 2,044 of them across 1,843prefixes, and most are corporate: an acquisition closing, a subsidiary folded into a parent, a brand retired. EMC Corporation's prefixes read Dell EMC after 2016. Those are the changes that quietly break a vendor-name match written years earlier.

Withdrawals are rare, 5 in the entire record, and reassignments rarer still. That rarity is itself useful: a prefix that stops resolving is unusual enough to be worth a look rather than a shrug.

A fourth category is excluded from the headline on purpose. 281 events on 277prefixes are the IEEE restyling its own text, such as SEIKO EPSON CORPORATION becoming Seiko Epson Corporation in 2017. The registrant did not change, so counting those as registrant changes would inflate the figure with the registry's house style. They are typed recased in the published file, because anyone matching vendor names as exact strings is broken by them all the same.

What it means for device identification

Anything that identifies a device by its MAC prefix inherits this. A DHCP fingerprint rule, an asset inventory, a network access control policy, a security alert keyed on a vendor string: each was written against the registry as it stood on some particular day, and 4.6% of the registry has moved under them since 2016.

The practical fix is not to stop using OUIs. It is to store the prefix rather than the vendor name, resolve it at read time, and keep the date you resolved it on. That is the same discipline this record itself follows, and it is why every row here carries the capture it was observed in.

The other half of the identification problem is that a growing share of addresses have no registrant at all, because the device made the address up. Randomized MAC addresses covers that case.

How to check this yourself

Nothing here has to be taken on trust. Every row names the Internet Archive capture it was read from, so any single claim can be checked against the bytes it came from:

curl -sO https://raw.githubusercontent.com/Drumworks/oui-change-history/main/oui-changes.csv

# every observed change to one prefix
awk -F, '$1 == "000097"' oui-changes.csv

# renames per year
awk -F, '$2 == "renamed" { print substr($3,1,4) }' oui-changes.csv | sort | uniq -c

observations.csv in the same repository lists every capture date and the registry size at that date. It is what makes an absence of change provable rather than merely unrecorded: a prefix with no row between two dates was observed unchanged across every capture between them.

FAQ

Does a MAC address prefix always identify the same manufacturer?
No. 1,848 of the 40,115 prefixes in the IEEE OUI registry, 4.6%, resolve to a different organisation today than they did in 2016. The prefix does not move. What it resolves to does, through renames, acquisitions and the occasional withdrawal. ssid.ai has measured this across 86 dated captures of the registry between 2016-07-29 and 2026-09-09, and publishes every observed change with the archive URL it was read from.
How often does the IEEE OUI registry change?
Roughly 185 prefixes a year change the organisation they are registered to, averaged over 10 years of observation. New assignments are far more frequent: the registry grew to 40,115 prefixes over the same period. Withdrawals are rare, 5 in the whole record, which is why a prefix that stops resolving is worth investigating rather than ignoring.
Where can I get a change history of the IEEE OUI registry?
ssid.ai publishes one free at github.com/Drumworks/oui-change-history, licensed CC BY 4.0 including commercial use. It carries 2,049 observed changes with the date each was first seen and the Internet Archive URL it was seen in. The IEEE itself does not publish one: it overwrites oui.csv in place and keeps only current state, so this record cannot be reconstructed after the fact by anyone who was not already watching.
Why does my OUI lookup return a different vendor than my old records?
Most likely because the registrant changed and your records were written against an older copy of the registry. EMC Corporation's prefixes read Dell EMC after the 2016 acquisition, and there are 1,843 prefixes with at least one such change. A second, quieter cause is formatting: the IEEE restyled its own capitalisation on 277 prefixes, so an exact string match breaks even though the registrant is the same company. Both are in the published record, typed separately.
Is this the same as an OUI database download?
No, and the difference is the point. An OUI database is the registry as it stands today, and the IEEE publishes that itself at https://standards-oui.ieee.org/oui/oui.csv. Dozens of repositories mirror it. This is the diff between dated copies of that file, which nobody else keeps, and which cannot be generated later from the current file no matter how good the tooling is.
How accurate are the dates in this record?
Each change is dated to the capture that first showed it, which is an upper bound rather than the change's own date. Between 2016-07-29 and 2026-07-17 the captures are irregular, sometimes months apart, so a change in that window is placed at the next capture after it happened. From 2026-07-17 the registry is observed daily, so recent changes are dated to within a day. observations.csv in the repository lists every capture date, so the width of the bound is visible on any row rather than implied.
What counts as a change in this dataset?
Three things: a rename, where the prefix stays assigned and the organisation on it changes; a withdrawal, where a prefix present in an earlier capture is absent from a later one; and a reassignment, where a withdrawn prefix reappears. Formatting-only restyles are recorded as a fourth type and excluded from the headline figure, because the registrant did not change. First observations are not changes at all: the first capture of the registry shows every prefix in it, and treating that as tens of thousands of simultaneous assignments would be nonsense.
Can I use this data commercially?
Yes. CC BY 4.0, which permits commercial use, redistribution and modification. The one requirement is attribution: credit ssid.ai and link back. If you pass rows on, keep the source_url and source_archive_url fields on them, because those are what make a row checkable rather than merely asserted.

The data