EU Cyber Resilience Act

The Cyber Resilience Act — Regulation (EU) 2024/2847 — makes cybersecurity a condition of selling any product with digital elements in the EU. Manufacturers must ship without known exploitable vulnerabilities, provide security updates for a defined support period, maintain a vulnerability handling process, produce an SBOM, and CE-mark the product. It is a regulation, not a directive — it applies directly and identically in every Member State, with no national transposition.

If your product has software in it, or connects to anything, the CRA probably applies to you. That includes industrial machinery, medical-adjacent hardware, consumer electronics, mobile apps, desktop software, and standalone SaaS-adjacent components — a far wider net than most manufacturers assumed when it was drafted.

---

The deadlines

Date	What applies
10 Dec 2024	CRA entered into force
11 Jun 2026	Conformity assessment bodies can be notified
11 Sep 2026	Article 14 reporting obligations apply — actively exploited vulnerabilities and severe incidents
11 Dec 2027	Full application — all obligations, CE marking under the CRA

The near-term deadline is the one being missed. Most manufacturers have planned around December 2027 and have not built the 24-hour reporting capability that became live in September 2026. Reporting duties arrived roughly fifteen months before the rest of the regulation.

---

Does the CRA apply to you?

Products with digital elements

The scope is products with digital elements (PDEs): any software or hardware product, and its remote data processing solutions, that can be connected — directly or indirectly — to a device or network.

That is deliberately broad. It captures embedded firmware, operating systems, applications, libraries sold commercially, and connected hardware of nearly every kind.

Which role are you in?

Role	Trigger
Manufacturer	You develop or manufacture, or have it developed/manufactured and market it under your name or trademark
Importer	You place a third-country product on the EU market
Distributor	You make it available without being manufacturer or importer

Two traps:

• Rebranding makes you the manufacturer. Put your name on someone else's product and you take on the full obligations.
• Substantial modification makes you the manufacturer. Materially change a product after it is placed on the market and you assume manufacturer duties for the modified version.

What is excluded

Products already covered by equivalent sectoral rules: medical devices, in-vitro diagnostics, motor vehicles, civil aviation, and marine equipment. Products developed exclusively for national security or defence, and certain spare parts.

Open source is the nuanced case. Free and open-source software supplied outside commercial activity is largely out of scope, and the regulation introduces a lighter category of open-source software steward. But monetisation — paid support, commercial distribution, some sponsorship arrangements — can pull a project into scope. This is the single most-litigated interpretation question in the CRA and guidance is still developing. If you monetise OSS in any form, get advice rather than assuming exclusion.

---

Product classification — this determines everything

Classification decides whether you can self-assess or must involve a third party.

Class	Basis	Conformity route
Default	Everything not listed in Annex III or IV	Self-assessment (internal control)
Important, Class I	Annex III, Class I	Self-assessment only if harmonised standards are applied in full — otherwise third party
Important, Class II	Annex III, Class II	Third-party assessment mandatory
Critical	Annex IV	May require European cybersecurity certification (EUCC)

Important — Class I includes identity and privileged access management, browsers, password managers, anti-malware, VPNs, network management systems, SIEM, boot managers, PKI and certificate issuance, network interfaces, operating systems, routers/modems/switches, microprocessors and microcontrollers with security-related functions, smart home assistants, smart locks and security cameras, connected toys with social interaction or location tracking, and personal wearables for health monitoring.

Important — Class II includes hypervisors and container runtimes, firewalls, intrusion detection and prevention systems, and tamper-resistant microprocessors and microcontrollers.

Critical (Annex IV) covers hardware devices with security boxes, smart meter gateways, and smartcards or similar devices including secure elements.

Roughly 90% of products land in default and can self-assess. But if you build an OS, a router, a firewall or a hypervisor, you cannot — and third-party assessment capacity is only now coming online, which makes queueing a real scheduling risk for December 2027.

---

What you must do — Article 13

1. Cybersecurity risk assessment

Documented, covering the whole lifecycle, included in the technical documentation, and updated as the product changes. It must demonstrably drive which Annex I Part I requirements apply and how.

2. Annex I Part I — essential requirements (secure by design)

Requirement	In practice
No known exploitable vulnerabilities at release	Gate releases on scan + triage
Secure by default configuration	No default passwords; hardened defaults; reset to secure state
Protection from unauthorised access	Authentication, identity and access management
Confidentiality	Encryption at rest and in transit
Integrity	Of data, commands, configuration, program state
Data minimisation	Only what is adequate, relevant and limited to purpose
Availability	Resilience to DoS; essential functions protected
Limit impact on other devices/networks	Don't let your product become the attack platform
Minimise attack surface	Including external interfaces
Exploitation mitigation	ASLR, stack protection, sandboxing
Security logging and monitoring	With opt-out where appropriate
Secure deletion / export of user data	Factory reset that genuinely erases
Secure — and where feasible automatic — update distribution	With clear opt-out and user notification

3. Annex I Part II — vulnerability handling

This is the operational core, and where most manufacturers are weakest:

• SBOM, machine-readable, covering at minimum top-level dependencies — see SBOM Explained
• Address and remediate vulnerabilities without delay, including by providing security updates
• Regular testing and review of product security
• Publish information about fixed vulnerabilities once a fix is available
• Publish a coordinated vulnerability disclosure policy
• Publish a contact address for reporting vulnerabilities
• Mechanism for secure distribution of updates
• Security updates free of charge and without delay, distributed separately from functional updates where feasible

