BLE Security Modes and Levels: A Practical Breakdown

Why Knowing BLE Security Modes Are Important?

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.

What BLE Security Modes and Levels Actually Mean

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.

Security Mode 1: The Four Levels You'll Actually Use

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.

Choosing a Pairing Method for Your Device's I/O Capabilities

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

Legacy Pairing vs. LE Secure Connections

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.

Practical Recommendations by Product Type

  • 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.

Common Mistakes in BLE Security Implementation

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.

FAQ

What's the difference between BLE Security Mode 1 and Mode 2?

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.

Is Level 4 security always the right choice?

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.

Why would a manufacturer still use LE Legacy Pairing today?

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.

Can a simple sensor with no screen ever reach Level 4 security?

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.

Does BLE security handle privacy (address tracking) separately from encryption?

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.

Conclusion

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.

Author

Parthraj Gohil

Parthraj Gohil is the Founder and CEO of CoreFragment Technologies. He run the team of IoT developers, embedded engineers, app developers and AI engineers. With more than 10 years of industry experience, he has delivered projects across Healthcare IoT, Industrial IoT, Consumer IoT and AIoT.

Have Something on Your Mind? Contact Us : info@corefragment.com or +91 79 4007 1108

Share this blog

Share this on social channels to benefit others.