Data sources and methodology.

Who operates this

macadress.com is a product of ApisOS FZE. See the about page for the longer version.

Primary data source

All vendor and block data comes from the IEEE Registration Authority's own public registries: MA-L (the classic 24-bit OUI), MA-M (28-bit), MA-S (36-bit, also called OUI-36), IAB (36-bit, IEEE's now-retired predecessor to MA-S, existing assignments still valid), and CID (24-bit Company ID, not a hardware OUI). We don't maintain a second-hand or purchased database; every registered block traces back to one of these five IEEE registries.

Synchronization frequency

A background service pulls all five registries on a recurring schedule (once daily, by default) and only writes rows that actually changed: each fetch is a conditional request against the source, so an unchanged registry costs nothing but a cache check. The downloadable database files on the downloads page are rebuilt from that data on their own schedule (twice daily, by default), independent of the ingestion run. Both schedules are configurable per deployment; the values above are this site's defaults, not a contractual SLA.

Last successful synchronization: Oct 6, 2026, 03:00 UTC.

How matching works

A MAC address is matched against the narrowest registered block first: a 36-bit MA-S or IAB prefix takes priority over a 28-bit MA-M prefix, which takes priority over a 24-bit MA-L prefix, since smaller blocks are carved out of a larger organization's OUI and share its first three octets. A lookup that only checked the first 24 bits would misattribute every MA-M and MA-S assignment to whichever MA-L organization happens to hold the shared prefix; this site always matches the complete registered block, at whatever size IEEE actually assigned it.

CID (Company ID) is 24 bits wide, the same size as MA-L, but IEEE assigns it with the locally administered bit set. A CID prefix therefore never appears in a real hardware address and never competes with an MA-L block for the same lookup; it identifies an organization for use in other IEEE 802 protocols, not a device maker.

When a registry re-publishes a record IEEE has already assigned (a corrected organization name, for instance), the new sync run overwrites the existing row for that exact prefix and block size. The most recent successful sync is always what's live; there's no manual conflict resolution step, because there's nothing to reconcile beyond taking IEEE's latest published version.

How randomization confidence is estimated

Randomization can't be detected directly. What can be read from the address itself is whether the U/L (universal/local) bit is set, which is necessary but not sufficient: privacy randomization, a virtual machine or container's generated address, and a manually configured address can all set the same bit. This site's confidence estimate weighs a few more signals from the address before labeling it: whether it falls in a SLAP quadrant IEEE reserves for other purposes rather than device interfaces (which rules randomization out), and whether the non-OUI bytes are all zero, a pattern far more consistent with a deliberately constructed placeholder than genuine randomness (which caps the result at "possible" rather than "likely"). Every result exposes this as one of three levels (none, possible, likely) with the reasoning in plain English, never a bare true/false.

Known limitations

• Address capacity is the size of a registered block. It is not, and can't be, a count of devices actually manufactured, sold, or currently online.
• The derived EUI-64 and IPv6 link-local fields are a mathematical derivation from the MAC address supplied. They don't confirm that any device is currently reachable at that address.
• Registration identifies the organization holding a block, never a specific device model, unit, owner, or physical location.
• A locally administered address can come from privacy randomization, a virtual machine, a container, or manual configuration; this site estimates a likelihood, not a certainty.
• IEEE's published organization names and addresses are reproduced as published, including any gaps, inconsistencies, or delays on IEEE's own side.

License

The database files on the downloads page are released under CC0 (public domain): use, redistribute, or modify them for any purpose, with or without attribution. The underlying facts (which organization holds which prefix) are IEEE's own public registry and aren't independently copyrightable; this site places no additional restriction on top of that for its compiled files either. This doesn't extend to macadress's own site content, branding, or the self-hosted product license, covered separately in the terms page.

Correction and removal requests

If a registered organization's details look wrong here, the fastest fix is usually a correction filed directly with the IEEE Registration Authority, since this site mirrors their registry rather than maintaining its own. If something on this site itself looks broken, stale beyond what the schedule above would explain, or you believe a listing shouldn't be published, get in touch and we'll look into it.

Privacy of submitted addresses

MAC addresses looked up through the web tool or API aren't tied to your identity or account. See the privacy policy for the full detail on request logging and retention.

Trademarks and affiliation

macadress is an independent service and is not affiliated with or endorsed by IEEE, Cisco, Wireshark, Nmap, or any hardware vendor named in its results or downloads. See the terms page for the full statement.

Changelog

The changelog lists blocks recently added to this database and blocks that have changed registered owner. Every date there is when one of this site's sync runs first observed that state, not an IEEE registration date: the IEEE feed carries no registration date, so an observation date is the most this site can honestly report. It is a convenience view of recent activity, not a complete audit trail.

File checksums

Every file on the downloads page is published with its SHA-256, both next to the file and collected in a single SHA256SUMS file in the format sha256sum -c reads. The checksums are regenerated with the files on each rebuild, so a given SHA256SUMS only matches files fetched in the same rebuild window.