Updated: 27 August 2026
How do the CRA and NIS2 differ? The Cyber Resilience Act governs the security of a product placed on the EU market; the NIS2 Directive governs the security of an organisation providing services in sectors deemed important. Two different objects of regulation, two different bases of liability, two different reporting channels. An organisation that manufactures products and also operates in a NIS2 sector falls under both regimes in parallel and cannot discharge one through compliance with the other.
Canonical definition: The CRA and NIS2 are disjoint regimes: the CRA places obligations on the party placing a product with digital elements on the market, while NIS2 places them on an essential or important entity in respect of the services it provides.
CRA vs NIS2 – in brief:
- NIS2 is Directive (EU) 2022/2555, implemented through national law, with a transposition deadline of 17 October 2024. Implementation has been uneven: as of early 2026 a majority but not all member states had transposed it.
- The CRA is Regulation (EU) 2024/2847 and applies directly. Its reporting obligation starts on 11 September 2026 and full application follows on 11 December 2027.
- Reporting obligations look similar but are not identical: they differ in triggering event, recipient, channel and final report deadline.
- The real overlap sits in three process areas: vulnerability management, incident handling and supply chain security. Those three can be built once and used under both regimes.
- Documentation does not overlap. Technical documentation under the CRA and management system evidence under NIS2 go to different recipients and cannot substitute for each other.
- The dependency runs asymmetrically: NIS2 entities are accountable for supply chain security, so they will demand CRA conformity from suppliers well before December 2027.
- Patronusec delivers regulatory compliance projects spanning product and organisational requirements, including NIS2 support and readiness reviews for manufacturers.
How do the CRA and NIS2 differ structurally?
They differ in what they regulate, on what basis liability attaches, and what non-compliance costs. The CRA answers “may this product lawfully be sold in the EU”; NIS2 answers “does this organisation manage cybersecurity risk as the law requires”.
| Dimension | CRA | NIS2 |
|---|---|---|
| Object | product with digital elements | the organisation and the services it provides |
| Instrument | Regulation (EU) 2024/2847, directly applicable | Directive (EU) 2022/2555, via national law |
| Obligated party | manufacturer, importer, distributor | essential or important entity |
| Scope test | product type and availability on the EU market | sector, organisation size, role in the service |
| Evidence of compliance | technical documentation, declaration of conformity, CE marking | risk management measures, audit, registration |
| Consequence of failure | sales ban, product withdrawal or recall, fines | fines, supervision, management liability |
| Authority | market surveillance authority | competent authority and CSIRTs |
The practical consequence catches legal teams by surprise. A manufacturer can run a mature information security management system and still lose the right to sell after December 2027 if it has not completed conformity assessment. Conversely, an organisation selling fully compliant products remains accountable for its own risk management measures as an essential entity.
Organisational compliance does not transfer to the product, and product compliance does not discharge the organisation. These are separate bases of liability, enforced by different authorities.
Who falls under both regimes at once?
Dual compliance applies to any organisation that manufactures or places products with digital elements on the market and also meets the criteria for an essential or important entity. That group is wider than intuition suggests, because NIS2 expanded the sector catalogue substantially.
Organisation profiles that typically catch both regimes:
- A manufacturer of equipment for a regulated sector, such as industrial automation for energy, that also operates in a sector covered by national NIS2 law.
- A software vendor serving essential entities that itself falls within ICT service management.
- An infrastructure operator maintaining its own technical solutions and then selling them to third parties.
- A digital service provider with a hardware component, where the service falls under NIS2 and the device under the CRA.
- A consumer product manufacturer with a connected component, where the scale of operations crosses national thresholds in a covered sector.
There is an asymmetry here that forces earlier action. An essential entity is accountable for supply chain security, so it will demand product conformity evidence from suppliers. A manufacturer formally obligated only from December 2027 will meet those questions in procurement long before then, and “it does not apply to us yet” does not win tenders.
Where do the obligations genuinely overlap, and where do they only look similar?
The overlap is real in three process areas and illusory in documentation. Processes can be built once. Evidence has to be produced separately, because it goes to different recipients and covers different ground.
| Area | CRA requirement | NIS2 requirement | Can it be built once? |
|---|---|---|---|
| Vulnerability management | handling vulnerabilities in the product throughout the support period | managing vulnerabilities in the organisation’s systems | process yes, scope no: the CRA covers versions in customers’ hands |
| Incident handling | reporting actively exploited vulnerabilities and severe incidents | reporting significant incidents | one detection and escalation process, two reporting paths |
| Supply chain | requirements for components and an SBOM inventory | measures towards suppliers and security of acquired products | shared supplier assessment method, different acceptance criteria |
| Risk assessment | cybersecurity risk assessment for the product | risk analysis at organisation and service level | separate objects, shared methodology |
| Documentation | technical documentation retained for 10 years | management system documentation and audit results | disjoint, no substitution possible |
| Accountability | the party placing the product on the market | the entity’s management, with personal sanctions | disjoint |
The biggest saving sits in detection and escalation. An event is detected once and classified once; only at the end does the path fork into two notifications. Organisations that build these processes separately pay twice for the same operational capability and create the risk of divergent accounts of the same event in two reports.
How do CRA and NIS2 reporting obligations differ?
They differ in triggering event, recipient, channel and final report deadline. The 24-hour and 72-hour windows look identical, which routinely leads to the mistaken assumption that a single notification satisfies both.
| Element | CRA | NIS2 |
|---|---|---|
| Triggering event | actively exploited vulnerability in a product, or severe incident affecting its security | significant incident affecting the service provided |
| Who reports | the manufacturer | the essential or important entity |
| Recipient | CSIRT of the manufacturer’s main establishment, shared with ENISA | the relevant national CSIRT |
| Channel | single reporting platform operated by ENISA | national reporting system |
| Early warning | 24 hours | 24 hours |
| Full notification | 72 hours | 72 hours |
| Final report | 14 days after a corrective measure is available for a vulnerability, one month for a severe incident | one month |
The key practical difference concerns the independence of the two events. A vulnerability in your product can trigger the CRA obligation even where your own services were untouched and no NIS2 duty arose. Conversely, an incident in your infrastructure may require notification as an essential entity without touching any product you sell.
Identical 24-hour and 72-hour windows do not mean a single obligation. These are two notifications of different scope, sent through different channels, triggered by different events.
What does the combined obligation calendar look like?
The two regimes converge through 2026 and 2027. National NIS2 registration and readiness deadlines vary by member state, while CRA dates are fixed across the Union because the CRA applies directly.
| Date | Obligation | Regime |
|---|---|---|
| 17 Oct 2024 | NIS2 transposition deadline for member states | NIS2 |
| 11 Jun 2026 | rules on notifying conformity assessment bodies apply | CRA |
| 11 Sep 2026 | vulnerability and severe incident reporting begins | CRA |
| varies by state | national registration and implementation deadlines under transposing law | NIS2 |
| 11 Dec 2027 | full CRA application: essential requirements, conformity assessment, CE marking | CRA |
For organisations operating across several member states, the NIS2 line of this calendar has to be built per jurisdiction. Transposition dates, registration mechanisms and thresholds differ, and self-identification is generally the entity’s own responsibility rather than something a regulator initiates.
Patronusec Insight: Across dual-status projects one organisational pattern recurs: CRA duties land with product engineering and NIS2 duties with security or compliance, and both teams then build their own reporting processes. The consequence shows up during the first real event, when it emerges that they hold divergent definitions of a significant incident and two separate registers. Our recommendation is straightforward: one detection and classification process, one event register, forking only at the point of sending the notification. We usually run that consolidation under an IT Compliance Officer arrangement, because it needs continuous process work rather than a one-off document.
What do organisations get wrong when combining CRA and NIS2?
❌ Treating NIS2 compliance as covering the CRA – an information security management system does not replace product conformity assessment or technical documentation.
❌ Assuming one notification closes both obligations – triggering events, recipients and channels differ, and the CRA final report for a vulnerability runs to a different deadline than the NIS2 report.
❌ Building two independent detection processes – it doubles the cost and, at the first serious event, produces two inconsistent accounts of the same incident.
❌ Deferring CRA work to 2027 while supplying essential entities – product conformity questions arrive in procurement long before the regulatory deadline.
❌ Skipping self-identification under national NIS2 law – assessing your own status is the entity’s responsibility, and failing to register on time is a breach independent of your actual security posture.
❌ Limiting the component inventory to current products – the CRA reporting duty also covers versions sold earlier and still in use.
FAQ – CRA vs NIS2
Does NIS2 compliance mean CRA compliance?
No. NIS2 addresses risk management within an organisation; the CRA addresses the security of a product placed on the market. A mature management system eases CRA implementation and supplies some evidence, but it does not replace conformity assessment, technical documentation or CE marking.
Can a single event require two notifications?
Yes, where it concerns both a product in CRA scope and a service provided by an essential entity. The notifications then travel through different channels, cover different ground and carry different final report deadlines. Plan for this scenario before the first real event.
When do national rules implementing NIS2 apply?
Member states were required to transpose NIS2 by 17 Oct 2024, but implementation has run late in a number of jurisdictions, with several transposing laws entering force during 2026. Registration and implementation deadlines therefore have to be checked per country rather than assumed EU-wide.
Does a non-EU manufacturer fall under both regimes?
The CRA covers products made available on the EU market regardless of where the manufacturer is established, discharged directly or through an authorised representative. NIS2 covers entities providing services in the EU under national criteria. These are two independent scope tests to be run separately.
Which controls are worth building first under dual status?
Detekcję i klasyfikację zdarzeń wraz z jednym rejestrem, inwentarz komponentów obejmujący wersje w rękach klientów oraz metodykę oceny dostawców. Te trzy elementy obsługują oba reżimy i stanowią warunek wykonalności pozostałych obowiązków.
How does Patronusec support dual-status organisations?
We run a review covering product classification against the CRA, self-identification under national NIS2 law, and assessment of shared reporting processes. The output is a single action plan split into product and organisational duties, with named owners.
What to read next
A path from classification to operational readiness:
- Cyber Resilience Act – obligations and deadlines – a detailed breakdown of manufacturer duties and the CRA calendar.
- Ransomware response playbook – the first 72 hours – response mechanics inside the reporting windows of both regimes.
- Business continuity (BCM) in the age of cyber warfare – maintaining operations during a reportable event.
- IT security testing – how to choose the right method – the technical verification both regimes expect.
CRA vs NIS2 – free consultation
Patronusec delivers regulatory compliance projects spanning product and organisational requirements, for clients across industrial, financial and technology sectors.
