Fixed Passkey Pairing on Peripheral without I/O

RE: Fixed Passkey Pairing on Peripheral without I/O

Masa Kawa — Tue, 13 Jan 2026 04:53:04 GMT

Thank you for your response.

We will refer to the information you provided regarding the concept of passkey and serial number.

As for the fixed passkey, we were able to implement it as follows, so we will close this inquiry:

1.Set the passkey at startup using sd_ble_opt_set.

2.When the BLE_GAP_EVT_SEC_PARAMS_REQUEST event occurs, respond with the following parameters using sd_ble_gap_sec_params_reply:

ble_gap_sec_params_t sec_param;
sec_param.bond = 0;
sec_param.mitm = 1;
sec_param.lesc = 0;
sec_param.keypress = 0;
sec_param.io_caps = BLE_GAP_IO_CAPS_DISPLAY_ONLY;
sec_param.oob = 0;
sec_param.min_key_size = 7;
sec_param.max_key_size = 16;

RE: Fixed Passkey Pairing on Peripheral without I/O

tesc — Mon, 12 Jan 2026 16:12:17 GMT

Hi,

If what you want is a serial number, then it would be better to either use the device address or let the device advertise with its serial number using manufacturer specific data in the advertising packet. That way you would find the device (based on the serial number) before you connect to it. With using passkey for this, you will have to connect first, then figure out whether or not you are connected to the correct device.

Regards,
Terje

RE: Fixed Passkey Pairing on Peripheral without I/O

Masa Kawa — Mon, 12 Jan 2026 03:06:49 GMT

I understand the security concerns.

For the device we are developing, we are not considering using random keys for security; instead, we intend to use the passkey essentially as a device serial number (by attaching the fixed passkey to the device and having the user read it).

Could you please provide a detailed explanation of how to configure ble_gap_sec_params_t and what values should be set?

Should we use sd_ble_gap_sec_params_reply() during the BLE_GAP_EVT_SEC_PARAMS_REQUEST event?

If so, what would be the appropriate parameter values?

RE: Fixed Passkey Pairing on Peripheral without I/O

Emil Lenngren — Fri, 09 Jan 2026 10:39:00 GMT

I don't know why you want this; it is explicitly discouraged by the specification, since you can brute force it in 20 attempts, see https://insinuator.net/2021/10/change-your-ble-passkey-like-you-change-your-underwear/ for an explanation. The protocol is only designed for and secure if a new randomly generated key is used for each new attempt.

RE: Fixed Passkey Pairing on Peripheral without I/O

Masa Kawa — Fri, 09 Jan 2026 01:34:19 GMT

Thank you for your response. We will refer to your guidance for configuring the passkey.

Regarding the IO Capability configuration, my understanding is that it is set via ble_gap_sec_params_t.

Could you please provide more details?
Should we configure it by calling sd_ble_gap_sec_params_reply() on the BLE_GAP_EVT_SEC_PARAMS_REQUEST event?

Also, what would be the appropriate values for ble_gap_sec_params_t in this case?

RE: Fixed Passkey Pairing on Peripheral without I/O

tesc — Thu, 08 Jan 2026 14:57:29 GMT

HI,

In nRF5 SDK you can configure a static passkey with sd_ble_opt_set(BLE_GAP_OPT_PASSKEY, &passkey_options), where &passkey_options is of type ble_opt_t and with the field gap_opt.passkey.p_passkey pointing to a uint8_t array of length 6 containing the wanted passkey. See also the ble_gap_opt_passkey_t Struct Reference.

Alternatively, instead of the above configuration, you can handle it by providing the static key with sd_ble_gap_auth_key_reply() on BLE_GAP_EVT_AUTH_KEY_REQUEST events.

Then if your device claims to be Display (BLE_GAP_IO_CAPS_DISPLAY_ONLY), and the central has Keyboard (either Keyboard Display or Keyboard Only), you will get a situation where the central must enter that static passkey for the key generation.

There are some other IO Capability combinations also triggering passkey entry on the central. For more details on the mapping from IO Capabilities to key generation method (i.e. when Passkey Entry is selected), please consult the Bluetooth Core Specification Version 6.0, Vol 3, Part H, section 2.3.5.1 Selecting key generation method, table 2.8 (the table goes over two pages). The remainder of section 2.3.5 contains the descriptions of those methods.

Regards,
Terje