The Cyber Resilience Act (CRA) makes cybersecurity a condition for the CE marking. From 11 December 2027, a product with digital elements can only be placed on the EU market if the manufacturer can prove it was built securely and will be kept secure. Part of the law already applies: since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents within 24 hours, for every product they have on the market.
This summary is based on my talk “Surviving EU CRA: what manufacturers must prove” at BSides Krakow in September 2026.
A regulation, not a directive
The CRA is an EU regulation, like GDPR. That matters for how you plan:
| EU regulation (CRA, GDPR) | EU directive (NIS2) | |
|---|---|---|
| Directly applicable | Yes | No, needs national legislation |
| Uniform across the EU | Fully | Varies by member state |
| Binding | Entirely | In terms of its goals |
| Room for national variation | None | Yes |
The two laws also protect different things. NIS2 protects critical sectors, the organizations operating in them, and everyone who depends on their continuity. The CRA protects consumers and businesses by making sure the products they buy are secure throughout their lifecycle. An organization can fall under both: NIS2 as an operator, the CRA as a manufacturer.
The CRA was published in the Official Journal on 20 November 2024 and entered into force on 10 December 2024.
What it covers
The CRA applies to products with digital elements: “a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately.”
In practice that covers almost everything with software in it: consumer electronics, boxed and downloadable software, engineering applications such as CAD, smart home systems, connected industrial machinery, and the cloud backends those products need to work. Components sold separately, such as libraries or chips, are products in their own right.
Some sectors are excluded because they have their own product safety rules: medical and in-vitro diagnostic devices, motor vehicles, civil aviation, marine equipment, and products developed exclusively for national security or defence. Rail isn’t on the exclusion list, which makes it a grey area worth checking for each product. Pure SaaS falls outside the CRA unless it is the remote data processing of a product.
“Placed on the market” decides when the rules bite
A product is placed on the market when a manufacturer or importer first supplies it to a distributor or end user in the EU. The rules apply at that moment, per individual unit. A device that leaves your warehouse on 10 December 2027 doesn’t need to meet the CRA; an identical one shipped a day later does.
There is one important exception. The reporting obligations apply to every product in scope, including products placed on the market long before December 2027. Your installed base is already covered.
The timeline
| Date | What applies | Status |
|---|---|---|
| 10 December 2024 | The CRA enters into force. | Done |
| 11 June 2026 | Rules for conformity assessment bodies. Member states can notify the bodies that assess products. | In force |
| 11 September 2026 | Reporting of actively exploited vulnerabilities and severe incidents, for all products in scope. | In force |
| 11 December 2027 | All obligations. New products need a CE marking that covers cybersecurity. | Upcoming |
Product classes decide the conformity route
| Category | Examples | Conformity assessment |
|---|---|---|
| Default lowest risk | General-purpose software and apps, office IT hardware, smart office devices without a security function, consumer devices used in business. About 90% of products. | Internal control (module A). A manufacturer may choose a third-party assessment voluntarily. |
| Important, class I elevated risk | Password managers, browsers, operating systems, SIEM systems, identity management software, VPNs, routers | Internal control (module A) only if harmonised standards, common specifications or EU cybersecurity certification are applied in full. Otherwise a notified body. |
| Important, class II significant risk of disruption | Hypervisors and container runtimes, firewalls and intrusion detection or prevention systems, including industrial ones, tamper-resistant microprocessors and microcontrollers | Always third party: a notified body, or EU cybersecurity certification. |
| Critical critical infrastructure | Smart meter gateways, hardware security modules, smartcards and secure elements | A European cybersecurity certificate at assurance level "substantial" or higher where the Commission requires one; otherwise the class II route. |
For class I products, the availability of harmonised standards decides whether internal control (module A) is enough or you need a notified body. The standards are being finalized now; see our overview of the CRA harmonised standards for where each one stands.
What manufacturers must prove
From December 2027, every product needs:
- an EU declaration of conformity
- technical documentation, including the cybersecurity risk assessment
- security by design and by default
- vulnerability handling, including an SBOM and a coordinated vulnerability disclosure policy
- security requirements derived from that risk assessment
Two numbers to plan around. Manufacturers must provide security updates for a support period of at least five years, unless the product is expected to be in use for less. And they must keep the technical documentation and declaration of conformity available to authorities for ten years after the product is placed on the market, or for the support period if that’s longer.
There is no checklist
This is the part that surprises most management teams. The CRA doesn’t give you a list of controls to tick off. It sets essential requirements and expects each manufacturer to define its own reasonable requirements and controls, based on a risk analysis of its product. Two products in the same category can end up with different controls, and both can be compliant, as long as the reasoning is documented.
Harmonised standards will guide that process and give presumption of conformity once they’re cited in the Official Journal. They don’t remove the need for your own risk analysis.
Reporting already applies
Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of their products. Reports go through ENISA’s single reporting platform to the national CSIRT designated as coordinator and to ENISA:
- an early warning within 24 hours of becoming aware
- a notification within 72 hours
- a final report within 14 days after a fix is available for a vulnerability, or within one month for a severe incident
Manufacturers must also inform affected users and tell them how to mitigate the problem. A 24-hour deadline is only realistic with a tested process: someone has to recognize a report as reportable, have the authority to file it, and know where.
What non-compliance costs
| Infringement | Maximum fine, whichever is higher |
|---|---|
| Not meeting the essential cybersecurity requirements or the manufacturer's obligations, including reporting | €15 million or 2.5% of worldwide annual turnover |
| Other obligations, such as administrative requirements | €10 million or 2% of worldwide annual turnover |
| Giving incorrect, incomplete or misleading information to notified bodies or market surveillance authorities | €5 million or 1% of worldwide annual turnover |
The bigger risk is often not the fine. Market surveillance authorities can order a non-compliant product to be withdrawn or recalled. Without a valid CE marking, you have no EU market.
How to get there
Compliance is a property of how you build and maintain products, not of a document you write before the deadline. In practice it means a secure software development lifecycle with evidence at every stage:
- Risk assessment
- Threat modeling
- Security requirements
- Secure implementation
- SBOM
- Functional and non-functional security testing
- Secure configuration and user documentation
- Continuous monitoring of third-party vulnerabilities
- Incident response
A maturity model such as OWASP SAMM gives that lifecycle a structure: you assess where you are, set targets per practice, and show progress over time. Our comparison of SAMM and BSIMM explains how to choose a model.
What to do now
- Make sure you can report within 24 hours today. That obligation already applies to everything you have on the market.
- List your products with digital elements and classify each one: default, class I, class II or critical. The class decides whether you need a notified body, and notified body capacity is limited.
- Run a gap assessment of your development and vulnerability handling processes against the essential requirements.
- Start the risk assessments and technical documentation for products you’ll still sell after December 2027.
- Decide who owns CRA compliance. It touches engineering, product management, legal, support and procurement, and it fails when it’s left to one team.
For a first indication of where you stand, take the free EU CRA Self Assessment or book a free EU CRA strategy call. When you’re ready for a structured program, the EU CRA Compliance Journey takes you from reporting-ready to CE conformity. For a more detailed walkthrough of the obligations, read our CRA guide for SMBs.