Short answer
EU cybersecurity law does not appoint one lead reporter for an entire supply chain. It assigns duties to each actor according to its own role, the affected service or product, and the applicable sector.
NIS2 requires an in-scope essential or important entity to manage risks to its network and information systems, including risks involving direct suppliers, and to report a significant incident under the Member State law transposing the Directive. DORA is the more specific regime for covered financial entities: it governs their ICT risk, third-party arrangements and major ICT-related incident reports. A financial entity remains responsible even if a provider handles the technology or submits a report for it. The Cyber Resilience Act (CRA) addresses products with digital elements. It places lifecycle-security and vulnerability duties principally on manufacturers, with supporting controls for importers and distributors.
Consequently, one compromise can require parallel action: a software manufacturer may have a CRA duty, a cloud or managed-service provider may have a NIS2 duty, and a bank using the service may have a DORA duty. Contracts should make evidence and escalation move quickly between them, but cannot erase the statutory responsibility of any actor.
Three regimes protect different things
The starting question is not “which cyber law wins?” It is: which regulated object and actor are affected?
- NIS2, Directive (EU) 2022/2555, protects the provision of services by essential and important entities. It is a directive, so scope, designated authorities, procedures and enforcement must be checked in the relevant Member State's transposing law. Member States were required to apply those measures from 18 October 2024.
- DORA, Regulation (EU) 2022/2554, protects the digital operational resilience of listed financial entities. It has applied directly since 17 January 2025.
- The CRA, Regulation (EU) 2024/2847, protects hardware and software products with digital elements placed on the EU market, including qualifying remote data-processing solutions. Its dates are phased: manufacturer reporting under Article 14 applies from 11 September 2026, while most of the Regulation applies from 11 December 2027.
One company may be a NIS2 cloud provider, a DORA ICT third-party service provider and a CRA software manufacturer. Each role needs its own analysis.
NIS2 makes the service entity manage supplier risk
Article 21 requires appropriate and proportionate technical, operational and organisational measures. Its minimum subjects include incident handling, business continuity, secure acquisition and development, vulnerability handling, access controls and:
“supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers;” —
The entity must consider vulnerabilities specific to each direct supplier and the quality of its suppliers' products, cybersecurity practices and secure development procedures. Outsourcing infrastructure therefore changes the risk map, not the entity's responsibility to manage it. The management body must approve and oversee the Article 21 measures under Article 20.
NIS2 reporting is triggered by an incident having a significant impact on the provision of the entity's services. Article 23 treats an incident as significant where it has caused or can cause severe operational disruption or financial loss, or considerable material or non-material damage to others. The entity sends an early warning within 24 hours after awareness, an incident notification within 72 hours, and ordinarily a final report within one month after that notification. Where appropriate, affected service recipients must also be informed.
For DNS, cloud, data-centre, content-delivery, managed-service and managed security providers, online marketplaces, search engines, social-networking platforms and trust-service providers, Commission Implementing Regulation (EU) 2024/2690 adds harmonised technical measures and detailed significance thresholds. Other NIS2 entities must still consult the relevant national transposition rather than importing those sector-specific figures.
DORA replaces the relevant NIS2 duties for financial entities
NIS2 contains a targeted lex-specialis rule:
“Where sector-specific Union legal acts require essential or important entities to adopt cybersecurity risk-management measures or to notify significant incidents and where those requirements are at least equivalent in effect to the obligations laid down in this Directive, the relevant provisions of this Directive, including the provisions on supervision and enforcement laid down in Chapter VII, shall not apply to such entities.” —
DORA Article 1(2) expressly says that DORA is such a sector-specific Union act for financial entities identified as essential or important under national NIS2 rules. This avoids duplicate NIS2 and DORA risk-management, reporting, supervision and enforcement requirements for the same covered financial entity. It does not exempt its cloud, software or managed-service provider from that provider's own NIS2 obligations, nor does it remove product duties under the CRA.
DORA requires the financial entity to detect, record, classify and manage ICT-related incidents. A major ICT-related incident is assessed under Commission Delegated Regulation (EU) 2024/1772. It must affect critical services and meet the specified combinations of thresholds concerning clients or transactions, reputation, duration or downtime, geographic spread, data loss and economic impact.
Once classified as major, Commission Delegated Regulation (EU) 2025/301 sets a distinct clock: the initial notification is due as early as possible, within four hours after classification and no later than 24 hours after awareness of the incident. The intermediate report is generally due within 72 hours after the initial notification, and the final report no later than one month after the intermediate or latest updated intermediate report. The report goes to the relevant financial-sector competent authority; DORA governs onward sharing.
Third-party arrangements must make that reporting possible, but do not transfer the legal burden:
“financial entities that have in place contractual arrangements for the use of ICT services to run their business operations shall, at all times, remain fully responsible for compliance with, and the discharge of, all obligations under this Regulation and applicable financial services law;” —
DORA permits outsourcing the act of reporting, but Article 19(5) preserves the financial entity's responsibility. Article 30 requires written duties, incident assistance and cooperation with authorities; contracts supporting critical or important functions need further reporting, contingency, audit and exit provisions.
The CRA follows the product and its economic operators
The CRA's manufacturer must assess product cybersecurity risks, design and produce the product to meet Annex I requirements, maintain vulnerability handling through the support period, and exercise due diligence when integrating third-party components. If it identifies a vulnerability in an integrated component, it must report it to the component's manufacturer or maintainer and address it in its own product.
From 11 September 2026, Article 14 creates a separate regulatory report:
“A manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA.” —
The manufacturer uses the CRA single reporting platform. An actively exploited vulnerability requires a 24-hour warning, a 72-hour notification and a final report within 14 days after a corrective or mitigating measure becomes available. A severe product-security incident has 24-hour and 72-hour stages and a final report within one month. Impacted users must also be informed. These are future-applying duties; similar NIS2 clocks do not make Article 14 apply early.
Importers and distributors play a supporting market-control role. They must verify required conformity material, avoid placing or making available a non-compliant product, pass vulnerability information to the manufacturer, and escalate a significant cybersecurity risk to market-surveillance authorities. They do not automatically inherit the manufacturer's Article 14 report.
The CRA also yields to specified product regimes. It excludes, among other things, products governed by the EU medical-device, in-vitro diagnostic and certain motor-vehicle rules, certified aviation products, and marine equipment. For other products, the Commission can limit or exclude CRA application by delegated act where sectoral rules cover the same risks at an equal or higher level. Scope must therefore be checked product by product.
How to handle one incident across the chain
Consider an exploited component in a managed cloud service used by a bank. The same facts should be tested three times:
- Product track: Is an actor the CRA manufacturer of a covered product, and is there an actively exploited vulnerability or severe product-security incident? If so, prepare the CRA pathway when Article 14 is applicable.
- Service track: Is the provider itself within NIS2, and has the event significantly affected its service under the transposed national rule and any applicable Regulation 2024/2690 threshold?
- Financial track: Has the bank classified a major ICT-related incident under DORA's criteria? If so, its financial-sector report is independent of whether the provider has already notified a CSIRT.
Contracts should define a faster alert than the shortest statutory clock, preserve logs and timestamps, flow duties to subcontractors, and allocate each report field. Record when every actor first became aware and, for DORA, when the financial entity classified the incident as major. “The supplier reports” is not enough.
Conclusion
NIS2, DORA and the CRA divide responsibility by regulated entity, financial activity and product—not by choosing one reporter for the supply chain. DORA displaces the equivalent NIS2 duties for covered financial entities, while a provider's own NIS2 obligations and a manufacturer's CRA obligations can still run in parallel. A workable response plan therefore maps each legal role, trigger, recipient and clock separately, then uses contracts to move the necessary facts without pretending to transfer statutory responsibility.
Sources
- — checked for judgments interpreting these duties; none is relied on as at 29 July 2026
This article provides general legal information, not advice for a specific matter. Laws, facts and procedural deadlines may change the result. Follow the linked primary sources and obtain local advice before acting.