CRA and NIS2 Dual Reporting: One Event, Two Clocks, Two Portals — the Step-by-Step Filing Sequence for Manufacturers That Are Also NIS2 Entities

One compromised firmware-update server can put a manufacturer on two separate reporting sequences in the same week. If you make products with digital elements and you are also an essential or important entity under NIS2, the event can trigger a Cyber Resilience Act Article 14 report through ENISA’s Single Reporting Platform and a NIS2 Article 23 report to your national CSIRT or competent authority. Neither report counts as the other today. Each clock starts when you become aware of a different thing, so the deadlines rarely line up.

Does dual reporting apply to you?

In plain terms: you face both regimes only if you pass two separate gates, one for the product and one for the company. Passing one says nothing about the other.

The CRA gate is about what you sell. Article 14 applies to manufacturers of products with digital elements and has applied since 11 September 2026. Under Article 69(3) it also covers products placed on the market before 11 December 2027, so your installed base is already in scope. Medical devices regulated under the MDR and IVDR are excluded by Article 2(2).

The NIS2 gate is about who you are. Annex II, sector 5 lists manufacturers of medical devices, computer, electronic and optical products (NACE C26), electrical equipment, machinery, motor vehicles and other transport equipment. Size thresholds then decide whether you’re in scope. The three-question dual-scope test for manufacturers walks through both gates in detail.

Your situation	CRA Art. 14 report	NIS2 Art. 23 report
40-person IoT sensor maker, below NIS2 size thresholds	Yes, for its products	No
300-person industrial controller maker (NACE C26)	Yes, for its products	Yes, for significant incidents in its own operations
Same maker, ransomware hits only the office network, no route to product systems	No (no impact on product security)	Yes, if significant under Art. 23(3)
Same maker, attacker tampers with the firmware release channel	Yes (severe incident, Art. 14(5)(b))	Only if the incident is also significant under Art. 23(3)

The last row is the dual-reporting case.

Two clocks: what starts each one

In plain terms: both laws start their clock when you “become aware”, but of different things. The CRA asks whether the incident affects the security of your product. NIS2 asks whether it is significant for your services, or for other people. The same event can pass one test hours or days before the other.

CRA Article 3(43) defines “incident” by pointing straight at NIS2 Article 6(6). The filters on top of it differ:

Track	What starts the clock	Legal test
CRA, severe incident	Awareness of an incident with an impact on the security of the product	Art. 14(5): affects, or is capable of affecting, the protection of sensitive or important data or functions; or has led, or is capable of leading, to malicious code in the product or in users’ systems
CRA, actively exploited vulnerability	Reliable evidence that a malicious actor has exploited a flaw in the product	Art. 3(42); a published CVE or proof of concept alone is not enough
NIS2, significant incident	Awareness of a significant incident	Art. 23(3): severe operational disruption or financial loss for you, or considerable damage to others (actual or capable of)

Two details push the clocks apart. First, the CRA test uses “capable of”, so a contained intrusion into your release pipeline can be severe before a single customer is harmed. Second, NIS2 Recital 101 (non-binding) frames significance as the result of the entity’s own initial assessment of the systems affected, the threat’s severity and the disruption’s duration, and that assessment often finishes later.

Implementing Regulation (EU) 2024/2690 sets numeric significance thresholds only for digital providers such as cloud, data centre and managed service providers (Article 1). A manufacturer applies the general Article 23(3) test as transposed nationally; our guide to deciding whether an incident is significant covers that test. For how the CRA clocks are counted to the hour, see CRA reporting requirements.

Two portals: where each report goes

In plain terms: the CRA report goes through one EU platform to one coordinating CSIRT. The NIS2 report goes through your national channel. Today the EU platform cannot carry a NIS2 report.

	CRA Article 14	NIS2 Article 23
Channel	ENISA’s Single Reporting Platform (Art. 16), using the end-point of one national CSIRT	The national CSIRT or competent authority, through the channel your national law sets
Recipient	CSIRT designated as coordinator, and ENISA at the same time (Art. 14(1) and (3))	CSIRT or, where applicable, the competent authority (Art. 23(1))
Which country	Main establishment: where cybersecurity decisions on your products are mainly taken (Art. 14(7))	Where each entity is established (Art. 26(1))
Group with EU subsidiaries	One notification per event for the manufacturer (ENISA FAQ 8)	Each in-scope entity reports in its own Member State
Cross-border spread	Coordinator CSIRT passes it on to the other Member States you list (Art. 16(2))	CSIRT, authority or single point of contact informs others where appropriate (Art. 23(6))

There’s a link between the two. CRA Article 3(51) defines the “CSIRT designated as coordinator” as the CSIRT each Member State names under NIS2 Article 12(1) for coordinated vulnerability disclosure. That can be the same national CSIRT that receives your NIS2 reports, but the SRP is a separate system. ENISA’s SRP FAQ states that the platform currently supports only mandatory notifications under Article 14 of the CRA (FAQ 30). Where a Member State runs several CSIRTs (Poland has three, Spain two, as our map of national NIS2 reporting portals shows), your NIS2 recipient depends on your sector and may not be the CRA coordinator at all.

