How should OEMs structure firmware signing programs to support CRA compliance across the product lifecycle?

Firmware signing as a product-lifecycle trust control

Under the EU Cyber Resilience Act, firmware signing is not just a release gate. It is the mechanism that proves code provenance, supports update integrity, and gives OEMs a repeatable way to show that only authorised firmware can move from build systems to deployed devices. NIST’s security control guidance is useful here because the same trust assumptions must hold across development, production, update delivery, and retirement, not only at shipment time. EU Cyber Resilience Act

For OEMs, the practical question is whether the signing process can survive changes in tooling, teams, suppliers, and device state without weakening assurance. That means the signing program has to be designed around identity of the code, integrity of the update path, and traceable authority for every signing event. In practice, many security teams encounter signing failures only after a device fleet is already in the field and a recovery path has been reduced to exceptions, manual overrides, or delayed recalls.

How firmware signing works across build, update, and retirement

A compliant signing program starts by separating the act of building firmware from the authority to sign it. Build systems should produce reproducible artefacts, while signing keys remain in a protected environment with explicit approval, logging, and segregation of duties. The device side then needs secure boot or an equivalent trust anchor so it can verify that installed firmware matches the expected signer and has not been modified in transit or at rest.

In lifecycle terms, the signing decision should apply to three distinct moments. First, pre-release signing confirms that the delivered image is the approved image. Second, update signing verifies that patches, hotfixes, and maintenance releases are still governed by the same trust chain as the original firmware. Third, end-of-support and decommissioning processes need a policy for what happens when trust material changes, such as key rotation, revocation, or device resale.

Operationally, this usually requires:

• protected key custody with limited human access
• clear release approval records tied to each signature
• verification on device before execution or installation
• revocation and rotation procedures for compromised or retired keys
• evidence retention that can show what was signed, when, and by whom

The important point is that signing only works as a compliance control when verification is enforced downstream. If devices can accept unsigned images, bypass checks, or keep trusting obsolete keys after a product transition, the program stops being a lifecycle control and becomes a document control exercise. That is where compliance evidence and technical assurance diverge.

Where firmware signing programs break down in real deployments

Tighter signing controls often increase release friction, requiring organisations to balance delivery speed against assurance and evidential completeness.

One common edge case is field repair or factory rework. Teams sometimes assume these are operational exceptions, but they still create a trust decision: if repaired devices can load firmware from alternate tooling, the signing model needs to cover that path explicitly. Another edge case is third-party manufacturing or ODM involvement. If a supplier can inject firmware, reflash devices, or trigger signing workflows, the OEM must define whether the supplier is trusted to sign, trusted to submit for signing, or only trusted to handle pre-approved artefacts.

A second issue is key lifecycle drift. A signing program that never rotates keys, never tests revocation, or never proves what happens to older signed images after a trust change will struggle to show durable CRA-aligned governance. The same applies to products with long support tails: the signing model has to remain viable when cryptographic assumptions, tooling, and device capabilities evolve over time.

Where guidance is less settled is the exact balance between centralised signing services and distributed product-team autonomy. There is consensus that the trust boundary must be controlled, but organisations differ on how much release automation can be delegated without weakening accountability. The safest rule is to treat any place where firmware can be altered, re-signed, or accepted as a trust boundary that needs explicit owner, evidence, and verification. Without that, compliance gaps tend to appear first in exception paths, not in the main release flow.

Practitioner Guidance

What to prioritise: Define the signing program as part of the product security architecture, not as a build-team procedure. The first design decision should be which authority can approve a signing event and which device states are allowed to trust that signature.

What to verify: Confirm that the device enforces verification before install or execution, that revoked keys are actually rejected, and that the evidence trail can reconstruct signing decisions across firmware generations. If any of those are missing, the program is not yet lifecycle-ready.

Common mistake: Treating secure boot as sufficient by itself. Secure boot helps only when the signing chain, update channel, and recovery path all use the same governance model. OEMs often underestimate the risk created by service tooling, factory images, and exception handling.

Practitioner takeaway: CRA-aligned firmware signing succeeds when OEMs can prove trust continuity from first boot to decommissioning; if the trust model changes at any point in the lifecycle, the compliance burden changes with it.

Related resources from NHI Mgmt Group

• Who is accountable when a product fails CRA compliance because firmware signing controls were weak?
• Who is accountable for CRA compliance across the product supply chain?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities for SOC 2 compliance?