NIS2 regulates how an organisation secures the services it runs; the Cyber Resilience Act regulates how a product is built and supported, and a company that does both can owe two reports for one exploited flaw. NIS2 (Directive (EU) 2022/2555) places risk-management and incident reporting duties on essential and important entities through national law. The Cyber Resilience Act, or CRA (Regulation (EU) 2024/2847), places security requirements, vulnerability handling and reporting duties on manufacturers, importers and distributors of products with digital elements, directly across the EU. This guide compares the two by scope, roles, security duties, reporting triggers and supply chain effects, then shows how to run one evidence base for both. It is for CISOs, product security and PSIRT leads, GRC teams and buyers in organisations that operate critical services, make connected products, or both. For each law on its own, see the NIS2 Directive Guide and the EU Cyber Resilience Act Guide.
Status line (checked 14 November 2026 on EUR-Lex and the European Commission's CRA page): NIS2 has applied through national transposition laws since 18 October 2024; a Commission proposal to amend it, COM(2026) 13, is still in the legislative procedure. The CRA entered into force on 10 December 2024; its Chapter IV on notification of conformity assessment bodies applies from 11 June 2026, Article 14 reporting from 11 September 2026, and the rest from 11 December 2027 (Article 71(2)). The Commission published practical CRA guidance on 27 July 2026. Dates and proposals can change, so confirm against the official texts.
Key takeaways
- Entity law versus product law. NIS2 asks whether your organisation manages risk to the services it provides; the CRA asks whether each product you place on the EU market meets Annex I requirements for its whole support period.
- The role decides the duty. Under NIS2 the duty holder is the essential or important entity and its management body. Under the CRA it is the economic operator for a given product: manufacturer, authorised representative, importer or distributor, and anyone who substantially modifies a product becomes a manufacturer (Article 22).
- Two reporting triggers on similar clocks. NIS2 Article 23 is triggered by a significant incident affecting your services; CRA Article 14 is triggered by an actively exploited vulnerability or a severe incident affecting the security of your product. Both use 24 and 72 hour stages, but they go to different recipients with different final report deadlines.
- The CRA feeds NIS2 supply chain duties. CRA recitals 24 and 125 say the Regulation should help entities meet NIS2 supply chain obligations; NIS2 Article 21(3) requires entities to consider the product quality and secure development practices of their suppliers.
- Build one control set with two views. Asset and product inventories, vulnerability handling, incident triage and supplier evidence can serve both laws if each record carries the service affected, the product involved and the role you hold.
The short answer
If you operate a service in a NIS2 sector and meet the size rules, NIS2 applies to your organisation regardless of what you buy. If you make, import, distribute or substantially modify a hardware or software product with a data connection and make it available on the EU market, the CRA applies to that product regardless of who buys it. Many organisations are in both: a manufacturer of electronic products can be a NIS2 entity in the manufacturing sector, and a digital provider that ships client software or devices is a CRA manufacturer for those products. The CRA does not replace NIS2 duties for the entity, and NIS2 compliance does not satisfy CRA duties for the product.
| Question | NIS2 | Cyber Resilience Act |
|---|---|---|
| Legal form | Directive, applied through national transposition laws | Regulation, directly applicable in every Member State |
| What it regulates | Essential and important entities in Annex I and II sectors | Products with digital elements made available on the market with a direct or indirect data connection (Article 2(1)) |
| Duty holder | The entity; management bodies approve and oversee measures and can be held liable (Article 20) | Economic operators: manufacturer, authorised representative, importer, distributor (Article 3(12)) |
| Core security duty | Appropriate and proportionate risk-management measures, minimum list Article 21(2)(a) to (j) | Annex I essential requirements and vulnerability handling for a support period of at least five years, or the expected use time if shorter (Article 13(8)) |
| Reporting trigger | Significant incident: severe operational disruption or financial loss, or considerable damage to others (Article 23(3)) | Actively exploited vulnerability (Article 3(42)) or severe incident affecting product security (Article 14(5)) |
| Recipient | National CSIRT or competent authority (Article 23(1)) | CSIRT designated as coordinator and ENISA, simultaneously, through the single reporting platform (Article 14, Article 16) |
| Evidence of compliance | Supervision, audits and inspections by national authorities | Technical documentation, conformity assessment, EU declaration of conformity and CE marking |
| Maximum fines | At least EUR 10 million or 2% of worldwide turnover (essential) and EUR 7 million or 1.4% (important) as national ceilings (Article 34) | Up to EUR 15 million or 2.5% for Annex I and Articles 13 and 14 breaches; EUR 10 million or 2% and EUR 5 million or 1% for other breaches (Article 64) |
Scope: entity versus product with digital elements
NIS2 threat model
NIS2 is concerned with the continuity and security of services that society depends on. An incident matters when it disrupts those services or harms their users, whatever the cause: a supplier compromise, a ransomware attack or a misconfigured cloud tenant. Its unit of analysis is the organisation and every network and information system it uses.
CRA threat model
CRA recital 3 notes that NIS2 "does not directly cover mandatory requirements for the security of products with digital elements". The CRA fills that gap: insecure products and poorly supported products spread risk to every customer at once. Its unit of analysis is the product, including its remote data processing solutions and separately placed components (Article 3(1)), across its life on the market.
Where the lines fall
- Cloud services: CRA recital 12 explains that NIS2 applies to cloud computing services and models such as SaaS, PaaS and IaaS. A pure SaaS offering is therefore mainly a NIS2 matter, while the remote data processing that a product needs to function is part of the CRA product.
- Excluded products: Article 2 excludes products covered by the medical device, in vitro diagnostic and vehicle type approval regulations, certified aviation products, marine equipment, identical spare parts, and products developed exclusively for national security or defence.
- Stricter national demands: CRA recital 13 notes that NIS2's minimum harmonisation allows Member States to require essential or important entities to use products meeting stricter requirements than the CRA, and NIS2 Article 24 lets Member States require certified ICT products, services and processes.
- Open source: the CRA defines an open-source software steward (Article 3(14)) with lighter duties, and Article 64(10) exempts stewards from administrative fines. NIS2 has no equivalent role; open-source components matter to a NIS2 entity only as part of its supply chain.
Roles: who holds which duty
| Your situation | NIS2 position | CRA position |
|---|---|---|
| Hospital buying connected medical and IT equipment | Essential or important entity; supply chain duty under Article 21(2)(d) and 21(3) | Customer; medical devices are excluded from the CRA, other IT products are in scope for their makers |
| Manufacturer of industrial controllers with over 250 staff | Likely an important entity under Annex II manufacturing; confirm under national law | Manufacturer for each controller model and its firmware |
| Managed service provider that rebrands a firewall image | In scope as a managed service provider if it meets size rules | Manufacturer if it markets the product under its own name, or if its changes are a substantial modification (Article 22) |
| EU reseller of a non-EU router brand | Usually out of scope unless in a listed sector | Importer (Article 3(16)) or distributor (Article 3(17)) with verification duties |
| SaaS provider with a desktop sync client | Digital provider in scope if size rules are met | Manufacturer of the client software; the SaaS itself is mainly a NIS2 matter |
The most commonly missed role is manufacturer by modification. Article 22 treats any person other than the original manufacturer, importer or distributor who carries out a substantial modification and makes the product available as a manufacturer. Substantial modification (Article 3(30)) means a change after placing on the market that affects compliance with the essential requirements or changes the intended purpose that was assessed. Integrators and service providers who customise firmware or bundle hardened images for sale should assess this explicitly.
Security duties compared
NIS2 Article 21(2) sets ten minimum measures for the entity. The CRA's Annex I sets product properties and vulnerability handling requirements for the manufacturer. The table maps where they meet; the EU CRA Product Classes Guide covers conformity routes in depth.
| NIS2 Article 21(2) measure | CRA counterpart | What one evidence record can show |
|---|---|---|
| (a) Risk analysis and security policies | Cybersecurity risk assessment of each product, kept in the technical documentation | Entity risk register links to product risk assessments for products you make or rely on |
| (b) Incident handling | Article 14 reporting of severe incidents affecting product security | One triage record that tests both the significant incident and the severe incident criteria |
| (d) Supply chain security | Article 13(5) due diligence on third-party components, including free and open-source components | Supplier and component inventory with security assessments and contract terms |
| (e) Security in acquisition, development and maintenance, including vulnerability handling and disclosure | Annex I vulnerability handling requirements; Article 13(8) support period | A PSIRT process with intake, triage, fix and advisory records; see the PSIRT Guide |
| (f) Assessing effectiveness of measures | Conformity assessment and testing before placing on the market | Test reports and audit results stored against each product version and service |
| (h) Cryptography and encryption | Annex I product properties on confidentiality and integrity of data | Cryptographic standards applied to products and to the entity's own systems |
| (i) Access control and asset management; (j) MFA | Annex I protection from unauthorised access | Authentication design for products and administrative access policy for the entity |
NIS2 Article 21(3) is the bridge: entities must take into account the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers, including secure development procedures. CRA evidence such as a declaration of conformity, the stated support period and the manufacturer's vulnerability disclosure policy is exactly what a NIS2 entity should ask for. See the NIS2 Supply Chain Security Guide.
Incident and vulnerability reporting: avoiding double reporting errors
| Stage | NIS2 Article 23(4) | CRA Article 14 |
|---|---|---|
| Trigger | Significant incident affecting the entity's services | Actively exploited vulnerability in the product; or severe incident having an impact on the security of the product |
| First stage | Early warning within 24 hours of becoming aware | Early warning within 24 hours of the manufacturer becoming aware |
| Second stage | Incident notification within 72 hours | Vulnerability or incident notification within 72 hours |
| Final report | One month after the incident notification | Vulnerabilities: no later than 14 days after a corrective or mitigating measure is available. Severe incidents: one month after the incident notification |
| Recipient | National CSIRT or competent authority | CSIRT designated as coordinator and ENISA via the single reporting platform |
| Users | Recipients of services informed of significant incidents where required | Impacted users informed of the vulnerability or incident and mitigations (Article 14(8)) |
Nothing in the CRA text says that an Article 14 notification satisfies NIS2 Article 23, or the reverse. The CRA asks market surveillance authorities to cooperate with coordinator CSIRTs and ENISA (Article 52(4)) and to inform NIS2 competent authorities in some cases (Article 54(2)), but those are authority duties, not a substitute for your own reports. Plan for two reports when both triggers are met. Proposals for a single incident reporting entry point exist in the Digital Omnibus but are not law; see the EU Digital Omnibus Guide. The EU Cyber Resilience Act Vulnerability and Incident Reporting Guide covers report content, and the Cyber Incident Reporting Requirements Map covers other regimes.
Worked scenario: one exploited flaw, two duties
A mid-sized European company makes building management controllers and also runs a hosted monitoring service for them used by hospitals and utilities. It is an important entity under its national NIS2 law as a digital provider, and a CRA manufacturer for the controllers.
- Day 0, 09:00: the SOC sees authentication bypass attempts against customer controllers that connect to the hosted service. Engineering confirms a firmware flaw and finds reliable evidence that it has been exploited in a customer system. That meets the Article 3(42) definition of an actively exploited vulnerability: the CRA 24 hour clock starts.
- Day 0, 15:00: attackers used the flaw to pivot into the hosted service and disrupt monitoring for several customers. The incident lead assesses this as a significant incident under the national NIS2 rules: the NIS2 24 hour clock starts.
- Day 1: the PSIRT submits the CRA early warning through the single reporting platform; the incident lead submits the NIS2 early warning to the national CSIRT. Both reports reference the same internal case number so facts stay consistent.
- Day 3: both 72 hour notifications are sent. The CRA notification includes the affected product versions and mitigations; the NIS2 notification includes service impact and indicators of compromise.
- Day 10: fixed firmware is released and customers are informed under Article 14(8). The CRA final report is due within 14 days of the fix; the NIS2 final report is due one month after the incident notification.
- Afterwards: hospital and utility customers, themselves NIS2 entities, record the event under their Article 21(3) supplier assessments and ask for the advisory and the remaining support period.
The failure to avoid is one team assuming the other has reported. Assign both clocks at triage, not later.
One control set, two evidence views
- Map roles: list every service you provide and every product you make, import, distribute or modify. Record NIS2 status per legal entity and CRA role per product.
- Join the inventories: link products to the services that depend on them and to the components inside them, using SBOM data where available; see the SBOM Guide.
- Unify triage: one incident and vulnerability intake with a decision tree that tests NIS2 significance, CRA active exploitation and CRA severe incident criteria, and assigns owners for each clock.
- Prepare templates: pre-agree the content of each report stage for both regimes, the internal approvers, and the national CSIRT contacts for every Member State where you have NIS2 obligations.
- Run supplier evidence once: ask suppliers for CRA artefacts (declaration of conformity, support period, disclosure policy, advisories) and store them in the NIS2 supplier record.
- Exercise: run a tabletop where one event triggers both regimes, with legal, PSIRT and incident response present; measure time to each decision.
- Review on change: re-check roles when products are rebranded, modified or newly imported and when NIS2 national law or the amending proposal changes.
Decision guidance
- Service operator only: NIS2 is your law; use the CRA as a procurement lever. Require support periods, advisories and conformity evidence in contracts.
- Product manufacturer only: the CRA is your law; expect NIS2 customers to ask for evidence that maps to Article 21(3). A clear disclosure policy and published support period shorten sales cycles.
- Both: separate the PSIRT (product) and CSIRT or SOC (service) roles but share the case system; give one executive ownership of both reporting regimes.
- Small companies: Article 64(10) exempts micro and small enterprises from fines for missing the CRA 24 hour early warning deadlines, but not from the duty to report; NIS2 generally applies from medium size upwards, with listed exceptions.
- Large groups: NIS2 applies per entity under each national law, while CRA duties follow the product and its economic operator; map legal entities carefully.
Detection, measurement and framework mapping
- Clock compliance: percentage of NIS2 and CRA early warnings sent within 24 hours of awareness, tracked separately.
- Dual trigger coverage: percentage of incident and vulnerability cases with both regimes assessed and recorded at triage.
- Role currency: percentage of products with a recorded CRA role and support end date.
- Supplier evidence: percentage of critical suppliers with CRA artefacts or equivalent on file.
- Fix to final report: days from corrective measure availability to CRA final report (limit 14).
| Need | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Know which laws apply | GV.OC-03 | PM-15 (contacts with groups and authorities) | 5.31 Legal, statutory, regulatory and contractual requirements |
| Supplier and component assurance | GV.SC-05, GV.SC-07 | SR-3, SR-4, SR-5 | 5.19 to 5.21 Supplier relationships and ICT supply chain |
| Vulnerability intake and disclosure | ID.RA-08 | RA-5(11) Public Disclosure Program | 8.8 Management of technical vulnerabilities |
| Secure development and support | PR.PS-06 | SA-15, SA-22 | 8.25 Secure development life cycle |
| Incident reporting | RS.CO-02, RS.CO-03 | IR-6 Incident Reporting | 5.24 to 5.26 Incident management |
Common failure patterns
- Assuming one report covers both: a NIS2 notification is sent and the CRA early warning is forgotten, or the reverse, because nothing in either text makes one count for the other.
- Missing manufacturer duties: a service provider rebrands or substantially modifies a product without realising Article 22 makes it a manufacturer.
- Inconsistent facts: two teams send different timelines or impact statements to two authorities about one event.
- Treating CRA as a 2027 problem: Article 14 has applied since 11 September 2026, including to products placed on the market before December 2027 (Article 69(3)).
- Supplier questionnaires that ignore the CRA: NIS2 entities keep asking generic questions instead of requesting the support period, declaration of conformity and disclosure policy that manufacturers must now hold.
- Clock confusion: the CRA vulnerability final report runs from the fix, not from notification, so it can fall due before or after the NIS2 final report.
Decision checklist
- Which of our legal entities are essential or important under each national NIS2 law?
- Which products do we manufacture, import, distribute or substantially modify for the EU market?
- Does our triage test NIS2 significance and CRA exploitation and severe incident criteria on every case?
- Who sends each report, through which channel, and who approves it?
- Do we know the support period of every product we make and every critical product we buy?
- Have we exercised a dual-trigger event in the last year?
Practitioner checklist
- Record NIS2 status per legal entity and CRA role per product in one register.
- Screen rebranding, white labelling and firmware customisation for Article 22 manufacturer status.
- Add CRA Article 14 and NIS2 Article 23 criteria to the same triage form with separate owners and timers.
- Set up access to ENISA's single reporting platform (live since 11 September 2026) and confirm national CSIRT contacts before you need them.
- Keep one case reference across both regimes so reports stay consistent.
- Publish a vulnerability disclosure policy and support periods for every product.
- Request CRA artefacts from suppliers and store them in NIS2 supplier records.
- Track proposals such as COM(2026) 13 and the Digital Omnibus and update procedures only when adopted.
Standards and references
- EUR-Lex: Directive (EU) 2022/2555 (NIS2 Directive)
- EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)
- European Commission: Cyber Resilience Act
- ENISA: Cyber Resilience Act and the Single Reporting Platform
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: DORA and NIS2 Overlap Mapping Guide · NIS2 Readiness Checklist · EU Cyber Resilience Act Readiness Checklist for Manufacturers · EU Cyber Resilience Act Harmonised Standards Guide. This guide summarises Directive (EU) 2022/2555 and Regulation (EU) 2024/2847 and is not legal advice.