Bluetooth Versions From 1.0 to 6.x, LE Audio and Security History

Bluetooth has two radios and a long version history. Bluetooth Classic (BR/EDR) arrived in the original 1.x specifications and gained faster rates in 2.0 + EDR (2004) and Secure Simple Pairing in 2.1 (2007). Bluetooth Low Energy arrived in 4.0 (2010), LE Secure Connections in 4.2 (2014), the isochronous channels behind LE Audio in 5.2 (2019), and Channel Sounding in 6.0 (2024). Security changed most when researchers broke pairing and key negotiation: BlueBorne in 2017, KNOB in 2019, BIAS and BLURtooth in 2020, and BLUFFS in 2023.

That is the short answer. The longer one matters if you build, buy or secure anything with a Bluetooth radio, because the version number on a product tells you less than you would hope. The Bluetooth SIG now asks its members not to market products by core specification version at all, and the flaws that caused the most trouble lived either in the shared specification (so every compliant device was affected) or in host stacks such as BlueZ and the Android Bluetooth stack (so the fix was a software update). This post walks through the radio track and the security track side by side, with adoption dates taken from the version history in the Bluetooth Core Specification itself and security details from the Bluetooth SIG's own notices, CERT/CC and NIST.

Our companion post on Wi-Fi generations from 802.11b to Wi-Fi 7 and Wi-Fi 8 tells the same story for the other radio in your laptop.

Key takeaways

• Bluetooth has two radios. Classic (BR/EDR) uses 79 channels in the 2.4 GHz band and is mainly used for audio streaming; Low Energy (LE) uses 40 channels in the same band and supports point to point, broadcast and mesh, according to the Bluetooth SIG's technology overview.
• The Core Specification's own version table dates the releases: 2.0 + EDR on 15 October 2004, 2.1 + EDR on 26 July 2007, 4.0 on 30 June 2010, 4.2 on 2 December 2014, 5.0 on 6 December 2016, 5.2 on 31 December 2019, 5.4 on 31 January 2023 and 6.0 on 27 August 2024.
• The SIG moved to a twice a year release schedule in 2025. Core 6.1 was published on 6 May 2025 with randomized timing for resolvable private address changes; 6.2 and 6.3 followed with more Channel Sounding work.
• Pairing went from PIN based legacy pairing to Secure Simple Pairing (2.1), BR/EDR Secure Connections (4.1) and LE Secure Connections (4.2). NIST SP 800-121 Rev. 2 recommends Security Mode 4 Level 4 for BR/EDR and LE Security Mode 1 Level 4 where the devices support them.
• KNOB (2019), BIAS (2020), BLURtooth (2020) and BLUFFS (2023) were specification level weaknesses. The SIG answered with errata and recommendations: a 7 octet minimum encryption key length for BR/EDR, mutual authentication, Secure Connections Only mode and restrictions on cross transport key derivation.
• BlueBorne (2017) was a set of implementation bugs in Windows, iOS, Linux and Android stacks. Those fixes came from operating system and stack updates, which is why BlueZ, Zephyr and Android Bluetooth code are components to track like any other dependency.

The dated timeline: radio and security side by side

The adoption dates below come from the "Version history" table in Volume 0 of Bluetooth Core Specification 6.0, which lists each version with the date the SIG Board adopted it. That table starts at v1.2. For 6.1, 6.2 and 6.3 the dates come from the SIG's release announcement and specification pages, as noted.

Two dates in common summaries deserve a correction. Version 5.2 is often filed under 2020 because it was announced early that year, but the SIG's table records adoption on 31 December 2019. Version 6.0 is often given as September 2024; the table records 27 August 2024. The 6.2 and 6.3 rows use the publication dates of the SIG's specification pages (4 November 2025 and 5 May 2026), because the pages we fetched do not state a separate adoption date.

Versions 1.0 and 1.1 are not in the SIG's current version table. Widely cited histories put them in 1999 and 2001; we could not confirm either date on a SIG page, so treat them as approximate.

The spec comparison table: what each version added

This table condenses the "New features" lists from the change history in Volume 1 of the 6.0 specification, plus the SIG's feature overviews for 6.1 to 6.3. "Security relevant" means the change affects pairing, keys, privacy or ranging integrity.

