CRA-Compliant OTA Updates for Embedded Firmware

The CRA doesn't just require you to find and fix vulnerabilities. It requires you to deliver those fixes to devices in the field — for the entire support period, free of charge, and without undue delay. For embedded product teams, this means having a working, secure firmware update mechanism isn't optional. It's a legal obligation.

This post covers the specific CRA requirements around security updates, how to implement A/B update schemes for common embedded platforms, and the infrastructure and testing evidence you'll need for compliance.

What the CRA Requires for Security Updates

Annex I Part II: The Update Obligation

Annex I Part II, point 2 establishes the core requirement:

Manufacturers must ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic updates. The updates must be provided free of charge and without undue delay after the vulnerability becomes known.

Key elements to unpack:

"Free of charge": You cannot charge customers for security patches. Feature updates can be gated behind a subscription, but patches addressing known vulnerabilities must be free for the product's support period.

"Without undue delay": The CRA text doesn't specify a hard SLA (e.g., "within 30 days"), but ENISA guidance suggests that "without undue delay" for critical and actively exploited vulnerabilities means days to weeks, not months. Market surveillance authorities will look at your patch timeline relative to the vulnerability severity.

"Where applicable, through automatic updates": For connected devices, the expectation is that updates can be delivered remotely. If your device requires physical access to update (JTAG, SD card swap, serial connection), you need to document why remote updates aren't technically feasible.

Annex I Part I, Requirement 3: Update Integrity

Updates themselves must be delivered securely. Annex I Part I, Requirement 3 (integrity protection) applies to the update delivery mechanism:

• Updates must be signed and verified before installation (see our post on secure boot and firmware signing)
• The update channel must be protected against tampering (TLS for transport, signature verification at the device)
• Users must be informed about available security updates

Article 14: The Reporting-to-Patching Pipeline

Article 14's vulnerability reporting obligations (see our Article 14 breakdown) feed directly into the update pipeline:

1. You discover or are notified of a vulnerability
2. You report to ENISA within 24 hours (if actively exploited)
3. You develop and test a patch
4. You deliver the patch via your OTA update mechanism
5. You confirm patch deployment in your 14-day final report to ENISA

The update pipeline is the mechanism that closes the loop between vulnerability discovery and remediation. Without it, your Article 14 reports become a record of vulnerabilities you found but couldn't fix.

A/B Update Schemes for Embedded Platforms

The most robust firmware update pattern for MCU-based products is the A/B (dual-slot) scheme: the device maintains two firmware slots, runs from one, and installs updates into the other. If the update fails or the new image is faulty, the device can revert to the known-good slot.

MCUboot (Zephyr, bare-metal Cortex-M)

MCUboot supports two update strategies:

