Key Takeaways

  • Every BLE device broadcasts an address that can be used to track its owner. If that address is static, your product is a tracking beacon — whether you intended it or not.
  • Modern BLE provides a robust anti-tracking architecture — Resolvable Private Addresses (RPA), Identity Resolving Keys (IRK), and Encrypted Advertising Data (EAD) — but only if you implement it correctly on both sides of the link.
  • EU regulations now mandate privacy by design for wireless products. GDPR, the Cyber Resilience Act, the Radio Equipment Directive, and the Data Act collectively require that BLE devices protect users against tracking and unauthorized data access.
  • RPA is the correct default for personal devices — but not for every device. Shared infrastructure, factory testing, mesh nodes, and closed-environment asset trackers have legitimate reasons to use static addresses. A credible privacy architecture knows when to apply RPA and when not to.

Introduction

Encryption protects data. BLE Privacy protects people.

In our companion brief on BLE link-layer encryption, we made the case that modern BLE security — LE Secure Connections with AES-128-CCM — is cryptographically strong and sufficient for most over-the-air protection scenarios. But a device can have perfect encryption and still betray its owner’s location, habits, and identity — simply through the address and data it broadcasts before any connection is established.

Every BLE device advertises. It broadcasts packets to announce its presence, its services, and its willingness to connect. These packets are visible to every BLE scanner in range — your phone, your laptop, the mall’s proximity marketing system, a researcher’s Raspberry Pi, or an attacker’s purpose-built sniffer. What’s in those packets, and how often they change, determines whether your product respects user privacy or undermines it.

At needCode, we build BLE firmware and companion applications on Nordic nRF-series (including nRF Connect SDK / Zephyr RTOS), Silicon Labs EFR32, TI CC26xx, and Espressif ESP32. On the host side, we develop native iOS (CoreBluetooth) and Android apps, cross-platform Flutter apps, Windows desktop applications (Windows.Devices.Bluetooth), and Linux systems using BlueZ. Privacy engineering touches every layer of this stack — and getting it wrong on any one layer can undo the protections built into the others. On a smart running insole project, for example, the device streamed real-time pressure sensor data over BLE for live coaching — athletic performance data that required careful attention to advertising identity, connection privacy, and platform-specific behavior across both iOS and Android.

The BLE Privacy Problem: Your Device Is a Tracking Beacon

To understand BLE privacy, you need to understand what a passive observer sees.

Every BLE advertising packet contains, at minimum, a 48-bit device address. If that address never changes — which is the case for devices using a public address or a random static address — any observer who sees the packet once can recognize the device forever. They don’t need to connect. They don’t need to pair. They just listen.

A static BLE address enables: passive location tracking (following a device — and its owner — across locations and over time), behavioral profiling (correlating a device’s presence with specific venues, times, and activities), manufacturer identification (the first three bytes of a public address are an IEEE-assigned Organizationally Unique Identifier, revealing the chipset vendor), and cross-session correlation (linking a device seen yesterday to the same device seen today, even without knowing the owner’s name).

This is not a theoretical concern. Academic researchers have demonstrated passive BLE tracking in shopping malls, airports, and public transit systems. And with the proliferation of BLE-enabled products — from fitness bands to hearing aids to smart luggage — the tracking surface is only growing.

BLE’s Anti-Tracking Architecture: How It Works

The Bluetooth specification provides a layered privacy framework that, when implemented correctly, makes passive tracking difficult and expensive. The core mechanisms are:

Resolvable Private Addresses (RPA). Instead of broadcasting a static address, a device using RPA generates a new, cryptographically random address that changes periodically. The specification recommends rotation intervals shorter than 15 minutes — and iOS devices follow this recommendation. Each RPA is derived from a random component and a cryptographic hash computed using the device’s Identity Resolving Key (IRK). To any observer without the IRK, the device appears as a completely new, unknown device every time the address rotates. The address cannot be traced back to a specific manufacturer, and it cannot be correlated across rotation periods.

