August 11, 2026 · How-To

BLE Pairing and Bonding: Security Explained

BLE ships encrypted by default — sort of. The link layer can run with no encryption at all (Security Mode 1 Level 1), with unauthenticated encryption (Level 2), with authenticated encryption (Level 3), or with authenticated encryption plus a 128-bit ECDH-protected key exchange (Level 4). What gets your connection from Level 1 to Level 4 is the pairing process, and the most common cause of the device will not reconnect is a broken bond.

This guide covers the difference between pairing and bonding, the LE Legacy vs LE Secure Connections key exchanges, the four association models, the STK vs LTK key hierarchy, AES-CCM encryption, the random-private-address privacy model, security mode levels, and how to debug authentication failures from macOS.

If you want to pair first and understand the GATT tree your encrypted connection unlocks, our guide to GATT services and characteristics picks up exactly where this one leaves off. For connectionless BLE broadcasts that bypass pairing entirely, see iBeacon vs Eddystone.

Why Pairing Exists

Without pairing, BLE traffic is sent in the clear on the link layer. Anyone with a sniffer and a compatible capture adapter can read every GATT transaction. They can also inject their own packets if they are willing to be active. The threat model BLE assumes is therefore:

• Passive eavesdropper: an attacker who listens but does not transmit.
• Active man-in-the-middle (MITM): an attacker who relays, modifies, or injects packets between the two legitimate devices.
• Tracking: an attacker who follows a device across space by observing its stable MAC address.

Pairing addresses the first two threats by establishing an encryption key. The Random Private Address (RPA) mechanism addresses the third.

Pairing vs Bonding

The two words get used interchangeably but they are distinct:

• Pairing is the in-session exchange where two devices negotiate an encryption key and turn on encryption for the current connection. After the central and peripheral complete pairing, the link is encrypted for the rest of that connection.
• Bonding is pairing plus persistent storage. Both devices save the long-term key (LTK) and associated identity information (IRK, identity address) to non-volatile memory. On reconnect, they skip the pairing exchange and re-encrypt directly from the stored keys.

A paired-but-not-bonded connection drops back to plaintext every time it disconnects. Many peripherals will not even let you re-pair without first deleting the bond on the central side, which is a frequent source of won't-reconnect bugs.

Secure Simple Pairing (SSP)

BLE 4.0 introduced Secure Simple Pairing (SSP) to replace the old BR/EDR-style fixed PIN exchange. SSP has two phases:

1. Pairing Feature Exchange: the central and peripheral exchange their capabilities — IO capabilities (display, keyboard, none), whether they support LE Secure Connections, whether they have an out-of-band key available, and the maximum encryption key size (7 to 16 bytes).
2. Authentication and Key Generation: based on the agreed association model (Just Works, Numeric Comparison, Passkey Entry, Out of Band), the two devices perform a key exchange and produce a short-term key (LE Legacy) or a long-term key directly (LE Secure Connections).

SSP is simple from the user's perspective; under the hood it is a three- or four-message protocol with cryptographic commitments.

LE Legacy vs LE Secure Connections

The most consequential design choice in BLE security happened in version 4.2: the introduction of LE Secure Connections (LESC) alongside the original LE Legacy Pairing.

LE Legacy Pairing produces a temporary key (TK) through one of three mechanisms: Just Works (TK = 0), a 6-digit Passkey (TK derived from the 20-bit passkey), or Out of Band (TK delivered via NFC, QR code, etc.). Both devices then derive a short-term key (STK) from the TK and a random number exchange, and use the STK to encrypt the link. The fatal problem: the TK is short — 0 bits for Just Works, 20 bits for the passkey. A passive attacker who records the pairing exchange can brute-force the TK offline and decrypt the entire session. For Just Works, no brute forcing is even needed; TK = 0 is known.

LE Secure Connections (LESC) replaces the symmetric TK exchange with an Elliptic Curve Diffie-Hellman (ECDH) key agreement on the P-256 curve. Each side generates an ephemeral key pair, exchanges public keys, computes the shared secret DHKey, and uses it (with commitments F5, F6) to derive the LTK directly. A passive attacker observing the exchange cannot recover DHKey without solving the elliptic-curve discrete logarithm problem, which is intractable on current hardware.

LESC is mandatory in BLE 5.0 and later profiles and strongly recommended everywhere both devices support it. The remaining risk in LESC is an active MITM during pairing, which the association models below are designed to defeat.

