There’s often a lot of confusion about Bluetooth LE Addresses. How they’re used and generated seems complicated because they’re not just a single number.
Overview: Device Address vs MAC Address
Devices communicating over Bluetooth Low Energy must be able to identify themselves. For this purpose, the Bluetooth specification defines a Device Address.
Although the BLE specification uses the term Device Address, you’ll often hear it referred to as a MAC address. There’s a lot of similarities to a MAC address:
- A BLE Device Address is 48 bits (6 bytes) long, just like an IEEE MAC address.
- One valid BLE address type is an IEEE-allocated MAC address.
- Bluetooth Classic explicitly refers to it as a MAC address.
For simplicity, we’ll use Device Address and MAC address interchangeably—they refer to the same 48-bit identifier.
BLE Address Hierarchy (High Level)
BLE device addresses are not all the same. There is a clear hierarchy that determines what type of address is in use and how it should be interpreted as you can see below
Now that we know what the hierarchy is, let’s look at them.
Public Device Address
A Public Device Address is a fixed address allocated by the IEEE, similar to Ethernet or Wi-Fi MAC addresses.
These addresses are:
- Assigned from a block purchased by the manufacturer
- Identifiable back to the vendor
- May be shared between Bluetooth Classic and BLE (with some restrictions)
If the same address is going to be used by the device for Bluetooth Classic as well, there is a restriction on LAP values.
Why Public Addresses Are Rare in BLE
In practice, BLE devices rarely use public addresses because of a few issues:
- IEEE address blocks cost money and there’s limited address blocks available in general
- Public addresses can be tracked
- BLE was designed with privacy as a core goal
For most BLE products, public addresses are avoided entirely. In fact, in over 15 years we’ve never had to use Public Addresses in products we’ve developed and we’ve never seen them used either.
Random Device Addresses
Random addresses are not allocated by the IEEE and are provided by the device itself or by the product developer. They fall into two major categories:
- Static Random Addresses
- Private Random Addresses
Both are widely used in real-world BLE products.
Static Random Device Address
A Static Random Address is a semi-permanent address generated at each power-up. To be a static Random address, there’s a few rules that need to be followed:
- Randomly generated
- Must contain at least one
0bit and one1bit - Bits
[47:46]must be11 - Remains constant for the entire power cycle
- Can only change after a power reset
In many chipsets, a unique static address is pre-programmed at the factory. Developers often use this address directly because:
- It is stable and predictable
- It simplifies debugging and packet sniffing
- It behaves like a traditional MAC address
The downside is that static addresses provide no privacy. Anyone observing the air traffic can track the device over time.
Device Programmed Static Random Address
Many developers rely on the factory-programmed address that comes with the chipset, which tend to be the default. These addresses are typically:
- Unique
- Random-looking
- Fixed across boots (unless explicitly changed)
Static addresses are easy to work with, especially during development, because they remain stable and easy to track in packet sniffers.
Private Device Addresses
Private addresses exist specifically to prevent device tracking.
Bluetooth Classic used fixed MAC addresses, which made it trivial to track users. BLE introduced LE Privacy to address this problem via Private addresses.
Private addresses come in two forms:
- Non-Resolvable Private Addresses
- Resolvable Private Addresses
Resolvable Private Addresses
Resolvable Private Addresses are generated using an Identity Resolution Key (IRK).
- Address changes periodically
- Trusted devices can still recognize the peer by using the IRK
- Enables privacy without breaking reconnection
Example: How Address Resolution Works
Consider a BLE peripheral and an iPhone:
- The peripheral uses LE Privacy and advertises with a resolvable private address.
- The iPhone connects and pairing occurs. The connection is secured.
- During pairing, the peripheral shares its IRK.
- Sometime later, the devices disconnect.
- The peripheral changes its address periodically.
- When the iPhone scans later, it:
- Sees a new random address
- Uses the IRK to attempt address resolution
- Identifies the device and reconnects securely
All this behavior is hidden from the user
Hardware Acceleration for Address Resolution
Address resolution becomes more complex as the number of stored IRKs increases. To handle this efficiently, many chips include hardware acceleration. For example, the Nordic Semiconductor nRF52 series includes Accelerated Address Resolution (AAR)
Accelerating address resolution in Hardware critical because packets may be missed if software takes too long to do this:
- Resolving 8 IRKs can take ~49 µs
- BLE requires responses within ~150 µs
- Hardware offloading avoids missed packets and timing issues
Non-Resolvable Private Addresses
The last type of private addresses are the Non-resolvable addresses:
- Cannot be resolved using an IRK
- Offer maximum privacy
- Are rarely used in practice
Because they prevent reliable reconnection after the initial pairing, their use cases are limited.
Address Update Interval
If devices kept their address for long periods of time, it wouldn’t prevent tracking. Private addresses change periodically according to the Resolvable Private Address Generation Interval.
- Configurable by the application
- Bluetooth specification recommends 15 minutes
This is why smartphone BLE addresses appear to change frequently when sniffed, and the same smartphone will appear as having multiple addresses.
BLE Addresses in Practice
Now that we have an understanding of the various addresses and how to check which are in the packets it’s makes sense to talk some more about using them in practice.
If you don’t use pairing and bonding:
- Static Random Address is your only realistic option
- No IRK exchange occurs
- Your product can be tracked
In this case, devices often load a fixed, vendor-programmed address.
With Security and Privacy Enabled
When you enable pairing, bonding, and privacy:
- Resolvable Private Addresses are almost always used
- Privacy and security work together
In practice, it rarely makes sense to care about privacy without caring about security.
BLE Address in Packets
The top level shows the Uncoded LE Packet Format. The relevant item here is the Protocol Data Unit (PDU) which contains both Header and Payload.
The Header contains two fields called TxAdd and RxAdd. These fields are Payload specific – depending on the packet they may or may not be used, but they indicate whether the relevant address is public (0) or Random (1). This is the first indication of what kind of an address we actually have.
For cases where we have a random address we have to take another step. The Type of the address is encoded in the address itself. The actual Device Address is contained in the Payload itself, in fields such as AdvA (Advertiser Address). Since the header indicated to us whether the address is Public or Random, we can decode the address itself.
The Device Address is 48-bit (6 Octets or bytes). The top 2 bits, denoted above as [47:46] indicate the subtype of the address:
- 0b00 – Non-Resolvable Private Address
- 0b01 – Resolvable Private Address
- 0b10 – Reserved. Currently Unused
- 0b11 – Static Address
Summary
While BLE device addressing initially appears complex, real-world systems typically use one of two approaches:
- Static Random Address – simple and stable, ideal for development
- Resolvable Private Address – secure, private, and production-ready
Public addresses still exist but are increasingly uncommon due to privacy concerns.
Once you understand how address types are encoded and resolved, BLE addressing becomes predictable—and much easier to design around.
