The EU Cyber Resilience Act makes cybersecurity a condition of selling almost any connected hardware or software product in the European Union, and since 11 September 2026 manufacturers have had 24 hours to warn the authorities about an actively exploited vulnerability. Regulation (EU) 2024/2847 entered into force on 10 December 2024 and its main obligations apply from 11 December 2027, leaving product teams one release cycle to build secure development, vulnerability handling and conformity evidence into how they ship. This guide covers scope, roles, the Annex I requirements, product categories and conformity assessment, reporting, support periods, SBOMs, CE marking, standards and penalties. It is written for product security leads, PSIRT teams, compliance owners and buyers who will ask suppliers for CRA evidence.
Key takeaways
- Scope is broad. Any hardware or software product made available on the EU market with a direct or indirect data connection to a device or network is in scope, including separately sold components.
- Reporting already applies. From 11 September 2026, actively exploited vulnerabilities and severe incidents go through ENISA's Single Reporting Platform: an early warning within 24 hours, a notification within 72 hours and a final report later.
- Security is a lifecycle duty. Annex I Part I sets product properties such as secure by default; Part II requires an SBOM, coordinated vulnerability disclosure and free security updates for a support period of normally at least five years.
- The product category sets the assessment route. Default products can self-assess; class I only with harmonised standards or certification; class II and critical products need a notified body or certification scheme.
- Fines reach EUR 15 million or 2.5% of worldwide turnover. That tier covers Annex I and Articles 13 and 14; lower tiers cover other duties.
Scope: what counts as a product with digital elements
Article 2(1) applies to products with digital elements made available on the market whose intended purpose or reasonably foreseeable use includes "a direct or indirect logical or physical data connection to a device or network": devices, applications, operating systems and separately sold components.
- Remote data processing: back-end processing that the manufacturer designs or controls, and without which the product could not perform one of its functions, is part of the product. Standalone SaaS not tied to a product generally falls under NIS2 rather than the CRA; check the Commission's guidance for borderline cases.
- Commercial activity: only products supplied in the course of a commercial activity are in scope. Non-monetised open source is not, nor are developers contributing to projects they are not responsible for.
- Legacy products: products placed on the market before 11 December 2027 are covered only if they undergo a substantial modification after that date, but the Article 14 reporting duty applies to them regardless.
| Excluded or limited | Legal basis | Practical note |
|---|---|---|
| Medical devices and in vitro diagnostic devices | Art. 2(2): Regulations (EU) 2017/745 and 2017/746 | Own sector rules. See the Medical Device Security Guide. |
| Motor vehicles and their systems | Art. 2(2): Regulation (EU) 2019/2144 | Aftermarket devices may still be in scope. See the Automotive Cybersecurity Guide. |
| Certified civil aviation products; marine equipment | Art. 2(3): Regulation (EU) 2018/1139; Directive 2014/90/EU | Only products certified or in scope under those acts |
| Certain products under Regulation (EU) No 168/2013 (two or three-wheel vehicles and quadricycles) | Delegated Regulation (EU) 2025/1535 under Art. 2 | Sectoral rules giving equal or higher protection |
| Spare parts replacing identical components | Art. 2 | Only like-for-like replacements |
| Products developed or modified exclusively for national security or defence | Art. 2 | Applies only to exclusive use |
Roles and obligations in the supply chain
| Role | Who | Core obligations |
|---|---|---|
| Manufacturer | Develops or has a product developed and markets it under its own name or trademark | Risk assessment, Annex I compliance, component due diligence, vulnerability handling, technical documentation, conformity assessment, declaration of conformity, CE marking, Article 14 reporting |
| Authorised representative | Appointed by written mandate | Delegated tasks such as cooperation with authorities; not the design obligations |
| Importer | EU-established, places a non-EU manufacturer's product on the market | Verify conformity assessment, technical documentation, CE marking and vulnerability handling; do not place non-compliant products; inform the manufacturer of vulnerabilities |
| Distributor | Makes products available without altering them | Verify CE marking, contact details, user information and support period; same non-compliance and vulnerability duties as importers |
| Open-source software steward | Legal person that systematically supports FOSS intended for commercial use, such as a foundation | Light-touch regime under Article 24: a cybersecurity policy, cooperation with authorities, reporting to the extent involved; not subject to fines |
An importer or distributor that puts its own name on a product, or substantially modifies it, takes on the manufacturer's obligations. So does any organisation that substantially modifies a product already on the market. For upstream projects, Article 13(6) requires manufacturers that find a vulnerability in an integrated component, including open source, to report it to whoever maintains that component. See the Open Source Security Guide.
Essential requirements: Annex I
Part I sets product properties, applied on the basis of the risk assessment. Part II sets vulnerability handling processes for the whole support period.
| Annex I reference | Requirement (summarised) | Typical engineering evidence |
|---|---|---|
| Part I (1), (2)(a) | Appropriate level of cybersecurity; no known exploitable vulnerabilities at release | Threat model, release gate on scanner and pen test findings |
| (2)(b), (2)(c) | Secure by default configuration; vulnerabilities addressable through security updates | Hardened defaults, reset to factory state, signed update mechanism with automatic updates where appropriate |
| (2)(d) | Protection from unauthorised access by appropriate control mechanisms | No shared default passwords, authentication on every management interface, role-based access |
| (2)(e), (2)(f), (2)(g) | Confidentiality and integrity of stored, transmitted and processed data; data minimisation | Encryption at rest and in transit, integrity checks on configuration and firmware |
| (2)(h), (2)(i) | Availability of essential and basic functions; minimise negative impact on other devices and networks | Rate limiting, denial of service resilience testing |
| (2)(j), (2)(k) | Limit attack surfaces; reduce incident impact with exploitation mitigation | Closed unused ports and services, memory-safe code or compiler mitigations, sandboxing |
| (2)(l), (2)(m) | Record and monitor relevant internal activity; let users securely remove all data and settings | Security event logs, secure wipe function |
| Part II (1) | Identify and document vulnerabilities and components, including an SBOM | Machine-readable SBOM per release covering at least top-level dependencies |
| Part II (2), (3) | Remediate without delay; effective and regular security testing | Patch SLAs, recurring testing in CI and before release |
| Part II (4), (5), (6) | Publicly disclose fixed vulnerabilities; enforce a coordinated vulnerability disclosure policy; facilitate vulnerability information sharing | Security advisories, CVE assignment, a published CVD policy and contact address |
| Part II (7), (8) | Securely distribute updates; disseminate security updates without delay and, unless otherwise agreed, free of charge | Signed updates, advisory messages to users |
The SBOM is part of the technical documentation, not something manufacturers must publish. Article 13(24) lets the Commission specify its format; until then SPDX or CycloneDX is the practical choice. For build integrity evidence behind the SBOM, see the SLSA and Build Provenance Guide.
Support period, updates and component due diligence
- Support period: Article 13(8) says it "shall be at least five years", unless the product's expected use time is shorter. The end date, at least month and year, must be clear at the time of purchase.
- Update availability: each security update must remain available "for a minimum of 10 years or for the remainder of the support period", whichever is longer (Art. 13(9)).
- Documentation retention: technical documentation and the EU declaration of conformity are kept for at least 10 years after placing on the market or for the support period if longer (Art. 13(13)).
- Component due diligence: exercise due diligence when integrating third-party components, including FOSS, so they do not compromise the product (Art. 13(5)). The SBOM is the evidence base for that work. See the Vulnerability Management Guide.
Important and critical products and conformity assessment
A product falls into a higher category when its core functionality matches a category in Annex III or IV. Implementing Regulation (EU) 2025/2392 gives the technical descriptions of each category, so check it rather than relying on the short Annex titles.
| Category | Examples from the Annexes | Permitted routes (Art. 32) |
|---|---|---|
| Default (most products) | Everything not listed in Annex III or IV | Module A internal control; or module B plus C; module H; or a European cybersecurity certification scheme |
| Important, class I (Annex III, 19 categories) | Identity management systems and privileged access management software and hardware; browsers; password managers; anti-malware; VPN; network management; SIEM; boot managers; PKI and certificate issuance software; operating systems; routers, modems and switches; smart home assistants and smart locks; connected toys; wearables | Module A only if harmonised standards, common specifications or a certification scheme were applied in full; otherwise module B plus C or module H |
| Important, class II (Annex III, 4 categories) | Hypervisors and container runtime systems; firewalls and intrusion detection and prevention systems; tamper-resistant microprocessors and microcontrollers | Module B plus C, module H, or a certification scheme at assurance level at least "substantial" |
| Critical (Annex IV, 3 categories) | Hardware devices with security boxes; smart meter gateways; smartcards and similar devices including secure elements | A European cybersecurity certification scheme under Article 8(1) where required; otherwise the class II routes |
- Open-source exception: FOSS products in Annex III categories may use module A if the Article 31 technical documentation is made public when the product is placed on the market.
- Notified bodies: Chapter IV has applied since 11 June 2026, so Member States can now notify bodies. Book early if you need module B or H.
- SMEs: Article 32(6) requires conformity assessment fees to take account of micro, small and medium-sized enterprises and be reduced proportionately.
Documentation, CE marking and harmonised standards
- Technical documentation (Annex VII): product description, design information, the risk assessment, applied standards, test reports, vulnerability handling process and SBOM.
- User information (Annex II): contact details, the single point of contact for vulnerability reports, secure installation and use, and the support end date.
- Declaration and marking: the EU declaration of conformity (Annex V, or the simplified Annex VI version) and the CE marking come after a successful conformity assessment and before placing on the market.
- Standards status: the Commission adopted standardisation request M/606 for 41 harmonised standards, horizontal ones such as vulnerability handling and vertical ones for Annex III and IV categories, prioritising important and critical products. The Commission page (updated 31 July 2026) describes them as under development and mentions none published in the Official Journal. Until they are, there is no presumption of conformity, which limits module A for class I products.
Reporting actively exploited vulnerabilities and severe incidents
Since 11 September 2026, manufacturers notify the coordinating CSIRT of their main establishment and ENISA simultaneously through the Single Reporting Platform (Art. 16). The Commission states the platform is operational and that "Manufacturers report only once through the CRA Single Reporting Platform (SRP)."
| Stage | Actively exploited vulnerability (Art. 14(2)) | Severe incident affecting product security (Art. 14(4)) |
|---|---|---|
| Early warning | Within 24 hours of becoming aware | Within 24 hours, stating whether unlawful or malicious acts are suspected |
| Notification | Without undue delay, within 72 hours, with available detail and corrective measures | Without undue delay, within 72 hours |
| Final report | No later than 14 days after a corrective or mitigating measure is available | Within one month after the incident notification |
- What is severe: an incident that affects, or could affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of important data or functions, or that could introduce malicious code into the product or users' systems (Art. 14(5)).
- Users: after becoming aware, the manufacturer informs impacted users, and where appropriate all users, with mitigation or corrective measures; CSIRTs may do so if the manufacturer does not act in time (Art. 14(11)).
- No EU establishment: Article 14(9) sets a fallback order for which Member State's CSIRT receives the report, starting with where the authorised representative is.
- Stewards: open-source software stewards report under Article 24(3) from 11 December 2027.
- Parallel clocks: an exploited vulnerability in your own product that also hits your own systems may need an NIS2 notification and a GDPR Article 33 notification. See the NIS2 Directive Guide and the Zero-Day and Exploited Vulnerabilities Guide.
Timeline and penalties
| Date | What applies |
|---|---|
| 10 December 2024 | Entry into force |
| 11 June 2026 | Chapter IV: notification of conformity assessment bodies |
| 27 July 2026 | Commission guidance C(2026) 5252 published (non-binding, with 67 practical examples) |
| 11 September 2026 | Article 14 reporting for manufacturers, including products already on the market |
| 11 December 2027 | All remaining obligations, including Annex I, conformity assessment, CE marking and steward reporting |
| 11 June 2028 | End of validity of earlier EU type-examination certificates issued for cybersecurity requirements, unless they expire sooner |
Article 64 sets maximum administrative fines, whichever is higher: up to EUR 15 million or 2.5% of total worldwide annual turnover for breaches of Annex I and Articles 13 and 14; up to EUR 10 million or 2% for other listed obligations, including those of importers and distributors; and up to EUR 5 million or 1% for incorrect or misleading information to notified bodies or market surveillance authorities. Micro and small manufacturers cannot be fined for missing the 24-hour early warning, and stewards cannot be fined at all. Market surveillance authorities can also order corrective action, withdrawal or recall.
Where identity fits
- Identity products are important products: identity management systems, privileged access management software and hardware, password managers and PKI software are Annex III class I. Their vendors cannot self-assess unless harmonised standards or certification are applied in full. See the Privileged Access Management Guide.
- Default credentials: Annex I Part I (2)(b) and (2)(d) make shared default passwords and unauthenticated management interfaces hard to defend. Unique per-device credentials or forced first-use setup are the safe pattern. See the Device and IoT Identity Guide.
- Signing and update keys: secure update distribution (Part II (7)) depends on the signing keys and CI publishing tokens behind each release. See the CI/CD Pipeline Identity Security Guide.
How to implement the CRA: a phased approach
- Inventory and classify (now): list every product sold in the EU, confirm scope, map each to default, class I, class II or critical using Implementing Regulation 2025/2392, and record your role per product.
- Stand up reporting (already overdue if not done): register on the Single Reporting Platform, define who decides "actively exploited", give the PSIRT authority to file a 24-hour early warning without waiting for legal sign-off, and rehearse with a tabletop that times all three stages.
- Set support periods: decide per product line based on expected use time, publish the end date at the point of sale, and check that component suppliers support their parts for as long.
- Gap-assess Annex I: score each product against Part I (2)(a) to (m) and Part II (1) to (8), using the risk assessment to justify any requirement treated as not applicable.
- Build the evidence pipeline: generate an SBOM and test records per build and assemble technical documentation from CI. Pilot on one product line and compare against a manual review before scaling.
- Choose and book conformity assessment: module A for default products, and for class I only once standards are cited; otherwise engage a notified body early in 2027.
- Prepare market placement: declaration of conformity, CE marking, Annex II user information and importer checklists. Keep the previous release channel as a rollback if a change to defaults breaks customer deployments.
Decision guidance
- Self-assessment or notified body: for class I products, self-assessment depends on standards that are not yet cited. If your release falls close to December 2027, plan for module B plus C or H and treat module A as a later saving.
- Five years or shorter: a shorter support period needs a documented expected use time.
- CRA or NIS2: the CRA regulates products you place on the market; NIS2 regulates how in-scope entities secure their own operations. A software vendor can be subject to both, with one incident triggering CRA product reporting and NIS2 entity reporting.
- Small manufacturers: start with reporting readiness, secure defaults, an SBOM and a CVD contact; the 24-hour fine exemption does not remove the duty to report.
- Open source: a foundation supporting commercial use may be a steward; a company that monetises its own FOSS product is a manufacturer.
Detection, measurement and framework mapping
Monitor exploitation signals: CVD and bug bounty reports, CISA KEV and CSIRT advisories, threat intelligence, support tickets and product telemetry. Metrics that show the programme works:
- Time to early warning: hours from awareness of active exploitation to SRP submission, against 24.
- SBOM coverage: percentage of released versions with a machine-readable SBOM.
- Time to fix: median days from vulnerability confirmation to available update, by severity.
- Known exploitable at release: releases shipped with known exploitable vulnerabilities (target zero).
| CRA requirement | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Risk assessment (Art. 13(2)) | ID.RA | RA-3, SA-8 | 8.26, 8.27 |
| Secure development and testing (Annex I) | PR.PS | SA-11, SA-15 | 8.25, 8.28, 8.29 |
| Component due diligence and SBOM | GV.SC, ID.AM | CM-8, SR-3, SR-4 | 5.21 |
| Vulnerability handling (Part II) | ID.RA, PR.PS | RA-5, SI-2 | 8.8 |
| Reporting (Art. 14) | RS.CO | IR-6 | 5.5, 5.26 |
This mapping is indicative. NIST's Secure Software Development Framework (SP 800-218) is a useful process baseline but is not a harmonised standard.
Common failure patterns
- Waiting for 2027: reporting has applied since September 2026, legacy products included. The Ivanti Connect Secure exploitation shows how fast a VPN zero-day becomes mass exploitation.
- SBOMs that stop at the manifest: top-level dependencies are the floor. The XZ Utils backdoor sat in a transitive dependency that many product teams did not know they shipped.
- Ignoring the build system: Annex I says nothing about CI, but a compromised build defeats every product property, as the SolarWinds supply chain compromise showed.
- Misclassifying the product: reading Annex III titles instead of the technical descriptions in 2025/2392 leads to the wrong assessment route.
- Unpriced support periods: committing to five years of free security updates without checking upstream component support.
Practitioner checklist
- Inventory EU products, confirm scope, and record role and Annex III or IV category per product.
- Register on the Single Reporting Platform and test the 24-hour, 72-hour and final report sequence.
- Publish a coordinated vulnerability disclosure policy and a single point of contact.
- Set and publish a support end date per product, at least five years unless justified.
- Generate a machine-readable SBOM for every release and keep it with technical documentation.
- Remove shared default credentials and enable secure, signed, automatic updates.
- Gap-assess every product against Annex I Parts I and II and keep the risk assessment current.
- Track harmonised standards under M/606 and book notified bodies for class I, II and critical products.
- Give importers and distributors a conformity evidence pack and a vulnerability contact.
Standards and references
- EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)
- European Commission: Cyber Resilience Act
- European Commission: Cyber Resilience Act, summary of the legislative text
- European Commission: CRA reporting obligations
- European Commission: Guidance to support timely Cyber Resilience Act implementation
- European Commission: CRA standardisation
- European Commission: CRA and open source
Related NHI Mgmt Group resources: NIS2 Directive Guide · Open Source Security Guide · SLSA and Build Provenance Guide · Global Cybersecurity Regulatory Map. This guide summarises Regulation (EU) 2024/2847 and Commission guidance as of 17 October 2026 and is not legal advice.