BLE 6.0 introduced Randomized RPA Updates, an improvement that allows the BLE controller to autonomously rotate the address at random intervals within a configured time range — rather than on a fixed, predictable timer. This eliminates a subtle attack vector where a sophisticated tracker could detect the periodic pattern of address changes and correlate “before” and “after” addresses based on timing alone.

The Identity Resolving Key (IRK). The IRK is the mechanism that makes RPA “resolvable” — but only by trusted peers. During BLE bonding, each device distributes its IRK to its peer, which stores it alongside other bond information (LTK, peer address). When a bonded device subsequently sees an RPA in an advertising packet, it performs a local verification: it takes the random portion of the address, encrypts it with the stored IRK using AES, and compares the result to the hash portion of the address. If they match, the device has identified its bonded peer — without any over-the-air exchange, without any additional communication, and without revealing the peer’s identity to any other observer.

This is an elegant design: reconnection between trusted devices is seamless (the bonded central resolves the peripheral’s RPA automatically), while untrusted observers see only a stream of unrelated, random addresses.

Advertising Data Minimization. Even with RPA enabled, the contents of advertising packets can leak identity. A device name like “John’s Heart Monitor” or a unique combination of service UUIDs can fingerprint a device just as effectively as a static MAC address. Research has shown that advertising payload contents — even without explicit identifiers — can be used for device fingerprinting when the combination of data fields is sufficiently unique.

Good BLE privacy engineering means treating advertising data as publicly visible information (because it is) and minimizing it accordingly: use a generic or empty device name in advertising packets; move detailed service UUIDs to scan response data (only sent after an active scan request); never include user-identifiable information in broadcast payloads; rotate or omit manufacturer-specific data fields that could serve as stable identifiers; and consider whether your advertising interval or TX power pattern is distinctive enough to fingerprint.

Encrypted Advertising Data (EAD) — BLE 5.4+. Before BLE 5.4, all advertising data was transmitted in the clear. Even with RPA protecting the address, the payload was readable by everyone. BLE 5.4 introduced Encrypted Advertising Data, which allows some or all of the advertising payload to be encrypted using shared key material. Only devices with the correct key can decrypt the content. Combined with Periodic Advertising with Responses (PAwR), EAD enables secure connectionless data exchange — a major privacy improvement for applications like Electronic Shelf Labels, sensor broadcasts, and beacon networks where connection-based encryption isn’t practical.

Non-Resolvable Private Addresses: The Anonymous Option

RPA is the right privacy tool for devices that need to be recognized by bonded peers while remaining anonymous to everyone else. But there’s a second privacy address type that most teams overlook: the Non-Resolvable Private Address (NRPA).

An NRPA is a randomly generated address that rotates periodically — just like an RPA — but with one critical difference: it cannot be resolved by anyone. There is no IRK, no hash verification, no identity resolution. The device is truly anonymous to every observer, including previously bonded peers.

NRPAs are useful for a narrow but important category of devices: broadcast-only, connectionless products that never need to be recognized or reconnected to. Think one-way sensor beacons that push environmental data via advertising, anonymous proximity triggers (e.g., museum exhibit activations), or research and survey devices that intentionally avoid any possibility of identity correlation.

If your device never accepts connections and has no need for bonding or reconnection, NRPA provides the strongest possible address-level privacy — simpler than RPA (no IRK management) and more private (no party can resolve the address, ever).

When RPA Is the Wrong Choice

RPA is the correct default for any BLE device carried or worn by a person. But there are legitimate scenarios where RPA creates problems — and a credible privacy architecture acknowledges these rather than dogmatically applying RPA everywhere.

Manufacturing and factory testing. During production line testing, you need to identify specific units reliably by address. RPA makes this impossible — every time the address rotates, the test fixture loses track of the device. The standard approach is to use a static address during manufacturing and enable RPA as a final provisioning step before the device ships. This workflow needs to be designed intentionally, and the transition from static to RPA must be tested as part of your production process.

