https://devzone.nordicsemi.com/f/nordic-q-a/48171/bonding-in-dfu-bootloaderI have found many questions regarding passing bonding information from the application to the bootloader (e.g. https://devzone.nordicsemi.com/f/nordic-q-a/34497/dfu-with-bonds-and-nrf52810 ) and we already have Buttonless DFU working in several implementationsen-USTelligent Community 13Wed, 05 Jun 2019 12:55:00 GMThttps://devzone.nordicsemi.com/thread/191118?ContentTypeID=1Wed, 05 Jun 2019 12:55:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:97c685f6-41aa-441a-a178-0debab6b4bb5ilnadi<p>Thank you.&nbsp; This will simplify the design.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/191084?ContentTypeID=1Wed, 05 Jun 2019 11:52:23 GMT137ad170-7792-4731-bb38-c0d22fbe4515:a3995f5c-b309-446d-82b3-6f3a2db99698Kenneth<p>Hi,</p> <p>I do not see any security improvements of having the bootloader support bonding. The data you are transferring is in any case available to &quot;read&quot; by various means (e.g. either by someone sniffing communication when bonding and/or by someone just get the hex by other means).&nbsp;The best approach is to physically have a button the user must press to perform OTA, and then only when someone have physically access can they trigger OTA, you may still use signing of the hex file to ensure that only valid OTA will be performed.</p> <p>Best regards,<br />Kenneth</p><div style="clear:both;"></div>