iobewi has qualified a software verified-boot path on Espressif's S3 microcontroller. Before the processor runs an application image, the bootloader checks a pinned 3,072-bit Rivest-Shamir-Adleman (RSA) signature, the target product and board, the image length, and its Secure Hash Algorithm 256-bit (SHA-256) digest. A commit word is written last, so an interrupted update can't present a half-written proof as complete.
The useful part is the failure evidence. On real S3 hardware, the project confirmed that bad signatures, changed digests, and wrong lengths fall back to an authenticated image. It also tested signed upload, activation, confirmation, persistence, and rollback from an unconfirmed image. Continuous integration builds and checks image sizes for Espressif's C3 too, but the project labels that target as unqualified because no board test was run.
The documentation also names what this design doesn't cover: there is no hardware root of trust, permanent anti-rollback counter, key rotation, or power-loss qualification. That boundary makes the result more useful than a generic "secure boot supported" claim. Teams adopting the library can map those missing properties to their threat model before they copy the code, instead of discovering the gap during a security review.