CRA NIS2 and DORA Reporting Overlap
A company that is at once a CRA manufacturer, a NIS2 essential or important entity and a DORA financial entity keeps three separate reporting duties on three separate filings, even where two of them reach the same national CSIRT. The CRA's Single Reporting Platform consolidates filings within the CRA itself and does not fold NIS2 or DORA into that filing.
17 min read
41 views
Key takeaways: CRA, NIS2 and DORA reporting overlap 5
Why the Single Reporting Platform's own scope stops at the CRA, and what actually happens at the three regimes' shared touchpoints instead of a merged filing.
- SRP scope misread The Single Reporting Platform lets a manufacturer notify multiple national authorities under the CRA only once. It does not extend to NIS2 or DORA, a distinction easy to miss in the ENISA and Commission wording.
- Three distinct roles CRA, NIS2 and DORA each regulate a different role a company can occupy for the same product or service. Each duty carries its own trigger, its own clock and its own separate filing, even where two of the three land at the same national CSIRT.
- CRA-DORA link unsettled The Commission's guidance of 27 July 2026 only says it may consider further guidance on the CRA-DORA interplay. Its dedicated interplay section covers vehicle type-approval and certificates, not NIS2 or DORA.
- Coordination, not consolidation The CRA links to NIS2 through delayed disclosure, ENISA passing notifications to EU-CyCLONe and feeding the European vulnerability database. None of this reduces the number of filings a company itself has to make.
- One event, three filings A single exploited vulnerability can trigger the CRA, NIS2 and DORA duties separately if it crosses all three thresholds. Each regime still expects its own notification to its own authority on its own clock.
A vendor that sells a monitoring agent into hospitals, industrial plants and banks across the EU can end up wearing three regulatory hats over the exact same product. As the maker of that agent it is a manufacturer under the Cyber Resilience Act (CRA). As the operator of the security operations center that runs the agent for its own clients, it can be an essential or important entity under NIS2. And where part of its business is itself an authorized financial service, it is a financial entity under the Digital Operational Resilience Act (DORA). A recurring line of commentary around the CRA's Single Reporting Platform (SRP) suggests one of the CRA's quiet achievements is folding that pile of duties into a single filing. It does not. The SRP consolidates reporting across national authorities inside the CRA. It does not consolidate reporting across the CRA, NIS2 and DORA. Neither the Regulation nor the Commission's own guidance says otherwise.
In short: a company that is at once a manufacturer under the EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847), an essential or important entity under the NIS2 Directive (Directive (EU) 2022/2555) and a financial entity under DORA (Regulation (EU) 2022/2554) keeps three separate reporting duties, with three different triggers and three different clocks, on three separate filings even where two of them reach the same national CSIRT. The CRA's Single Reporting Platform consolidates notifications across national authorities within the CRA itself; it does not fold NIS2 or DORA obligations into that filing. The Commission's guidance of 27 July 2026 and its implementation FAQ are mostly silent on the interplay with NIS2 and DORA, and where the CRA substantively touches the NIS2 side, chiefly at Articles 13(25), 16(6), 17(1), 17(3) and 17(5), the effect is information moving between authorities, never a reduction in what a company itself has to file.
Where the confusion about reporting comes from
ENISA administers the SRP, and its frequently asked questions page for the Single Reporting Platform describes the service as “allowing for manufacturers to report actively exploited vulnerabilities and severe incidents having an impact on the security of products with digital elements only once, rather than having to notify multiple national authorities individually.”
Read quickly, that sentence sounds like it settles the overlap question outright. Read carefully, it is scoped to one specific problem: a manufacturer selling into several Member States used to have to notify several national authorities separately about the same vulnerability. The SRP removes that duplication inside the CRA. It says nothing about NIS2 or DORA, because the several national authorities the ENISA sentence refers to are the national CSIRTs a manufacturer with EU-wide distribution would otherwise have to contact one by one, not the other regimes a company might also answer to. This is the reading that most published commentary elides, usually without ever setting the two interpretations side by side, and then treats the narrower reading as though it had never been an option.
The Commission's own reporting page states the same scope with more precision, describing the CRA reporting duty as a single filing addressed to the coordinating CSIRT. Article 14(7) adds that the notification is simultaneously accessible to ENISA, with no exception for particularly exceptional circumstances; that qualifier belongs to a different provision, Article 16(2), which lets the coordinating CSIRT delay disseminating a notification on to other CSIRTs, not to whether ENISA sees it. That description names a single recipient chain, a coordinating CSIRT plus ENISA, not three regimes collapsing into one filing, because that is not the problem the Commission's page is answering. The mechanics of filing through that channel are covered in a companion piece on integrating with the CRA Single Reporting Platform.
Three regimes, three duties, three filings
CRA, NIS2 and DORA each regulate a different role, and a company owes each duty only in the role it actually occupies for a given product or service, on three separate filings and three separate clocks even where two of the three reach the same national CSIRT. The table below sets the three side by side, including the deadline each regime runs on and the article that sets it. For a deeper walk-through of the CRA's own timeline mechanics, see our companion piece on CRA incident reporting deadlines.
| Regime | Who it regulates | Reporting trigger | Reporting clock | Addressee |
|---|---|---|---|---|
| CRA | The manufacturer of a product with digital elements | An actively exploited vulnerability or a severe incident affecting the product, under Article 14 | Early warning within 24 hours of becoming aware (Art. 14(2)(a), 14(4)(a)); notification within 72 hours of becoming aware (Art. 14(2)(b), 14(4)(b)); intermediate report on request, no fixed deadline (Art. 14(6)); final report 14 days after a corrective or mitigating measure is available for a vulnerability (Art. 14(2)(c)) or one month after submitting the 72-hour notification for an incident (Art. 14(4)(c)) | The CSIRT designated as coordinator, plus ENISA, through the Single Reporting Platform |
| NIS2 | The essential or important entity operating the service | An incident with a significant impact on the provision of the entity's services, under Article 23(1) | Early warning within 24 hours of becoming aware (Art. 23(4)(a)); incident notification within 72 hours of becoming aware (Art. 23(4)(b)); intermediate report on request, no fixed deadline (Art. 23(4)(c)); final report one month after submitting the 72-hour notification (Art. 23(4)(d)); for an incident still ongoing when the final report is due, a progress report followed by a final report within one month of resolving it (Art. 23(4)(e)) | The national CSIRT or competent authority |
| DORA | The financial entity | A major ICT-related incident affecting the entity, under DORA's own incident classification framework | No number in Article 19 itself, delegated via Article 20, first paragraph, point (a), point (ii) to Commission Delegated Regulation (EU) 2025/301, Article 5(1): initial notification within 4 hours of classifying the incident as major, capped at 24 hours from becoming aware; intermediate report within 72 hours of submitting the initial notification; final report one month after submitting the intermediate report | The financial entity's competent authority |
A single company sitting in all three columns at once is unusual, but it is not rare in FinTech, healthcare technology or industrial software: the vendor that also runs the platform, and whose platform is itself a regulated financial service, occupies exactly that position. What the table also makes clear is that the three triggers are not one event described three different ways: the CRA's sits at the product, NIS2's sits at the entity's own service and DORA's sits at the financial entity's own operational continuity. Because the thresholds are defined independently, a single event does not automatically clear all three bars, a point worth holding onto before the walk-through later in this article.
The clock columns above show a second thing a trigger-and-addressee comparison hides: the three regimes do not clock incidents the same way. DORA sets no deadline number of its own. Article 19(4) defers to Article 20, first paragraph, point (a), point (ii), and the actual time limits live in Commission Delegated Regulation (EU) 2025/301, Article 5(1). That delegated regulation also gives DORA's first filing two nested limits instead of one: the initial notification is due within four hours of the incident being classified as major, capped at 24 hours from the moment the entity became aware of it, so a late classification cannot extend the outer limit. The CRA's and NIS2's early-warning clocks run from awareness alone, with no separate classification step. Each stage of each regime also starts from a different event. DORA moves from awareness or classification to submission of the initial notification to submission of the intermediate report. The CRA's own two tracks split the same way inside one regime: a vulnerability's final report runs from the availability of a corrective or mitigating measure, which can be a workaround as well as a patch, while an incident's final report runs from submission of the 72-hour notification. DORA's own final report follows a parallel two-limb rule: it is due one month after the intermediate report, or, where the entity kept filing updated intermediate reports, one month after the latest of those updates (Art. 5(1)(c)). The honest description of the three clocks is not that the deadlines differ. It is that the regimes do not even agree on what event starts a clock.
One filing quirk is worth knowing before it surprises a compliance team: Commission Delegated Regulation (EU) 2025/301 lets any of the three DORA deadlines slip to noon of the next working day when it falls on a weekend or a bank holiday (Art. 5(4)). That slip is withdrawn for the initial notification and the intermediate report only, and for credit institutions, central counterparties, trading venue operators and other financial entities identified as essential or important under NIS2 (Art. 5(5)); their final report still gets the slip. A competent authority can extend that same withdrawal to other financial entities it judges significant or systemically important, again limited to the initial notification and intermediate report (Art. 5(6)).
What the July 2026 Commission guidance says about overlap
The Commission's guidance of 27 July 2026 does address parallel reporting obligations directly, just not in the way the SRP's marketing suggests. Paragraph 212 acknowledges that manufacturers may be subject to comparable reporting obligations under different EU legal acts, and it aligns its own approach with recital 31 of Commission Implementing Regulation (EU) 2024/2690, a NIS2 implementing instrument, as well as Section II(A) of Guidelines 9/2022 on personal data breach notification under the GDPR. What gets harmonized across those three points of reference is the meaning of becoming aware of an incident, so that the clock a company starts running begins at the same moment regardless of which regime is counting the hours. Nothing in paragraph 212 harmonizes how many filings that clock produces. A shared starting gun is not a shared finish line.
Paragraph 9 of the same guidance is the clearest signal of how unsettled the CRA-DORA relationship still is. It states that the Commission may consider issuing further guidance, including on the interplay between the CRA and Regulation (EU) 2024/1689 (the AI Act) and Regulation (EU) 2022/2554 (DORA). May consider is a conditional, not a commitment. As of 27 July 2026, the Commission names that interplay as possible future work rather than settled doctrine.
The guidance's own section on interplay with other instruments, section 9.3, has exactly two subsections: one on Regulation (EU) 2019/2144 read together with Regulation (EU) No 168/2013 (both about vehicle type-approval) and one on the validity of EU type-examination certificates. Neither NIS2 nor DORA appears in that section. Where DORA does surface again, at paragraph 207, that is the second and last of only two mentions in the entire guidance, the first being paragraph 9 above. This second mention lists DORA as one of the reusable assurance artefacts a manufacturer can point to on a conformity-assessment due-diligence list, an evidentiary shortcut rather than a reporting rule. It is useful for a compliance team assembling that file. It is not guidance about who a company notifies and when.
What the Commission's implementation FAQ says, and does not say
The Commission's separate implementation FAQ takes the same absence further. Its interplay section enumerates nine other EU instruments the CRA has to be read alongside: civil aviation under Regulation (EU) 2018/1139, marine equipment under Directive (EU) 2014/90, the Product Liability Directive, the Machinery Regulation, the General Product Safety Regulation, the Radio Equipment Directive, the European Health Data Space, the GDPR and the Data Act. That list is close to exhaustive across the sectoral and horizontal rules a product manufacturer might otherwise worry about. NIS2 and DORA are both missing from it.
Its reporting section is organized around four subsections: how a manufacturer becomes aware of a vulnerability or incident, how zero-day vulnerabilities are handled, what happens for products placed on the market before the CRA applies and how third party components fit into a notification. None of the four touches NIS2 or DORA. The document itself is titled FAQs on the Cyber Resilience Act, version 1.3, dated 1 July 2026 in its own internal version table, 66 pages, with its landing page last updated 2 July 2026. That is a distinct document from the Commission's guidance discussed above, which is dated 27 July 2026. A full-text extraction of that version 1.3 FAQ, 175,847 characters, found zero occurrences of DORA, zero of 2022/2554, zero of digital operational resilience and zero of financial entit(y/ies), confirming the claim under both the acronym and the formal name. This check is pinned to version 1.3 of the FAQ; if the Commission republishes it, the claim should be re-verified against the new version before this page relies on it again.
If anything, the FAQ's own subsection on third party components moves in the opposite direction from consolidation. Where an exploited vulnerability sits inside a component that has itself been separately placed on the market, the FAQ states that the component manufacturer has to notify as well as the manufacturer that integrated the component into its own product. One exploited vulnerability, in other words, can already generate multiple notifications purely inside the CRA, before NIS2 or DORA enter the picture at all.
What the CRA actually does at the NIS2 interface
None of this means the CRA ignores NIS2 entirely. It genuinely coordinates with it at several points, and being fair to that coordination is part of getting this right; it is just coordination between authorities, not a reduction in a company's own filings.
The receiving CSIRT may delay dissemination of a notification under Article 16(6) where the same vulnerability is already inside a coordinated vulnerability disclosure procedure under Article 12(1) of the NIS2 Directive, avoiding a premature public disclosure that would undercut a process already running. ENISA, in turn, may pass CRA notifications on to EU-CyCLONe under Article 17(1), the crisis liaison network established under Article 16 of NIS2, where a notification matters for coordinated management of a large-scale incident. Every 24 months, ENISA also prepares a technical report on emerging trends for the NIS2 Cooperation Group under Article 17(3), feeding CRA reporting data into NIS2's own policy work at the aggregate level rather than the individual-filing level. Where ADCO runs a Union-wide dependency assessment on a category of products, it submits a report on the results to that same NIS2 Cooperation Group under Article 13(25), another aggregate-level channel routing CRA data into NIS2's own institutional structure rather than a company's own filing.
The clearest link runs through vulnerability data itself. After a security update or another form of corrective or mitigating measure is available, Article 17(5) has ENISA add the vulnerability, in agreement with the manufacturer, to the European vulnerability database established under Article 12(2) of NIS2. That database is a distinct instrument from the SRP, and ENISA has said so explicitly in its own coverage of the database's launch, in a passage worth reading directly against the SRP's report-only-once framing: ENISA's own announcement states “It is important to highlight the SRP is therefore different from the EUVD established by the NIS2 Directive.” One is the intake channel for a manufacturer's mandatory notification. The other is a published catalog that NIS2 itself established. The CRA feeds it with data after the fact; it does not merge into it.
These five are the CRA's substantive coordination points with NIS2, the ones where an authority actually acts on information because of the NIS2 side. The CRA also names Directive (EU) 2022/2555 in the Article 3 definitions of incident, near miss and CSIRT designated as coordinator and at Article 14(9), but those references borrow a definition or fix an authority's identity rather than create a new coordination duty.
Recital 72 comes closest to describing what a genuine single entry point across regimes could look like, and even there the language stays soft. In view of overlapping reporting duties across instruments including the GDPR, DORA, the ePrivacy Directive and NIS2, the recital encourages Member States to consider providing national single entry points for incident reporting. Encouraged to consider is the entire strength of that sentence, and it addresses a Member State's own administrative architecture, not a manufacturer's or a financial entity's filing count. The recital's own closing sentence draws the bridge to ENISA's platform directly: “When establishing the single reporting platform referred to in this Regulation, ENISA should take into account the possibility for the national electronic notification end-points referred to in this Regulation to be integrated into national single entry points that may also integrate other notifications required under Union law.” No Member State has publicly announced that it has built one. Neither the Commission's guidance nor its implementation FAQ cites or elaborates on Recital 72, and the term single entry point does not appear in either document.
The recital's own text sits inside the consolidated Regulation, at the CRA's official text.
A separate recital states the honest version of what the CRA does for NIS2 and DORA entities, and as a recital it explains the Regulation's intent rather than binding anyone directly: Recital 125 frames the CRA as helping those entities meet their own supply chain security obligations when they use products with digital elements built by someone else. That is a real benefit, and it flows to the buyer of a compliant product, not to the vendor that made it. It does not touch the vendor's own separate duties under NIS2 or DORA where the vendor also happens to occupy those roles.
One incident, three hats, three filings
Put the earlier example to work. A vendor builds an intrusion-detection agent it sells to banks, hospitals and industrial operators, which makes it a CRA manufacturer for that product. The same vendor runs a security operations center using that agent for its own clients, and that operating role is what could put it inside NIS2 as an essential or important entity. Part of the same group is also an authorized payments institution offering banking-as-a-service, which makes it a DORA financial entity for that line of business.
An attacker actively exploits a vulnerability in the agent. Three things can follow, on three separate clocks. As the manufacturer, the vendor notifies the coordinating CSIRT and ENISA through the SRP under Article 14, an actively-exploited-vulnerability duty measured from when the manufacturer becomes aware. If that same vulnerability degrades the security or availability of the vendor's own SOC service to a level that meets NIS2's own significant incident threshold, the entity separately notifies its national CSIRT or competent authority under Article 23, on NIS2's own clock, not the CRA's. If the exploit also disrupts the group's banking-as-a-service platform badly enough to meet DORA's own major ICT-related incident classification, the financial entity separately notifies its competent authority under DORA, on a third clock again.
Three filings, three regulators, one root cause. Nothing in the CRA, the Commission's guidance or its implementation FAQ collapses that into one.
The honest caveat matters as much as the scenario. The three thresholds do not move together. A vulnerability that is actively exploited in the product but never actually degrades the vendor's own SOC service can trigger the CRA duty alone, because NIS2's Article 23(1) bar requires a significant impact on the provision of the entity's own services, not merely the existence of a vulnerability in software the entity happens to make. A vulnerability patched cleanly before it ever touches the banking-as-a-service platform's production environment may never approach DORA's major-incident classification at all. Whether one event crosses one, two or all three bars depends on facts specific to that event, not on which regimes apply to the company in the abstract. What does not vary is that when an event does clear all three thresholds, each regime still expects its own filing.
How Pharos Production helps
We build the compliance tooling and incident-response infrastructure that lets a platform team track CRA, NIS2 and DORA obligations as three distinct workflows with three distinct clocks, instead of one merged process that quietly drops whichever duty looks least urgent that week. That means separate trigger logic for product-level vulnerabilities, entity-level significant incidents and financial-entity major ICT incidents, feeding the right notification into the right authority through the right channel, with the audit trail each regime's supervisor expects to see on its own terms.
See our compliance and regtech solutions, or talk to us about our cybersecurity services if the incident-response and reporting pipeline itself is what needs building.
Sources: Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 13, 14, 16 and 17 and Recitals 72 and 125. Regulation (EU) 2022/2554 (DORA), Articles 19 and 20. Commission Delegated Regulation (EU) 2025/301, Article 5. Directive (EU) 2022/2555 (NIS2), Articles 12, 16 and 23. European Commission, guidance on the CRA, Brussels, 27.7.2026, C(2026) 5252 final, paragraphs 9, 207 and 212 and section 9.3. European Commission implementation FAQ for the CRA, version 1.3, dated 1 July 2026, its interplay and reporting sections. ENISA, Single Reporting Platform frequently asked questions, and ENISA's announcement on the European Vulnerability Database. This article is engineering and compliance guidance, not legal advice.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 7
No matches
Try a different keyword, change the topic or clear filters
-
No. The Single Reporting Platform consolidates a manufacturer's CRA notifications across national authorities within the CRA itself. It does not fold NIS2 or DORA obligations into that filing, and neither the Regulation nor the Commission's own guidance says otherwise.
-
Something else. Regulation (EU) 2022/2554 never states a DORA deadline in hours or days itself; Article 19(4) hands the job to Article 20, first paragraph, point (a), point (ii), which hands it again to Commission Delegated Regulation (EU) 2025/301, Article 5(1), where the numbers finally sit.
Once there, Article 5(1)(a) sets two limits on the first filing at once rather than one: no later than four hours after the entity classifies the incident as major, and in any case no later than 24 hours after the entity first became aware of it, so a slow classification never buys extra time. Article 5(1)(b) then gives 72 hours from that initial notification for the intermediate report, and Article 5(1)(c) gives one month for the final report, counted from either the intermediate report or, if the entity filed a later updated version of it, from that latest update instead. Both the CRA and NIS2 write their own numbers straight into the primary legal text; DORA's own Article 19 does not, which is the real difference behind this question.
-
Paragraph 9 states the Commission may consider issuing further guidance on the interplay between the CRA and DORA, a conditional rather than a commitment. Section 9.3, the guidance's own section on interplay with other instruments, covers only vehicle type-approval and EU type-examination certificates, and neither NIS2 nor DORA appears there.
DORA gets one more mention after that, at paragraph 207, its second and last in the whole document, where it is listed as one of the reusable assurance artefacts on a conformity-assessment due-diligence list, not a reporting rule.
-
Not once, on the evidence available. That FAQ is version 1.3, dated 1 July 2026 with a landing-page update of 2 July 2026, 66 pages and a separate release from the Commission's 27 July 2026 guidance discussed elsewhere on this page.
Running the full 175,847 characters of that version through a text search turns up zero hits for DORA, zero for 2022/2554, zero for digital operational resilience and zero for financial entit(y/ies), which covers both the shorthand and the formal name. The FAQ's own list of nine other EU instruments the CRA has to be read alongside skips NIS2 and DORA both. Because the finding is pinned to version 1.3 specifically, any future republication of the FAQ would need its own fresh check before this answer could still be relied on.
-
The receiving CSIRT may delay dissemination of a notification under Article 16(6) where the vulnerability is already inside a coordinated disclosure procedure under NIS2. ENISA may pass CRA notifications to EU-CyCLONe under Article 17(1) and feeds a technical report to the NIS2 Cooperation Group under Article 17(3).
After a security update or another form of corrective or mitigating measure is available, ENISA also adds the vulnerability to the European vulnerability database established under NIS2's Article 12(2), under Article 17(5). ADCO, running a Union-wide dependency assessment, submits its results to that same NIS2 Cooperation Group under Article 13(25). All of this moves information between authorities, it does not reduce what a company itself has to file. These five are the substantive touchpoints; a few other CRA provisions cite Directive (EU) 2022/2555 only for definitions or to fix an authority's identity.
-
Yes, but the three thresholds are independent and do not move together. A vulnerability that is actively exploited in a product can trigger the CRA duty alone if it never degrades the vendor's own service to the level NIS2's Article 23 requires.
When an event does clear all three bars, each regime still expects its own separate filing on its own clock.
-
It depends on the report and the entity, not on a single yes or no. Article 5(4) of the delegated regulation is the general rule: a deadline landing on a weekend or bank holiday moves to noon of the next working day, across all three DORA filings.
Article 5(5) takes that back for a named group, credit institutions, central counterparties, trading venue operators and any financial entity separately identified as essential or important under NIS2, but only for their initial notification and intermediate report; even that group keeps the slip for its final report. Article 5(6) then leaves the question open a second time for everyone outside that named group: a competent authority can decide the slip should not apply to a financial entity it judges significant or systemically important either, again limited to the initial notification and intermediate report, and that decision only starts to bind once the authority has notified the entity concerned. So a financial entity outside Article 5(5)'s named list should confirm its status with its competent authority rather than assume the slip is guaranteed.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
