Bluetooth and BLE Security: Attacks and Defense

Bluetooth and BLE security is one of the most common blind spots in the connected device ecosystem. Smart locks, fitness trackers, headphones, industrial sensors, insulin pumps and pacemakers all share the same short-range radio that, in many cases, was designed to prioritize power consumption and pairing convenience over resistance to an active attacker. The result is an attack surface that is rarely audited and that an adversary with a five-euro antenna can listen to from across the street.

This article is a technical deep dive into Bluetooth security, a companion to our broader overview of IoT and OT cybersecurity. We review the two stacks in the standard, the historical attacks that shaped the sector (BlueBorne, KNOB, BIAS), the sniffing and spoofing that are specific to BLE, the particular risk in wearable and medical devices, and the secure pairing, defense and detection measures we apply in a professional audit.

Bluetooth Classic and BLE: two stacks, two threat models

Two radically different technologies live under the Bluetooth brand. Bluetooth Classic (BR/EDR) is the stack oriented to continuous streams (audio, file transfer) and uses frequency hopping over 79 channels. Bluetooth Low Energy (BLE), introduced in version 4.0, is optimized for battery-powered devices that transmit small bursts of data: it uses 40 channels (3 for advertising and 37 for data) and exposes its functionality through the GATT (Generic Attribute Profile), a hierarchy of services and characteristics that a client can read, write or subscribe to.

That architectural difference defines the threat model. In BR/EDR the historical problem has been key negotiation and link authentication. In BLE the problem is twofold: advertising packets are broadcast in the clear and predictably (making tracking and reconnaissance easy), and legacy pairing allows modes with no real protection against a man in the middle. Understanding which stack each device uses is the first step, much as in industrial environments it helps to clearly separate the concepts we explain in what OT/ICS security is.

Historical attacks against Bluetooth Classic

BlueBorne (2017)

Discovered by Armis, BlueBorne is a set of eight vulnerabilities (including CVE-2017-0781, CVE-2017-0785, CVE-2017-1000251 and CVE-2017-14315) that affected the Bluetooth stacks of Android, Linux, Windows and iOS. Its severity was exceptional for one reason: it required no prior pairing and no user interaction. Bluetooth simply had to be enabled and reachable to achieve remote code execution or information disclosure. It was the proof that the protocol stack itself, and not only the application, is a first-order target.

KNOB (2019)

The KNOB (Key Negotiation Of Bluetooth) attack, cataloged as CVE-2019-9506, exploits a design weakness in the entropy negotiation of the BR/EDR encryption key. An attacker positioned in the middle can force the negotiated key to have as little as 1 byte of entropy, a key space that can be brute-forced in real time. Because the reduction happens during negotiation and before encryption is applied, many devices accepted it without alerting the user.

BIAS (2020)

BIAS (Bluetooth Impersonation AttackS), identified as CVE-2020-10135, attacks the BR/EDR authentication procedure. It lets an attacker impersonate a previously paired device without knowing the long-term link key, leveraging weaknesses in legacy authentication and in the master-slave role switch. Combined with KNOB, an adversary can establish themselves as a legitimate intermediary between two devices that already trusted each other. This family was joined by BLURtooth (CVE-2020-15802), which abuses Cross-Transport Key Derivation (CTKD) in dual-mode devices to overwrite one transport's keys with the other's.

BLE-specific attacks: sniffing and spoofing

Traffic sniffing

Capturing BLE traffic is surprisingly accessible. With a Nordic nRF52840 dongle and the nRF Sniffer for Bluetooth LE add-on, an Ubertooth One, or NCC Group's open-source Sniffle tool on a Texas Instruments CC26x2 board, an attacker can follow a connection's channel hopping and dump the exchange into Wireshark, which includes native BLE dissectors. If the connection uses legacy pairing, tools such as crackle recover the temporary key (TK) and decrypt the entire session passively. The same utilities (hcitool, gatttool, bettercap with ble.recon and ble.enum, or the nRF Connect app) let you enumerate GATT services and characteristics without authentication on most consumer devices.

Spoofing and man-in-the-middle attacks

The next step up is the active intermediary. Frameworks such as GATTacker, BtleJuice and Mirage clone a legitimate peripheral's advertisements, place themselves between the device and its mobile app, and relay (or modify) GATT reads and writes in real time. A recurring case study is the smart lock whose unlock command travels without application-layer encryption: captured once, it is replayed as many times as desired. The BLESA (Bluetooth Low Energy Spoofing Attack) brought this to the reconnection procedure: many stacks (BlueZ, Fluoride and iOS clients) did not require reauthentication on reconnect, so a spoofed peripheral could inject false data into a client that believed it was talking to an already known device.

Wearables and medical devices: when the risk is physical

The impact stops being abstract in devices that touch the body or the process. The SweynTooth (2020) family of vulnerabilities, which affected the BLE SoCs of vendors such as Cypress, NXP, Dialog and Texas Instruments, caused crashes, deadlocks or security bypasses in products ranging from fitness trackers to insulin pumps and pacemaker programmers. The FDA issued specific advisories because of their presence in medical equipment. In parallel, BleedingTooth (CVE-2020-12351 and related) demonstrated code execution in the Linux kernel through the BlueZ stack, relevant to IoT gateways and Linux-based clinical equipment.