Choose the CRA coordinator with care: a notification sent to the wrong one may be invalidated and has to be resubmitted (ENISA FAQ 18).

The step-by-step filing sequence for one event

The scenario below is illustrative. A 300-person maker of industrial network controllers (NACE C26, an important entity in its home Member State) detects suspicious activity late on a Friday. All times are UTC, because the SRP records awareness in UTC (SRP Glossary, field i37).

1. Fri 30 Oct, 22:40: detection. The SOC flags an unknown process on the firmware-signing server. Open one incident record with two regime tracks and log detection and awareness separately. The SRP field is currently labelled “detected”, but the glossary defines it as awareness. Effort: Low.
2. Sat 31 Oct, 03:10: CRA awareness. Forensics confirm that a firmware package on the download portal differs from the build artefact. The portal is taken offline and logs show no customer downloads. Under Art. 14(5)(b) an incident “capable of leading to” malicious code in the product is severe, so the CRA clock starts now. NIS2 is assessed and recorded as not yet significant: no operational disruption, and no customer has the package. If customers had already downloaded it, Art. 23(3)(b) could have made it significant at the same moment. Effort: Medium.
3. Sat 31 Oct, 14:00: CRA early warning filed through the SRP (due Sun 1 Nov, 03:10). It states whether malicious acts are suspected and lists the Member States where the product is available. Weekends don’t pause the clock. Effort: Low.
4. Mon 2 Nov, 06:30: second impact. The same intruder’s ransomware encrypts the ERP system, and order processing and shipping stop. At 09:00 the incident manager concludes this is severe operational disruption under Art. 23(3)(a). NIS2 awareness starts here, about 54 hours after the CRA clock. Effort: Medium.
5. Mon 2 Nov, 15:00: NIS2 early warning to the national CSIRT (due Tue 3 Nov, 09:00). It indicates suspected malicious acts and any possible cross-border impact. Effort: Low.
6. Mon 2 Nov, 16:00: CRA incident notification (due Tue 3 Nov, 03:10). It covers the nature of the incident, an initial assessment, measures taken, measures users can take, and how sensitive the information is. Effort: Medium.
7. Same day: inform users. Art. 14(8) sets no fixed deadline, and this company chooses to act the same day. The article requires informing impacted users, and where appropriate all users, about the incident and any measures they can deploy. NIS2 Art. 23(1) separately asks you, where appropriate, to notify the recipients of your services. For a manufacturer, that can include customers whose deliveries have stopped. One advisory can serve both if it covers the product risk and the service disruption. Effort: Medium.
8. Wed 4 Nov, 11:00: NIS2 incident notification (due Thu 5 Nov, 09:00). It updates the early warning and gives an initial assessment of severity and impact, plus indicators of compromise where available. Effort: Medium.
9. Final reports, on two dates. The CRA final report is due one month after the CRA incident notification was submitted, so by 2 December 2026. The NIS2 final report is due one month after the NIS2 incident notification, so by 4 December 2026. If the incident is still ongoing on 4 December, NIS2 Art. 23(4)(e) requires a progress report then and a final report within one month of handling the incident. The CRA has no equivalent, so its final report goes in on time with the best root-cause assessment available. Effort: High.
10. Watch for a third track. If forensics show the intruder got in through a flaw in one of your own products, you now have an actively exploited vulnerability. It is reported separately under Art. 14(1) and (2), and its final report is due 14 days after a fix or mitigation is available. Effort: Medium.

Either CSIRT may also request an intermediate status report: the CRA coordinator under Art. 14(6), the NIS2 recipient under Art. 23(4)(c). One practical warning: ENISA’s FAQ 26 says the SRP’s 72-hour counter currently shows a due time 48 hours after the early warning was submitted, not 72 hours after awareness. Set deadlines from your own awareness log, not from the platform’s counter.

Field by field: what you can write once

Reading CRA Article 14(4)(c) and NIS2 Article 23(4)(d) side by side, we found that their first three final-report items are word-for-word identical: “a detailed description of the incident, including its severity and impact”, “the type of threat or root cause that is likely to have triggered the incident”, and “applied and ongoing mitigation measures”. NIS2 adds a fourth item, the cross-border impact where applicable.

Item	CRA (Art. 14(4))	NIS2 (Art. 23(4))	Write once?
Suspected unlawful or malicious acts	Early warning, “at least”	Early warning, “where applicable”	Yes
Geography	Member States where the product is available	Possible cross-border impact	No: different questions
Initial assessment	72h notification	72h notification, including severity and impact	Mostly
Indicators of compromise	Not listed	Where available	NIS2 only
Measures users can take; sensitivity of the information	72h notification	Not listed	CRA only
Description, root cause, mitigation	Final report (i)–(iii)	Final report (i)–(iii)	Yes, identical wording
Cross-border impact	Not listed	Final report (iv)	NIS2 only

