The European Union (EU) Cyber Resilience Act (CRA) marks an era-defining regulation for all products that contain digital elements. With full regulatory rollout marked for December 11, 2027—and other mandatory requirements coming even sooner—it is essential for engineering teams and product managers to understand the legislation. After all, manufacturers bear primary responsibility for ensuring all devices are compliant before market release.
Alongside full liability in the event of cybersecurity incidents, the penalties for non-conformity are severe:
- Fines of up to €15 million or 2.5% of global annual turnover, with non-compliant products banned, withdrawn, or recalled from EU markets.
- Loss of CE marking, meaning that products cannot legally be sold in the EU.
- Possible automatic exclusion from tenders and partnerships, since many requests for proposal (RFPs) require CRA-compliant solutions.
In addition, manufacturers that are found to not comply risk losing market credibility and trust as critical-sector customers (such as those from government, financial, and industrial applications) avoid products that lack comprehensive security guarantees.
Given these risks, system designers must now consider the security implications of key hardware and software choices from the start of the design process, since both will affect long-term compliance and therefore market access. This article will define a manufacturer’s main security commitments under the CRA before highlighting over-the-air (OTA) updates as a powerful strategy for maintaining long-term compliance. It will then outline a robust software framework for delivering these updates securely and provide an example of a commercial-off-the-shelf (COTS) solution that aligns with these principles.
Security commitments under the CRA
From consumer devices to distributed infrastructure components, modern edge systems suffer from an increasing number of security vulnerabilities. Outdated firmware issues and insecure communication protocols can lead to data breaches and unauthorized access that compromise device integrity. Accordingly, the CRA mandates several measures to maintain a minimal attack surface:
First, manufacturers must protect devices against unauthorized tampering and ensure software integrity from first boot. While the CRA does not define a specific framework for achieving this, secure boot, in combination with a root-of-trust (RoT), serves as a fundamental baseline for meeting this requirement.
Secure boot utilizes cryptography to ensure that only authentic, verified software runs on the device. This RoT forms the first link in a chain of trust that authenticates each stage of the boot process to ensure device integrity, as shown in Figure 1. If, for example, a hash of a software component is encrypted with a private key that does not match the public keys in the RoT—whether due to tampering or corruption—the boot process will either stop or restrict higher system capabilities (such as network access) to prevent potential malware or botnets from spreading.
Manufacturers must ensure integrity via continuous vulnerability management and timely security updates throughout the entire product lifecycle. The CRA defines a mandated support period of at least 5 years, or the expected lifetime of the product if shorter, and requires that manufacturers provide a specified end-of-support date upon market release.
When an actively exploited vulnerability is discovered, manufacturers must disclose it to their national Computer Security Incident Response Team (CSIRT) and European Network and Information Security Agency (ENISA), the EU agency for cybersecurity. This reporting commitment comes into effect on September 11, 2026, with the following timeframe requirements:
- 24 hours: Early warning reports must be sent to ENISA and the national CSIRT.
- 72 hours: A formal vulnerability notification must be generated that details the exploit and how it affects a system.
- 14 days: A final report must be submitted once a security patch is available.
Naturally, continuous vulnerability management requires some level of real-time threat monitoring. Public frameworks like the Common Vulnerabilities and Exposures (CVE) system can help manufacturers spot and patch new threats in third-party software components, even before they are actively exploited within their own devices.
To support the above, the CRA also mandates that manufacturers maintain technical documentation for every update. In particular, a software bill-of-materials (SBOM) must be provided in a machine-readable format, such as CycloneDX or SPDX, covering all top-level dependencies at minimum. This format enables automated tools to scan every software build against CVE databases to identify new vulnerabilities as soon as they are reported. DevSecOps teams can then deliver patches that fix in-house issues without introducing third-party software.
In addition to SBOMs, CRA conformity requires extensive documentation that includes a high-level security risk assessment, system architecture diagrams with a description of the development process, and descriptions of the vulnerability handling process (see Figure 2). These are used to verify that the system is secure-by-design within CRA guidelines. Logged documentation must be retained throughout a device’s lifecycle and made available to auditors and surveillance authorities and notified bodies for 10 years after market release, or for the duration of a longer support period.
Finally, a formal declaration of conformity (DoC) allows manufacturers to use the CE marking for EU market access. The DoC document contains details that include the manufacturer’s name and address, a unique identification for the product, and references to specific standards and technical specifications used to prove compliance. For certain digital products that come under the CRA’s “Important Class I,” “Important Class II,” and “Critical” categories, details of a third-party auditor must also be included to verify compliance. Such devices include industrial control systems, IoT gateways, and software for privileged access, where breaches may cause wider infrastructure damage.
By signing a DoC, manufacturers take full responsibility for CRA compliance. Given the depth of these commitments, OTA updates provide the most effective way to quickly deliver patches and maintain connected device integrity. Continuous OTA updates, however, require a sophisticated software architecture that specifically caters to CRA-aligned updates.
Designing software infrastructure for regular OTA security patches
Under the CRA, DevSecOps teams face immense time pressure when locating, characterizing, and solving security issues after discovery. To ease security management, embedded devices benefit from the following architectural adjustments:
- Integrated telemetry reporting: By collecting device health data and sending it back to a cloud platform, manufacturers can quickly discover bugs or exploits across connected devices. Telemetry reporting also allows teams to verify the effectiveness of new patches in limited real-world trials before fleet-wide rollout.
- Highly modular, containerized software architecture: Threat isolation supports a reduced attack surface if a device becomes compromised. For example, containerization prevents a user interface hack from accessing core operating system (OS) code. It also allows individual software components to continue running while others get updated, reducing operational downtime. Similarly, modular software accelerates the location of vulnerabilities and reduces OTA data requirements—and therefore cost—when compared to monolithic code updates.
- Rollback mechanisms: OTA interruptions and glitches can prevent patches from being installed correctly, which could cause bricking. Rollback mechanisms ensure that a device can always return to a state of working order if an update fails, allowing manufacturers to fulfill the CRA commitment and maintain device integrity.
Understandably, secure OTA updates require end-to-end encrypted tunnels to ensure that patches cannot be compromised during transmission and that only signed and verified firmware can run on a device. To meet documentation requirements for every patch issued, manufacturers benefit from software development frameworks that provide automated SBOM generation and logging.
However, implementing CRA-aligned frameworks can place a large burden on developers building software from scratch, especially with fast-approaching regulatory deadlines. Thankfully, COTS solutions can help teams meet compliance requirements on time.
Leveraging COTS software frameworks for CRA alignment
COTS software frameworks offer several advantages that are particularly relevant to the CRA. The first is accelerated development for reducing time-to-market. Similarly, while the legal responsibility for compliance lies with manufacturers, tried-and-tested third-party solutions can also reduce the chance of encountering regulatory blind spots. Moreover, by working with commercial partners, manufacturers can gain additional long-term support for their software infrastructure, which can further ease the burden on developers.
An example of such a solution is SECO’s Clea OS, a customizable software architecture that is designed for industrial-grade secure systems and exhibits many features that ease CRA compliance. Based on the open-source Yocto Project, Clea OS provides reproducibility and traceability for CRA audits, with automated SBOM generation capabilities to support mandatory documentation efforts.
In contrast to many closed operating systems, Clea OS is designed as a streamlined and controlled Linux OS foundation, minimizing unnecessary components to reduce the attack surface and improve overall security and resilience. Containerization is facilitated by Docker to isolate threats and enable 24/7 operation during patching. This is additionally supported by A/B partitioning to ensure a working firmware image is always present on the device, and rollback of the active firmware in case an update fails.
Furthermore, Clea OS supports secure boot, digitally signed OTA updates, continuous real-time device monitoring in combination with SECO’s wider Clea ecosystem (as outlined in Figure 3) and a Cyber Security Package. Enabling manufacturers to maximize threat detection and patching opportunities, this support facilitates the CRA’s long support lifetime requirements, directly addressing key requirements such as secure update mechanisms, continuous vulnerability management, and system integrity.
The existence of COTS solutions including SECO’s Clea OS proves that CRA compliance does not have to be as challenging as it first appears. By encouraging development teams to use ready-made software frameworks that enable high levels of customization, manufacturers can ease the transition into a new cybersecurity landscape while delivering differentiated products to market.