How can an NCS Central pair with an nRF5 SDK Peripheral that only supports Legacy Pairing?

[Ethan]

Environment

Central

• nRF54

• NCS v3.3.0 (Zephyr Bluetooth Host)

Peripheral

• nRF52

• nRF5 SDK v15.3.0

• Existing commercial product (cannot be modified)

Problem

My nRF54 Central connects successfully to an nRF52 Peripheral and then initiates bonding.

The Peripheral is an existing product that cannot be modified, so I can only change the Central configuration.

During pairing, the Central reports:

BT_SECURITY_ERR_AUTH_REQUIREMENT (4)
"The requested security level could not be reached."

If I disable Secure Connections Only mode by setting:

CONFIG_BT_SMP_SC_PAIR_ONLY=n

the error changes to:

BT_SECURITY_ERR_UNSPECIFIED (9)
"Pairing failed but the exact reason could not be specified."

Peripheral Security Configuration

The Peripheral uses nRF5 SDK 15.3.0 Peer Manager with the following security parameters:

sec_param.bond         = true;
sec_param.mitm         = false;
sec_param.lesc         = false;
sec_param.keypress     = false;
sec_param.io_caps      = BLE_GAP_IO_CAPS_NONE;
sec_param.oob          = false;
sec_param.min_key_size = 7;
sec_param.max_key_size = 16;

Since this is an existing product, these settings cannot be changed.

Questions

• Is it possible for an NCS 3.3.0 Central to pair with a Peripheral that only supports Legacy Pairing?

• Besides setting CONFIG_BT_SMP_SC_PAIR_ONLY=n, are there any additional Kconfig options or API calls required on the Central?

• Does Zephyr/NCS disable Legacy Pairing by default in any other way?

• Has anyone successfully paired an NCS 3.3.0 Central with an nRF5 SDK Peripheral that has sec_param.lesc = false?

Any suggestions would be appreciated.

[ABlueTingInTheCloud]

Hi Ethan,

Your understanding of the callbacks is correct. security_changed and bt_conn_auth_info_cb report the result/state of the security procedure; merely registering them does not make SMP succeed or fail.

An authentication callback becomes functionally relevant when the selected association model needs application interaction — passkey, OOB, confirmation, etc. With the peripheral configuration you posted (mitm=false, lesc=false, oob=false, IO_CAPS_NONE), Legacy Just Works is the expected association model, so no user-interaction callback should be required.

NUS also does not alter SMP pairing by itself. A GATT service can indirectly trigger security if an attribute has encrypted/authenticated permissions, or if application code requests a security level before or while discovery is taking place, but replacing HRS with NUS does not change the pairing algorithm.

Since Nordic has already reproduced NCS 3.3.0 - nRF5 SDK Legacy Pairing successfully, I would stop looking for another global "enable legacy" switch and compare the actual SMP exchange in your application.

I would:

1. Remove the existing bond on both peers.
2. Enable Bluetooth/SMP debug logging.
3. Reconnect from a clean state.
4. Capture the Pairing Request, Pairing Response and Pairing Failed reason.
5. Verify that the central is really proposing no MITM/OOB requirement and that the requested level remains BT_SECURITY_L2 throughout the procedure.

If you can post the SMP log from connection through the failure, it should be possible to identify whether the rejection comes from authentication requirements, stored-key/re-pairing state, or something in the application's security sequencing.

— ABTC Open Engineering Initiative