Secure Boot in Production: How to Protect Signing Keys and Provision Devices Securely

Secure boot is often straightforward to demonstrate on a development board. Generate a key pair, sign the firmware, enable secure boot, and verify that the device boots correctly.

Production is a different story.

When hundreds or thousands of ESP32 devices move through a manufacturing line, the challenge is no longer just verifying a firmware signature. It is protecting signing authority, provisioning the correct trust anchor, managing irreversible eFuse settings, and ensuring that a compromised manufacturing station cannot compromise an entire product fleet.

I believe one of the most important questions to answer before mass production is this:

How do we establish trust in every device without exposing the private key that gives us the authority to sign trusted firmware?

This article explores a practical production-line architecture for ESP32 Secure Boot V2, including key storage, eFuse provisioning, manufacturing threats, flash encryption, and the checks I would put in place before shipping a device.

Figure 1: Secure Boot V2 production architecture.

1. First, understand which key the ESP32 actually needs

One mistake I want to avoid is treating every cryptographic key as if it serves the same purpose.

In an asymmetric secure-boot design, the firmware-signing private key and the device's verification trust anchor have different responsibilities.

• Private signing key: Used by an authorized signing system to sign firmware images. This key must remain protected.
• Public verification key: Used to verify firmware signatures. It is not secret.
• Public-key digest: A cryptographic hash of the public key. On the original ESP32 using Secure Boot V2, this digest is stored in eFuse and anchors the device's trust in the verification key.

For the original ESP32, Secure Boot V2 is supported on chip revision 3.0 and later. It uses RSA-PSS signatures with RSA-3072 keys.

The private signing key does not need to be copied into every ESP32 or stored on every manufacturing station.

Instead, the device verifies the firmware using the public key and the trusted digest established through its eFuse configuration.

This distinction is fundamental to the production architecture.

Design principle: Keep the authority to sign firmware separate from the process that physically provisions the device.

Official reference: ESP-IDF Secure Boot V2

2. Production-line architecture: separate signing from provisioning

I would divide the production system into five logical components.

        OFFLINE ROOT OF TRUST
        Protects signing authority
                  |
                  v
       FIRMWARE SIGNING SERVICE
       HSM-backed private key
                  |
          Signed firmware
                  |
                  v
       AUTHENTICATED FACTORY STATION
       - Identifies the device
       - Flashes approved firmware
       - Executes provisioning steps
       - Verifies results
                  |
                  v
             ESP32 DEVICE
       - Public-key digest in eFuse
       - Signed firmware in flash
       - Secure Boot V2 verification
                  |
                  v
       MANUFACTURING RECORD SYSTEM
       Device ID, firmware version,
       provisioning status and audit log

The arrows represent logical relationships, not a requirement for every operation to pass through a single service.

For example, firmware may be signed before it reaches the factory. The manufacturing station can then flash an approved, signed release without having access to the private signing key.

Component responsibilities

Offline root of trust

Protects the authority used to authorize operational signing keys. Its access should be tightly controlled and separated from routine factory operations.

Firmware-signing service

Signs approved firmware releases. Ideally, the private key remains inside a Hardware Security Module (HSM), and callers can request authorized signing operations without exporting the key.

Manufacturing station

Programs the device and executes an approved provisioning workflow. It should have only the permissions necessary for its job.

ESP32 device

Uses its configured trust anchor to verify firmware according to the selected secure-boot scheme.

Manufacturing record system

Records the device identifier, firmware release, provisioning status, station identity, and relevant verification results. It should not store private signing keys or unnecessary secret material.

The main security benefit is that compromising one factory computer should not automatically give an attacker the ability to create firmware trusted by every device in the fleet.

3. Where should the secure-boot key be stored?

The answer depends on which key we are talking about.

Why use an HSM?

An HSM helps keep the private signing key within a protected cryptographic boundary. An authorized system submits a signing request, and the HSM performs the cryptographic operation without needing to export the private key.

For a smaller team, an appropriately protected signing service may be a practical starting point. The important requirement is to define and enforce the security boundary around signing authority rather than leaving private keys on ordinary workstations.

Why use eFuse for the trust anchor?

On the original ESP32 Secure Boot V2 implementation, the public-key digest is stored in eFuse. This helps anchor firmware verification to the expected public key.

However, eFuse programming requires care. Many eFuse operations are irreversible, and the exact fields and protections depend on the chip and security configuration.

One particularly important detail: the public-key digest must remain readable by the verification mechanism. Do not blindly apply read protection to the digest.

Reference: ESP-IDF security documentation

4. What can go wrong on the production line?

A manufacturing station is part of the security boundary. It should not automatically be trusted simply because it is inside a factory.

Here are the threats I would explicitly include in a production threat model.

Comparing signing-key exposure

The following ratings are illustrative threat-model scores, not measured security benchmarks.

Relative signing-key exposure risk
(1 = lower risk, 5 = higher risk)

HSM-backed signing service   █ 1
Protected signing service    ██ 2
Private key on factory PC    █████ 5

The exact risk depends on implementation. A poorly configured signing service is not automatically secure just because it uses an HSM. Authorization, release approval, auditability, and operational controls still matter.

The goal is to minimize the number of systems that can access signing authority and to make unauthorized signing detectable.

5. A safer ESP32 manufacturing workflow

I would treat provisioning as a controlled transaction rather than a sequence of commands that a script executes without checking the device's state.

