Understanding the Cyber Resilience Act

Over the past decade¹, numerous high-impact vulnerabilities, such as Heartbleed (2014), WannaCry (2017), SolarWinds ( 2020), and Log4Shell (2021)². Have exposed systemic flaws in how software is developed, maintained, and deployed. These incidents illustrate how a single weakness can cascade through supply chains, disrupt infrastructure, and erode trust in digital systems.

Modern development practices rely heavily on open-source components, with reuse accelerating exponentially. Between 2014 and 2023, software release frequency increased by 1466%, while known vulnerabilities (CVEs) grew by 463%³. The rise of supply chain attacks, including package poisoning and dependency confusion, further demonstrated how vulnerable the ecosystem has become.

camera

Regulatory Response: the Cyber Resilience Act

To address these risks, the EU introduced the Cyber Resilience Act (CRA). It establishes mandatory baseline security requirements for all products with digital elements marketed in the European Economic Area—including software, firmware, and hardware that connects to a network directly or indirectly during foreseeable use⁴.

The CRA applies across a wide landscape: from consumer IoT to embedded Linux systems, industrial controllers, and connected services. With over 40 billion connected devices projected by 2027⁵, the regulation aims to raise the cybersecurity baseline for an increasingly interconnected world.

Systems Impact

For developers and architects, the CRA codifies best practices as legal requirements: secure defaults, transparent supply chains, and timely vulnerability management. Meeting these obligations helps prevent large-scale exploits and simplifies assurance processes.

For customers and integrators, it brings visibility. The mandatory SBOM (Software Bill of Materials) enables faster risk assessment when CVEs are disclosed and makes product security postures auditable.

Security is no longer assumed—it must be demonstrated. The CRA turns this into a shared, enforceable responsibility across the product lifecycle.

What Software Providers and Developers Must Do

The Cyber Resilience Act introduces enforceable cybersecurity obligations for any company that develops, integrates, or distributes software in the EU market. Whether you’re building embedded systems, cloud-connected apps, or supplying third-party libraries, CRA compliance affects your release process, documentation, and lifecycle management.

Build Secure by Design

Eliminate known exploitable vulnerabilities before release
Apply secure defaults (no default passwords, close unused ports)
Minimize attack surface and enforce least privilege
Implement secure data handling (encryption in transit and at rest)
Integrate logging, monitoring, and mitigation mechanisms
Use secure and vetted third-party components
Document all of the above in your technical file

Tip: Treat threat modeling and security reviews as release criteria—not optional QA steps.

Generate and Maintain an SBOM

Create a machine-readable Software Bill of Materials (SPDX, CycloneDX)
Include all open-source and proprietary components
Keep it current with every build and make it accessible to authorities on request

Tip: Automate SBOM generation in your CI/CD pipeline.

Handle Vulnerabilities Responsibly

Monitor CVEs relevant to your components
Establish clear internal processes for triage, patching, and disclosure
Support coordinated vulnerability disclosure (CVD)

Tip: Maintain a public security contact and disclosure policy.

Report Exploited Vulnerabilities Within 24 Hours

If your product is under active attack, you must report it to ENISA (the European Union Agency for Cybersecurity) ⁶
Have internal alerting and workflows ready to meet this deadline

Tip: Link this process to your incident response runbook.

Deliver Free Security Updates for At Least 5 Years

Declare your support period clearly
Provide signed, secure updates for the full term
Keep records of your delivery mechanisms and update history

Tip: Include rollback or reset-to-safe mechanisms to meet “secure by default” expectations.

Complete Technical Documentation (Annex VII)

Describe the product and software versions
Include architecture, risk assessments, testing, update procedures, and SBOM
This file must be ready before market placement and kept up to date

Undergo the Right Conformity Assessment (Annex VIII)

Before a product can be placed on the EU market, manufacturers must demonstrate that it meets the CRA’s cybersecurity requirements. This is done through a conformity assessment—a formal process based on one of several predefined * modules*.

Modules are standardized procedures for proving compliance. They range from internal self-assessment to full third-party audits, depending on the product’s risk profile and classification.

Module A – Internal Production Control Most software providers will use this self-assessment path. You document how the product complies with CRA requirements, prepare technical documentation (Annex VII), issue a Declaration of Conformity, and apply the CE marking—no external party involved.
Modules B + C – EU-Type Examination + Production Control For products classified as critical (Annex III), a notified body first reviews the product’s design (Module B). The manufacturer then ensures production matches that approved design (Module C).
Module H – Full Quality Assurance For highly critical systems, this module requires a notified body to audit the manufacturer’s entire quality management system, including development, cybersecurity controls, and update procedures.

Tip: If your product functions as an OS, cryptographic module, network interface, or system-level component, consult Annex III early and prepare for third-party assessment.

Conclusion

The CRA sets a new standard for cybersecurity in digital products. It requires engineering teams to embed security into every phase—from design to updates. It gives customers better insight into product composition and risk.

Preparing early ensures compliance and builds stronger systems. As attacks grow more sophisticated, the CRA turns resilience into a product requirement—not a feature.

These steps aren’t just checkboxes—they form a continuous process. The CRA makes it clear: cybersecurity is a development responsibility, a documentation responsibility, and a business responsibility.