Shared infrastructure devices. A meeting room BLE Privacy beacon, a museum audio guide trigger, a public information kiosk — these devices are designed to be discovered by any nearby device. RPA would make them unresolvable by non-bonded observers, defeating their purpose. Static random addresses (or public addresses) are the correct choice here. These devices aren’t personal — tracking them is not a user privacy concern.

Debugging and field diagnostics. When a support engineer needs to find a specific device in a warehouse with 500 BLE sensors, RPA makes identification painful. Some teams implement a time-limited “diagnostic mode” that temporarily reverts to a static address, triggered by physical access (e.g., a button press or NFC tap). This is a reasonable engineering tradeoff — but the diagnostic mode must be time-limited and must not be remotely activatable, or it becomes a permanent privacy hole.

Asset tracking in closed environments. Industrial asset tags, logistics trackers, and fleet equipment exist to be located by authorized systems. RPA can work here — the tracking infrastructure bonds with each device and holds the IRK — but it adds meaningful complexity to deployment and provisioning. If the devices operate in a controlled environment with no personal privacy concern (a warehouse, a factory floor), the engineering overhead of RPA may not be justified. Evaluate whether the bonding and IRK management burden is proportionate to the actual privacy risk.

Bluetooth Mesh nodes. Bluetooth Mesh uses its own addressing and security model — network keys (NetKey), application keys (AppKey), and device UUIDs — separate from GAP-level addressing. The mesh provisioning and relay mechanism doesn’t use standard RPA. Forcing GAP-level RPA onto mesh nodes can create conflicts with mesh provisioning flows and is generally unnecessary, since mesh has its own privacy and security architecture.

Platform Behavior: What iOS, Android, Windows, and Linux Actually Do

One of the most common sources of privacy failures is the assumption that enabling RPA on the embedded device is sufficient. In practice, the host platform’s behavior is equally important — and each platform has its own quirks.

iOS (CoreBluetooth). Apple enforces RPA by default for all BLE operations. When an iOS device acts as a central, it uses RPA for its own address in connection requests. Apple also hides the peripheral’s real address from the CoreBluetooth API — app developers never see the actual MAC address, only a locally generated UUID. This is strong privacy behavior, but it means your mobile app cannot rely on MAC addresses for device identification. Design your GATT service with a custom device identifier characteristic (protected by encryption) if your app needs stable identity across reconnections.

Android. Android uses RPA when scanning and connecting since Android 6.0, but the implementation details vary across manufacturers and Android versions. Unlike iOS, Android does expose peripheral MAC addresses through the API in some circumstances. Android’s bond management is also less predictable — the bond table size varies by OEM, and bond eviction behavior is not standardized. Test your privacy implementation across multiple Android devices from different manufacturers.

Windows (Windows.Devices.Bluetooth). The Windows BLE stack supports RPA and IRK resolution for bonded devices. However, Windows has historically lagged behind iOS and Android in BLE privacy enforcement. Developers working with Windows should verify that RPA is correctly negotiated on both sides and that bond information (including IRKs) is properly persisted in the Windows credential store.

Linux (BlueZ). BlueZ, the official Linux Bluetooth stack, supports the full BLE privacy feature set, including RPA generation, IRK exchange, and address resolution. For embedded Linux gateways and edge devices, BlueZ is the primary stack, and its privacy configuration is managed through the D-Bus API and bluetoothd settings. BlueZ allows fine-grained control over privacy modes — including the ability to configure RPA rotation intervals — but this control comes with the responsibility to configure it correctly. Misconfigured BlueZ instances can inadvertently broadcast static addresses.

