TF-M: Provisioning image

Running the provisioning image sample will initialize the provisioning process of a device in a manner compatible with Trusted Firmware-M (TF-M). This sample does not include a TF-M image, it is a Zephyr image intended to be flashed, run, and erased before the TF-M image is flashed.

After completion, the device is in the Platform Root-of-Trust (PRoT) security lifecycle state called PRoT Provisioning. For more information about the PRoT security lifecycle, see Arm’s Platform Security Model 1.1 defined in the Platform Security Architecture (PSA).

When built for the nrf5340dk_nrf5340_cpuapp target, this image by default also includes the TF-M: Provisioning image for network core sample as a child image for the network core (nrf5340dk_nrf5340_cpunet target). The child image demonstrates how to disable the debugging access on the network core by writing to the UICR.APPROTECT register.


The following development kits are supported:

Hardware platforms


Board name

Build target

nRF9160 DK




nRF5340 DK




The sample also requires the following libraries to generate and store the master key encryption key (MKEK) and the identity key into the key management unit (KMU):


Once the required identity key is provisioned on the device, the UICR should not be erased by ERASEALL for example, as that removes the identity key from the system.


The PSA security model defines the PRoT security lifecycle states. This sample performs the transition from the PRoT security lifecycle state Device Assembly and Test to the PRoT Provisioning state.

PRoT Provisioning is a state where the device platform security parameters are generated. This enables a TF-M image to transition to the PRoT security lifecycle state Secured at a later stage.

The sample performs the following operations:

  1. The device is verified to be in the Device Assembly and Test state.

  2. The device is transitioned to the PRoT Provisioning state.

  3. Random hardware unique keys (HUKs) are generated and stored in the key management unit (KMU).

  4. A random identity key of type secp256r1 is generated and stored in the KMU.

  5. The identity key is verified to be stored in the KMU.

The hardware unique keys (HUKs) include the master key encryption key (MKEK) and the master key for encrypting external storage (MEXT).

The identity key is stored in the KMU in encrypted form using the master key encryption key (MKEK). The identity key is used as the Initial Attestation Key (IAK) as described in the PSA security model.


See Configuring your application for information about how to permanently or temporarily change the configuration.

Building and running

This sample can be found under samples/tfm/provisioning_image in the nRF Connect SDK folder structure.

To build the sample with Visual Studio Code, follow the steps listed on the How to build an application page in the nRF Connect for VS Code extension documentation. See Building and programming an application for other building and programming scenarios and Testing and debugging an application for general information about testing and debugging in the nRF Connect SDK.


After programming the sample to your development kit, complete the following steps to test it:

  1. Connect to the kit that runs this sample with a terminal emulator (for example, PuTTY). See How to connect with PuTTY for the required settings.

  2. Reset the kit.

  3. Observe the following output:

    Successfully verified PSA lifecycle state ASSEMBLY!
    Successfully switched to PSA lifecycle state PROVISIONING!
    Generating random HUK keys (including MKEK)
    Writing the identity key to KMU

    If an error occurs, the sample prints a message and raises a kernel panic.


The following libraries are used: