The Link Most Products Leave Open

Bluetooth Low Energy is the default connection between a phone app and a consumer device, and it is routinely the weakest part of the system. Teams harden the cloud API with TLS and OAuth, then expose an unauthenticated GATT characteristic that unlocks the door, changes the dose, or dumps stored data to anyone within 30 feet with a $20 dongle and free software.

The attack surface is not theoretical. Off-the-shelf tools sniff and replay BLE traffic without any special skill, and published teardowns of smart locks, medical accessories, and fitness devices have repeatedly found no authentication beyond "you connected, therefore you are the owner." Getting this right adds perhaps two to four weeks of firmware and app work if planned early, and is very expensive to retrofit once units are in the field.

What You Are Actually Defending Against

Name the threats before choosing mechanisms, because different products care about different ones.

  • Passive eavesdropping. An attacker records the radio traffic. Matters when the payload is health data, location, credentials, or anything covered by privacy law.
  • Man-in-the-middle during pairing. A device impersonates yours during the one moment keys are exchanged, and thereafter reads and modifies everything.
  • Unauthorized connection. Anyone in range connects and writes to a characteristic. This is the single most common real-world flaw and it needs no cryptography to exploit.
  • Replay. A captured "unlock" or "dispense" packet is retransmitted later.
  • Cloned or spoofed device. A counterfeit unit presents your GATT profile and harvests user credentials or account bindings.
  • Tracking. A static advertising address lets anyone follow the user, which is a privacy failure even when no data leaks.

Use What the Protocol Already Gives You

Bluetooth 4.2 and later provide LE Secure Connections, which uses ECDH key agreement and defeats passive sniffing of the pairing exchange. Require it and refuse to fall back to LE Legacy Pairing, which is broken and still widely enabled by default.

Man-in-the-middle protection depends on the association model, and that depends on your hardware. Just Works provides encryption but no MITM protection, because there is nothing binding the connection to the physical device. Passkey Entry with a six-digit code shown on a display, or Numeric Comparison where both sides show a number, does provide it. Out-of-Band pairing, where the key material comes from an NFC tap or a QR code printed on the device, is both the most secure and the best user experience.

That is an industrial design decision as much as a firmware one. A product with no display and no keypad cannot do Passkey Entry, so if MITM resistance matters, budget for a display or an OOB channel during enclosure design rather than discovering the gap at firmware integration. Bond storage is the other half: keys must survive reset, and the device needs a bounded bond table with a defined eviction policy.

Do Not Trust the Channel Alone

Even a perfectly paired link only proves that some phone completed pairing. It does not prove the app is yours, that the user is authorized, or that a command is fresh. Serious products add an application layer on top of the encrypted link.

  • Challenge-response on connect. The device sends a random nonce, the app returns an HMAC computed with a shared or account-derived key, and the device unlocks its command characteristics only on success. Without this, GATT writes are open to anyone who connects.
  • Per-device secrets, never a global key. A single key shared across the whole fleet means one extracted device compromises every unit ever sold. Provision unique keys on the production line, as covered in secure device provisioning.
  • Anti-replay. Monotonic counters or nonces in every command, with the device rejecting anything it has already seen or anything out of window.
  • Payload integrity. A MAC over the command and its parameters so a flipped bit or an altered value is rejected rather than executed.
  • Ownership binding through the cloud. Claiming a device to an account should be a server-mediated operation, so a resold or stolen unit can be unbound and rebound under control.

These mechanics are the device-side counterpart to the platform practices in IoT security for connected products.

Security Starts Inside the Product

A radio link is only as trustworthy as the firmware behind it. Three firmware-side controls do most of the work.

Lock the debug port. An open SWD or JTAG header lets anyone with the device in hand read out flash, including your keys and your entire application. Set the readout protection fuses in production and verify on a sample of shipped units, not just on the bench. The tooling context is in embedded debugging tools.

Verify what you run. Signed images with a hardware root of trust prevent an attacker from flashing modified firmware that simply removes your authentication, which is the practical purpose of secure boot and firmware encryption.

Assume you will need to patch. Vulnerabilities are found after launch, always. A signed, resumable, rollback-protected update path is a security control, not a convenience feature, and the failure modes are covered in OTA firmware updates. Also validate every incoming GATT write for length and range: buffer overruns in characteristic handlers are a classic embedded remote-code path.

Privacy Is Part of the Threat Model

Enable resolvable private addresses so the advertising address rotates, typically every 15 minutes, instead of broadcasting a permanent identifier. Keep the advertising payload minimal: no serial numbers, no user names, no health state. Anything in an advertisement is public by definition.

Then treat what you collect as regulated data, because it often is. Health, location, and household data pull in GDPR, CCPA, and sometimes HIPAA obligations, addressed in privacy compliance for connected products. Medical devices face an explicit and enforced FDA expectation for premarket cybersecurity documentation, including a software bill of materials, spelled out in FDA cybersecurity requirements.

Checklist Before You Release

Run this list against a production unit, not a development board. LE Secure Connections required and legacy pairing refused. Association model matched to the actual threat, not defaulted to Just Works. Unique per-device key provisioned at manufacture. Challenge-response gating every state-changing characteristic. Replay counters in place. Debug port locked and verified on shipped hardware. Secure boot enabled with production keys. Advertising address randomized and payload stripped. A written procedure for revoking a compromised device. Finally, pay an outside firm for a few days of BLE penetration testing before mass production; at $5,000 to $15,000 it is far cheaper than a firmware recall.

Have Your Link Reviewed Before It Ships

Projects House reviews BLE security across firmware, app, and provisioning, then specifies the fixes that fit your hardware rather than a generic checklist. Send your device type, Bluetooth stack, and launch timing through our contact form.