Designing Secure OTA Updates for CRA Compliance

Connected products no longer end their security lifecycle when they leave the factory. Once a device is deployed, its firmware, software dependencies, communication stack and update mechanisms become part of an ongoing security responsibility. This is particularly important with the EU Cyber Resilience Act (CRA), which introduces cybersecurity requirements across the lifecycle of products with digital elements.

The CRA places strong emphasis on vulnerability handling throughout the defined support period, including the ability to address security issues after a product reaches the market. Manufacturers must therefore think beyond secure firmware development and design an update infrastructure that can deliver trustworthy security fixes over time.

For connected and embedded products, Over-the-Air (OTA) updates are one of the most practical ways to achieve this but only when the OTA architecture itself is secure.

Security vulnerabilities can emerge months or years after deployment. A device may have been thoroughly tested before launch and still require a firmware patch because of a newly discovered vulnerability in its operating system, communication protocol, third-party library or application layer.

The CRA requires manufacturers to handle vulnerabilities effectively during the product's declared support period. It also requires manufacturers to provide secure information and instructions for installation and operation.

This makes OTA capability more than a convenience feature. It can become a critical component of a product's lifecycle security strategy.

A robust update mechanism should answer several engineering questions:

These questions should be addressed at architecture level—not after deployment.

A secure OTA ecosystem typically contains several layers:

The update server should maintain controlled firmware artefacts, version information, device eligibility and deployment policies. The device, meanwhile, should authenticate the update source, download the image securely, verify its authenticity and integrity, and only then permit installation.

A common production architecture separates the application firmware from the secure boot loader. The boot loader becomes the final authority that decides whether a firmware image is trusted.

This separation is particularly valuable because an attacker who compromises the application should not automatically gain the ability to install arbitrary firmware.

Firmware signing is one of the foundations of a secure OTA system.

Before deployment, the firmware image should be cryptographically signed using a controlled private signing key. The device contains the corresponding trusted public key or certificate chain and verifies the signature before installation.

The process can be represented as:

Encryption and signing solve different problems. Encryption can protect confidentiality, while digital signatures provide authenticity and integrity.

For security-critical products, signing should also be integrated into the build and release pipeline so that production firmware cannot bypass established security controls.

A technically strong OTA design can still fail if its cryptographic keys are poorly managed.

Private signing keys should not be embedded in source code, developer machines or ordinary build environments. Production environments should use controlled access, secure storage, key rotation procedures and strict separation between development and production credentials.

For large product fleets, device identity also matters. Each device should have a unique identity or credential wherever practical rather than relying on a single shared secret.

This enables stronger controls such as:

A secure OTA mechanism must protect against more than modified firmware. It should also prevent downgrade attacks.

Suppose version 5.0 fixes a critical vulnerability, but an attacker forces the device to reinstall vulnerable version 3.0. Signature verification alone may not stop the attack if version 3.0 is legitimately signed.

Rollback protection addresses this problem by using firmware version counters, secure monotonic counters or equivalent anti-downgrade mechanisms.

The boot loader should reject firmware that falls below the minimum permitted security version.

Not every device has the storage, bandwidth or power budget for complete firmware downloads.

Delta updates transmit only the differences between firmware versions. This can significantly reduce bandwidth and update time, which is particularly useful for cellular, LPWAN and battery-powered devices.

However, delta mechanisms introduce additional complexity. The update package, source version, target version and reconstruction process must all be authenticated and verified.

The engineering goal is not simply to make updates smaller—it is to make them smaller without weakening the trust chain.

Downloading a firmware image successfully does not mean the update is safe.

A robust implementation can verify multiple properties:

The device should also use an atomic or fail-safe update strategy. If power is lost during installation, the system should have a known recovery path rather than becoming permanently unusable.

Dual-bank or A/B firmware architectures are commonly used for this purpose:

If the new image fails health checks, the boot loader can return to the known-good image.

Updating ten devices is fundamentally different from updating 100,000.

Fleet management should provide visibility into firmware versions, update status, device health and deployment failures. Manufacturers should be able to identify which devices are running vulnerable versions and prioritise them for remediation.

A mature OTA platform may support:

Staged deployment is particularly important for critical products. Instead of releasing a firmware update to the entire fleet immediately, manufacturers can first deploy it to a small controlled population, monitor telemetry and then progressively expand deployment.

A practical architecture for a connected industrial device could look like this:

This architecture creates a chain of trust from the firmware build environment through deployment and finally to execution on the device.

CRA readiness should not be treated as a documentation exercise performed immediately before certification. The update mechanism should be considered during hardware selection, bootloader architecture, firmware development, cloud design and product lifecycle planning.

The European Commission's current CRA guidance reinforces the importance of lifecycle cybersecurity, risk assessment, support periods and vulnerability handling.

For engineering teams, the practical takeaway is straightforward: secure OTA should be designed as part of the product's security architecture, not added as a feature after launch.

Ascenten Technologies brings embedded firmware, hardware, connectivity and product engineering capabilities together to develop connected products from architecture through validation. Its embedded engineering capabilities include firmware, bootloader development, RTOS integration, network stacks, OTA update support and security implementation.

For companies developing connected industrial, telecom, IoT or embedded products, Ascenten can help architect firmware and OTA ecosystems around secure boot, firmware verification, update mechanisms, connectivity, testing and lifecycle requirements.