How to tell a device-generated (randomized) MAC apart from a real burned-in vendor MAC — by reading a single octet — and why it matters for captive portal and MAC re-authentication.
The one-second check
Look at the second character of the MAC address. If it is 2, 6, A, or E, the address is locally administered — almost always a randomized MAC. Any other value means it is a real, vendor-assigned (burned-in) address.
Worked example
Reading the address 62:18:48:9D:21:82
Only the first octet carries the flag that tells you whether a MAC was randomized. The other five octets are random in a randomized address, but on their own they prove nothing — always decode octet 1.
↑ first octet — the only one that matters
Verdict: randomized. The Universal/Local bit (second-lowest bit of octet 1) is set to 1, so no manufacturer owns this address — the device made it up. An OUI lookup of 62:18:48 confirms it: it returns no registered vendor.
You can also use this tool to look up a MAC Address online: https://maclookup.app/
First-octet lookup table
The tell lives in the second hex digit of the first octet. Match it against this table — no binary math required in the field.
| 2nd char of MAC | U/L bit | Meaning | Verdict |
|---|---|---|---|
| 2, 6, A, E | 1 | Locally administered — no real vendor owns it | Randomized |
| 0, 4, 8, C | 0 | Universally administered — maps to a real OUI / vendor | Burned-in |
| 1, 5, 9, D | 0 | Universal and multicast — not a normal device address | Not a client |
| 3, 7, B, F | 1 | Local and multicast — not a normal device address | Not a client |
Why only the second character? Each MAC is 48 bits. The two lowest bits of the very first octet are control flags: the I/G bit (bit 0) marks unicast vs. multicast, and the U/L bit (bit 1) marks vendor-assigned vs. locally generated. A randomizing device forces U/L = 1 and I/G = 0, which always lands the second hex digit on 2, 6, A, or E.
Procedure
How to check an address in the field
Grab the MAC
From Manage → Users in ElevenOS Admin, the MikroTik lease/registration table, or Support → Radius Activity. Any format works —
62:18:48…,62-18-48…, or6218.48….Isolate the second character
Ignore everything except the first two characters. The second one is your answer.
Match against the tell
Is it 2, 6, A, or E? → Randomized. Anything else → burned-in vendor address.
Confirm with an OUI lookup (optional)
Run the first three octets through any OUI/vendor lookup. A randomized MAC returns no registered vendor; a real one resolves to Apple, Samsung, Intel, etc. Two signals agreeing = certainty.
Fast filter on Managed MikroTik
First-pass filter to surface likely-randomized leases (matches the four locally-administered second characters):
# flags MACs whose 2nd hex char is 2, 6, A or E /ip dhcp-server lease print where mac-address~"^.[26AEae]"
Why it matters
Field impact on ElevenOS
Randomized MACs break any flow that recognizes a device by its address. When a device re-randomizes — per SSID, or per connection on newer OS versions — it presents a MAC the platform has never authorized.
Symptoms you'll see on a ticket
Guest hits the captive portal every visit despite "remember me"; MAC Authentication / RADIUS seamless re-auth silently fails to match; a single physical device appears as many entries under Manage → Users; PMS check-in deauth targets a MAC the device no longer uses.
What the guest sees on their device
iOS / iPadOS
“Private Wi-Fi Address” — toggle per network under Wi-Fi → (i). On newer iOS it can rotate to a fresh address roughly every 2 weeks.
Android
“Use randomized MAC” (default) vs. “Use device MAC” — per network under Wi-Fi → network → Privacy.
Windows
“Random hardware addresses” — global toggle plus a per-network setting under Wi-Fi adapter properties.
Comments
0 comments
Article is closed for comments.