Secure boot only proves who signed an image, not that it is safe. Four recent CVEs in FatFs, U-Boot, RAUC and UEFI (PKfail) show the three ways signed firmware fails, and the one that signing and key management actually prevent.

A signature decides whether a device accepts an update, not who can read it. Two ways to encrypt firmware updates, a shared product key or a key per device, where the plaintext and the keys exist, what one leaked key exposes, and what the CRA asks for.

Secure boot decides what may run. A signed update decides what gets installed, and its security comes down to who holds the signing key, a second signature at boot, and anti-rollback. What the CRA expects, and three questions for your own product.

Secure boot on a Linux gateway is a chain of five or six verified links, each with its own key and its own trust anchor. Count the links, count the keys, and ask of each: where is it, who may use it, is there a record.

The EU Cyber Resilience Act expects three engineering practices from connected devices: secure boot, verifiable firmware updates and a cryptographic device identity. Why they are one key-management problem, and three questions to test your own product.