Association Models

The association model is how the two devices verify each other's identity during pairing and detect an active MITM.

Just Works

Just Works performs no MITM protection. The two devices exchange public keys (in LESC) or TK = 0 (in Legacy) and proceed. There is no user interaction. Use it only when the threat model excludes active attackers — for example, a peripheral that has no display or keyboard and is being paired in a physically private setting. Just Works is secure against passive eavesdropping under LESC, but it provides zero protection against an active relay.

Numeric Comparison

Numeric Comparison is LESC-only (BLE 4.2+). Both devices compute a 6-digit confirmation value from the ECDH exchange and display it. The user confirms yes on both devices if the numbers match. A MITM cannot make both displays match without breaking the underlying ECDH commitment, so a matching number is strong evidence that no MITM is present. This is the recommended association model for devices with a display and a yes/no button.

Passkey Entry

A 6-digit passkey is shown on one device and entered on the other. Each digit is committed round-by-round (20 rounds), which raises the cost of an active attack but does not eliminate it entirely under LE Legacy. Under LESC, the passkey is combined with the ECDH exchange and the resulting protection is strong. Use Passkey Entry when one device has a display and the other has a keyboard (for example, a phone and a keyboardless peripheral).

Out of Band (OOB)

The TK or LESC commitment is delivered over a separate, mutually authenticated channel — typically NFC or a QR code scanned between the two devices. OOB inherits the MITM protection of the out-of-band channel. It is the strongest association model when both devices support it, and it is mandatory for some profiles (for example, mesh provisioning).

Key Hierarchy: STK vs LTK

Under LE Legacy Pairing:

• TK (Temporary Key): 128-bit, but low-entropy (0 bits for Just Works, 20 bits for passkey). Ephemeral.
• STK (Short-Term Key): 128-bit, derived from TK and a random number exchange. Used to encrypt the link for the current connection.
• LTK (Long-Term Key): 128-bit, generated by the peripheral and distributed to the central over the encrypted link. Stored by both for re-encryption on reconnect.

Under LE Secure Connections:

• LTK: 128-bit, derived directly from the ECDH shared secret (DHKey). No STK or TK intermediate. Stored by both for re-encryption on reconnect.

The LTK is what makes bonding possible. Lose the LTK and you must re-pair.

Encryption (AES-CCM)

Once the LTK (or STK) is in place, both sides encrypt the link using AES-CCM with a 128-bit key derived from the LTK and a per-connection session nonce (the IV is derived from the master's and slave's random contributions). Each packet carries a 1-byte to 4-byte MIC (Message Integrity Check) — typically 1 byte at the ATT layer but 4 bytes at the link layer. The MIC authenticates both the packet's integrity and its origin.

Replay protection comes from a 39-bit packet counter on the master and a 39-bit counter on the slave. The MIC fails if the counter is out of sequence, so an attacker cannot replay a previously captured packet without invalidating the MIC.

Privacy: Random Private Addresses and IRK

A BLE device that always advertises its public MAC address is trivially trackable across space. The BLE privacy feature replaces the public address with a Random Private Address (RPA) that changes on a schedule (default every 15 minutes).

There are two flavors:

• Non-resolvable private address: random, changes frequently, no way to link back to the public identity. The peer just sees a new address every time.
• Resolvable private address (RPA): derived from a 128-bit Identity Resolving Key (IRK) and a 24-bit random number, using the ah cryptographic function (AES-based). A scanner that knows the IRK can verify that the RPA belongs to the same device, but an observer who does not know the IRK cannot link two RPAs to the same device.

The IRK is exchanged during pairing and stored as part of the bond. A bonded central can resolve the peripheral's RPAs transparently and reconnect without the user noticing the address change.

Authentication vs Authorization

These two terms are easy to confuse:

• Authentication verifies who the peer is. In BLE, this happens at pairing time (the ECDH exchange and the association model together authenticate the identity).
• Authorization decides what an authenticated peer is allowed to do. A characteristic can require authenticated access (Level 2+) or authorized access (a per-characteristic authorization callback on the peripheral that the implementer writes).

A characteristic that requires authenticated access can be read or written by any bonded peer. A characteristic that requires authorized access can be read or written only by an authenticated peer that the peripheral's application code has explicitly authorized.

Security Mode 1, Levels 1 to 4

