Implement Secure Firmware updates for CRA

In the context of the EU Cyber Resilience Act (CRA), ensuring device integrity from the earliest stage of operation is a critical cybersecurity objective. Annex I of the CRA outlines essential requirements that all products must meet regardless of classification. While detailed harmonized standards are still under development (expected by September 2026), manufacturers are already under pressure to align product designs with CRA expectations ahead of the regulation’s enforcement in December 2027.

Secure Firmware Updates, both manual and over-the-air (OTA), are essential to maintaining the cybersecurity posture of connected products. Under the EU CRA, the ability to deliver secure updates is not optional. Instead, it is a core expectation of maintaining product security throughout its lifecycle.

This guide explores how secure firmware updates fit into CRA compliance and how cryptographic controls, particularly those enabled by Public Key Infrastructure (PKI) and digital signing, support manufacturers in fulfilling their obligations, even in the absence of finalized harmonized standards.

This guide is intended for embedded engineers, product security teams, firmware developers, and compliance leads who are building or maintaining connected products intended for the European market. It is especially relevant to those responsible for security architecture and product lifecycle risk mitigation, including those preparing for conformity assessment under the CRA.

Disclaimer: This guide provides one possible interpretation of the Cyber Resilience Act (CRA) and outlines how enabling Secure Firmware Update may contribute to compliance efforts.

Keyfactor anticipates that forthcoming harmonized standards will align with this interpretation; however, at the time of writing, Keyfactor does not have direct involvement or firsthand insight into the development of those standards.

Updating firmware on real systems

Firmware updates, both manual and over-the-air (OTA), are essential to maintain the cybersecurity posture of connected products. Under the EU Cyber Resilience Act (CRA), the ability to deliver secure updates is not optional. Instead, it is a core expectation of maintaining product security throughout its lifecycle.

CRA Annex I specifically outlines the need to prevent unauthorized access, preserve integrity, and limit attack surfaces. Each of these is directly affected by how updates are packaged, delivered, authenticated, and applied.

While secure boot ensures that only verified code executes on startup, secure firmware update processes ensure that new code is trusted before it ever runs. Together, they form a complete lifecycle of software trust.

This section outlines how cryptographic signing of firmware updates is a central enabler of compliance, and how those updates should be applied securely, whether manually or via remote channels.

Secure Firmware Update Process (Manual or OTA)

A secure firmware update process enforces the following characteristics:

1. Integrity and Authenticity – The firmware image must be cryptographically signed by a trusted authority, using a trusted process from the firmware developer.

2. Verification Before Execution – The device must verify the update’s signature before applying it.

3. Rollback Protection – Older (possibly vulnerable) firmware should not be re-installed unless explicitly allowed and signed.

4. Key Trust Anchoring – The device must contain trusted keys or public key hashes used to verify updates.

5. Auditability – Signing events and update installations must be logged for traceability and forensic value.

These features are independent of how the update is delivered. Whether an update is loaded manually via USB, SD card, or JTAG—or delivered from the internet over an ethernet connection, mobile network, or Wi-Fi—the validation and trust model must remain consistent.

Manual Update Workflow

Manual updates typically follow this path:

1. A firmware image is built by the manufacturer.

2. The image is cryptographically signed using a secure signing key and a secure, auditable process.

3. The image is transferred via USB or SD card to the device.

4. The device validates the signature before applying the update.

5. If validation fails, the update is rejected and logged.

Manual updates are common in air-gapped, industrial, or tightly regulated environments. But even in these environments, signing is the boundary between trust and compromise.

OTA Update Workflow

Over-the-air (OTA) updates are essential for distributed, consumer, and IoT devices. A simplified OTA process might include:

1. The device checks in with a remote server or management system.

2. An update package (signed) is downloaded.

3. The device verifies the signature before applying the update.

4. If valid, the update is staged and applied.

5. Optional: Post-update verification or rollback plan is triggered.

In this case, transport-layer security (e.g., TLS) is required to protect the connection, but it does not replace image-level signing, which proves who authored the new firmware.

Signing Is the Gatekeeper of Firmware Trust

Whether manual or OTA, firmware updates must be signed using cryptographic keys controlled and protected by the manufacturer. Otherwise, the update path becomes a direct exploit vector—allowing attackers to introduce malware or backdoors.

Key concerns addressed by signed firmware updates backed by best-in-class processes:

• Unauthorized code injection

• Compromised update servers or mirrors

• Insider threat during the build or packaging process

• Downgrade attacks to vulnerable firmware

• Lack of traceability of code changes

Rollback Prevention

Firmware updates don’t just need to be secure—they need to stay secure. Even when a system is compromised, an attacker’s goal is often to install an older, vulnerable version of the firmware to re-enable known exploits. This is called a rollback attack.

Rollback prevention is the mechanism that ensures devices cannot accept or apply firmware that is older than the current trusted version—even if the image is validly signed.

A secure rollback prevention mechanism typically includes:

• A monotonically increasing version number or anti-rollback counter

• Version checks built into the bootloader or update agent

• Optional secure storage (e.g., fuses, OTP, or protected flash) to track current version

• Update rejection and logging if version is lower than expected

