Cyber Resilience Act (Regulation 2024/2847) — obligations for products with digital elements, vulnerability disclosure, SBOM and security updates

The CRA, Regulation (EU) 2024/2847, was adopted on 23 October 2024 and entered into force on 11 December 2024. Full application of substantive obligations: 11 December 2027. Article 14 (active incident and exploited-vulnerability reporting) already applies from 11 September 2026 — so one of the most pressing deadlines for manufacturers falls in the next 16 months.

What is fundamentally new versus the previous regime: the CRA introduces CE marking for products with digital elements, exactly as CE marking worked for physical safety or electromagnetic compatibility. Cybersecurity becomes a condition for placing a product on the EU market.

TL;DR

• The CRA covers “products with digital elements” (PDE) — hardware or software with direct or indirect connection to a network or device.
• Three classes: standard (self-assessment), important class I/II, critical (third-party assessment + certification).
• Substantive obligations: secure-by-design, 5-year vulnerability handling, free security updates, SBOM, active incident reporting to ENISA.
• Full application 11 Dec 2027; active vulnerability reporting from 11 Sep 2026.
• Fines: up to 15 million EUR or 2.5% of turnover.

Scope — what is a product with digital elements (PDE)

Article 3 defines PDE as “any software or hardware product and its remote data processing solutions, including software or hardware components to be placed on the market separately”. The scope is intentionally broad. It covers:

• All IoT devices (from routers and NVRs to connected fridges).
• Commercial software (operating systems, applications, browsers, productivity suites, dev tooling).
• Hardware components with firmware (microcontrollers, motherboards).
• Cloud-connected solutions sold together with hardware or software.

Important exceptions (Art. 2):

• Medical devices (covered by MDR/IVDR).
• Motor vehicles (Reg. 2018/858, UNECE WP.29).
• Aviation (Reg. 2018/1139, EASA).
• Military equipment and national security.
• Non-commercial open-source software (see below).
• Pure SaaS (covered by NIS2 and DORA).

Open-source — critical clarification. The 2023-2024 debate on the CRA focused on impact on the open-source ecosystem. The final compromise introduced the “open-source software steward” concept for non-commercial projects and excludes personal/contributory OSS. Only commercialised OSS (offered as a product with paid support) falls under the CRA.

The three product classes

Article 7 plus Annexes III and IV split PDEs into:

Standard class (default). Most products — ordinary laptops, desktop software, consumer IoT. Self-assessment of conformity by the manufacturer + EU declaration of conformity + CE marking. Roughly 90% of PDEs land here.

Important class I (Annex III, Section 1). Products with a sensitive role in the security chain. The list includes: password managers, anti-malware, network firewalls, VPNs, identity management systems, browsers with enterprise functions, password managers in general. Requirement: self-assessment BASED ON A HARMONISED STANDARD (when published) or third-party assessment.

Important class II (Annex III, Section 2). More sensitive products: hypervisors, container runtimes, PKI systems, software HSM systems, IDS/IPS. Requirement: mandatory third-party assessment.

Critical (Annex IV). Small list of products deemed critical for NIS2/CER: smart meters with security functions, FIDO2 hardware tokens, smartcards with sensitive chips. Mandatory certification under EUCC scheme or equivalent.

The 13 substantive requirements (Annex I)

Annex I lists 13 essential requirements that any PDE must meet:

1. Secure-by-default. The default shipped configuration is secure. Admin passwords are not “admin/admin”.
2. Confidentiality protection — encryption in transit + at rest for sensitive data.
3. Integrity protection — against tampering with code, configuration data, user data.
4. Data minimisation — the product collects only data necessary for operation.
5. Availability protection — against DoS, including via rate limiting.
6. Attack surface minimisation — closed ports by default, unneeded services disabled.
7. Incident impact mitigation — logical segmentation, fail-safe defaults.
8. Logging and monitoring — relevant security events logged with timestamp and retention.
9. Secure update mechanism, automated where possible, with verified integrity.
10. Patch policy — free patches over a “support period” of at least 5 years.
11. Public vulnerability disclosure policy (security.txt + procedure).
12. Secure default with minimum user effort — security does not require advanced configuration.
13. Secure uninstall mechanism that correctly removes data.