Most features are optional, so a product "with Bluetooth 6.0" may not implement Channel Sounding at all. The SIG's 6.1 announcement asks members to describe supported features rather than the core version. Ask which features are implemented, not which version is printed on the box.

How does Bluetooth Low Energy differ from Classic?

Bluetooth Classic and Bluetooth Low Energy share a name and a band, but they are different radios with different link layers, and a "dual mode" chip implements both.

In practice, a phone, laptop or car head unit is dual mode, while a fitness band, tag or sensor is usually LE only. The two radios share keys in one important way: since 4.2, dual mode devices can use cross transport key derivation (CTKD) to pair once on one transport and derive keys for the other. That convenience is what BLURtooth later abused, as the security section explains.

What is LE Audio (LC3, Auracast and isochronous channels)?

LE Audio is the SIG's name for audio carried over the Low Energy radio instead of the Classic radio. Classic Audio, the A2DP and hands free profiles most headphones still use, runs on BR/EDR. LE Audio runs on LE and builds on three pieces.

Isochronous channels. Version 5.2 added LE Isochronous Channels, a transport for time bound data where every receiver needs packets at a predictable time. Connected isochronous streams serve one listener such as an earbud; broadcast isochronous streams serve any number of listeners. 6.0 then improved the Isochronous Adaptation Layer (ISOAL) with a framing mode that cuts latency, according to the SIG's 6.0 feature overview.

LC3. The Low Complexity Communications Codec is LE Audio's new codec. The SIG states that listening tests showed LC3 improving on the SBC codec used by Classic Audio "even at a 50% lower bit rate". Lower bit rates for the same quality translate into longer battery life or smaller batteries.

Multi-Stream Audio, hearing aid support and Auracast. Multi-Stream Audio sends several independent, synchronized streams from one source to one or more sinks, which helps truly wireless earbuds. LE Audio adds standard hearing aid support. Auracast broadcast audio lets one source broadcast one or more audio streams to an unlimited number of receivers, for example a television in a public space or an assistive listening system in a venue.

From a security standpoint, broadcast changes the threat model. A personal stream is protected by the pairing between your phone and your earbuds. A broadcast is designed for many listeners, so whether it is encrypted, and who gets the key, is a deployment decision for whoever runs the transmitter. A venue that wants a private broadcast has to configure it that way.

The SIG's LE Audio page states that the LE Audio specifications are complete. We could not find a single dated "LE Audio adopted" milestone on the SIG pages we fetched, because LE Audio is a family of profiles and services layered on 5.2's core features rather than one document.

What is Channel Sounding in Bluetooth 6.0?

Channel Sounding is a secure fine ranging feature added in Core 6.0. Before 6.0, Bluetooth distance estimates relied on received signal strength, which the SIG's 6.0 feature overview explains requires knowing the transmitter's signal strength at a reference distance and is easily skewed by bodies, walls and reflections.

Channel Sounding uses two methods together, per the SIG's Channel Sounding page:

• Phase based ranging (PBR). An initiator sends tones to a reflector, which returns them, across many frequencies. Distance comes from phase differences across those frequencies. The SIG describes the accuracy as centimeter level.
• Round trip time (RTT). The initiator sends cryptographically scrambled packets and measures how long the reflector takes to return them. The SIG describes RTT as a secure distance bounding technique that cross checks the PBR result.

The security point is relay attacks. Digital keys for cars, doors and safes have long been vulnerable to an attacker relaying the radio exchange between a key in someone's pocket and a lock far away, so the lock believes the key is close. An independent time of flight check that the attacker cannot shortcut makes that much harder. The SIG pitches Channel Sounding for digital keys and "Find My" style item finding for this reason.

The work did not stop at 6.0. The 6.2 feature overview adds Channel Sounding Amplitude-based Attack Resilience, which detects and mitigates RF amplitude attacks against ranging, and describes how "Early Commit" ranging attacks evolved. The 6.3 technical overview adds Inline PCT Transfer and PHY specific RTT accuracy reporting. Read that sequence as a sign that secure ranging is an active research area: if you build a digital key on Channel Sounding, plan for controller firmware and host updates over the product's life.