Flutter (cross-platform). Flutter BLE plugins (such as flutter_blue_plus or flutter_reactive_ble) abstract the underlying platform APIs, but privacy behavior is ultimately determined by the native stack beneath. iOS’s address masking and Android’s varying behavior both apply. If your Flutter app needs to handle bonding, reconnection, or device identification, test the privacy implications on both platforms separately — the abstraction layer can mask important differences.

The Regulatory Landscape: Why Privacy Is a Compliance Requirement

For any BLE product sold in the European Union — and increasingly, globally — privacy is not a feature. It is a legal obligation. Multiple overlapping EU regulations now mandate privacy protections in wireless connected devices:

GDPR (General Data Protection Regulation). A BLE MAC address, when it can be linked to an individual — and in practice, a static address on a personal device often can — may constitute personal data under the GDPR. Broadcasting a static, trackable address could be viewed as a processing activity that requires a legal basis and should comply with data protection principles, including data minimization and privacy by design (Article 25). Implementing RPA with proper rotation intervals is one of the most direct technical measures to help demonstrate GDPR compliance at the device level — though technical measures alone do not guarantee legal compliance.

EU Cyber Resilience Act (CRA). The CRA entered into force in December 2024, with main obligations applying from December 2027 and vulnerability reporting required from September 2026. It mandates cybersecurity-by-design for all products with digital elements — including BLE devices. The CRA requires manufacturers to conduct cybersecurity risk assessments, protect against unauthorized access, and ensure products are secure by default. BLE devices that ship with static addresses, legacy pairing, or unencrypted characteristics may face increased scrutiny during conformity assessment. The CRA also requires manufacturers to maintain security and provide updates throughout the product’s expected lifecycle.

Radio Equipment Directive (RED) — Delegated Act. Since August 2025, new wireless products marketed to EU consumers must demonstrate that personal data is protected against unauthorized access and that devices cannot be used to disrupt communication networks. This directly applies to BLE products. A device broadcasting a static, trackable address — or advertising unencrypted personal data — may struggle to satisfy RED’s personal data protection requirements.

EU Data Act. Applicable since September 2025, the Data Act governs access to and sharing of data generated by connected products. For BLE IoT devices, this means manufacturers must consider not only the security of data in transit but also user rights to data generated by their connected devices. Penalties for non-compliance reach up to €20 million or 4% of global annual turnover. While the Data Act’s primary focus is data access rather than privacy, its requirements around secure data sharing and user control reinforce the need for robust privacy architecture in connected products.

The regulatory trajectory is clear: the EU expects demonstrable privacy protections in connected products. BLE’s built-in privacy mechanisms — RPA, IRK, EAD — are strong technical tools for meeting these expectations at the protocol level. But the tools only work if they’re correctly implemented, correctly configured, and documented as part of a broader compliance strategy that includes legal and organizational measures.

Common Privacy Mistakes We See in the Field

In our work across client projects, these are the most frequent privacy failures we encounter:

Shipping with a static public address. This is the single most common privacy mistake. Many development kits default to the factory-programmed public address, and teams carry this default into production firmware. The fix is straightforward: enable RPA in your BLE stack configuration and ensure the IRK is exchanged during bonding.

Leaking identity through advertising data. RPA on the address, but “SmartLock-A7B3” as the device name in every advertising packet. The address rotates; the name doesn’t. Advertising data must be treated as public information and minimized aggressively.

Ignoring platform-side privacy behavior. A peripheral with perfect RPA implementation, paired with an Android app that caches and exposes MAC addresses to the user or to analytics. Privacy is a full-stack concern — embedded firmware, mobile app, and cloud backend all matter.

Not testing across platform versions. iOS 15 handles RPA differently than iOS 17. Android 10’s BLE behavior differs from Android 14. Bond management, address resolution, and reconnection logic all have platform-specific edge cases that only surface through real-device testing.

Missing RPA in scan response. Some implementations enable RPA for advertising packets but inadvertently use a static address in scan response packets or connection requests. Both addresses must be randomized.

