The Cyber Resilience Act Explained: What Software Makers Must Do

The EU Cyber Resilience Act (CRA) is one of the most far-reaching pieces of technology regulation Europe has produced — and one of the least understood. Where the GDPR governs personal data and the AI Act governs artificial intelligence, the CRA governs the security of products themselves. If your product has digital elements and is sold in the EU, it almost certainly applies to you.

With key obligations phasing in over the next year, software and hardware makers can no longer treat security as a best-effort afterthought. The CRA turns it into a legal requirement backed by significant penalties, and preparation needs to start now.

What the CRA covers

The CRA applies to “products with digital elements” — an intentionally broad category covering software, connected hardware and the components in between. From operating systems and applications to smart devices and industrial controllers, almost anything that processes data or connects to a network falls within scope.

There are nuances: certain products already regulated by sector-specific rules are carved out, and open-source software developed outside a commercial context receives lighter treatment. But the default assumption for any vendor should be that the CRA applies unless a clear exemption exists.

The core obligations

The CRA imposes duties across the entire product lifecycle, not just at launch. Manufacturers must build security in by design, ship products with secure default configurations, and provide security updates for a defined support period. They must also handle vulnerabilities responsibly and document the product’s security properties.

• Secure by design: address security from the start of development, not as a patch later
• Secure defaults: ship with safe configurations rather than convenient-but-risky ones
• Vulnerability handling: maintain a process to find, fix and disclose flaws
• Security updates: provide patches throughout a declared support period
• Documentation: produce a software bill of materials and clear security information
• Incident reporting: notify authorities of actively exploited vulnerabilities promptly

The vulnerability-reporting duty

One of the CRA’s most operationally demanding requirements is rapid reporting of actively exploited vulnerabilities and serious incidents to the relevant authorities. This is not a once-a-year compliance exercise; it requires an always-on capability to detect, assess and report problems within tight deadlines.

For many vendors, building this capability is the heaviest lift the CRA demands. It means monitoring, triage processes, defined responsibilities and the ability to communicate quickly with both authorities and customers when something goes wrong.

The software bill of materials

The CRA effectively mandates a software bill of materials (SBOM) — a complete inventory of the components, including open-source dependencies, that make up a product. Modern software is assembled from many third-party parts, and an SBOM lets both vendors and regulators understand what is inside and react quickly when a component is found to be vulnerable.

Producing and maintaining an SBOM is good engineering practice regardless of regulation, and tooling has matured to make it manageable. Vendors who adopt it early will find CRA compliance considerably easier than those who leave their dependency graph undocumented.

How to prepare

The worst approach is to wait. The CRA rewards organisations that treat security as a continuous discipline and punishes those who bolt it on at the end. A sensible preparation programme:

1. Determine which of your products fall within scope and how they are classified
2. Audit your current security practices against the CRA’s requirements
3. Establish a vulnerability-handling and disclosure process
4. Start generating and maintaining SBOMs for your products
5. Define and commit to a security-update support period
6. Build the incident-reporting capability the law requires

The upside

It would be easy to read the CRA purely as a burden, but it also levels the playing field. By making security a baseline legal requirement, it stops vendors who cut corners from undercutting those who invest in doing things properly. For European software companies that already take security seriously, the CRA turns a quiet virtue into a competitive advantage.

Open source and the CRA

One of the most debated aspects of the Cyber Resilience Act is how it treats open-source software. Early drafts alarmed the open-source community, which feared that volunteer maintainers could be saddled with onerous obligations and liability for software they give away for free. The final text introduced important nuances to address this.

Broadly, open-source software developed and supplied outside the course of a commercial activity receives lighter treatment, while a new role of ‘open-source software steward’ carries lighter-touch duties than a full manufacturer. The obligations bite hardest where open source is commercialised — integrated into a product and sold — at which point the commercial entity, not the upstream volunteer, bears responsibility.

The practical message for businesses is that using open-source components does not exempt you from the CRA; if you ship a product built on open source, you are responsible for its security. This makes the software bill of materials and good dependency hygiene not just best practice but compliance necessities. It also strengthens the case for supporting the open-source projects you depend on, since their security is now your security.

The timeline you need to know

The CRA does not arrive all at once. Its obligations phase in over a staged timeline, giving manufacturers time to adapt — but the deadlines arrive sooner than complacent organisations expect, and some duties precede others. The vulnerability and incident-reporting obligations, in particular, come into force ahead of the full set of requirements.

This phasing rewards early movers and punishes procrastinators. Building the necessary capabilities — secure development practices, SBOM generation, a vulnerability-handling process, an incident-reporting pipeline — takes months, not weeks, especially for organisations starting from a low base. The sensible posture is to treat the earliest deadline as the planning horizon and work backwards, rather than waiting for the full regime to land.

• Lighter obligations for non-commercial open source and stewards
• Full manufacturer duties when open source is commercialised
• Reporting duties arrive ahead of the complete requirement set
• Capability-building takes months — start from the earliest deadline

Conclusion

The Cyber Resilience Act represents a fundamental shift: security is now a legal obligation woven through the entire product lifecycle, not an optional extra. The breadth of the law means almost every software and hardware maker selling into the EU must engage with it.

The vendors who thrive will be those who treat the CRA not as a checkbox but as an accelerant for practices they should have already adopted — secure design, transparent dependencies and responsible vulnerability handling. Start now, and compliance becomes a byproduct of good engineering rather than a last-minute scramble.