They must be unique in a LAN segment. And only the lower 3 bytes in a MAC are “unique” as the upper 3 are the vendor ID and relatively fixed.

In practice people put fewer than 256 devices on networks (class C), so they have less than 1/65536 possibility of complete failure. And far less because they have a mix of OUIs.

But yeah, if you put a few hundred or thousand security cameras or other device from a single vendor, all on the same network, conflicts are certainly possible.

MAC conflicts are also a bit nasty to troubleshoot, and less obvious than IP conflicts.

If your configuration doesn't randomize the MAC, that doesn't guarantee you won't be involved in a conflict. It only guarantees that it will go more badly for you, since you will be waiting on the other device to change their MAC before you get working networking. Whereas if yours is randomized, you will probably be okay after one reconnect.

MAC randomization does not have to constrain itself to the lower three bytes; you can randomize the OUI too.

What does Android MAC randomization do with the OUI?

According to this possible hallucination from Google Gemini 2.5 Flash, the OUI is partially randomized too:

- Locally Administered Bit (U/L bit): This bit (the 2nd LSB of the first octet) is forced to '1'.

- Unicast/Multicast Bit (I/G bit): The least significant bit (LSB) of the first octet is usually set to '0' to indicate a unicast address.

- Remaining OUI bits (and the entire lower three bytes): All the other bits in the MAC address, including the remaining bits of the first octet, the entire second and third octets (which are part of the OUI), and the entire last three octets, are randomized.

Me again:

So if two bits are fixed, everyone in the randomized space is randomizing 46 bits, which contains 7.03E+13 addresses.

Practically speaking, it seems that the only way you will ever see a clash arising from the above randomization strategy is if two devices are using the same very poorly seeded PRNG.