A boot chain can verify signatures correctly and still be bypassable. Alternate boot sources, debug state, recovery images, stale trusted keys or downgrade paths can create a valid path to code that the design was meant to exclude. The security property only holds if every transition from immutable trust to mutable firmware preserves the intended policy.
The failure is rarely in the cryptography. It is in the transitions: a bootloader that verifies its successor but not the configuration it reads, a recovery mode that accepts an older signed image, a debug state that survives into production, or a trust anchor that can be updated without verification. Each link is defensible in isolation; the chain breaks where they meet.
This is why "signature verification enabled" on a feature list says almost nothing. The meaningful question is which paths exist from reset to execution, and whether every one of them enforces the same policy.
The security property depends on several technical assumptions.
- Root of trust Where the first immutable trust decision lives, and how it is configured (OTP, fuses, ROM).
- Boot-stage verification Which stages verify the next component, and what metadata is covered by the signature.
- Alternate boot paths USB, recovery, service, fallback, external flash or removable media as routes to code execution.
- Rollback policy Whether older but validly signed images remain acceptable anywhere in the chain.
- Debug and lifecycle state Whether production settings can be weakened, bypassed or left in development mode.
- Key lifecycle How trust anchors are provisioned, replaced or revoked, and whether old keys still authorize boot.
- Verification logic Whether the implementation checks what the design assumes, including metadata and configuration.
The signature is valid; the trust policy is not.
ROM verifies the bootloader. The bootloader verifies the firmware. Every check succeeds. The recovery path then accepts an older image, validly signed by the manufacturer, but carrying a known vulnerability that was fixed two releases ago.
Signed vulnerable firmware runs. No check failed; the policy that should have excluded the image never executed on this path.
Verify the assumption in the implemented product.
We map the implemented boot chain, identify trust decisions and alternate execution paths, then test the assumptions that protect the transition from reset to trusted firmware. This can include hardware configuration, bootloader and firmware analysis, recovery testing and cryptographic review.
- New secure-boot implementation
- New MCU, SoC or bootloader
- Product moving from development to production lifecycle state
- Recovery mechanism added or changed
- Signing-key migration
- Need to verify anti-rollback behavior before release