In secure environments, rollback protection is often hardware-enforced. In resource-constrained or legacy systems, software-based version checks and update policy enforcement are common.

Example Rollback Scenario:

1. Device is running version 3.2 of firmware.

2. An attacker attempts to re-install version 2.9, which has a known vulnerability.

3. The firmware image is validly signed—but the device checks the version metadata.

4. Because 2.9 < 3.2, the update is rejected and logged as an attempted downgrade.

Rollback prevention ensures signed ≠ safe unless it’s also current.

Without rollback prevention, even a perfectly signed update process can still be exploited in the field.

A/B Partitioning to Prevent Device Bricking

Secure updates must not only protect against unauthorized firmware—they must also guarantee system availability. A failed update should never leave the device unbootable (a state commonly referred to as bricked).

To prevent this, many platforms implement A/B partitioning (also known as dual-bank or redundant firmware slots). This approach keeps the currently running firmware untouched during the update process, storing the new update in a separate location until it's successfully verified and ready to run.

How A/B Partitioning Works:

• The device maintains two partitions (A and B), each capable of storing a full firmware image.

• One partition is active (e.g., A), while the other is inactive (e.g., B).

• When an update is downloaded, it's written to the inactive partition (B).

• The system verifies the new firmware’s signature and performs pre-flight checks.

• On next boot, the system attempts to boot from the updated partition (B).

• If boot fails, the system automatically rolls back to the last known good partition (A).

• Once the updated image is proven functional, partition B becomes the active slot.

This approach provides:

• Atomic updates — update is only “live” once validated.

• Rollback on failure — corrupted or misconfigured firmware won’t brick the device.

• Safe update staging — ensures updates don’t interrupt device availability.

A/B partitioning is critical for remote, unattended, or mission-critical devices—anywhere physical recovery is difficult or impossible.

A/B systems should also pair with rollback prevention to ensure that recovery doesn’t introduce older insecure images.

CRA Annex I Alignment – Firmware Updates

Signing and Update Trust: Beyond the Bootloader

Firmware signing is only as strong as the control over the signing keys. A signed firmware update proves trust—but only if that signature came from a verified, authorized source. Just like secure boot, secure update signing relies on protecting the private signing keys. If an attacker can sign firmware themselves, they can bypass all other protections.

That’s why secure update signing should include:

• Keys stored in HSMs

• Signing audit logs

• Controlled access to signing systems

• Developer workflow integration

• Signature verification logic on the device

The signing infrastructure becomes the root of update trust—not the update server, not the packaging tool, not the USB stick.

Secure Firmware Updates with EJBCA PKI, SignServer, and Signum

EJBCA PKI, SignServer, and Signum provide a complete platform for trusted firmware updates. EJBCA issues signing certificates, while SignServer and Signum enforce secure signing operations with keys protected in FIPS-certified HSMs.

Key capabilities include:

• Policy-controlled signing of firmware updates with role-based access.

• Integration with CI/CD pipelines or manual release workflows.

• Cryptographic verification of updates before installation.

• Full audit trail of all signing events for compliance and investigations.

• Signed firmware integrates seamlessly with over-the-air (OTA) and field update mechanisms.

The diagram below shows how SignServer and EJBCA integrate into a CI/CD pipeline to enforce these controls and provide a trusted foundation for secure firmware updates. Signum can replace SignServer for certain use case scenarios.

Combined with secure boot, secure firmware updates ensure a continuous chain of trust so that no untrusted firmware ever runs on your devices, from factory floor to field deployment.

Conclusions

Secure firmware updates, whether delivered manually or over-the-air, are a critical requirement under the EU Cyber Resilience Act (CRA). They directly support several essential cybersecurity objectives defined in Annex I, including preventing unauthorized access, maintaining software integrity, and reducing attack surfaces over time.

Effective update processes must go beyond basic delivery. They must ensure authenticity, prevent rollback attacks, and guarantee availability through safe deployment practices like A/B partitioning. These protections are enforced not by delivery mechanisms alone, but through cryptographic signing, key management, and verifiable trust anchored in the device itself.

With no finalized harmonized standards yet available, manufacturers must act now to implement secure update mechanisms aligned with the CRA’s intent. SignServer and Signum provide the trusted infrastructure to ensure signed firmware is authentic, auditable, and resilient, supporting CRA compliance and protecting devices long after deployment.

Related Content

Complementary Solution Areas and Guides

• The EU CRA Requirements: Security and Compliance Across the Product Lifecycle - An engineering-focused summary of the CRA.

• Implementing Secure Boot for CRA - Validate firmware signatures at startup to ensure device integrity from the moment it powers on.

• Implementing Initial Device Identities for CRA – Issue and manage identity certificates at manufacturing or first boot to establish strong device identity.

• Implementing Operational Certificates for CRA – Automate the lifecycle of operational certificates to enable secure communications, access control, and encrypted services.

• Implementing SSH Certificates for CRA – Replace unmanaged SSH keys with certificate-based access, enforce security policies, and enable auditability.

Contact us

Request a live demo with one of our experts — whether you want to explore workflows hands-on or discuss your specific needs.

Request a Demo