How did pairing evolve, and what are the security modes and levels?

Legacy PIN pairing (up to 2.0 + EDR)

Early Bluetooth paired devices with a PIN, often a short fixed code such as 0000 on headsets. Link keys derived from that PIN were only as strong as the PIN, and an eavesdropper who captured the pairing exchange could attempt to recover a short PIN offline. NIST SP 800-121 Rev. 2 notes that starting with Secure Simple Pairing in 2.1, PINs are no longer used for pairing.

Secure Simple Pairing (2.1 + EDR, 2007)

Version 2.1 introduced Secure Simple Pairing (SSP), which uses Elliptic Curve Diffie-Hellman (ECDH) key agreement, and Security Mode 4. SSP has four association models, which NIST describes as follows:

• Numeric Comparison. Both devices show a six digit number and the user confirms they match. Provides protection against man in the middle (MITM) attacks.
• Passkey Entry. One device displays a passkey and the user types it on the other. Also MITM protected.
• Just Works. For devices with no display or keyboard. It runs the same exchange as Numeric Comparison but without the user check, so it gives no MITM protection.
• Out of Band (OOB). Uses another channel, such as NFC, to exchange pairing data.

BR/EDR Secure Connections (4.1, 2013)

Version 4.1 upgraded BR/EDR Secure Connections to FIPS approved algorithms: P-256 for key agreement, HMAC-SHA-256 for device authentication and AES-CCM for encryption, per NIST.

LE legacy pairing and LE Secure Connections (4.0 and 4.2)

Bluetooth LE in 4.0 and 4.1 supported Out of Band, Passkey Entry and Just Works pairing without ECDH. NIST notes that LE legacy pairing provides limited eavesdropping protection because of weak key establishment. Version 4.2 added LE Secure Connections, which uses ECDH P-256 and adds Numeric Comparison to LE.

Security modes and levels in one table

NIST SP 800-121 Rev. 2 organises the modes like this.

Secure Connections Only mode is a further setting in which every service except service discovery requires Level 4. It matters because several of the attacks below work by convincing a device to fall back from Secure Connections to legacy procedures. A device in Secure Connections Only mode refuses that fallback, at the cost of refusing older peers.

The security track: what the research broke and how it was fixed

Protocol flaws and implementation flaws, side by side

Implementation bugs are fixed once in a stack. Specification flaws affect every compliant device, and the fix often has to land in both controller firmware and host stack, on both ends of a link.

What was BlueBorne? (2017)

BlueBorne was a collection of implementation vulnerabilities that CERT/CC published on 12 September 2017 in note VU#240311. CERT/CC describes them as affecting Windows, iOS and Linux kernel based systems including Android and Tizen, in the worst case letting an unauthenticated attacker run commands on a device. The listed flaws included a buffer overflow in the L2CAP configuration handling of the BlueZ module in the Linux kernel, information leaks in the SDP servers of BlueZ and the Android Bluetooth stack, and further Android issues fixed in the September 2017 Android security patch level.

BlueBorne was not about pairing. It reached parsers that run before any pairing, exposed whenever the radio is on, and the fix was ordinary patching: kernel updates, Android patch levels and vendor updates. Devices that never received updates stayed exposed.

What was KNOB? (2019)

The Key Negotiation of Bluetooth (KNOB) attack was published on 14 August 2019 as CVE-2019-9506 and CERT/CC note VU#918987, and presented at USENIX Security 2019. It targeted the step in which two BR/EDR devices agree on how long their encryption key will be.

The BR/EDR specification allowed that length to be anywhere from 1 to 16 bytes, and the negotiation was not integrity protected. The Bluetooth SIG's notice explains that an attacker in range could interfere with the negotiation and shorten the key, in some products down to a single octet, then brute force it to monitor or manipulate traffic. The SIG also noted that some devices did not verify that the negotiated length met the minimum even where a specification required one.

The SIG's notice also sets out the limits: the attacker must be in range of two vulnerable devices as they connect, act within a narrow time window, and repeat the attack every time encryption starts. If either device is fixed, the attack fails, and the SIG said it was not aware of malicious use.

