Signing and device identity in practice: from first login to a signed image or a trusted device
Signing and device identity for embedded teams. Live in days, not months.
Pick your chip, update tool or identity flow and watch a team set up LAAVAT, sign a real release or issue device certificates, in about 90 seconds.
Prefer to read? Every flow above has a full step-by-step guide in our solution guides.
How it works
Day 0 is onboarding: sign in with your company login, create a product, install the reference client, fetch the public keys and anchor them on the device. Day 1 is every release: request a signature, approve it in the platform, get the signed image and verify it on the device.
The private keys stay in the HSM the whole time. Nothing changes in how your developers build, and every signature and certificate lands in the audit log, ready for CRA documentation.
For device identity, LAAVAT runs your PKI: a Root CA and issuing CAs with keys in the HSM, and IDevID certificates issued on the factory line. It can also chain under your existing root CA.
Secure boot
Nordic nRF secure boot with MCUboot
LAAVAT signs the MCUboot stage for b0 and the Zephyr application for MCUboot, both with ECDSA P-256 keys held in the HSM.
STM32H5 secure boot with OEMiRoT
Secure and non-secure images are signed in MCUboot format, and the public keys go into OBKeys once at the factory.
NXP i.MX8M: HAB, FIT, OP-TEE and RAUC signing
One product covers the HAB boot image, the kernel FIT, OP-TEE trusted apps and RAUC update bundles, with the SRK hash fused once.
NXP i.MX 9 AHAB signing with SPSDK
AHAB containers are signed with four SRK keys created in the HSM. Only the SRK hash leaves the platform.
Raspberry Pi 4 secure boot and encrypted updates
The boot image is signed for the EEPROM bootloader, and update keys are wrapped so images never reach the platform.
Zynq UltraScale+ boot image signing with Bootgen
The full boot image is authenticated against a PPK hash in eFUSEs, with PSK and SSK keys kept in the HSM.
ESP32 Secure Boot v2 and custom firmware
Digest signing sends only a hash to LAAVAT, so it fits ESP32, custom bootloaders and other formats.
Read the digest signing guide →
Device identity and PKI
Your device PKI, keys in the HSM
Create a Root CA and issuing CAs in LAAVAT, or chain them under your existing root CA. CA keys are generated in the HSM and cannot be exported.
Read the device identity guide →
Factory device identity (IEEE 802.1AR IDevID)
Each device creates its own key on the line, and the factory test PC gets its IDevID certificate in seconds with the same pip-installed reference client your developers use. The test PC runs under its own identity in your identity provider, so there are no tokens to handle. A blanket rule for the manufacturing group issues certificates without waiting, and every request is logged under the station's name.
Firmware updates
Signed Mender OTA updates
The Mender artifact manifest is signed in LAAVAT, and devices accept only artifacts signed with your key.
Encrypted RAUC updates with per-device keys
Bundles are signed and encrypted to the devices in each rollout wave. Device keys stay inside OP-TEE.
Read the encrypted RAUC guide →
Signed SWUpdate updates
Only the sw-description digest goes to LAAVAT, with raw RSA, RSA-PSS or CMS signatures.
Other formats
Certificate-based signing for kernel modules, UEFI and CMS
An HSM key with an X.509 certificate signs kernel modules, UEFI db updates and CMS-signed SWUpdate files.
Read the certificate signing guide →
Container image signing with cosign
OCI images are signed through LAAVAT and verified with cosign or a Skopeo policy on pull.
Read the container signing example →
Frequently asked questions
01
How fast can we start signing?
A trial needs nothing but a call with us. With the LAAVAT reference client, teams sign their first image on day 1.
03
Can we use our existing root CA or HSM?
Yes. LAAVAT can chain under your existing root CA and use your existing HSM.
05
How does the factory test PC authenticate?
It runs the reference client under its own identity in your identity provider, such as Microsoft Entra ID. Requests from stations in your manufacturing group are issued on the line, and each one is recorded under the station's name.
07
How does it fit into our build?
Through the reference client (a pip package and API) in your pipeline, or the LAAVAT Yocto recipes. Developers keep building the way they do today.
02
Do our private keys ever leave the HSM?
No. Signing happens inside the HSM, and only signatures and public keys come back to your build.
04
Can LAAVAT issue device certificates on the factory line?
Yes. The factory test PC requests an IDevID for each device with the LAAVAT reference client, and the device key never leaves the device.
06
How is revocation handled?
LAAVAT generates and signs your certificate revocation lists. You publish them at your own CRL distribution point.