No privacy documentation for regulatory compliance. Even if the technical implementation is correct, the absence of documented privacy measures — what address type is used, how often it rotates, what data is advertised, how bonds and IRKs are managed — can cause problems during CRA or RED conformity assessments. Document your privacy architecture as part of your product’s technical file.

A Real-World Benchmark: The Find My Paradigm

Apple’s Find My network is perhaps the most visible example of BLE privacy engineering at scale — and a useful benchmark for what “privacy by design” looks like in production.

Find My devices broadcast BLE advertisements containing a rotating public key that changes every 15 minutes. Nearby Apple devices — hundreds of millions of iPhones, iPads, and Macs worldwide — encrypt their own GPS location under this public key and upload the encrypted report to Apple’s servers. Only the owner, who holds the corresponding private key synchronized via iCloud, can decrypt the location. Apple’s servers act as a blind relay — they cannot read the location data they store.

The architecture uses standard BLE primitives: rotating advertisement keys, elliptic curve encryption (ECIES), and minimal broadcast payloads. No observer — not Apple, not the relay devices, not passive scanners — can determine who the device belongs to or where it is. Google’s Find My Device network for Android follows similar privacy-by-design principles.

For product teams, the lesson is not that you need to replicate Find My — it’s that privacy-respecting BLE Privacy architectures are achievable using the primitives already in the specification. The hard part is not the cryptography. It’s the systems engineering: making all the pieces — firmware, mobile app, cloud backend, key management — work together correctly.

Making the Right Privacy Decisions: A Practical Checklist

  1. Enable RPA on personal devices. Configure your BLE stack to use Resolvable Private Addresses with a rotation interval of 15 minutes or less for any product carried, worn, or used by an identifiable person. For shared infrastructure or closed-environment assets, evaluate whether the bonding and IRK complexity is justified — and document your reasoning.
  2. Minimize advertising data. Audit every byte in your advertising packet. Remove device names, limit service UUIDs, and move detailed information to encrypted GATT characteristics accessible only after connection and pairing.
  3. Exchange and store IRKs during bonding. Ensure that bonded peers can resolve your device’s RPA seamlessly. Test reconnection after address rotation on every target platform.
  4. Test on real devices across platforms. iOS, Android, Windows, Linux — each handles RPA, bonding, and address resolution differently. Emulators and single-platform testing are not sufficient.
  5. Consider EAD for broadcast use cases. If your device broadcasts data without a connection (beacons, sensors, ESL), evaluate BLE 5.4’s Encrypted Advertising Data to protect payload contents from passive observers.
  6. Document your privacy architecture. For EU market access, your technical file should describe your address type, rotation interval, advertising data contents, bonding and IRK management, and how your implementation supports GDPR and CRA requirements. Technical measures are necessary but may not be sufficient on their own — consult with legal and compliance teams for the full picture.
  7. Don’t treat privacy as firmware-only. Your mobile app, your cloud backend, your analytics pipeline — all of these can leak the identity that your firmware works to protect. Privacy is a system property, not a component property.

When to Call needCode

Privacy architecture review. You’re designing a BLE Privacy product for the EU market and need to ensure your address strategy, advertising data, and bonding implementation support GDPR and CRA expectations. We review the full stack — firmware, mobile app, and cloud — and deliver actionable recommendations.

Privacy implementation. You need RPA, IRK exchange, advertising data minimization, or EAD implemented correctly across your firmware and companion app. We build it and validate it across iOS and Android.

Rescue and debug. Devices being tracked despite RPA, reconnection failures after address rotation, GATT caching conflicts with privacy features, or platform-specific bonding issues. We diagnose from both sides of the link.

Compliance documentation. You need technical privacy documentation for CRA conformity assessment, GDPR data protection impact assessments, or customer due diligence questionnaires. We deliver the implementation and the supporting technical documentation.

Bartek Kling — bartek.kling@needcode.io