The fix. The SIG updated the Core Specification to recommend a minimum encryption key length of 7 octets for BR/EDR, added testing for that to its qualification program and urged vendors to enforce the minimum in existing products. The 6.0 change history records Erratum 11838, "new security requirements and recommendations relating to encryption key size on BR/EDR", as integrated into v5.2. Version 5.3 then added host to controller encryption key control enhancements, which give the host a standard way to set and check the key size the controller will accept.

What was BIAS? (2020)

Bluetooth Impersonation AttackS (BIAS) came from researchers at EPFL and were disclosed to the SIG in December 2019. CERT/CC published VU#647177 on 18 May 2020, and the issue is tracked as CVE-2020-10135.

BIAS let an attacker who knows the Bluetooth address of a device you have already paired with impersonate it and complete authentication without knowing the link key. The SIG's notice describes two building blocks in plain terms. First, the attacker claims to be the bonded device but without Secure Connections support, which pushes the target to legacy authentication unless the target is in Secure Connections Only mode. Second, the attacker uses a role switch so that it initiates authentication; if the target does not also authenticate the attacker in return, the target reports authentication as complete. The researchers report testing 30 devices built on 28 distinct Bluetooth chips, and all were vulnerable.

BIAS combines with KNOB: an impersonator can then try to negotiate a short key with a device that is still vulnerable to KNOB.

The fix. The SIG committed to specification changes that clarify when role switches are allowed, ensure a role switch mid authentication cannot affect the procedure, require authenticating the peer in legacy authentication and recommend checks to prevent downgrading Secure Connections to legacy encryption. In the meantime it asked vendors to refuse key lengths under 7 octets, initiate mutual authentication, support Secure Connections Only mode where possible, and not treat Bluetooth authentication alone as a trust signal without first establishing an encrypted link.

What was BLURtooth? (2020)

BLURtooth, CERT/CC VU#589825 published on 9 September 2020 and CVE-2020-15802, targeted cross transport key derivation in dual mode devices implementing Core 4.2 through 5.0. Researchers at EPFL, the University of Oxford and CISPA, and separately at Purdue University, found that a key derived over one transport could overwrite a key on the other transport even when the existing key was stronger or had been created with authentication.

The SIG's notice describes the precondition: the target must allow pairing on BR/EDR or LE with no authentication (Just Works) or without user controlled restrictions on when pairing is available. An attacker spoofing a known device could then pair over the weaker path and replace an authenticated key, opening the way to man in the middle attacks between previously bonded devices.

The fix. The SIG recommended that potentially vulnerable implementations adopt the restrictions on cross transport key derivation that Core 5.1 and later already mandate. The SIG did not treat cross transport access itself as a vulnerability, because that is what CTKD is for.

What was BLUFFS? (2023)

BLUFFS, short for Bluetooth Forward and Future Secrecy attacks, came from researchers at EURECOM and is tracked as CVE-2023-24023, published in NVD on 28 November 2023. It affects BR/EDR devices supporting Secure Simple Pairing and Secure Connections in Core 4.2 through 5.4.

The SIG's notice explains that a man in the middle spoofing two already paired devices to each other can push both into a later encryption procedure using legacy encryption, force the shortest key length both support, and fix the values that are supposed to make each session key unique. The result is that the same session key is reused every time while the attacker is nearby, so cracking one key exposes past and future sessions. The SIG says any conforming BR/EDR implementation is expected to be vulnerable to this attack on session key establishment.

The fix. The SIG's recommendations are implementation checks: reject service level connections on links with keys shorter than 7 octets; where a device can always use Security Mode 4 Level 4, reject keys shorter than 16 octets; run both devices in Secure Connections Only mode where possible; and record in the security database that a link key came from Secure Connections, then terminate the link if a later encryption setup does not also use Secure Connections.

The pattern across all five

Every specification level attack above worked by pushing devices toward an older, weaker option the specification still allowed for compatibility: short keys, legacy authentication, unauthenticated pairing on one transport. The durable defences are the same each time. Enforce minimum key sizes. Prefer Secure Connections Only. Refuse silent downgrades. Keep controller firmware and host stacks current on both ends.

What does NIST SP 800-121 recommend?

