A MAC address looks like six pairs of hex digits separated by colons. Looking at one feels like reading a fingerprint. In some sense it is — the first half identifies the hardware vendor with reasonable certainty, the second half is supposed to identify the specific device.
But the world of MAC addresses has changed significantly in the last decade. Modern phones randomise. Modern laptops sometimes randomise. Knowing what a MAC actually tells you — and what it has stopped telling you — is more useful than knowing how to look one up.
The structure of a MAC
A MAC address is 48 bits, usually written as six pairs of hex digits:
AC:DE:48:00:11:22
The first three pairs (AC:DE:48) are the OUI — the Organisationally Unique Identifier. This is allocated to vendors by the IEEE. The OUI tells you who made the network interface card.
The last three pairs (00:11:22) are assigned by the vendor when they manufacture the device. In principle, this means every NIC ever made has a globally unique MAC. In practice, vendors occasionally collide and you'll find duplicate MACs on the network — usually because someone cloned a virtual machine without changing its NIC.
You can look up the vendor for any MAC prefix using the IEEE's public OUI registry. The registry is maintained directly by IEEE and updated when new prefixes are issued.
What you can learn from a MAC
The vendor lookup tells you something useful: which hardware family the device is from.
AC:DE:48→ Private (a research/experimental block)00:1B:63→ Apple, Inc.00:0F:DE→ Sony EricssonB8:27:EB→ Raspberry Pi Foundation
In a typical office network, scanning a /24 and looking up the OUI of every device gives you a reasonable inventory:
- 60% Apple OUIs → probably MacBooks and iPhones
- 20% Dell, Lenovo, HP OUIs → corporate laptops
- 10% Cisco, Aruba, Ubiquiti → infrastructure (switches, APs)
- 10% miscellaneous → printers, projectors, IoT, whatever
That's useful for capacity planning, network audits, and "is there anything on this network I don't recognise."
The Raspberry Pi OUI specifically is interesting — those devices often end up in places nobody officially deployed them. Looking up MACs on a network and finding a Pi Foundation prefix you don't recognise is a worthwhile early signal.
What you cannot learn
This is where most MAC-based reasoning falls apart.
You cannot identify the owner
A MAC is hardware-bound, not human-bound. Knowing a MAC tells you what device was on the network. Knowing who was using the device requires correlating with authentication logs, DHCP leases tied to identities, or physical observation. None of those is the MAC itself.
You cannot identify the exact device model
The OUI tells you the vendor. It does not tell you whether the Apple MAC is an iPhone, a MacBook, an Apple TV, or an AirPod. Some advanced fingerprinting techniques can narrow it down by looking at the device's DHCP fingerprint or its network behaviour, but the MAC alone won't.
You cannot reliably identify the OS
A "Lenovo" MAC could be running Windows, Linux, or ChromeOS. The OUI is about the hardware, not the software.
You cannot track a modern phone across networks
This is the biggest change. Modern phones randomise their MAC address on every network they join. iOS has done this by default since iOS 14 (2020). Android has done it by default since Android 10 (2019). MacOS has options to randomise. Windows can randomise.
This was a deliberate privacy improvement. Before randomisation, every phone broadcast its real MAC in every probe request it sent looking for known wifi networks — making it trivially trackable across coffee shops, airports, shopping malls. Now most phones look like a new device every time they connect.
Practical implications:
- Your wifi captive portal cannot reliably "remember" a returning user by MAC alone.
- Counting unique devices by MAC over a long period overcounts dramatically (one phone may show as 50 unique MACs over a year).
- Tracking guest device returns is now far less reliable than it was in 2018.
If you see a network design that assumes MAC stability for anything privacy-sensitive — guest analytics, retail footfall tracking, time-based device identification — that design is probably outdated.
When MAC forensics still helps
Even with randomisation, MAC-based investigation still has uses.
Inventory
Within your own controlled network — corporate laptops, infrastructure, IoT — devices that aren't phones usually keep stable MACs. You can build and maintain accurate inventories from MAC tables.
Detecting unauthorised devices
A new MAC on a network where you tightly control device enrollment is a high-signal event. Even with phones randomising, a phone connecting fresh to your corporate VLAN is unusual enough to alert on.
Confirming the vendor of a device under physical inspection
Sometimes you find a network device — a switch, a sensor, an unidentified box — and want to know what it is. A MAC address lookup gives you the vendor immediately, which usually narrows the device family enough to identify it from photos.
Distinguishing real vs randomised MACs
Randomised MACs are marked. The second bit of the first byte is the Locally Administered Address flag. If that bit is 1, the MAC was assigned locally (i.e., randomised by the device), not by the vendor. You can check this trivially: take the first byte of the MAC, AND it with 0x02. If the result is non-zero, the MAC is locally administered.
Practical example: A2:DE:48:00:11:22 — the A2 first byte has bit 1 set (A2 = 1010 0010), so this is a randomised MAC. AC:DE:48:00:11:22 — the AC first byte does not have bit 1 set (AC = 1010 1100), so this is a hardware-assigned MAC and the OUI lookup is meaningful.
The MAC address lookup tool flags randomised MACs automatically — if you submit one, you'll see "Locally administered (randomised by device)" rather than a vendor name.
A typical investigation flow
When you find an unknown device on your network, the realistic flow is:
- Look up the MAC vendor via OUI lookup. If it returns a vendor, you have a starting point.
- Check whether the MAC is locally administered. If yes, you're probably looking at a phone or device that randomises — don't expect to track it across appointments.
- Cross-reference with DHCP lease history. If the same MAC has appeared before with the same hostname, you have continuity.
- Cross-reference with switch port history. If your switches log port MAC tables, you can see exactly which port the device is plugged into and when.
- If still unclear, physically inspect — most environments are small enough that you can walk the floor and find an unexplained device.
The takeaway
MAC addresses are useful for what they were designed for: identifying network interface hardware. They have never been a good identifier for humans, and as of 2020 they aren't even a reliable identifier for phones. Use them for inventory, infrastructure tracking, and vendor identification — and don't build anything that depends on a phone keeping the same MAC across visits.
Run MAC lookups liberally during network investigations. Just remember the OUI tells you who made the hardware, not who's using it.