BLE defines Security Mode 1 with four levels:

• Level 1 — No security: no authentication, no encryption. Open access.
• Level 2 — Unauthenticated pairing with encryption: pairing without MITM (Just Works), link encrypted with the LTK.
• Level 3 — Authenticated pairing with encryption: pairing with MITM protection (Numeric Comparison, Passkey, or OOB), link encrypted.
• Level 4 — Authenticated LE Secure Connections pairing with encryption: LESC with 128-bit key, link encrypted with the ECDH-derived LTK.

Each GATT operation declares its required security level. The peripheral returns an ATT error (Insufficient Authentication, 0x05) if the link does not meet the requirement. To see where these requirements live in the data model, see our GATT services and characteristics guide.

Debugging Auth Failures on macOS

Most BLE auth issues fall into a small set of cases:

• Wrong PIN / wrong passkey: entered on one side but not the other. SMP (the Security Manager Protocol) aborts after a few mismatches. Retry the pairing.
• Missing bond after factory reset: one device's bond was cleared (factory reset, settings toggle, app uninstall). The other device still holds the LTK and waits for an encrypted packet that never arrives. Delete the bond on both sides and re-pair. On macOS, remove the device from System Settings > Bluetooth; on iOS, Settings > Bluetooth > the (i) > Forget This Device.
• MITM mismatch on association model: one side is configured for Numeric Comparison, the other for Just Works. Pairing fails at the commitment step. Align the association model on both sides.
• SMP timeout (30 seconds): the Security Manager Protocol has a 30-second timeout. If either side does not respond within 30 seconds of an SMP PDU, pairing aborts with a timeout reason code. Look for a peripheral that is too slow to respond, often because the application is busy on another task.
• Key size mismatch: the central supports a 16-byte key, the peripheral only 7 bytes. The negotiated size is the minimum, and some profiles reject anything below 16 bytes. Align the key size on both sides.
• IRK / RPA mismatch: the peripheral uses an RPA that the central cannot resolve because the IRK stored in the bond is stale (after a re-flash, for example). The central will not even attempt to connect. Delete and re-bond.

A native macOS tool like MacTools BLE Inspector surfaces the connection log — pairing attempts, bond status, SMP failures with reason codes — so you can see which of the above actually happened rather than guessing from the device's behavior. For more on the broader macOS BLE debugging workflow, see BLE Debugging on macOS.

LE Legacy vs LE Secure Connections

Frequently Asked Questions

What is the difference between pairing and bonding in BLE?

Pairing is the in-session process where two devices exchange cryptographic keys and set up encryption. Bonding is pairing plus the storage of those keys in non-volatile memory so the devices can reconnect and re-encrypt without repeating the pairing exchange. A paired-but-not-bonded device must re-pair every time the connection drops.

Should I use LE Legacy Pairing or LE Secure Connections?

Use LE Secure Connections (LESC) whenever both devices support it (BLE 4.2 or later). LESC performs key exchange over an Elliptic Curve Diffie-Hellman (P-256) channel, which protects against passive eavesdropping. LE Legacy Pairing uses a temporary key (TK) that can be brute-forced or sniffed for Just Works and 6-digit passkey cases, and is considered broken for any threat model that includes a passive attacker.

Why does my previously paired BLE device refuse to reconnect?

The most common cause is a missing bond on one side. If the central or peripheral deleted the stored long-term key (LTK) through a factory reset, a setting toggle, or because the bond was never actually saved, the device that still holds the key will fail silently at the encryption step. Delete the bond on both devices and re-pair. On macOS, removing the device from System Settings then Bluetooth deletes the bond.

Does BLE encryption protect against active man-in-the-middle attacks?

Only with an authenticated association model. Just Works has no MITM protection: an active attacker can relay pairing messages and observe or inject traffic. Numeric Comparison, Passkey Entry, and Out of Band (OOB) all provide MITM protection by verifying that no attacker is in the middle, provided the LE Secure Connections ECDH exchange is used. Without LESC, even Numeric Comparison is vulnerable to active attacks.

Further Reading

• BLE Debugging on macOS: nRF Connect Alternatives That Actually Work
• BLE GATT Services and Characteristics Explained: How Every BLE Device Is Structured
• iBeacon vs Eddystone: BLE Beacon Formats Compared
• Industrial Protocol Comparison: Modbus, OPC-UA, MQTT, BLE, and More