 I would like to spend a few words on the integration of SecureBoot SecureFirmwareUpdate on STM32WB. This ST solution is available for some STM32 families and it has been recently ported on WB as well. The primary purpose is to authenticate all the user application firmware before running it. And in case of SecureFirmwareUpdate the candidate version is authenticated first before it's installed. The SBSFU can optionally provide confidentiality so the firmware can be transferred to the device in an encrypted form and it's decrypted in place during the installation process. This requires to store a key inside the device and also to provide some isolation barrier between the secret key and the untrusted user application. On STM32WB this is achieved thanks to the dual core architecture. The secrets are stored in the area of flash which is only accessible by the CM0+. The user application firmware can request to load this key into the AES periphery without actually knowing the key. This mechanism is sometimes called OPEC key or key hiding mechanism. It's possible to provision multiple keys into the secure area. One key can be used to decrypt the new firmware images and there can be optionally some other user application specific keys. The SBSFU comes with a standalone loader which is in fact based on the BLE OTA example that we have seen before. There is a version of the project for the single slot, for dual slot and also for dual slot with the open source crypto library. So let's have a look how it looks in practice. In this demonstration the WB is already provisioned with a key and SBSFU and user application is installed in the flash. If I press reset the SBSFU first validates the signature of the user application and then passes the execution to it. I will call this firmware A just to distinguish it from the new version. The user application doesn't provide any BLE interface but it lets you jump into the standalone BLE loader which is in fact the OTA example that we have seen before. It also lets you test some of the protection mechanism. I will select the option 1 to jump into the BLE standalone loader and connect to the target via the STBLE sensor app. I need to change the address where the firmware will be downloaded to respect the memory mapping of the SBSFU. And I will select the last file in the list, the one with the extension SFB which is in fact the encrypted new binary plus some metadata that contain cryptographic signature of the firmware. And I will start the download. You notice that the speed is a little lower. That's because the current SBSFU version integrates an older version of BLE OTA example. So after reboot you see the installation continues. Use the firmware, the active and download slot are swapped and we see that the signature of the new firmware is verified and now the new application B is running successfully.