4. Support period

You must define and publish it. Minimum five years, unless the product's expected lifetime is shorter — and if it is, you must justify that. During the support period you owe security updates.

For products with lifetimes measured in decades — industrial machinery, infrastructure hardware — this is a significant and often unbudgeted commitment.

5. Technical documentation and CE marking

Annex VII technical documentation, an EU Declaration of Conformity (Annex V), and CE marking. Documentation must be retained 10 years after placing on the market, or for the support period, whichever is longer.

---

Article 14 — the reporting duty already in force

Live since 11 September 2026. Two triggers, reported to the designated coordinating CSIRT and ENISA through the single reporting platform.

Trigger A: an actively exploited vulnerability in your product. Trigger B: a severe incident having an impact on the security of your product.

Stage	Deadline	Content
Early warning	24 hours from awareness	That it exists; Member States affected, if known
Notification	72 hours from awareness	General information, severity, impact, corrective or mitigating measures, IoCs where available
Final report	14 days (exploited vulnerability, once a corrective measure is available) or 1 month (severe incident)	Description, severity, impact, root cause, mitigations applied

You must also notify affected users of the incident or vulnerability and, where necessary, of corrective measures.

The hard part is not the templates — it is the clock. Practical readiness means: a named 24/7 owner, a written definition of what event constitutes awareness, triage criteria decided in advance, platform access provisioned before you need it, and at least one tabletop exercise run against the 24-hour deadline. Almost nobody has done the last one.

Reporting is required even when no fix exists yet. Do not wait for a patch before reporting.

---

Penalties

Breach	Maximum
Essential requirements (Annex I) or Art. 13/14 obligations	€15m or 2.5% of total worldwide annual turnover, whichever is higher
Other obligations	€10m or 2%
Supplying incorrect, incomplete or misleading information	€5m or 1%

Verify these against Art. 64 before publishing — penalty tiers are frequently misreported.

Beyond fines, market surveillance authorities can require corrective action, restrict availability, or order withdrawal or recall from the market. For a hardware manufacturer, recall is the risk that dwarfs the fine.

---

CRA vs NIS2 — they are not the same thing

Companies routinely conflate these. They regulate different objects.

	CRA	NIS2
Instrument	Regulation — directly applicable	Directive — transposed nationally
Regulates	Products you place on the market	Organisations operating in listed sectors
Who	Manufacturers, importers, distributors	Essential and important entities
Core duty	Product security + vulnerability handling	Organisational risk management + incident reporting
Reporting to	CSIRT + ENISA	National CSIRT / authority
Marking	CE marking	None

You can easily be subject to both. A German machinery manufacturer with 200 employees is an important entity under NIS2 (Annex II manufacturing) and a manufacturer under the CRA for the machines it sells. Two regimes, two sets of duties, two reporting cascades with different deadlines and different recipients.

See NIS2 Explained.

---

Where to start

1. Determine scope and classification, in writing. Default, Important I/II, or Critical decides whether you need a third party — and third-party capacity is finite before December 2027.
2. Build the Art. 14 reporting capability now. It is already live and it is the one you cannot retrofit under incident pressure.
3. Generate an SBOM and wire it into CI. Everything in vulnerability handling depends on knowing what you ship.
4. Publish a CVD policy and a security contact. Cheap, fast, and explicitly required.
5. Define and publish the support period. It has budget consequences — decide it deliberately, not by default.
6. Gap-assess Annex I Part I with evidence, not assertions.
7. Then build the technical documentation to Annex VII.

Most programmes start at step 7 because it feels like the deliverable. Steps 2 and 4 are the ones an authority can check tomorrow.

---

FAQ

What is the Cyber Resilience Act? Regulation (EU) 2024/2847, setting mandatory cybersecurity requirements for products with digital elements sold in the EU, including secure design, vulnerability handling, security updates and CE marking.

When does the CRA apply? Reporting obligations under Art. 14 from 11 September 2026; full application including CE marking from 11 December 2027.

Does the CRA apply to software only, or hardware too? Both. Any product with digital elements, including embedded firmware, plus their remote data processing solutions.

Does the CRA apply to open source? FOSS supplied outside commercial activity is largely out of scope, and there is a lighter open-source steward category. Monetisation can bring a project into scope, and interpretation here is still developing.

Do I need a third party to assess my product? Only if it is Important Class II or Critical, or Class I without full application of harmonised standards. Most products self-assess.

Is an SBOM mandatory under the CRA? Yes — Annex I Part II requires a machine-readable SBOM covering at minimum the top-level dependencies.

How long must I provide security updates? For the defined support period — minimum five years unless the expected product lifetime is shorter and you justify it.

What are the CRA penalties? Up to €15m or 2.5% of worldwide annual turnover for breaches of the essential requirements or Art. 13/14 obligations.

Is the CRA the same as NIS2? No. The CRA regulates products; NIS2 regulates organisations. Many companies are subject to both.

---

Next step

→ CRA Product Classification Checker — default, Important or Critical?

Related reading:

• CRA Article 14: the 24-hour reporting obligation in detail
• SBOM Explained: what the CRA actually requires
• PSIRT: building a product security incident response team
• Coordinated Vulnerability Disclosure: policy template
• NIS2 Explained