“Write once” has limits on the SRP. Its root-cause field holds 255 characters, while the detailed impact description takes up to 4,000 (SRP Glossary, fields i35 and i36). Keep the full root-cause analysis in your incident record and paste a 255-character summary into the SRP. Our guide to the NIS2 Article 23 incident notification covers the national content rules.

Who owns which filing

Role	Owns	Watch for
PSIRT lead (SRP Assigned Representative)	CRA tests, SRP filings, user advisory	SRP drafts are visible only to the AR who wrote them (ENISA FAQ 9); draft in a shared record
CISO / incident manager	NIS2 significance assessment and national filings	Rerun the Art. 23(3) test whenever the impact changes, as it did on Monday morning in the scenario
Compliance officer / Legal	Awareness log, parallel-regime check (NIS2, GDPR, contracts)	Record why NIS2 was “not yet significant” at each checkpoint; it is your evidence if timing is questioned
SME owner / management	Approving who may file outside office hours	CRA Art. 64(10)(a) spares micro and small enterprises a fine for a late early warning only; the duty to report remains

Breaching CRA Article 14 can bring fines of up to €15 million or 2.5% of worldwide turnover, whichever is higher (Art. 64(2)). For an important entity, breaching NIS2 Article 23 carries a national maximum of at least €7 million or 1.4% (Art. 34(5)), and at least €10 million or 2% for essential entities. CRA Article 17(4) and NIS2 Article 23(1) both state that notifying does not by itself expose you to increased liability.

What may change: the Digital Omnibus proposal

The Commission’s Digital Omnibus proposal, COM(2025) 837, would add a new NIS2 Article 23a: a single-entry point for incident reporting, run by ENISA, which “may” build on the CRA platform. It would also add an Article 23(12) to NIS2. Under it, a CRA Article 14(3) severe-incident report that “contains relevant information as required under paragraph 4” of Article 23 “shall constitute reporting of information” under NIS2. It would cover severe incidents only, not actively exploited vulnerabilities. Under the proposal, the single-entry point would come into use 18 months after the regulation enters into force, or 24 months if the Commission delays it.

It is still a proposal. The European Parliament’s Legislative Observatory lists procedure 2025/0360(COD) as “Awaiting committee decision” (checked 19 October 2026). Until it is adopted and in use, file both sequences. CRA Recital 72 only encourages Member States to offer national single entry points; it creates no obligation. You can prepare now: write your CRA reports so they also carry the NIS2-only items, cross-border impact and indicators of compromise.

Frequently asked questions

Does filing on ENISA’s Single Reporting Platform satisfy NIS2?
No. The SRP currently accepts only mandatory CRA Article 14 notifications (ENISA FAQ 30). NIS2 Article 23 reports go to your national CSIRT or competent authority through the channel your national law sets.

Do both 24-hour clocks start at the same time?
Only if both tests are met at the same moment. The CRA clock starts when you become aware of a severe incident affecting product security. The NIS2 clock starts when you become aware of a significant incident. In the scenario above they started about 54 hours apart.

Is the CSIRT that receives the CRA report the same one that receives NIS2 reports?
Often, but not always. The CRA coordinator is the CSIRT named under NIS2 Article 12(1), while your NIS2 recipient depends on national law and, in some countries, on your sector. Even when it’s the same organisation, the reports arrive through different systems.

Does a personal-data breach add a third report?
It can. If personal data is involved and you are its controller, check the GDPR breach-notification duty as well. It runs separately from both the CRA and NIS2 filings.

Groups rolling out one CRA reporting procedure across several entities, or consultants serving clients, can use the CRA Enterprise Licence. For the wider programme, start with the Cyber Resilience Act compliance guide.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal text — EUR-Lex. Articles 2(2), 3(42)–(44) and (51), 14, 16, 17(4), 64, 69(3) and 71; Recital 72.
2. Cyber Resilience Act, Articles 3, 14, 16 and 64 — european-cyber-resilience-act.com (consolidated article text).
3. Directive (EU) 2022/2555 (NIS2), Official Journal text — EUR-Lex. Articles 6(6), 12(1), 23, 26(1) and 34; Recital 101; Annex II, sector 5.
4. NIS2 Directive, Articles 23 and 26 — nis-2-directive.com (article text).
5. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex. Article 1.
6. CRA Single Reporting Platform: Frequently Asked Questions — ENISA. FAQs 8, 9, 18, 26 and 30.
7. CRA SRP Glossary — ENISA. Fields i35–i37.
8. Proposal for a Regulation amending the digital acquis (Digital Omnibus), COM(2025) 837 final, 19 November 2025 — EUR-Lex. Proposed NIS2 Articles 23(12) and 23a.
9. Procedure file 2025/0360(COD) — European Parliament Legislative Observatory, accessed 19 October 2026.