Step 1: Prepare and sign the firmware

Build the bootloader and application using the approved production configuration. Sign the release through the authorized signing process.

The factory should receive only approved firmware artifacts and the information required to validate them.

Step 2: Authenticate the station and identify the device

Verify the manufacturing station's identity and read the target device's identifier.

Confirm the exact chip model, revision, and intended security profile. Do not assume that every ESP32-family chip supports the same Secure Boot V2 workflow.

Step 3: Inspect the existing eFuse state

Before programming anything irreversible, inspect the relevant eFuse fields and compare them with the expected state for that device.

If a device has unexpected security settings, stop and investigate instead of blindly continuing.

Step 4: Flash firmware and provision the trust anchor

Use the documented ESP-IDF workflow for the target. Provision the public-key digest and other required settings according to the selected secure-boot scheme.

The ordering of firmware flashing, digest provisioning, secure-boot activation, and any flash-encryption operations must follow the platform-specific instructions.

Step 5: Verify before irreversible operations

Validate the firmware artifact, intended trust anchor, and current eFuse state before applying irreversible security settings.

Read back and verify fields where the hardware permits it. For fields that are protected or not readable, verify using the documented status and validation mechanisms instead.

Do not treat a timeout as proof that an eFuse operation failed. Inspect the device's actual state before retrying.

Step 6: Enable security controls and test boot

Apply the documented secure-boot configuration and any required production restrictions on debugging and download interfaces.

Power-cycle the device and verify that it boots the approved firmware successfully.

Step 7: Record and release the device

Record the device identifier, firmware version, trust-anchor fingerprint or identifier, provisioning outcome, station identity, and relevant audit information.

Mark the device as production-ready only after all mandatory checks pass.

Workflow at a glance

  Prepare approved firmware
             |
             v
  Authenticate station and device
             |
             v
  Inspect current eFuse state
             |
             v
  Flash and provision trust anchor
             |
             v
  Verify configuration and image
             |
             v
  Enable required security controls
             |
             v
  Test boot and record results
             |
             v
       Release device

This workflow should also define what happens when any step fails. A production process that handles successful provisioning but has no safe failure or recovery procedure is incomplete.

6. Secure boot is not flash encryption

These two features solve different problems.

Secure boot establishes firmware authenticity: the device verifies that firmware is signed by an authorized key before executing it.

Flash encryption protects the confidentiality of supported data stored in external flash.

A device can have secure boot enabled without having flash encryption configured. Depending on the product and threat model, that may leave firmware contents or stored data more exposed than intended.

For production ESP32 devices, evaluate both features together.

• Enable the appropriate secure-boot scheme for the target.
• Configure flash encryption in Release Mode when required.
• Follow Espressif's recommended device-specific flash-encryption key workflow.
• Apply the intended debug and download restrictions.
• Validate OTA updates and recovery procedures under the final security configuration.

Flash encryption is not a replacement for secure boot, and secure boot is not a replacement for protecting secrets.

Reference: ESP-IDF security feature enablement workflows

7. Plan for signing-key rotation before shipping

Key rotation is easy to postpone during development and difficult to introduce after devices are deployed.

Before mass production, answer these questions:

• Can the target support multiple trusted public-key digests?
• Can a new signing key be introduced without disrupting deployed devices?
• What happens if the production signing key is compromised?
• How will the manufacturer authorize an emergency firmware release?
• What recovery options remain if an update fails?

The answers depend on the exact ESP32 model, secure-boot scheme, and configured revocation mechanisms. Do not assume that every chip supports the same trust-anchor capacity or key-revocation behavior.

For a production fleet, key rotation should be part of the security design, not an emergency improvisation.

8. My production-readiness checklist

Before releasing an ESP32 product to manufacturing, I would want clear answers to these questions:

• [ ] Is the production signing private key protected and unavailable to factory stations?
• [ ] Are development and production signing keys separated?
• [ ] Is the target chip model and revision explicitly validated?
• [ ] Is the public-key digest provisioned and protected correctly?
• [ ] Are irreversible eFuse operations preceded by state validation?
• [ ] Is flash encryption configured where the threat model requires it?
• [ ] Are debug and download interfaces configured for production?
• [ ] Are interrupted provisioning and unexpected device states handled safely?
• [ ] Are OTA updates, recovery, and key rotation tested?
• [ ] Can each shipped device be traced to an approved firmware release and provisioning record?

If any answer is unclear, I would resolve it before scaling production.

Conclusion

Secure boot is not just a bootloader feature. It is a trust-management problem that spans firmware development, signing infrastructure, manufacturing, device provisioning, OTA updates, and long-term maintenance.

For an ESP32 product, my preferred design is to keep the firmware-signing private key inside protected signing infrastructure, provision only the trust material required by the device, and treat eFuse programming as a high-risk operation that requires explicit validation.

The production line should not need the authority to create trusted firmware simply to manufacture a trusted device.

Protect signing authority centrally. Provision device trust deliberately. Verify every security-critical state before locking the hardware.

That is the foundation of a secure and maintainable ESP32 production process.

Further reading

• ESP-IDF Secure Boot V2
• ESP-IDF security feature enablement workflows
• ESP-IDF security guides
• NIST SP 800-57 Part 1: Key Management

What does your production setup look like? Are you using ESP32 eFuse provisioning directly from the manufacturing station, or a separate provisioning service? I'd be interested in how other embedded teams handle this boundary.