NIST SP 800-121 Rev. 2, the Guide to Bluetooth Security, was published in May 2017 and updated on 19 January 2022. Its scope covers versions 1.1 through 4.2, so it predates KNOB, BIAS and LE Audio, but its recommendations line up with the SIG's later advice.

The core recommendations, paraphrased:

• Use the strongest security mode available. For BR/EDR, Security Mode 4 Level 4 on 4.1 and later devices, Level 3 on 2.1 to 4.0 devices, and Security Mode 3 on 2.0 and older devices. Never use Security Mode 1.
• For LE, use Security Mode 1 Level 4 where both devices support LE Secure Connections, and Level 3 otherwise. Avoid Just Works pairing for LE because it provides no MITM protection.
• Write a Bluetooth security policy that lists approved uses and the types of information that may be transmitted, with a baseline configuration for default settings.
• Keep an inventory of all Bluetooth capable devices.
• Change default settings to match the policy, including device names and unneeded services.
• Keep devices undiscoverable except when pairing, and set power levels no higher than needed.
• Patch Bluetooth software and firmware, testing patches before deployment.
• Unpair lost or stolen devices from everything they were bonded to.
• Train users so they do not accept unexpected pairing requests.

NIST's checklist (Table 4-2) is a ready made policy starting point. Add two post 2019 items: a 7 octet minimum BR/EDR key size and Secure Connections Only mode where every peer supports it.

What privacy features exist (resolvable private addresses)?

Every Bluetooth device has an address. If that address is fixed and the device advertises it, anyone with a receiver can follow the device around. NIST notes that BR/EDR has no private addressing, so a discoverable Classic device can be tracked by its address.

LE has offered address privacy since 4.0. During pairing, devices exchange an Identity Resolving Key (IRK). With privacy enabled, a device advertises a resolvable private address (RPA), a periodically changing random address computed from its IRK. Bonded devices that hold the IRK can map each new RPA back to the device's identity address; everyone else sees what looks like a series of unrelated devices. Version 4.2 moved address resolution into the controller (Link Layer privacy), so a phone does not have to wake its main processor to recognise a paired watch.

Three later changes refine this:

• Core 6.1 (May 2025), Randomized RPA Updates. The SIG's announcement explains that randomizing when the address changes makes it harder to correlate activity over time, and offloading the change to the controller saves battery.
• Core 5.4, Encrypted Advertising Data. Advertising payloads can be encrypted so that only devices holding the key can read them.
• Host configuration. Privacy has to be switched on. BlueZ's main.conf ships with Privacy = off by default and offers network, device and limited discoverable variants. Zephyr's CONFIG_BT_PRIVACY makes the device use RPAs by default, and CONFIG_BT_RPA_TIMEOUT sets the rotation period, 900 seconds by default.

Privacy has limits. A rotating address does not help if the advertising payload carries a stable identifier such as a serial number or a fixed device name. The SIG's statement on location and tracking systems asks members to follow security and privacy best practice, including user consent, transparency about data collection and retention, and the right to be forgotten.

How should device makers handle Bluetooth stack updates?

A Bluetooth product has at least two pieces of software with independent update paths, and most of the fixes in this post needed both.

1. Controller firmware. It runs on the radio chip and implements the link layer and link manager, including key size negotiation. It comes from the chip vendor as a binary. KNOB and BIAS needed controller changes on many chips.
2. Host stack. BlueZ on Linux, the Android Bluetooth stack, Zephyr's host on microcontrollers, and the stacks inside Windows, macOS and iOS. It implements L2CAP, SDP, ATT, GATT, the Security Manager and the policies above. BlueBorne lived here.

A workable process for a device maker:

• Inventory both pieces for every release. Record the host stack name and version, the controller chip and its firmware version, and the core version the product qualified against. Put them in the product's software bill of materials. Our post on whether a Wi-Fi or Bluetooth module blob belongs in your SBOM covers how to list binary firmware honestly.
• Subscribe to the right feeds. The Linux kernel and BlueZ for Linux products, the monthly Android Security Bulletin for Android products (see our note on the October 2026 Android bulletin and its Bluetooth fixes), the Zephyr project's security advisories for microcontroller products, your chip vendor's security notices, and the Bluetooth SIG's security notices.
• Set secure defaults in the build. Secure Connections Only where every expected peer supports it; MITM protection enforced; privacy on; pairing only in an explicit, time limited mode started by a user action.
• Ship a field update path for both pieces. A host fix that cannot reach the controller, or a controller fix with no way to install it, leaves the product exposed.
• Report and receive. The SIG runs a Bluetooth Security Response Program for specification vulnerabilities. Publish your own product security contact so researchers can reach you.

Configuration examples

On Linux with BlueZ, these settings in /etc/bluetooth/main.conf express the policy above. The option names and allowed values come from BlueZ's annotated main.conf.

[General]
# Leave discoverable mode automatically after 3 minutes (BlueZ default is 180 s)
DiscoverableTimeout = 180
# Leave pairable mode after 2 minutes instead of staying pairable forever
PairableTimeout = 120
# Use resolvable private addresses for LE advertising
Privacy = device
# Refuse Just Works re-pairing initiated by a peer (BlueZ default)
JustWorksRepairing = never
# Allow only Secure Connections; older peers will fail to pair
SecureConnections = only

Restart the service with sudo systemctl restart bluetooth and test with every accessory you need before rolling out SecureConnections = only, because older peers will stop pairing.

On a Zephyr based product, the equivalent intent goes in prj.conf:

CONFIG_BT_SMP=y
# Security Mode 1 Level 4 only (except services needing no security)
CONFIG_BT_SMP_SC_ONLY=y
# Set the MITM flag whenever IO capabilities allow it (default y)
CONFIG_BT_SMP_ENFORCE_MITM=y
# Use resolvable private addresses
CONFIG_BT_PRIVACY=y
CONFIG_BT_RPA_TIMEOUT=900

Zephyr's Kconfig help text describes CONFIG_BT_SMP_SC_ONLY as using only Security Mode 1 Level 4, except for services that require no security.

Step by step: check what your devices support and run

None of the commands below change data on disk. Removing a pairing only deletes a bond, which you can recreate by pairing again.

1. On a Linux laptop or server

# Kernel and BlueZ versions (BlueZ fixes ship in both)
uname -r
bluetoothctl --version

# Controller address, name, powered, discoverable and pairable state
bluetoothctl show

# Controller details, including supported and current settings (look for secure-conn, privacy)
sudo btmgmt info

# List paired devices (older bluetoothctl versions use: paired-devices)
bluetoothctl devices Paired

# Turn off discoverable and pairable when you are not pairing
bluetoothctl discoverable off
bluetoothctl pairable off

# Remove a bond you no longer trust (replace with the device address)
bluetoothctl remove AA:BB:CC:DD:EE:FF

If btmgmt info lists secure-conn under supported settings but not current settings, Secure Connections is available but not enabled. Check main.conf, then your distribution's kernel and BlueZ package changelogs for fixes relevant to your version.

2. On macOS

# Chipset, firmware version, discoverable state, and paired and connected devices
system_profiler SPBluetoothDataType

Bluetooth firmware on Macs ships with macOS updates, so the practical control is staying on a supported macOS version and applying updates. Remove old pairings in System Settings, Bluetooth.

3. On Windows

# Bluetooth radios and paired devices known to Plug and Play, with status
Get-PnpDevice -Class Bluetooth | Sort-Object Status, FriendlyName | Format-Table -AutoSize

# Driver version for the Bluetooth radio
Get-CimInstance Win32_PnPSignedDriver | Where-Object { $_.DeviceClass -eq 'BLUETOOTH' } |
  Select-Object DeviceName, DriverVersion, DriverDate

Radio drivers often come from the laptop or chip vendor rather than Windows Update, so check the vendor's support page for the model.

4. On Android

# Security patch level of a connected test device (requires adb and USB debugging)
adb shell getprop ro.build.version.security_patch

Compare the patch level against the Android Security Bulletin. A device stuck on an old patch level carries every Bluetooth fix it missed.

5. In the products you build or buy

• Ask suppliers for the host stack and version, the controller chip and firmware version, and the list of Bluetooth features implemented, not just the core version.
• Ask whether the product enforces a 7 octet minimum BR/EDR key size, supports Secure Connections Only, and uses resolvable private addresses.
• Ask how controller firmware updates reach devices in the field, and for how many years.
• Request an SBOM that lists the Bluetooth host stack as a component.

