BLE Security Modes Explained: Why Most IoT Devices Ship with No Encryption

Right now, somewhere in a warehouse, factory floor, or hospital room, a BLE sensor is transmitting data in plaintext. Not because the Bluetooth spec lacks encryption. Not because the chip can’t support it. Because the firmware was compiled from an SDK example, the GATT characteristics were left open, and nobody on the team ever configured the Security Manager Protocol. The device connects, it ships, and every byte it sends is readable by anyone with a $30 USB dongle and 5 minutes of setup.

This describes the majority of BLE IoT devices in production today.

We’re going to walk through what the BLE spec actually offers for security, map it against what gets deployed, and pick apart the specific, structural reasons the gap exists. No fixes here. Just the autopsy.

BLE Security Modes and Levels: What the Spec Actually Says

The BLE spec defines two security modes, each with multiple levels. These are GAP-level constructs that determine what protections a connection has (or doesn’t have).

Security Mode 1 is encryption-based. It’s where almost all the real-world conversation happens:

Level   Description                              MITM Protection
1       No security (no auth, no encryption)     None
2       Unauthenticated pairing w/ encryption    None
3       Authenticated pairing w/ encryption      Yes
4       Authenticated LE Secure Connections       Yes (P-256 ECDH)

Security Mode 2 is based on data signing without encryption:

Level   Description                              MITM Protection
1       Unauthenticated pairing w/ data signing  None
2       Authenticated pairing w/ data signing    Yes

Mode 2 barely exists in practice. Signed writes show up in a handful of niche applications. For everything else, Mode 1 is the only game in town.

Here’s the critical distinction that trips people up: Level 2 gives you encryption but not authentication. Your data is encrypted on the link, but you have no assurance you’re talking to the right device. An attacker who interposes during pairing gets a perfectly encrypted channel to both sides. That’s the ceiling for any device using “Just Works” pairing, which, as we’ll see, is the only option for most IoT hardware.

Level 4 was added in BLE 4.2. It uses ECDH (Elliptic Curve Diffie-Hellman) for key exchange, a real improvement over legacy pairing’s fixed Temporary Key (TK). But Level 4 still depends on the pairing method for MITM resistance. ECDH protects against passive eavesdropping. It doesn’t tell you who’s on the other end.

Level 1 is nothing. No encryption, no authentication, no signing. Raw plaintext over the air. It requires zero lines of security code. It’s the default.

BLE Pairing Methods: Where Theory Meets Hardware Constraints

The Security Manager Protocol (SMP) supports four pairing methods:

Pairing Method       Requires             MITM Protection   Typical Use
Just Works           Nothing              NO                Headless sensors
Numeric Comparison   Display on both      Yes               Phones, watches
Passkey Entry        Display + keyboard   Yes               Keyboards, locks
OOB (Out of Band)    NFC, QR, etc.        Yes               Rare in practice

Look at the “Requires” column. Numeric Comparison needs a display on both devices. Passkey Entry needs a display and an input mechanism. OOB needs a secondary channel like NFC.

A temperature sensor bolted to a pipe doesn’t have a display. A livestock tracking tag doesn’t have a keyboard. An industrial vibration monitor doesn’t have an NFC radio. For the vast majority of IoT peripherals, Just Works is the only pairing method available. The form factor dictates the security ceiling.

What does Just Works actually do? With legacy pairing (BLE 4.0/4.1), the Temporary Key (TK) is set to zero. Literally 0. The Short-Term Key (STK) derived from it is trivially crackable by anyone who captured the pairing exchange. Mike Ryan demonstrated this at USENIX WOOT in 2013, and the math hasn’t changed.

BLE 4.2 improved this. Just Works with LE Secure Connections uses ECDH key exchange, so passively sniffing the pairing exchange no longer lets you derive the Long-Term Key (LTK). But there’s still no MITM protection. An active attacker can interpose during the pairing phase, and neither side has any mechanism to verify the other’s identity.

The decision tree:

Device has display + input?
├── YES → Passkey / Numeric Comparison → Mode 1 Level 3/4 (authenticated)
└── NO
    ├── OOB channel available?
    │   ├── YES → OOB pairing → Mode 1 Level 3/4 (authenticated)
    │   └── NO → Just Works → Mode 1 Level 2 (encrypted, NOT authenticated)
    └── Security not configured? → Mode 1 Level 1 (NOTHING)

Most devices land at Level 1. The next section explains why.

