> Markdown version of https://docs.laavat.io/solutions/ from the LAAVAT PKI and Signing Platform documentation. All pages: https://docs.laavat.io/llms.txt

# Solutions

Reference designs for putting LAAVAT into a real product. Where the
[signing and encryption](https://docs.laavat.io/usage/signing-encryption/signing-encryption/)
pages document one operation at a time, these describe a **complete pattern**:
which operations to configure, how they fit together, and how to verify the
result before you have hardware in front of you.

Each guide covers the same ground:

- what the design achieves, and what each component trusts
- the LAAVAT product and operations that anchor it
- the signing or issuance flow, step by step
- how to verify the output off-device, and where that stops being enough

## Secure boot

Making a device run only firmware you authorised, from the first instruction
after reset.

<div class="grid cards" markdown>

-   __CRA-ready nRF devices__

    ---

    Nordic nRF52840 with b0/NSIB, MCUboot and a Zephyr application, optionally
    with TF-M. Two HSM-held ECDSA-P256 keys anchor a three-stage chain.

    [Read the guide](https://docs.laavat.io/solutions/cra-ready-nrf/)

-   __CRA-ready STM32H5 controllers__

    ---

    STM32H5 with ST's OEMiRoT, an immutable MCUboot that verifies the secure
    and non-secure application images. Two HSM-held ECDSA-P256 keys, one per
    image, with public keys provisioned into the chip's OBKeys.

    [Read the guide](https://docs.laavat.io/solutions/cra-ready-stm32h5/)

-   __CRA-ready i.MX8M gateways__

    ---

    NXP i.MX8M with HAB from ROM, a signed kernel FIT, OP-TEE Trusted
    Applications, and RAUC update bundles under your own CA — one product,
    four operations.

    [Read the guide](https://docs.laavat.io/solutions/cra-ready-imx8m/)

-   __CRA-ready Raspberry Pi gateways__

    ---

    Raspberry Pi 4 with signed boot from the EEPROM bootloader, update images
    encrypted under a product key held in a secure element, and a signed
    update manifest — three HSM-held keys.

    [Read the guide](https://docs.laavat.io/solutions/cra-ready-raspberry-pi/)

-   __CRA-ready Zynq UltraScale+ gateways__

    ---

    AMD Zynq UltraScale+ MPSoC with Bootgen run as a platform operation:
    every partition signed with PSK and SSK keys held in the HSM, anchored in
    the PPK eFUSEs.

    [Read the guide](https://docs.laavat.io/solutions/cra-ready-zynq-ultrascale/)

</div>

## Update delivery

Making a device accept only updates you signed, for the whole of its supported
life.

<div class="grid cards" markdown>

-   __CRA-ready Mender OTAs__

    ---

    Signed `.mender` artifacts delivered over Mender's OTA channel, with the
    manufacturer's signing key held in the HSM and verified on every device.

    [Read the guide](https://docs.laavat.io/solutions/cra-ready-mender-ota/)

-   __Encrypted RAUC updates__

    ---

    RAUC `crypt` bundles that only the devices of one rollout can read: a
    per-device key generated in OP-TEE, a certificate from a dedicated Sub CA,
    and bundles signed and encrypted per rollout.

    [Read the guide](https://docs.laavat.io/solutions/encrypted-rauc-per-device-keys/)

</div>

## Device identity

Making each device individually authenticable, from the factory through its
whole deployed life.

<div class="grid cards" markdown>

-   __Trusted device identities__

    ---

    An IDevID birth certificate issued at manufacturing over REST, and an
    LDevID operational certificate enrolled in the field over EST — the
    manufacturer and operator PKIs behind IEEE 802.1AR.

    [Read the guide](https://docs.laavat.io/solutions/trusted-device-identities/)

</div>

More designs will be added here. If the platform, update system or identity
scheme you are working with is not covered yet, the underlying operations are
usually the same — see
[Secure boot and CRA](https://docs.laavat.io/cra-compliance/secure-boot-cra/) for what LAAVAT
signs, and get in touch about your target.

## How this relates to CRA compliance

These guides show the mechanism; the
[CRA Compliance](https://docs.laavat.io/cra-compliance/) section explains the obligation.
Secure boot, signed updates and device identity are three parts of the same
requirement — a device has to run only authorised firmware, keep accepting
authorised fixes for its supported life, *and* be individually identifiable so
that access to it can be controlled — and together they are what make
"vulnerabilities can be fixed" and "unauthorised access is prevented" true
rather than theoretical.

Building a device this way does not by itself make a product CRA compliant. The
[Annex I mapping](https://docs.laavat.io/cra-compliance/annex-i-mapping/) sets out which
requirements the platform supports and which remain yours.