Choosing a configuration: a decision table

What should users actually do?

You do not need to know the security mode names to get most of the benefit.

1. Install updates for your phone, laptop, earbuds, watch and car. Bluetooth fixes ship inside operating system and firmware updates. NIST and the SIG both say this first.
2. Remove pairings you no longer use. Every bond is a stored key and a device that can be impersonated. Remove pairings for sold or lost devices, rental cars and borrowed speakers.
3. Stay non discoverable. Most phones and laptops are only discoverable while the Bluetooth settings screen is open. Leave it closed when you are not pairing.
4. Pair in private and check the numbers. When both devices show a six digit code, compare them. Do not accept pairing requests you did not start.
5. Turn Bluetooth off when you do not need it, especially on old devices that no longer receive updates. If a device's manufacturer stopped updates years ago, treat its Bluetooth as unpatched.

On a company fleet, Bluetooth is also an exfiltration path: our post on MITRE ATT&CK T1011.001, exfiltration over Bluetooth covers how to detect and restrict it.

Common mistakes

• Reading the version number as a security level. A 5.x or 6.x product can still pair with Just Works and accept short keys if its stack allows it. Ask which features and settings are implemented.
• Assuming LE Secure Connections covers Classic links. LE Secure Connections (4.2) protects LE pairing. BR/EDR has its own Secure Connections (4.1). A dual mode device needs both, plus CTKD restrictions.
• Patching the host and forgetting the controller. KNOB and BIAS fixes often needed controller firmware. A fully updated kernel on top of an old radio firmware may still negotiate short keys.
• Leaving pairable mode open. BLURtooth needed a device that would accept unauthenticated pairing at any time. Time limited pairing started by a user action removes that precondition.
• Turning on privacy but advertising a stable identifier. A rotating RPA does nothing if the advertising data includes a fixed serial number or name.
• Not inventorying Bluetooth stacks. When the next BlueZ or Android Bluetooth advisory lands, teams without an inventory cannot tell which products carry the affected version.

FAQ

What is the latest Bluetooth version?

As of October 2026, the newest Core Specification on the Bluetooth SIG's site is 6.3, whose specification page was published in May 2026. The SIG moved to a twice yearly release schedule in 2025, starting with 6.1 on 6 May 2025, so expect a new minor version roughly every six months.

What is the difference between Bluetooth Classic and Bluetooth Low Energy?

Classic (BR/EDR) uses 79 channels and is mainly used for audio streaming and some data transfer. Low Energy uses 40 channels, is designed for very low power, and supports broadcast, mesh, positioning and, since 5.2, LE Audio. They are separate radios; dual mode chips implement both.

Is Bluetooth 5 more secure than Bluetooth 4?

Not automatically. The big security additions came in 2.1 (Secure Simple Pairing), 4.1 (BR/EDR Secure Connections) and 4.2 (LE Secure Connections). Later versions added fixes and features such as the 5.2 key size erratum and 5.4 encrypted advertising data, but the security you get depends on the mode and settings the device actually uses.

Was the KNOB attack fixed?

Yes, in specification and products. The SIG recommended a 7 octet minimum BR/EDR key size and integrated an encryption key size erratum into Core 5.2, and vendors shipped firmware and operating system updates. Devices that never received those updates remain exposed.

What is LE Audio and do I need it?

LE Audio is audio over the Low Energy radio, using the LC3 codec and isochronous channels from 5.2. It adds Multi-Stream Audio, standard hearing aid support and Auracast broadcast. You need both a source and a sink that support it; Classic Audio keeps working alongside it.

What is Auracast?

Auracast is the SIG's name for LE Audio broadcast: one transmitter sends one or more audio streams to an unlimited number of receivers. It is used for shared listening, televisions in public places and assistive listening. Whether a broadcast is open or encrypted is up to whoever runs the transmitter.

What is Bluetooth Channel Sounding used for?

Secure distance measurement between two devices. It combines phase based ranging for centimeter level accuracy with round trip time measurement as a check against relay attacks. Target uses include digital car and door keys and item finding.

Does a resolvable private address stop Bluetooth tracking?

