11 June 2026
Rules on the notification of conformity assessment bodies
Only from here does the landscape of notified bodies build up. If you need third-party assessment, clarify availability early rather than shortly before market launch.
The Cyber Resilience Act makes cybersecurity a condition of market access. It applies directly as a regulation, without national implementing legislation, and it binds the manufacturer of a product with digital elements rather than the operator. This page sets out the duties, the deadlines and the boundary to NIS-2 and ISO 27001.
The CRA entered into force on 10 December 2024 and takes effect through staggered dates. The next one matters most, because it requires a process you cannot invent on the day.
11 June 2026
Rules on the notification of conformity assessment bodies
Only from here does the landscape of notified bodies build up. If you need third-party assessment, clarify availability early rather than shortly before market launch.
11 September 2026
Reporting obligations for actively exploited vulnerabilities and severe incidents
The 24-hour early warning is a crisis process in practice. It runs at night and at weekends. Anyone who settles thresholds, roles and sign-off only during an incident will miss the deadline.
11 December 2027
Full application, including conformity assessment and CE marking
From here, conformity decides lawful market access. It comes from security by design, ongoing vulnerability handling and technical documentation that grows with the product. It cannot be caught up later.
Products placed on the market before 11 December 2027 generally fall under the full duties only upon a substantial modification. The reporting obligations, however, also apply to products already made available.
The CRA requires product properties and lifecycle duties. Both sit in Annex I, and both are poorly met in practice, in different ways.
On the basis of the risk assessment under Article 13(2): placed on the market without known exploitable vulnerabilities and with a secure default configuration, vulnerabilities remediable through security updates, unauthorised access controlled and reported. Where automatic security updates are provided, Annex I Part I point 2(c) requires them to be installed by default, to carry a clear opt-out and to be temporarily deferrable by users. This is engineering work on the product.
Identify and document components and vulnerabilities, among other things through an SBOM in a commonly used machine-readable format covering at least the top-level dependencies. Remediate without undue delay, test regularly, run a CVD policy and provide updates throughout the defined support period. Security updates must be distributed without undue delay and, as a rule, free of charge; departures from that are limited to tailored products for business users. Fixed vulnerabilities must in principle be described publicly, with publication deferrable until users have had the opportunity to apply the patch. This is a standing duty, not a project.
The support period is neither a recommendation nor a guide figure. Under Article 13(8) third subparagraph it is at least five years; only a shorter expected product lifetime takes the place of that minimum. The determination is also bound: the second subparagraph requires it to reflect the expected use, taking account of users' expectations and the nature of the product. Security updates provided remain available under Article 13(9) for at least ten years or for the remainder of the support period, whichever is longer. Technical documentation and the EU declaration of conformity must be kept under Article 13(13) for at least ten years or for the duration of the support period, whichever is longer. And the period is not an internal figure: Article 13(19) requires the end date to be stated at the point of purchase in an easily accessible, clear and understandable way, giving at least the month and the year. Where technically feasible, users must also be shown a notice once that end is reached.
Reporting is separate from both. Vulnerability handling is a standing duty, reporting is an event duty. The same PSIRT function should serve both, but they are different processes.
Under the CRA the software bill of materials is no longer good practice but part of vulnerability handling under Annex I Part II. It is the data basis for the question that has to be answered in minutes during an incident: is the reported component in one of our products, and in which version.
Three things are often conflated. Creating it is mandatory: under Annex I Part II point 1, in a commonly used machine-readable format covering at least the top-level dependencies. Documenting it is too: Annex VII point 2(b) places the SBOM in the technical documentation, and point 8 additionally requires it on a reasoned request from the market surveillance authority, where that authority needs it to check the essential requirements. Publishing it is not required: recital 77 states expressly that manufacturers should not be obliged to publish the SBOM. Where a manufacturer does make it available to users voluntarily, Annex II point 9 only requires stating where it can be accessed.
In practice only an SBOM that comes out of the build pipeline and is versioned alongside the product holds up. A list compiled once is wrong on the day of the next release. As national guidance, BSI TR-03183 can help, with Part 2 covering the SBOM. It is freely available but not legally binding and creates no presumption of conformity.
Reports go SIMULTANEOUSLY to the CSIRT designated as coordinator and to ENISA, through the single reporting platform under Article 16. Not to one body that passes it on to the other. Two triggers: actively exploited vulnerabilities, and severe incidents affecting the security of the product.
Beyond reporting to the authorities, Article 14(8) requires manufacturers to inform the affected users and, where applicable, all users about the incident or vulnerability, where necessary including the mitigating and corrective measures users can take themselves, and where appropriate in a structured, machine-readable format. Reporting to the CSIRT does not replace that. If the manufacturer fails to inform users in time, the CSIRTs designated as coordinators may do so themselves.
A company can be a manufacturer under the CRA and an operator under NIS-2 at the same time, and in the financial sector fall under DORA as well. The duties overlap; they do not replace one another. Without a clear boundary you get either a double report with contradictory content or a reporting gap, because everyone relies on the other regime.
No, and the line is clear: between process and product, between management system and product law. The frameworks interlock rather than replace one another.
| Question | CRA | NIS-2 | ISO 27001 |
|---|---|---|---|
| Who does it bind? | The manufacturer of a product with digital elements | The operator, as an essential or important entity | The organisation seeking certification |
| What is the subject? | The properties and lifecycle duties of a product | The risk management of an organisation | The information security management system |
| How does it apply? | Regulation, directly in all member states | Directive, implemented nationally (in Germany in the BSIG) | Voluntary standard, effective through certificate and contract |
| How is compliance evidenced? | Conformity assessment, EU declaration of conformity and CE marking, graded by product class | Towards the supervisory authority, governed nationally | A certificate from a certification body, with recurring audits |
The consequence of a gap differs accordingly: under the CRA lawful market access falls away, because CE marking hangs on conformity. Under NIS-2 supervision steps in with orders and fines under the BSIG. What is proven at process level carries the product law duties of the CRA. It does not replace them. What is new in the CRA is above all the tie to placing on the market, conformity assessment with an EU declaration of conformity and CE marking, a defined support period, the mandatory SBOM and statutory reporting deadlines for product vulnerabilities.
How strictly a product is assessed does not follow from risk in general but from the class it falls into. Determine it too late and a mandatory third-party assessment can block your market launch.
Default product
As a rule self-assessment through internal control (Module A).
Important product, class I (Annex III)
Operating systems are among them. Self-assessment is permitted only where relevant harmonised standards, common specifications or a European certification scheme designated under Article 27(9) are applied in full, with a certificate at assurance level "substantial" or above. Otherwise a third-party assessment by a notified body is required.
Important product, class II (Annex III)
Firewalls and intrusion detection and prevention systems are among them. Third-party assessment is mandatory unless such a certification scheme is available and applicable. Article 32(5) sets out an exception: manufacturers of Annex III products that qualify as free and open source software may also use the procedure under paragraph 1 where the technical documentation is made publicly available at the time of placing on the market.
Critical product (Annex IV)
Its own, stricter requirements for evidence.
Since 28 November 2025, classification runs on Annexes III and IV of the CRA IN CONJUNCTION WITH Implementing Regulation (EU) 2025/2392, which describes their categories bindingly by core function. The Implementing Regulation does not classify individual products; which class a given product falls into should be checked against both acts in each case.
We provide the specialist assessment. The legally binding determination of whether and how the CRA applies to a particular product stays with a law firm.
This page gives the ordering. The derivation with sources sits in our knowledge section, which is published in German.
In a consultation we assess your scope: which products are covered, which class they fall into, and what gaps sit between where you are today and lawful market access.
Free consultationManufacturers of products with digital elements placed on the EU market, plus importers and distributors with duties of their own. Anyone who substantially modifies a product can be treated as a manufacturer. Unlike NIS-2, the CRA does not attach to sector and company size but to the product.
On 11 September 2026. Actively exploited vulnerabilities and severe incidents affecting the security of the product must be reported simultaneously to the CSIRT designated as coordinator and to ENISA. The early warning is due without undue delay and in any event within 24 hours of becoming aware. In addition, Article 14(8) requires the affected users and, where applicable, all users to be informed.
Creating it, yes: Annex I Part II point 1 requires an SBOM in a commonly used machine-readable format covering at least the top-level dependencies. Annex VII places it in the technical documentation, to be provided to the market surveillance authority on a reasoned request where that authority needs it. An obligation to publish it does not follow.
No. ISO 27001 describes the management system of an organisation; the CRA governs the properties and lifecycle duties of a product. A proven management system carries the CRA duties, it does not replace them. What is new is above all conformity assessment, CE marking, the support period, the SBOM and statutory reporting deadlines.
Not across the board, and the common shorthand is wrong: building in open source components does not make you the manufacturer of those components. The manufacturer is whoever develops a product, or has it developed, and markets it under their own name or trade mark. That manufacturer carries the duties for the overall product, including due diligence for integrated third-party components. For non-monetised free software there is generally no commercial activity. The CRA also creates a separate role for open source stewards, with duties of their own.
No. It is a legally binding manufacturer declaration that the product meets the essential requirements. The form of evidence is tiered: it depends on the product class and on whether harmonised standards are applied. There is no blanket certification.
Now, with inventory and classification. Conformity comes from security by design, ongoing vulnerability handling and documentation that grows with the product. This is not a project with a submission date but a control loop per product line, and it cannot be caught up before the deadline.