CONFIG_FLASH_ENCRYPTION_ENABLED=y
CONFIG_FLASH_ENCRYPTION_MODE_RELEASE=y

espsecure.py generate_signing_key --keyfile signing_key.pem
espsecure.py sign_data --keyfile signing_key.pem   --version 2 firmware.bin --output firmware_signed.bin

1. Download via HTTPS with cert pinning
2. Verify SHA-256: computed_hash == twin.desired.ota.sha256
3. Verify signature: esp_secure_boot_verify_signature()
4. Only then: esp_ota_set_boot_partition()
// If any step fails: abort, report failure to cloud

Secure Element Integration for Firmware Signing Keys

The firmware signing private key is arguably the most sensitive key in your entire IoT product security architecture. If an attacker obtains it, they can sign malicious firmware that will pass secure boot verification on every device in your fleet. This key should never exist in a file on a developer’s laptop or a CI/CD server’s filesystem.

Store firmware signing keys in dedicated HSMs (Hardware Security Modules) for production signing pipelines. For development, a YubiKey or similar FIDO2 security key with PIV support provides a practical middle ground — signing operations happen inside the hardware key, which cannot be exported. Integrate HSM signing into your CI/CD pipeline (GitHub Actions, Azure DevOps) using PKCS#11 provider libraries — your build pipeline requests signatures from the HSM without ever accessing the raw key material.

Anti-Rollback Protection

Secure boot prevents running unsigned firmware, but it does not by itself prevent an attacker from downgrading a device to an older, vulnerable firmware version (if they have a valid signed image of the old firmware). Anti-rollback protection uses a monotonic counter in eFuse: each new firmware version increments the counter, and the bootloader refuses to boot any firmware signed for a lower version number than the current counter value.

CONFIG_BOOTLOADER_APP_ANTI_ROLLBACK=y
CONFIG_BOOTLOADER_APP_SEC_VER=1  # increment with each release

Anti-rollback is irreversible by design — once a device has booted firmware version N, it cannot be downgraded to N-1. This means your OTA pipeline must never distribute older firmware to devices that have already updated. Build your OTA management system to track the firmware version of every device and enforce version ordering.

Debugging in a Secure Environment

JTAG debugging is disabled by secure boot in RELEASE mode, which complicates post-production debugging of firmware issues. The workaround is comprehensive logging to a secure, tamper-evident log store — both a local ring buffer in NVS and cloud logging via MQTT. When a production device exhibits unexpected behaviour, the logs are your only diagnostic window. Design your logging system to capture enough context to diagnose issues remotely, without logging sensitive data (cryptographic material, personal information, or credentials).