It stops tracking by address for LE devices that enable privacy, because the address changes periodically and only bonded devices can resolve it. It does not help if the device advertises a stable name or identifier, and Classic BR/EDR has no equivalent.

Where Safeguard fits

Safeguard does not configure Bluetooth, manage devices, scan controller firmware or monitor radio traffic, and nothing in your Bluetooth hardening depends on it. The honest connection is component inventory. BlueBorne was fixed in BlueZ, the Linux kernel and the Android Bluetooth stack, and the host side of the KNOB and BIAS responses shipped in the same kind of software. If you build Linux, Android or Zephyr based products, those stacks are open source components in your images. If you generate SBOMs for those images, or receive them from suppliers, Safeguard can ingest and analyse them, match the listed components against vulnerability databases, and show which of your products contain a given component and version. When the next BlueZ or Zephyr Bluetooth advisory lands, that is how you find the affected releases. Our post on using SBOMs to find affected products fast walks through that workflow. Controller firmware from a chip vendor still has to be updated through that vendor.

Fix it without waiting for upstream

Bluetooth hardening is mostly configuration and vendor updates, but the host stacks that carried BlueBorne and enforce the KNOB and BIAS mitigations are open source software built into device images next to every other dependency. If you build products with Bluetooth, the same patch discipline applies to BlueZ, Zephyr and Android components you compile, while radio controller firmware still has to come from your chip vendor.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency and SBOM workflows, not Bluetooth configuration. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. If you build a Linux or Zephyr based device image, the same terminal scan can run against the SBOM you generate for each firmware release, so the BlueZ or Zephyr version inside it is checked before the image ships.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. The same approve each step flow applies when the component to bump is a pinned Bluetooth stack version in a build recipe or manifest you own.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your products list a particular BlueZ or Zephyr version in their SBOMs, and get the answer from your own data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Bluetooth SIG: Core Specification 6.0
• Bluetooth SIG: Core Specification 6.1
• Bluetooth SIG: Core Specification 6.2
• Bluetooth SIG: Core Specification 6.3
• Bluetooth Core Specification 6.0, Volume 0: Version history and acknowledgments
• Bluetooth Core Specification 6.0, Volume 1: Core specification change history
• Bluetooth SIG: Core 6.0 feature overview
• Bluetooth SIG: Delivering on the bi-annual release schedule, Bluetooth Core 6.1 is here
• Bluetooth SIG: Core 6.2 feature overview
• Bluetooth SIG: Core 6.3 technical overview
• Bluetooth SIG: Bluetooth technology overview
• Bluetooth SIG: LE Audio
• Bluetooth SIG: Channel Sounding
• Bluetooth SIG: Bluetooth security
• Bluetooth SIG: Reporting security vulnerabilities
• Bluetooth SIG: Security notice on Key Negotiation of Bluetooth (KNOB)
• Bluetooth SIG: Statement on the BIAS vulnerability
• Bluetooth SIG: Security notice on cross transport key derivation (BLURtooth)
• Bluetooth SIG: Statement on BLUFFS
• Bluetooth SIG: Origin of the Bluetooth name
• NIST SP 800-121 Rev. 2 (update 1): Guide to Bluetooth Security
• CERT/CC VU#240311: Multiple Bluetooth implementation vulnerabilities (BlueBorne)
• CERT/CC VU#918987: Bluetooth BR/EDR key negotiation attacks (KNOB)
• CERT/CC VU#647177: Bluetooth BR/EDR impersonation attacks (BIAS)
• CERT/CC VU#589825: CTKD key overwrite (BLURtooth)
• NVD: CVE-2019-9506 (KNOB)
• NVD: CVE-2020-10135 (BIAS)
• NVD: CVE-2020-15802 (BLURtooth)
• NVD: CVE-2023-24023 (BLUFFS)
• KNOB researchers: Key Negotiation of Bluetooth Attack
• Daniele Antonioli: BIAS, Bluetooth Impersonation AttackS
• BlueZ: annotated main.conf
• Zephyr Project: Bluetooth host Kconfig

Last reviewed: 23 October 2026. The Bluetooth SIG now releases core specification updates twice a year; check the linked SIG pages for versions newer than 6.3.