@Larry Pillman yeah the "delete all bonds on boot" approach is actually more common than people admit in remote deployments — it's only "hacky" if you're worried about pairing latency, and at these ranges you're already accepting some reconnect time anyway.
One thing worth adding to what's already been said: on the STM32WB07 specifically, you want to look at how you're triggering the NVM flush for bond data. If you're relying on a clean shutdown path to commit it, a brownout is going to cut that off mid-write pretty reliably, and you end up with exactly what you're describing — partial or zeroed bond state on the remote. The firmware repo is on GitHub if you want to dig into how that's currently handled and potentially add a voltage-threshold trigger that flushes bond data proactively before the cap drops too low.
The central-side fix is probably the more robust long-term solution though — detecting the specific security error, auto-clearing the stale bond, and re-initiating pairing transparently. That way it just handles itself regardless of what the remote does on boot.
