Bluetooth Addresses Versus WiFi MAC Addresses
Bluetooth devices also carry a 48-bit address in exactly the same format as a WiFi MAC, with the first 24 bits again an IEEE-allocated OUI, so the same database can look up the vendor. The privacy mechanisms and the way the addresses are used, however, differ considerably.
Same format, different name
In Bluetooth this address is the BD_ADDR, the Bluetooth Device Address. For classic Bluetooth, meaning BR/EDR, the structure matches an Ethernet MAC exactly: 24 bits of OUI plus 24 bits assigned by the vendor.
The WiFi and Bluetooth addresses of one phone are usually adjacent but not identical, often differing by one or two in the last digits, because vendors tend to allocate consecutive addresses from one batch across different radio modules. That detail is useful for asset identification: knowing a device's WiFi MAC often narrows down the range its Bluetooth address falls in.
The four BLE address types
Bluetooth Low Energy makes the mechanism considerably more elaborate, with four categories:
Public address. The traditional IEEE-allocated address, fixed and resolvable to a vendor.
Static random address. Generated randomly at power-on, constant for that power cycle and different after a restart. No vendor lookup.
Non-resolvable private address. Entirely random, changed periodically, and correlatable by nobody.
Resolvable private address, or RPA. This is the elegant one. The device generates its address from an Identity Resolving Key known only to paired peers and changes it at intervals, typically every fifteen minutes. A paired device can use the IRK to work out that this is a peer it knows, while any third party sees only a stream of shifting random addresses.
RPAs are why trackers, wireless earbuds and fitness bands can be recognised by their owner without being followed by strangers.
Recognising random addresses
As with WiFi, the flag bits in the first byte tell you. Addresses with the locally administered bit set resolve to no vendor, per reading the first byte of a MAC address. BLE random addresses additionally use the top two bits of the address to distinguish static from private types.
So a Bluetooth scanner showing a crowd of vendorless devices is the same situation as a failed lookup in a WiFi environment: the other side has privacy features enabled.
Privacy comparison
| WiFi | BLE | |
|---|---|---|
| Randomisation introduced | iOS 8 for scanning, iOS 14 for association | Present in the Bluetooth 4.0 specification |
| Enabled by default | On most platforms, yes | Depends on the device implementation |
| Rotation granularity | Usually fixed per SSID | RPAs typically rotate every 15 minutes |
| Can a paired peer identify it | Not applicable | Yes, via the IRK |
The BLE design is more mature, because it assumed from the start that devices would broadcast their presence continuously, whereas WiFi randomisation was retrofitted. That evolution is covered in MAC address randomisation, and the wider tracking risk in the privacy implications of MAC addresses.
Practical notes
Do not use a Bluetooth address as a long-term device identifier. A device using RPAs changes address every fifteen minutes, so any counting or identification based on addresses will overstate device numbers badly. Footfall analytics that simply count BLE addresses can be off by a large multiple.
Vendor lookups are still useful. For devices without privacy features, such as industrial sensors, older peripherals and beacons, the OUI still identifies the manufacturer, and you can cross-check in the vendor directory.
Scanning other people's devices has compliance implications. Passively collecting nearby Bluetooth addresses counts as processing personal data in most jurisdictions and needs a lawful basis. Diagnosing your own devices is fine; running footfall analytics means taking those obligations seriously.