All 13 are mandatory. The manufacturer cannot place the product on the market without meeting them.

Vulnerability handling — Annex I Section 2

In addition to the 13 product requirements, the manufacturer has process obligations:

• Component identification and documentation. SBOM (Software Bill of Materials) in machine-readable format (CycloneDX or SPDX). Must be available on request to authorities and updated at every release.
• Free patches without delay for discovered vulnerabilities throughout the support period.
• Effective and regular testing — internal pen-testing, fuzzing, code analysis.
• Coordinated public disclosure — once a patch is available, publish vulnerability information.
• Internal mechanism to receive reports from researchers (security.txt + bug bounty or equivalent).
• Simultaneous patch distribution to all affected users.

Article 14 — reporting to ENISA in 24h/72h

Article 14, applicable from 11 September 2026, is probably the most operationally inconvenient CRA requirement for manufacturers. Two reporting categories:

Actively exploited vulnerabilities.

• Early warning to ENISA (via the single reporting platform): 24 hours of awareness.
• Intermediate report with details and initial measures: 72 hours.
• Final report with root cause and corrective-permanent measures: 14 days after mitigation.
• Parallel notification to affected users.

Serious incidents affecting PDE security.

• Early warning: 24 hours.
• Detailed notification: 72 hours.
• Final report: one month.

Important: there is a single ENISA-operated central platform (single reporting) — no separate reporting per member state. National CSIRTs receive copies.

CE marking for cybersecurity

For the first time, CE marking explicitly covers cybersecurity requirements. The process:

1. Manufacturer assesses product class (standard / important / critical).
2. Applies the corresponding conformity procedure:
   • Standard: Module A (internal control) — self-assessment.
   • Important: Module B (EU-type examination) + Module C / Module H (full quality assurance).
   • Critical: Module H + EUCC certification.
3. Compiles technical documentation (SBOM, threat model, test reports, vulnerability disclosure policy).
4. Issues the EU Declaration of Conformity.
5. Applies the CE mark to the product or packaging.
6. Registers in the EU NANDO database (for important/critical classes that use a Notified Body).

Fines — up to 15 million EUR or 2.5%

Article 64 sets the maximum sanctions:

• Breach of essential requirements (Annex I): up to 15 million EUR or 2.5% of global turnover.
• Breach of other obligations (reporting, product recall): up to 10 million EUR or 2%.
• Providing false information to authorities: up to 5 million EUR or 1%.

In addition, the authority may order product withdrawal from the market, destruction of stocks and recall.

How Lexnomia helps

Lexnomia includes a CRA module that:

• Product inventory with auto-classification (standard/important/critical).
• SBOM tracker integrated with the CI/CD pipeline (CycloneDX + SPDX).
• Vulnerability handling workflow integrated with GitHub/GitLab security advisories + NVD CVE feed.
• Article 14 template for 24h/72h reporting to ENISA.
• Cross-mapping with ISO 27001:2022 (details) and NIS2 (checklist).

See also our article on on-premise SIEM with local LLM for Annex I requirement 8 (logging and monitoring).

Related articles

• NIS2 implementation — operational checklist for essential and important entities
• ISO/IEC 27001:2022 — migrating from the 2013 edition with the 93 controls reorganised
• From 10 vulnerabilities to 0 in 5 days: pre-production hardening of a legal platform
• On-premise SIEM with a local LLM: AI incident analysis without breaking confidentiality
• Pillar Lexnomia — the sovereign EU compliance platform

Next steps

For a CRA readiness assessment for your products, the Lexnomia page holds the CRA module. Or write to contact for a technical discussion.

References

• Regulation (EU) 2024/2847 (CRA) — consolidated text on EUR-Lex
• European Commission — CRA implementation page
• ENISA — Coordinated Vulnerability Disclosure
• CycloneDX — official SBOM specification
• SPDX — Software Package Data Exchange