Swap mode: The bootloader swaps the contents of the primary and secondary slots during boot. If the new image fails validation (doesn't confirm itself within a timeout), the bootloader swaps back on the next reboot.

• Primary slot: currently running firmware
• Secondary slot: newly downloaded firmware image
• Scratch area: temporary storage used during the swap (not needed in "swap using move" mode)
• Image confirmation: the application must call boot_set_confirmed() after successful boot, or MCUboot reverts on next reboot

Overwrite mode: The bootloader copies the secondary slot image to the primary slot, destroying the previous image. Simpler but no automatic rollback — if the new image is broken, recovery requires re-downloading the previous version.

Recommendation for CRA compliance: Use swap mode. The automatic revert capability provides the fail-safe recovery mechanism that Annex I implicitly requires (a bricked device can't receive future security updates, violating the update obligation).

ESP-IDF (ESP32 family)

ESP-IDF uses an OTA data partition to track which of two app partitions is active:

• ota_0 and ota_1: two application firmware slots
• otadata: tracks which slot is active and whether it's been confirmed
• The new image is written to the inactive slot, then the device reboots from that slot
• If the app calls esp_ota_mark_app_valid_cancel_rollback() within the configured timeout, the slot becomes permanent
• If the app crashes or fails to confirm, the bootloader reverts to the previous slot

ESP-IDF also provides esp_https_ota for downloading firmware over HTTPS with built-in TLS and signature verification — a complete OTA client in one API.

STM32 (SBSFU / custom bootloader)

STM32's SBSFU (Secure Boot and Secure Firmware Update) uses a download slot model:

• Protected slot: currently running firmware (read-protected via RDP)
• Download slot: area where the new firmware is staged
• The bootloader decrypts and verifies the download slot image, then installs it into the protected slot

SBSFU's limitation: it's not a true A/B scheme. The installation overwrites the current firmware. If the new image passes signature verification but has a runtime bug, there's no automatic rollback to the previous version.

For CRA compliance with STM32: Consider augmenting SBSFU with a self-test mechanism in the application that triggers a recovery mode if critical functionality fails post-update. Alternatively, use MCUboot on STM32 (it supports STM32 targets) for true A/B capability.

Yocto / Embedded Linux (RAUC, Mender, SWUpdate)

For Linux-based embedded products, the same A/B principle applies at the rootfs level:

All three integrate with U-Boot's verified boot for a complete chain of trust from bootloader to application.

Signing and Verification in the Update Pipeline

Every firmware update must be cryptographically signed and verified before installation. This isn't just for secure boot — it's for the OTA delivery path specifically.

End-to-End Update Signing

┌──────────┐    ┌──────────┐    ┌────────────┐    ┌──────────┐
│ Build    │───▶│ Sign     │───▶│ Update     │───▶│ Device   │
│ System   │    │ (HSM)    │    │ Server     │    │ Verifies │
└──────────┘    └──────────┘    └────────────┘    └──────────┘
                     │                                  │
                ┌────┴────┐                        ┌────┴────┐
                │ Private │                        │ Public  │
                │ Key     │                        │ Key     │
                └─────────┘                        └─────────┘

The signing key for OTA updates should be the same key (or in the same trust chain) as your secure boot signing key. This means the device's bootloader verifies both:

• Firmware images at boot time
• Firmware images received via OTA before installation

Transport Security

Even with signed images, the transport channel should use TLS to prevent:

• Downgrade attacks: An attacker intercepts the update check and tells the device "no update available" or serves an older signed image
• Metadata tampering: Modifying update metadata (version numbers, release notes) to confuse the update logic
• Privacy leakage: Device firmware versions and update patterns are sensitive information

For constrained devices that can't run full TLS 1.3, DTLS 1.2 (over UDP/CoAP) is an acceptable alternative. The key requirement is mutual authentication: the device must verify the server's identity, and ideally the server verifies the device's identity.

Rollback Protection in the Update Path

Anti-rollback in the OTA context prevents an attacker (or a misconfigured update server) from pushing an older firmware version that contains a known vulnerability.

This complements the boot-time anti-rollback described in the secure boot post — but it operates at the update level:

1. The update server includes a version number in the signed update metadata
2. The device compares the incoming version against its stored minimum version
3. If the incoming version is lower, the device rejects the update before writing it to flash
4. After successful installation and confirmation, the device increments its stored minimum version

This check should happen before the device spends time downloading the full image (check version in the update manifest first) and again after download (verify the version in the signed image header).

Fail-Safe Recovery

What happens when an update fails? The CRA implicitly requires a recovery mechanism — if a device is bricked by a bad update, it can no longer receive future security updates, which violates the ongoing update obligation.

Recovery Strategies

Automatic rollback (MCUboot swap, ESP-IDF OTA): If the new firmware doesn't confirm itself within a timeout, the bootloader automatically reverts to the previous version. This is the gold standard.

Recovery mode bootloader: If both A/B slots are corrupted, the device enters a minimal recovery mode that can accept firmware via a secondary channel (USB, UART, BLE DFU). The recovery bootloader itself must be immutable and signed.

Factory reset partition: A read-only partition containing a known-good base firmware image. If all else fails, the device can revert to the factory image. This image should be periodically updated (if possible) or at minimum be free of known critical vulnerabilities at manufacturing time.

What's not acceptable for CRA:

• A device that's permanently bricked by a failed update (no recovery path)
• A device that requires physical return to the manufacturer for firmware recovery
• A device that requires special tooling (JTAG programmer) that the end user doesn't have access to

Update Infrastructure

The update mechanism on the device is only half the story. You also need server-side infrastructure to manage firmware distribution.

Minimum Viable Update Infrastructure

1. Firmware hosting: A server (or CDN) that hosts signed firmware images. Can be as simple as an S3 bucket with signed URLs.
2. Version manifest: A signed JSON/CBOR document that tells devices what the latest version is, its hash, download URL, and minimum required version.
3. Device check-in: Devices periodically query the manifest to check for updates. The check-in interval should be configurable — daily is reasonable for most IoT products.
4. Staged rollout: Don't push updates to 100% of devices simultaneously. Use a staged rollout (1% → 10% → 50% → 100%) with monitoring between stages. This isn't a CRA requirement, but it prevents a bad update from bricking your entire installed base.
5. Audit logging: Record which devices have received which updates. This is needed for your Article 14 final reports (demonstrating that patches were deployed) and for your technical documentation.

Fleet Management Considerations

For products with large installed bases, you'll need:

• Device registration and identity management
• Per-device update status tracking
• The ability to target updates to specific device groups (by hardware revision, region, etc.)
• Metrics on update adoption rate (what percentage of devices are running the patched version)

Open-source options include Eclipse hawkBit (works with RAUC, SWUpdate, and Mender) and Mender Server. For MCU-based products with simpler needs, AWS IoT Jobs or Azure IoT Hub device management provide managed alternatives.

End-of-Life and Support Period

Annex I Part II, point 2 requires security updates for a period appropriate to the expected product lifetime. Article 13(8) adds that the support period must be at least five years from product placement on the market.

What "End of Life" Means Under the CRA

When you end-of-life a product, you must:

1. Declare the support end date in advance (give customers time to plan)
2. Continue delivering security updates until that date
3. Consider making the source code available — Recital 70 suggests that after end-of-support, manufacturers should consider making source code available so users can continue to maintain security

Planning for Long Product Lifecycles

Embedded products often have 10–15 year lifecycles, especially in industrial settings. Your update infrastructure needs to survive that long:

• Key rotation: Your signing keys may need to be rotated during the product lifecycle. Plan for key rotation in your bootloader design (support multiple key slots)
• Server infrastructure: Will your update server still be running in 10 years? Plan for infrastructure transitions
• Dependency maintenance: The libraries your update client uses (TLS stack, HTTP client) will need updates themselves over the product lifecycle

Testing Evidence for Compliance

Your technical documentation must demonstrate that the update mechanism works correctly under normal and failure conditions.

Required Test Scenarios

Positive tests:

• Device successfully downloads and installs a valid, signed update
• Device confirms the update and boots into the new version
• Update metadata (version, hash) matches the installed image

Failure and recovery tests:

• Device rejects an unsigned update image
• Device rejects an update signed with the wrong key
• Device rejects a rollback to an older version
• Device automatically reverts after a failed update (image doesn't confirm)
• Device recovers from a power loss during update installation
• Device recovers from a network interruption during download

Security tests:

• Update channel uses TLS/DTLS with certificate verification
• Man-in-the-middle on the update channel is detected and rejected
• Device does not expose firmware images in cleartext on the network

Document the test results with screenshots, logs, or automated test reports. These go into the Annex VII technical documentation file.

OTA Update Compliance Checklist

Update mechanism

• A/B or equivalent dual-slot update scheme implemented
• Automatic rollback on failed update (image doesn't confirm within timeout)
• Recovery mode available if both slots are corrupted
• Power-loss resilience tested and documented

Security

• All updates cryptographically signed (same trust chain as secure boot)
• Signature verified before installation on device
• Transport channel encrypted (TLS 1.2+ or DTLS for constrained devices)
• Anti-rollback protection prevents installation of older versions
• Update components listed in SBOM

Delivery

• Security updates deliverable free of charge
• Remote update capability (or documented justification for physical-access-only updates)
• Update infrastructure operational and maintained
• Staged rollout process documented

Lifecycle

• Support period declared (minimum 5 years from market placement)
• End-of-life policy documented and communicated to customers
• Key rotation plan covers the full product lifecycle
• Update adoption metrics tracked

Documentation

• Update mechanism described in Annex VII technical documentation
• Test evidence for all positive, failure, and security scenarios
• Vulnerability reporting to patching pipeline documented

The Stack Canary assessment tool assesses your update mechanism alongside your full Annex I posture and identifies specific gaps in your firmware update pipeline.

Based on Regulation EU 2024/2847 Annex I Part I (Requirement 3), Annex I Part II (point 2), Article 13(8), Article 14, Annex VII. MCUboot, ESP-IDF, STM32 SBSFU, RAUC, Mender, and SWUpdate documentation. This does not constitute legal advice.

Sources

• Regulation (EU) 2024/2847 — Cyber Resilience Act (full text)
• MCUboot — Design documentation (swap modes)
• Espressif — ESP HTTPS OTA
• STMicroelectronics — SBSFU reference
• Eclipse hawkBit — Update management
• Mender — OTA updates documentation
• RAUC — Robust Auto-Update Controller
• SWUpdate — Software Update for Embedded Linux