BLE Bond Storage Limits: Eviction, Factory Reset and Lost-Key Recovery

Capacity is a product policy, not just a build constant

A BLE product can connect successfully to a new phone and still fail to retain the relationship across reboot. It can also appear to “forget” an owner after a service technician pairs another device. Treat bond storage as a finite, security-relevant resource with an explicit admission and removal policy. This guide uses Bluetooth Core 6.0 as a deliberate protocol baseline and Zephyr 3.7.0 as an implementation example. It does not imply that either is the newest available version or that all stacks expose identical storage behavior. The central decision is who may occupy a bond slot, what happens at capacity, and how a legitimate owner recovers from a one-sided loss of keys. For qualification, consult the SIG’s Core 6.0 page and mandatory updates; this engineering guide is not a compliance checklist.

Separate connection, pairing, bonding and ownership

A connection creates a communication link. Pairing establishes security material and properties; bonding retains the applicable relationship for later use. Core 6.0 Security Manager describes bonding flags and key distribution, but it does not prescribe a universal number of stored phones for a product. Application ownership is another concept: a cryptographically paired peer is not automatically entitled to change every product setting. Keep an authorization record separate from low-level bond state, linked through a supported identity mechanism. Do not use a current advertising address as a permanent owner identifier when privacy addressing is in use. A user-interface label such as “paired” should not conceal whether the durable save actually succeeded.

Inspect the compiled policy rather than its default

In Zephyr v3.7.0 host Kconfig, BT_MAX_PAIRED bounds the stored peer count, and BT_KEYS_OVERWRITE_OLDEST can replace an eligible old key when storage is full. The documented selection excludes keys currently in use. Read the product’s generated configuration rather than assuming an upstream default. Also distinguish host bond capacity from controller resolving-list capacity, flash allocation and maximum simultaneous connections. Increasing one does not guarantee the others grow with it. Record the settings backend and boot-time loading sequence, because a RAM-only relationship can look correct until power cycles. The required deliverable is a versioned storage-policy table, not merely a larger compile-time number.

Choose a deliberate full-capacity behavior

Three plausible product policies are refusing new bonding until an owner removes a peer, explicit owner-approved replacement, or a documented automatic eviction rule appropriate to the risk. For an access-control product, silently evicting the least recently used owner can be unacceptable even if it is convenient for a demo. Define whether service accounts, emergency owners or active sessions are protected. Do not let an unauthenticated nearby device force eviction simply by initiating pairing repeatedly. Gate new enrollment with an appropriate physical or authenticated administrative workflow and a bounded enrollment window. When the store is full, report that condition clearly instead of presenting the failure as a wrong passkey.

Reconcile application records with bond deletion

Zephyr 3.7.0 exposes bt_foreach_bond and bt_unpair for enumeration and removal, while its connection-management callbacks include bond_deleted. These are examples of hooks through which the application can reconcile peer metadata; they are not permission to remove every peer on an ordinary connection error. Preserve the local identity parameter when a product uses multiple identities. Design deletion so a crash cannot leave an authorization record that refers to a removed relationship or recreate a deliberately revoked peer on the next boot. Handle storage failure explicitly. Do not claim that erasing the peripheral’s bond automatically removes the phone’s OS record or a separate cloud ownership record.

Recover one-sided key loss without weakening admission

If one side was reset or its bond was removed, the other may still attempt to reuse old security material. Repeated generic reconnects may therefore fail even though the radio path is sound. Diagnose the security event and each side’s known bond state before proposing repair. A legitimate recovery flow can ask the owner to remove the stale phone-side record and enter the device’s authorized enrollment mode, then establish a fresh relationship. It should not fall back to an open control characteristic or silently accept weaker security. Provide platform-specific instructions only after verifying the target OS behavior. Preserve unrelated bonds unless the owner deliberately requested a full factory reset.

Define factory reset as a set of separate effects

Specify whether reset removes bond keys, privacy identity material, application ownership, user data and network settings. These may live in different stores and require different API calls. Document which information the owner must re-enter and whether remote account unlinking is a separate action. A reset should have an explicit physical or authenticated trigger and a clear completion signal. Test interrupted reset and boot recovery so a partially cleared store cannot leave the product in an ambiguous enrollment state. Avoid recording keys, passkeys or raw security database dumps in support logs. A peer count, local identity index, storage error and short-lived support identifier usually provide a safer diagnostic starting point.

Test the boundary and the recovery story

For configured capacity N, validate enrollment at N−1, N and N+1 peers, with an eligible old peer disconnected and another peer actively in use. Then reboot, interrupt a bond save, delete only one side’s record, revoke a peer, and execute the documented factory-reset flow. Check both security outcome and the user-facing explanation. Require that authorized owners can regain access, unrelated peers remain intact under a targeted repair, and denied enrollment cannot force a destructive eviction. These are proposed tests, not completed phone or flash measurements. The release gate is a predictable lifecycle from admission through persistence to revocation, with a recovery procedure support staff can follow without asking customers to weaken security.