The EU Cyber Resilience Act: A 2026 Software Guide

There is a new compliance deadline coming for anyone who sells software in Europe, and unlike the AI Act it is not aimed at frontier labs. The EU Cyber Resilience Act (CRA) sets baseline security rules for "products with digital elements", which is regulator language for almost any software or connected device sold on the EU market. It entered into force on 10 December 2024, and the first hard obligation lands on 11 September 2026: from that day, manufacturers must report actively exploited vulnerabilities and serious incidents on a 24-hour clock.

The full regime, secure-by-design engineering, a CE mark on your software, and a documented support period, applies from 11 December 2027. That sounds far away until you realise the things the CRA expects (a software bill of materials, a vulnerability-handling process, a support commitment) take months to build into how a team actually ships. The deadline is not the day you start; it is the day you must already be done.

Here is who the CRA covers, what it asks for in plain terms, and the short list of things worth starting this quarter.

Does the CRA apply to you?

The scope is broad on purpose. The CRA covers any "product with digital elements" made available on the EU market: desktop and mobile apps, firmware, libraries, operating systems, and connected hardware. It does not matter where your company is based, the same way GDPR does not. If EU users can buy or install it, you are in scope.

Two exclusions matter. Pure SaaS and cloud services are largely outside the CRA, because a service you host and run is regulated under NIS2 rather than as a product placed on the market. The line gets blurry when a remote component is essential to a physical or downloadable product, so a connected device with a companion cloud backend is usually in. Open-source software is only caught when it is commercially distributed, so a maintainer publishing a free library is not a "manufacturer", but a company that bundles and sells it is.

What the CRA actually requires

Strip away the annexes and the CRA asks for four habits that good teams already aspire to, now made mandatory and auditable.

• Secure by design. Products must ship with a secure default configuration, no known exploitable vulnerabilities at release, and a sensible attack surface. Annex I, Part I spells out the product requirements; the point is that security is a design input, not a patch you add later.
• A software bill of materials (SBOM). You have to maintain a machine-readable list of the components and dependencies in your product. It does not have to be published, but it has to exist, so that when a CVE hits a library you can answer "are we affected?" in minutes, not weeks.
• Vulnerability handling across a support period. You must define how long you will support the product, monitor for vulnerabilities, and ship free security updates during that window. The support period has to be realistic for how long people actually use the thing.
• Conformity and the CE mark. Most software self-assesses and then carries a CE mark from December 2027. "Important" and "critical" categories (Annex III and IV: think password managers, firewalls, routers, operating systems, hardware security modules) face stricter checks, with third-party assessment for the higher tier.

If your product sits in one of those important or critical classes, start the conformity question early, because a notified-body assessment is not something you arrange the week before launch.

The reporting clock starts in September 2026

The single most time-sensitive piece is reporting, and it arrives well before the rest. From 11 September 2026, if you become aware of a vulnerability in your product that is being actively exploited, or of a serious security incident affecting it, you owe a tight sequence of notifications to ENISA and the relevant national CSIRT.

1. Within 24 hours: an early warning that something is happening.
2. Within 72 hours: a fuller notification with the details you have.
3. Within 14 days: a final report once a corrective measure (a patch or mitigation) is available.

Twenty-four hours is not long if nobody owns the decision. The practical work is naming the person who makes the call, writing the playbook before you need it, and making sure your support and engineering teams know that "actively exploited" triggers a regulatory clock, not just an internal ticket.

What to do in the next few weeks

You do not need a compliance department to make real progress before September. Start narrow and concrete.

• Inventory your products and decide, for each, whether it is in CRA scope and whether it falls in a standard, important, or critical class.
• Generate an SBOM for anything in scope. Modern build tools and dependency scanners produce one automatically, so this is mostly wiring, not theory. It also pays off immediately the next time a dependency has a CVE.
• Write a one-page vulnerability-handling policy: how issues are reported to you, how fast you triage, and your committed support period per product.
• Stand up the reporting playbook for the September clock, with a named owner and a tested path to ENISA and your national CSIRT.

This is the same "design it in now, do not retrofit under deadline pressure" lesson from the EU AI Act and your chatbot and the Digital Product Passport. Teams already practising secure development for AI features will find most of the CRA is formalising what they do, not inventing new work.

If you want a candid read on whether your product is in scope, which class it lands in, and the shortest path to an SBOM and a working reporting process, talk to us. We will map the parts that apply to you and, just as usefully, the parts you can ignore.