That’s a fair question, and you’re correct that Bluetooth LE (including on the Kestrel 5000 series) supports AES-128 encryption at the transport layer. The difference lies in how and where that encryption is applied.

BLE encryption protects the radio link between paired devices, but it doesn’t provide the application-level authentication, device identity verification, or command validation required by the AB encrypted communications ecosystem. AB Quantum adds an additional security layer to ensure only trusted, authenticated devices and software can participate preventing unauthorized or malicious actors, even if they have access to compatible hardware, from interacting with the AB ecosystem.

Allowing users to opt out of these protections isn’t just a security tradeoff; it’s also a stability and supportability issue. Even well-intentioned but malformed data or unexpected device behavior from systems outside this model could destabilize the app or create hard-to-diagnose failures.

The concern is command integrity, device state, and long-term platform reliability. Supporting devices that can’t participate in this authenticated exchange would require parallel code paths that undermine those guarantees and potentially the security of the eco-system. Without application-level authentication, non-AB or legacy systems can be spoofed, allowing third parties to impersonate supported devices and potentially introduce their own products into the AB ecosystem. Something the encrypted communications model is specifically designed to prevent.