Why Devices Actually Ship at Level 1: Five Compounding Failures

The gap between “Just Works pairing would at least give us encryption” and “we ship with nothing” is where the real story lives. Five causes reinforce each other.

SDK Defaults and the Path of Least Resistance

Every major BLE SoC vendor ships SDK examples where GATT characteristics are initialized with open permissions. Nordic’s BLE_GAP_CONN_SEC_MODE_SET_OPEN() is the poster child, but Espressif’s ESP-IDF, TI’s SimpleLink, and others all do the same thing. The example compiles. The device advertises. The phone connects and data flows.

Enabling encryption means configuring SMP: setting I/O capabilities, registering pairing event handlers, managing bonding storage, handling encryption failures gracefully. That’s not a line of code; it’s a subsystem.

On cost-optimized BLE SoCs in the sub-$1 range (think Telink TLSR8258 or PHY+ PHY6222), flash and RAM budgets are tight enough that fitting a full SMP implementation alongside application logic is a genuine engineering challenge.

The SDK is optimized for the demo. The demo is optimized for “it connects.”

Cross-Platform Pairing Pain

Anyone who’s shipped a BLE product with pairing enabled on both iOS and Android has stories. iOS silently caches bonding information and won’t re-pair without the user manually “forgetting” the device in Settings. Android’s behavior varies across manufacturer skins and OS versions. Pairing dialogs confuse non-technical users. Bond information gets wiped after OS updates.

Many teams have tried. They’ve enabled pairing, tested it, watched their support tickets spike, and stripped it back out. The rational response to “pairing breaks reconnection on 15% of Android devices in the field” is often “remove pairing.” I’ve seen this happen more than once.

No Regulatory Forcing Function

Wi-Fi has WPA requirements baked into certification. Medical devices have FDA guidance on wireless security. Most consumer and industrial BLE devices? Nothing. There’s no certification body checking whether your GATT characteristics require encryption. If it’s not mandated and it creates friction, it gets cut from the sprint.

The “It’s Just a Sensor” Rationalization

Temperature readings. Humidity data. Accelerometer values. Teams look at the data and conclude it’s not sensitive. But BLE characteristics often expose more than sensor readings: firmware update services (DFU), device configuration parameters, calibration data, diagnostic modes. An unencrypted DFU characteristic lets an attacker push arbitrary firmware to your device. The attack surface is almost always larger than what the team originally scoped.

Connection Latency and Power Budget

SMP pairing exchanges add round trips. On a device that wakes up for 200ms to push a sensor reading and then sleeps for 10 minutes, the overhead of a full pairing handshake feels enormous. If the bond gets lost (and it will, see above), the device has to re-pair, which means more time awake, more power burned, more battery life lost. For a device targeting 5+ years on a coin cell, this math hurts.

What This Looks Like to an Attacker

At Level 1, the exposure is total. An Ubertooth or nRF Sniffer configured with Wireshark captures every GATT read, write, and notification in plaintext. No key cracking. No exploit development. Just passive reception. The tooling is open source and well-documented.

At Level 2 with Just Works, an attacker uses something like BtleJuice to interpose during the pairing exchange. Because there’s no authentication step, neither the central nor the peripheral can detect the man-in-the-middle. The attacker establishes encrypted connections to both sides and relays (or modifies) traffic transparently.

GATTacker-style attacks are even simpler. The attacker scans the target peripheral, clones its advertisement data and GATT profile, and starts advertising with the same service UUIDs. The central connects and has no way to distinguish the clone from the real device. No pairing means no identity verification means no trust.

These aren’t theoretical. The tools are public. The hardware costs less than a nice lunch. Anyone who’s built a device with the Hubble Device SDK or any other BLE stack should understand that the default state of their air interface is a shared medium anyone can read.

The Problem is Structural

The spec makes insecurity the default. SDKs optimize for first-connection demos. Chips optimize for BOM cost. Phone OSes make pairing a UX minefield. And the market doesn’t punish the absence of encryption. All of these forces compound.

The BLE spec authors built real security into the standard: modes, levels, ECDH, authenticated pairing. But the path to “device works” and the path to “device is secure” diverge at the first line of initialization code, and every incentive pushes teams down the first path.

If your BLE device ships today, the odds are overwhelming that it’s broadcasting in the clear. The first step is acknowledging exactly why.

Hubble Network enables BLE connectivity from satellite to cloud without requiring devices to solve security at the air interface alone. See how it works →