- December 12, 2024
Not enough time? Get the key points instantly.
A team ships a BLE-connected device using the default "Just Works" pairing because it required no extra development effort and the demo worked fine. A security review months later flags the connection as unauthenticated and vulnerable to a man-in-the-middle attack - not because the team did anything wrong exactly, but because nobody made a deliberate decision about which BLE security mode and level the product actually needed.
BLE's security model is genuinely well-designed, but the specification describes what's possible, not what you should actually choose for a given product. This breakdown covers what BLE security modes and levels mean in practice, and more usefully - how to actually pick the right one for your specific device instead of defaulting to whatever requires the least code.
BLE's Generic Access Profile (GAP) defines two security modes, each addressing a different concern, with several levels of strength within each.
Security Mode 1 is about encryption and authentication - whether the connection is encrypted at all, and whether the two devices have verified each other's identity before establishing it.
Security Mode 2 is about data signing rather than encryption - the data itself isn't necessarily encrypted, but it's cryptographically signed so tampering can be detected. In practice, Mode 2 applies specifically to LE legacy connections and sees far less real-world use than Mode 1, since most modern implementations default to Mode 1's encrypted connections instead.
Every BLE connection starts at the lowest level and can be upgraded through a pairing procedure, based on what the application actually requires and what the two devices' I/O capabilities support.
This is the mode that matters for the overwhelming majority of real BLE products.
Level 1 : No Security. No encryption, no authentication. Appropriate only for connections carrying genuinely non-sensitive data where interception has no real consequence — a surprisingly small category in practice.
Level 2 : Unauthenticated Pairing with Encryption. The connection is encrypted, but neither device has verified the other's identity. This resists passive eavesdropping but not a man-in-the-middle attack. Suitable for low-stakes applications where encryption alone is the priority.
Level 3 : Authenticated Pairing with Encryption. Devices verify each other's identity before the connection is established, in addition to encryption. This is the practical floor for anything handling data a user would consider sensitive - most connected consumer products should be here or higher, not at Level 2.
Level 4 : Authenticated LE Secure Connections. The highest level, using Elliptic Curve Diffie-Hellman (ECDH) key exchange for genuinely strong authenticated encryption. This is the appropriate target for health monitoring, payment-adjacent features, or any product where a compromised connection has real safety or financial consequence.
The practical decision isn't "which level is most secure" - it's always Level 4 in the abstract. The real decision is which level matches the actual consequence of a compromised connection for your specific product, since higher levels require more complex pairing procedures and, in some cases, more device I/O capability (a display or keypad) than a simple sensor may have.
The pairing method available to reach Level 3 or 4 depends directly on what input/output capabilities your device actually has - this is a hardware constraint, not just a software choice.
Pairing method | Requires | Best for | Security level reached |
|---|---|---|---|
Just works | No display, no input | Simple sensors, no user interaction possible | Level 2 (no authentication, vulnerable to MITM) |
Passkey entry | A keypad or display + keypad on at least one device | Devices with a numeric keypad or display | Level 3-4, depending on Secure Connections support |
Numeric comparison | A display and a "yes/no" confirmation input on both devices | Devices with screens - wearables, consumer electronics | Level 4, strong MITM protection |
Out Of Band (OOB) | A secondary channel (NFC, QR code) | Devices with limited BLE I/O but another secure channel available | Level 3-4, strong protection if the OOB channel itself is trusted |
Bluetooth 4.2 introduced LE Secure Connections as a stronger replacement for LE Legacy Pairing, and the difference matters for any new product design.
LE Legacy Pairing | LE Secure Connections | |
|---|---|---|
Key generation | Temporary Key (TK) based, weaker | Elliptic Curve Diffie-Hellman (ECDH) |
Resistance to passive eavesdropping | Weaker, particularly with Just Works | Strong |
Available on | All BLE versions | Bluetooth 4.2 and later |
Recommended for new designs | No, unless supporting older hardware | Yes |
Any new product design should default to LE Secure Connections unless there's a specific requirement to interoperate with older Bluetooth 4.0/4.1 hardware that doesn't support it. There's little reason to build new firmware on Legacy Pairing today.
Simple environmental sensor with no display: Level 2 with Just Works is often defensible if the data has genuinely low sensitivity, but confirm this assumption explicitly rather than defaulting to it out of convenience.
Consumer wearable with a screen: Numeric Comparison at Level 4 is achievable given the display, and there's little reason to settle for less once the hardware supports it.
Health monitoring device: Level 4 with LE Secure Connections should be the floor, not the target — the consequence of a compromised connection is high enough to justify the additional pairing complexity.
Industrial sensor with no I/O, deployed in a controlled environment: Just Works at Level 2 may be acceptable given physical access controls already in place, but this should be a documented risk decision, not an unexamined default.
Defaulting to Just Works because it requires the least development effort. This is the single most common mistake, and it's usually a convenience decision made without evaluating what the connection is actually protecting.
Building on LE Legacy Pairing for a new product with no compatibility requirement. There's rarely a good reason to choose the weaker legacy option for hardware that supports Bluetooth 4.2 or later.
Choosing a pairing method the hardware can't actually support well. Selecting Numeric Comparison for a device with no display forces a compromise pairing method that undermines the intended security level.
Mode 1 governs encryption and authentication of the connection itself. Mode 2 governs data signing on unencrypted legacy connections, verifying data integrity without encrypting the data. Mode 1 is what the overwhelming majority of modern BLE products actually use.
It's the most secure option, but not always the practical one - a device with no display or keypad can't use Numeric Comparison, and a simple, genuinely low-sensitivity sensor may not need the added pairing complexity Level 4 requires. The right level depends on the actual consequence of a compromised connection for that specific product.
Almost exclusively for compatibility with older Bluetooth 4.0/4.1 hardware that doesn't support LE Secure Connections. For any new product design without that constraint, Secure Connections is the better default.
Not through Numeric Comparison, which requires a display. Out of Band pairing can reach Level 3-4 without a screen if a secondary channel like NFC is available; otherwise, the device is limited to Just Works or Passkey Entry (if it has a keypad), which cap out at lower authentication strength.
Yes. Random device addresses and the Identity Resolving Key (IRK) address a different concern - preventing a device from being tracked by its Bluetooth address across locations - separate from whether the connection itself is encrypted or authenticated.
BLE security modes and levels aren't a single "most secure" setting to switch on - they're a set of trade-offs between security strength, device I/O capability, and pairing complexity that need to be chosen deliberately for each product, not left at whatever default requires the least development effort.