The one thing to know first
Secure boot on Raspberry Pi 4/5-class devices is enabled by programming one-time-programmable (OTP) fuses with the hash of your public key. According to the official usbboot documentation, once enabled it cannot be disabled, and a different key cannot be programmed.
So before enabling it on a single device:
- Generate the signing key once, store it securely (ideally in an HSM), and back it up. Losing it means you can never sign new boot images for those devices.
- Try the whole flow on a device you are willing to dedicate permanently to that key.
- On Pi 5 (BCM2712), bootloader firmware updates must be counter-signed with your key, so plan for signing bootloader updates in your release process.
rpi-sb-provisioner: automation for fleets
rpi-sb-provisioner runs on a provisioning Raspberry Pi (a Pi 5 is recommended) with a web UI. You connect target devices one after another, and it installs your OS image and security settings automatically.
| Mode | What you get | Typical use |
|---|---|---|
secure-boot |
secure boot + full-disk encryption + device-unique keys | production devices |
fde-only |
full-disk encryption + device-unique keys, no secure boot | encryption without boot restrictions |
naked |
OS installation only | development devices |
- Supported targets: Pi 5, Pi 4, CM5, CM4, Zero 2 W.
- It accepts plain
.imgfiles and IDP artefacts from rpi-image-gen, which carry partition layout and encryption metadata. - It can keep a manufacturing database (serial numbers, MAC addresses, timestamps).
- The README states that a Compute Module on its IO board only gets 900 mA from the provisioning Pi, so connect no other USB devices during provisioning.
Know the limits
- Raspberry Pi computers have no secure hardware enclave. The device-unique key in OTP is protected by the verified boot chain, but kernel code can read OTP directly, and within the running OS the key is reachable by processes with access to the firmware mailbox. Treat compromise of the running OS as compromise of that device's key.
- Encryption protects data on removed or stolen storage. It does not protect a running, compromised device.
Start with naked or fde-only during development. Switch to secure-boot only when your key management and signed update pipeline are ready.