In wearables, the dominant risk is twofold: tracking through static MAC addresses that let someone be followed by their wristband, and the exposure of biometric data without application-layer encryption. These devices increasingly enter environments regulated by NIS2 and by the Cyber Resilience Act (CRA), so the security of their radio stops being a product detail and becomes a compliance obligation.

Secure pairing and defense in depth

The good news is that the standard offers robust defenses when implemented well. These are the non-negotiable measures.

Require LE Secure Connections

Since Bluetooth 4.2, LE Secure Connections replaces legacy pairing with an ECDH key exchange over the P-256 curve, which eliminates the passive-eavesdropper attack that makes crackle viable. Any sensitive product specification should forbid a fallback to legacy pairing.

Choose the right association model

The association models (Just Works, Passkey Entry, Numeric Comparison and Out Of Band) do not offer the same protection. Just Works does not authenticate the other endpoint and is vulnerable to an active intermediary, so it must not be used in locks, medical devices or access controls. For those cases, Numeric Comparison or Passkey Entry is the answer, since they do protect against MITM when the device has a screen or keypad.

Application-layer encryption and privacy

Link encryption is not enough. Adding application-layer encryption (for example, authenticating each command with a factory-provisioned key and a nonce) neutralizes replay even if the attacker breaks the link. For tracking, enabling LE Privacy with resolvable private addresses (RPA) rotated via an IRK prevents following the device by its MAC. And as a basic operational control: disable the radio when it is not in use, minimize advertising and keep firmware current, since most of the attacks above were fixed in updates that almost never reach the deployed device.

Detection and auditing of the Bluetooth attack surface

Auditing Bluetooth follows the same philosophy we apply to industrial pentesting and OT/ICS assessment: start passive and escalate under control. The passive phase is a reconnaissance sweep (bettercap, hcitool lescan, nRF Connect) to inventory the devices that advertise, their GATT services and their pairing model. From there you capture traffic with nRF Sniffer or Sniffle to verify whether the connection uses Secure Connections or legacy, and only afterward, with explicit agreement and on a test device, do you run active tests of spoofing, replay or GATT characteristic manipulation. The goal is not to crash the device but to demonstrate what a realistic attacker can do and to prioritize remediation by risk, with the same rigor we apply in SCADA environments.

Frequently asked questions

Is it safe to leave Bluetooth enabled on my phone?

On a modern, updated phone, the everyday risk is low, because attacks like BlueBorne were fixed years ago. The real problem is the device that never gets patched: locks, sensors or medical equipment still running vulnerable stacks. The practical recommendation is to disable the radio when it is not needed and, above all, to keep the entire connected ecosystem updated.

What is the security difference between Bluetooth Classic and BLE?

Bluetooth Classic (BR/EDR) has mostly suffered attacks on key negotiation and link authentication (KNOB, BIAS). BLE adds problems of its own: cleartext advertisements that ease tracking, a GATT profile that is enumerable without authentication, and legacy pairing that a passive eavesdropper can decrypt. Both stacks need defense, but the vectors are not interchangeable.

Can a BLE wristband or lock be spied on from a distance?

With affordable equipment (an nRF52840 dongle, an Ubertooth or a Sniffle-compatible board) you can capture BLE traffic at tens of meters with a suitable antenna. If the device uses legacy pairing or does not encrypt its commands at the application layer, that traffic can be decrypted or replayed. This is exactly what an audit validates before an attacker does.

Which standard governs Bluetooth security?

The main technical reference is the NIST SP 800-121 Rev 2 (Guide to Bluetooth Security), together with the Bluetooth Core Specification from the SIG itself, which defines LE Secure Connections and the association models. For devices sold in the European Union, the Cyber Resilience Act (CRA) and the NIS2 Directive impose additional requirements for security by design and vulnerability management.

How do I start securing a product with Bluetooth?

The first step is to inventory which stack and which pairing model each device uses. From there you require LE Secure Connections, forbid Just Works for sensitive functions, add application-layer encryption against replay and enable LE Privacy against tracking. A professional radio audit confirms that those measures hold up against a real attacker and not just the design diagram.

Related reading

• IoT and OT cybersecurity: critical threats in 2026
• What OT/ICS security is
• SCADA security: threats and best practices
• Industrial pentesting and OT/ICS assessment
• Flipper Zero: what it is and its security risks

Bluetooth security and IoT auditing with Secra

Secra evaluates the Bluetooth and BLE attack surface of your products and your connected environment with the same operational sensitivity we apply in OT: we start from passive reconnaissance, inventory GATT services and pairing models, verify whether the connection uses LE Secure Connections, and demonstrate the real impact of an attacker before proposing prioritized remediation.

If you design or deploy locks, wearables, sensors or medical equipment with a Bluetooth radio and need to validate their real security, explore our IoT/OT security audit or contact our team for a no-commitment initial conversation.