Firmware authentication
Verify signed firmware before transferring execution.
wolfBoot Secure Boot
Authenticate firmware before execution and implement update, recovery and anti-rollback policies around the target flash and trust architecture.
Firmware authenticationTrusted boot chainAuthenticated updatesRecovery & rollback
Firmware trust chain
InputsRoot public keySigned firmware image
Engineering controlsBootloader verifiesPolicy selects imageUpdate state machine
OutputsAuthorized executionRecoverable updateControlled rollback
Boot and firmware-update control layer for supported microcontroller and embedded targets.
Secure boot protects the authenticity decision at boot. The overall product still depends on key custody, update infrastructure, runtime security and hardware trust assumptions.
wolfSSLEmbedded security
Core capabilities
Core engineering capabilities
Exact capabilities depend on the selected edition, release and deployment environment.
Portable bootloader core
Integrate through a compact hardware abstraction layer on supported targets.
Update mechanisms
Support authenticated firmware update flows appropriate to selected transport and flash layout.
Recovery handling
Design interrupted-update recovery and fallback behaviour around available storage.
Rollback policy
Control version rollback based on project-specific security and availability requirements.
wolfCrypt integration
Use cryptographic verification through wolfCrypt and applicable hardware capabilities.
Implementation workflow
From evaluation to deployment
Validate the technology in the real build, target and reporting environment before wider rollout.
- 01Define immutable trust anchor
- 02Design image and metadata format
- 03Select signing and key process
- 04Map flash and recovery slots
- 05Port boot and update interfaces
- 06Test power loss, corruption and rollback
Confirm the deployment fit
Compatibility depends on the actual toolchain, target environment, integration needs and assurance objectives.
- MCU/MPU and startup architecture
- Internal/external flash topology
- Update transport and bandwidth
- Key storage and manufacturing signing process
- Power-loss and recovery requirements
- Anti-rollback and version policy
Where the technology adds value
Well suited for
- Authenticated embedded firmware boot
- Secure field-update programmes
- Products needing recovery from interrupted updates
- Systems integrating crypto hardware for verification
Important considerations
- Secure boot does not protect vulnerable application behaviour after handover.
- Signing keys require secure generation, storage, access control and rotation.
- Update and recovery design must match the target flash architecture.
- Anti-rollback behaviour requires persistent version-state and recovery design.
Relevant engineering frameworks
IEC 62443 secure update workflowsETSI EN 303 645 update principlesISO/SAE 21434 workflowsProduct-specific secure boot requirements
Related capabilities
Extend the software assurance workflow
Explore adjacent capabilities across requirements, verification, testing and embedded security.