Rotating Embedded Firmware Signing Keys: Test the Trust-Overlap Window Before Revocation

Retire a firmware signing key only after every supported boot and recovery path can authenticate an approved replacement image without that key. For a planned rotation, an explicitly qualified overlap state can let devices accept both the old and new signer while the fleet migrates. That overlap is a product-specific trust policy, not a universal command sequence.

The example below concerns a hypothetical product with an authenticated, updateable verifier configuration. It uses U-Boot v2024.10 FIT signature documentation to illustrate verification-policy choices and RFC 9124 to distinguish authorization from rollback policy. It does not describe changing ROM roots, programming fuses, modifying production keys, or recovering a compromised signing infrastructure. No keys or devices were changed for this article.

1. Identify the verifier that actually owns the decision

List every stage that verifies executable content: ROM, a first-stage loader, U-Boot, the operating-system updater, and any separate recovery environment. For each stage, record the trusted public-key identity, where the policy is stored, who can update it, and which earlier stage authenticates that change. Keep private keys out of the device inventory and test report.

U-Boot’s verified-boot guide describes a chain in which each stage authenticates the next. A software verifier policy is only useful within the protections of the surrounding chain. Adding a new key to an operating-system updater does not automatically change the bootloader’s acceptance rule.

Stop here if the required policy cannot be changed through an already authorized, recoverable mechanism. An immutable root or exhausted hardware key slot may require a different migration architecture. Do not convert an unverified assumption about the device into an irreversible retirement step.

2. Define the trust-state matrix before building packages

Use public identifiers A and B for the old and new signing keys. Let T0 trust A, T1 accept either A or B, and T2 accept B only. The following matrix is the intended signature decision for this example; it assumes all other compatibility and rollback checks pass.

Verifier state	Approved image signed by A only	Approved image signed by B only	Recovery requirement
T0: old signer	Accept	Reject	An A-authorized path must install the qualified transition
T1: overlap, either signer	Accept	Accept	Prove a B-authorized recovery image works before retirement
T2: retired A	Reject	Accept	Recover without restoring acceptance of A

Test each cell on the actual verifier build. Include unsigned content, a damaged payload, the wrong board identity, and a signature from an unrelated test key as negative controls. Store artifact hashes and expected outcomes. A manifest label saying “new key” is not evidence that the verification path used B.

For signed FIT configurations, the v2024.10 signature reference distinguishes required keys and the required-mode choices any and all. Requiring both keys is different from accepting either key. Merely storing two public keys does not establish the T1 policy. This distinction is specific to that documented mechanism; other boot chains need equivalent evidence from their own implementation.

3. Gate the overlap transition on recoverability

First qualify the package that moves a T0 device into T1. Its authorization must already be accepted at T0. Identify the persistent state written during the transition and what happens if power fails before, during, or after that write. The test must establish either a valid prior state or a recoverable new state, with no assumption that an interrupted trust update is atomic.

Next qualify an operational image authorized by B on T1. Confirm useful application operation, then deliberately invoke the product’s documented recovery path on a development unit. Test the recovery verifier independently: it may be an older binary with a separate key policy even when the normal boot path is current.

Only advance the retirement gate after an approved B-authorized recovery artifact and its installation route have passed. Keep the transition package available for eligible offline devices, with a clear supported starting-state list. Devices that missed the transition should not receive a B-only package and be classified as successfully migrated merely because it downloaded.

4. Keep signer acceptance separate from rollback acceptance

A valid signature does not necessarily make an old image acceptable. RFC 9124’s sequence-number requirement separates a manifest’s monotonic sequence number from the firmware version. Its model can authorize an older payload using a newly issued manifest, but that does not override unrelated bootloader security counters or product-specific downgrade restrictions.

Add those independent checks to the recovery matrix: board compatibility, security version, data-schema compatibility, and recovery privileges. If a previously trusted fallback becomes forbidden by a security counter, signing it with B does not prove that it will boot. Test the actual artifact against the complete policy.

Also inspect verifier rollback. If restoring an older bootloader or recovery image restores trust in A, the apparent retirement may be reversible by an unintended route. Define which policy state is authoritative after recovery and verify that an approved service operation cannot silently recreate the retired acceptance rule.

5. Test the interruption windows explicitly

• Before T1 is durable: the device must retain a documented route accepted by T0.
• After T1 but before the new operational image is ready: an approved image and recovery path must still be available.
• During the T2 policy change: verify persistence and recovery without relying on an A-only rescue artifact.
• After T2: prove that A-only test images are rejected across ordinary boot, alternate media, and supported recovery paths.
• After factory reset or service restoration: verify which trust state returns and whether that matches the retirement policy.

Perform these tests on devices reserved for destructive-interruption qualification, with approved recovery equipment and no live actuators. Choose interruption points from observed storage operations or implementation state transitions. Random resets can supplement this plan, but they do not demonstrate coverage of every relevant commit boundary.

6. A hypothetical delayed maintenance unit

Suppose most controllers have reached T1 and successfully boot the B-authorized release, while one maintenance unit has been offline at T0. The deployment service should classify that unit by its verified starting state and deliver the approved transition route. It should not infer trust migration from the application version alone.

Now suppose the maintenance unit’s recovery image still accepts only A. Even though its normal firmware later reaches the B release, retirement remains blocked for that unit until the recovery route is updated and exercised. The needed outcome is complete path coverage, not a fleet dashboard with a high installation percentage.

7. Treat planned retirement and compromise differently

This overlap example assumes A remains trusted during a planned migration. If A is suspected compromised, accepting it for longer extends the exposure. The response requires the product’s incident policy, available independent trust anchors, and an assessment of which transitions an attacker could authorize. Do not reuse a routine overlap schedule without that analysis.

Close planned rotation with a versioned acceptance matrix, signed-artifact hashes, per-cohort transition evidence, negative tests for A, and verified B recovery. Retain an explicit exception list for disconnected or unsupported devices. A key is retired from the product only when the relevant verification paths enforce that decision; stopping use of the private signing key alone does not change devices already deployed.