NIS2 vs CRA incident reporting: which obligation applies to your software company
If your company builds software or devices and is also an essential or important entity under NIS2, you may have to run two reporting regimes, and the first decision is which incident belongs to which one. NIS2 covers significant incidents affecting the services your entity provides, and you report them to your national CSIRT. The Cyber Resilience Act covers actively exploited vulnerabilities and severe incidents in the products you place on the EU market, and you report them to the CSIRT designated as coordinator and to ENISA through the Single Reporting Platform. Both regimes start with an early warning within 24 hours and a notification within 72 hours, but their final report clocks and triggers differ.
The question to ask first is whether the incident affects your own services or the product you place on the market. An outage in your hosted platform, a compromise of your cloud environment or a breach of your internal build system is a NIS2 question because the affected system delivers your service. A vulnerability in code you ship to customers is a CRA question. Some events hit both, such as a compromised update server that serves customer products and also runs your hosted service. Record which obligation each report discharges, and confirm with your national authority which significant incident criteria apply to your sector under Article 23 of NIS2.
The final report clocks are where teams most often diverge. NIS2 requires a final report within one month of the incident notification. Under the CRA, a severe product incident also gets a final report one month after notification, but an actively exploited vulnerability gets a final report within 14 days after a corrective or mitigating measure is available. The CRA channel is new: ENISA launched the initial operating capability of the Single Reporting Platform on 11 September 2026, so confirm your account and contact details before an incident. Micro and small enterprises are exempt from fines for missing the CRA 24-hour early warning under Article 64(10), but that exemption covers fines only, so the duty to report still applies.
How NIS2 and the CRA compare on reporting triggers, stages and recipients
This table sets NIS2 incident reporting for in-scope entities against CRA reporting for manufacturers, row by row across legal basis, triggers, stages, recipients and start dates. Read each row as a question: if you are a software or device maker that is also a NIS2 entity, you may owe reports under both regimes for different events, so check each row against your own incident types.
| Element | NIS2 (significant incidents affecting entity services) | CRA (product incidents and exploited vulnerabilities) |
|---|---|---|
| Legal basis | Article 23 of Directive (EU) 2022/2555, transposed through national law | Article 14 of Regulation (EU) 2024/2847 |
| What triggers a report | A significant incident affecting the entity's own services, as defined under national law and the criteria in Implementing Regulation 2024/2690 where it applies | An actively exploited vulnerability in the product, or a severe incident having an impact on the security of the product |
| Early warning | Within 24 hours of becoming aware of a significant incident | Within 24 hours of becoming aware, for exploited vulnerabilities and for severe incidents |
| Incident or vulnerability notification | Incident notification within 72 hours | Vulnerability notification within 72 hours; incident notification within 72 hours for severe incidents |
| Final report timing | Within one month of the incident notification | Vulnerabilities: within 14 days after a corrective or mitigating measure is available. Severe incidents: within one month after the incident notification |
| Recipients | The CSIRT or, where applicable, the competent authority | The CSIRT designated as coordinator, with ENISA receiving the notification at the same time through the Single Reporting Platform |
| Start date of the obligation | National transposition applied from 18 October 2024 (Article 41) | Article 14 reporting applies from 11 September 2026, for all in-scope products placed on the market |
| Small enterprise treatment | Confirm the position under your national transposition law and any proposed amendments still under review | Article 64(10) exempts microenterprises and small enterprises from fines for missing the 24-hour early warning deadline |
What decides which reporting track an incident falls under
An incident can trigger NIS2, the Cyber Resilience Act, or both, and the answer depends on what was hit and when. The cards below cover the questions to settle before any clock starts, since each one can move an incident from one regime to the other.
Entity service or product
NIS2 reporting concerns significant incidents affecting the services the entity itself provides. The Cyber Resilience Act concerns severe incidents and actively exploited vulnerabilities in a product with digital elements placed on the EU market. Check whether the affected asset is your own operated service, a product you ship to customers, or both, because a single event can touch each.
Article 14 placement dates
The Article 14 reporting obligations apply to in-scope products whenever they were placed on the market, so older products are not exempt from reporting even though most other CRA obligations wait until later. Record when each affected product version was placed on the market, since that date is what determines whether a reporting duty applies to it.
Actively exploited vulnerability
A vulnerability that is actively exploited in a manufacturer's product triggers a CRA notification to the CSIRT designated as coordinator and to ENISA, separate from any NIS2 filing. Confirm whether evidence of exploitation exists, because the clock for the early warning starts when the manufacturer becomes aware of it.
Suspected unlawful or malicious acts
For severe product incidents, the CRA early warning must state whether unlawful or malicious acts are suspected. NIS2 reporting does not use this same field in the same way, so the incident response team should capture the suspicion assessment at the first report rather than reconstruct it later. Ask who makes that call and how quickly it can be made.
Microenterprise or small enterprise status
Article 64(10) of the CRA exempts microenterprises and small enterprises from fines for missing the 24-hour early warning deadlines in Article 14. That exemption affects fines only, not the duty to report. Confirm your headcount and turnover against the official definitions, since the exemption does not change how NIS2 applies to the entity.
Open-source software steward role
Article 64(10) also exempts open-source software stewards from fines for any infringement of the CRA. Whether an organization holds the steward role depends on its function in the open-source project, not on whether it publishes code. Check the Commission guidance on free and open-source software before relying on this exemption, and review whether NIS2 obligations still apply to your entity.
How to map one incident to both reporting regimes
This sequence helps a software maker decide which reporting tracks an incident triggers, when the clocks start, and who receives each notice, so one event produces the right filings without missed deadlines. It is illustrative and should be confirmed with the national CSIRT and the Single Reporting Platform guidance before use.
Classify the incident against both regimes
The incident owner, with product security and legal present, decides whether the event affects the entity's own services under NIS2, the product under the Cyber Resilience Act, or both. A vulnerability in a shipped product that is actively exploited points to the CRA track, while a significant incident in the hosted service you run points to NIS2. Many events touch both, so record the classification as a yes or no for each track with the reason. The output is a signed classification record that names the affected services, the affected product versions and the decision maker.
Fix the awareness time that starts the clock
Record the exact moment the organization became aware of the incident or actively exploited vulnerability, using the same timestamp in both tracks. The 24-hour early warning runs from that point under the NIS2 reporting article and under the CRA Article 14 obligations, so a shared incident log with timestamps from detection tools, ticket creation and escalation is the evidence you will need later. Confirm with counsel how your national law and the CRA guidance define awareness for your case, since the wording differs in detail between the two regimes.
Identify the recipient for each track
Name the recipient for each track before the clock runs. For NIS2, the recipient is the CSIRT or, where applicable, the competent authority in your Member State. For CRA reports on actively exploited vulnerabilities and severe incidents in products, notifications go through ENISA's Single Reporting Platform to the CSIRT designated as coordinator, and ENISA receives them at the same time. Confirm with your national CSIRT which body is the coordinator for your products and how it wants to receive filings, and check the Single Reporting Platform guidance for account and submission steps.
Draft the early warning content
Prepare the 24-hour early warning with the facts you can verify at that point: the affected service or product, the likely impact, and whether the incident is significant under NIS2 or a severe incident under the CRA. For a CRA severe incident, the early warning must also state whether unlawful or malicious acts are suspected, so the response team must make and record that assessment in the first hours. Keep a statement of what is unknown, since later stages will update it. The output is a reviewed draft approved by a named officer and stored with the timestamp.
Submit the early warning on both tracks
Send the early warning to each recipient identified in the earlier step, and keep the submission receipts, confirmation emails or platform references for each one. Where a single event produces a CRA filing and a NIS2 filing, make sure the two versions do not contradict each other on facts such as scope, timing or suspected malicious activity. The check that closes this step is a filed record per track, with the content version and the time sent. The early warning cannot be deferred to the 72-hour stage.
Track the 72-hour notification separately
Set a separate tracker for the incident notification stage, due within 72 hours under NIS2 and for the CRA vulnerability or severe incident notification. Each track has its own deadline and its own recipient, so a single task list is not enough. Update the notification with the assessment of severity, impact and any mitigation in place, and confirm the content with the CSIRT before filing. The check is a completed notification per track, with the version of the facts used.
Track the final report stages on their own calendars
Open separate tickets for the final report stages. Under NIS2, the final report is due within one month of the incident notification. Under the CRA, the vulnerability final report is due within 14 days after a corrective or mitigating measure is available, and the severe incident final report within one month after the incident notification. Because these dates run from different events, do not reuse one calendar entry. Close the step when each final report is filed, and retain the full incident file for both regimes so that a later authority request can be answered from one record.
What the SME exemptions in Article 64(10) do and do not cover
Article 64(10) of the Cyber Resilience Act is a fine exemption, not a reporting exemption. It exempts microenterprises and small enterprises from fines for missing the 24-hour early warning deadline in Article 14, and it exempts open-source software stewards from fines for any infringement. Microenterprises and small enterprises still owe the early warning, the 72-hour vulnerability or incident notification and the final report, and the Single Reporting Platform still expects them. A small manufacturer that reads the clause as permission to skip or delay notifications has misread it. Confirm the size category that applies to your company and whether you are a steward, since the two exemptions cover different groups and different infringements.
The clause also does nothing to NIS2. NIS2 reporting duties under Article 23 and NIS2 fines are set through national transposition laws, and Article 64(10) of the CRA does not reach them. An entity that is both a software maker and an NIS2 essential or important entity must still meet the NIS2 24-hour early warning and 72-hour notification to its CSIRT or competent authority, whatever its size under the CRA. Check your Member State's transposition law for the size thresholds and penalties it applies, and do not assume that a small-company status under one regime carries over to the other.
The Commission's COM(2026) 13 proposal would add a new small mid-cap category to NIS2. That category is a proposal only. It needs approval by the European Parliament and the Council, and Commission pages updated through July 2026 still describe it as a proposal, so it should not change your current NIS2 planning. Build your reporting process to the rules in force, record which size category you have assumed and why, and review that assumption when the legislative text is final. Ask your legal counsel to confirm the national law position in each Member State where you operate.
Which reporting track applies to which kind of software business
This profile fits a SaaS provider that is an essential or important entity under NIS2 and does not place its service on the market as a product with digital elements. The reporting duty attaches to significant incidents affecting the entity's services, and the notices go to the national CSIRT or competent authority rather than to ENISA's platform. The clock and stages are the NIS2 ones, and the substance of the significant incident is set by the sector criteria.
- Clock: an early warning without undue delay and within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month of the notification (Article 23(4)).
- Recipient: the CSIRT or competent authority designated under your Member State's transposition law. Confirm which body and which channel it uses.
- Sector criteria: cloud computing and managed service providers fall under Implementing Regulation (EU) 2024/2690, which sets significant incident criteria for them. Confirm which criteria match your service type.
- Classification: essential or important status (Article 3) changes how supervision works, not the reporting stages.
- Product question: the CRA does not apply to this profile only if the service is not a product with digital elements under the Commission's guidance.
Confirm with counsel whether the service falls outside the CRA under the Commission's July 2026 guidance, and ask the national CSIRT how it wants NIS2 notices submitted.
This profile fits a manufacturer of installed software or connected devices that is in the CRA scope and is not itself an in-scope NIS2 entity. The duty is to report actively exploited vulnerabilities and severe incidents affecting the security of the product, through ENISA's Single Reporting Platform. The obligations for these reports apply from 11 September 2026, and they reach products already on the market when they fall in scope.
- Exploited vulnerability: an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure is available (Article 14(1) and (2)).
- Severe incident: an early warning within 24 hours that states whether unlawful or malicious acts are suspected, an incident notification within 72 hours, and a final report within one month after the notification (Article 14(3) and (4)).
- Recipient: notices go to the CSIRT designated as coordinator, and the platform makes them available to ENISA at the same time.
- Small enterprises: microenterprises and small enterprises are exempt from fines for missing the 24-hour early warning deadline (Article 64(10)). The deadline itself still applies.
- Open-source stewards: stewards are exempt from fines for any infringement under the same provision.
Confirm with counsel whether your company meets the SME criteria, which product class applies, and whether any support period or substantial modification affects which reports you owe.
This profile fits a company that is an in-scope NIS2 entity and also places products with digital elements on the EU market, such as a vendor whose hosted service and shipped software share components. One underlying event can start two reporting processes with different triggers, recipients and content requirements. The two regimes do not merge their clocks, so each track must be run separately even when the same team handles both.
- Two clocks: a NIS2 notice runs on the service impact, while a CRA notice runs on the product. A flaw present in both may start a 24-hour window under each regime.
- Two recipients: the national CSIRT or authority for NIS2, and the Single Reporting Platform for the CRA, which also makes the notice available to ENISA.
- Different content: the CRA early warning must state whether unlawful or malicious acts are suspected, while the NIS2 notice focuses on significant incident impact on your services.
- Exemptions stay narrow: the Article 64(10) exemption sits in the CRA. It does not change NIS2 deadlines or the national rules that set NIS2 penalties.
- Illustrative: a vulnerability in a shared library is exploited in the company's hosted service and in a shipped agent. That case would need two notices, two channels and two sets of stages.
Confirm with counsel how each regime's decision points map to one incident playbook, and ask the national authority whether transposition law adds reporting requirements under Article 5.
Questions software makers ask about NIS2 and CRA reporting
How much effort does it take to run two reporting tracks for NIS2 and the CRA?
Effort depends on how many reportable events each track can generate and how much of the evidence already exists. NIS2 reporting covers significant incidents affecting the entity's own services, while CRA reporting covers actively exploited vulnerabilities and severe incidents in products, so one event can trigger both. The main recurring work is keeping a triage step that decides which track applies, which clock starts, and who signs each submission. No supplied fact gives a figure for staff hours or cost, so ask any provider to break its quote into one-time build work (procedures, templates, contact lists, tabletop tests) and recurring work (monitoring, triage, reporting and updates during live events). Your own incident history will be the best input to that estimate.
What drives the effort of running NIS2 and CRA incident reporting?
Four factors usually move the effort most. The first is how many products and services are in scope, since each product line needs its own vulnerability handling and severe-incident path. The second is whether the same incident can reach both the CSIRT for your NIS2 entity and the CRA Single Reporting Platform, which requires one intake point that routes to both. The third is the number of notification stages: the NIS2 path runs an early warning within 24 hours, an incident notification within 72 hours and a final report within one month of that notification, while the CRA vulnerability path runs 24 hours, 72 hours and a final report within 14 days after a corrective or mitigating measure is available. The fourth is how quickly your engineering and legal teams can produce accurate content inside those windows.
How much lead time do we need before CRA reporting starts on 11 September 2026?
The Article 14 CRA reporting obligations apply from 11 September 2026, and ENISA launched the initial operating capability of the Single Reporting Platform on that same day. That date applies to all in-scope products already on the market, so the lead-in is short. In practice you need a named owner, an intake procedure, a way to determine whether a vulnerability is actively exploited, templates for each stage, and a tested contact path to the CSIRT designated as coordinator. Check whether your product line also needs a separate NIS2 path, and confirm with your national authority which CSIRT receives your notifications. Start with an inventory of products and a dry run of one exercise before the date, because the first live event is a poor time to learn the portal steps.
What does the work need from our security and product teams?
Security teams own detection, triage and the decision on whether an event is significant or actively exploited, and they must be able to make that call within the 24-hour window. Product teams own the technical facts: affected versions, available patches or mitigations, and whether a severe incident affects the product's security. Legal and compliance teams review content, track the fine exposure set out in the CRA (up to EUR 15 million or 2.5% of total worldwide annual turnover for breaches of Annex I and Articles 13 and 14, whichever is higher) and manage the NIS2 national transposition questions. Each team needs written roles, a fallback owner for weekends, and a shared record of what was sent and when.
Can we build the NIS2 and CRA reporting process ourselves?
Many software makers can build the process in house if they already run a mature incident response program and have product security staff who handle vulnerability disclosure. The internal work is usually the procedure, the decision criteria, the templates and the exercises. Harder parts are keeping the criteria current as guidance changes, and proving the process worked when it is tested. Note that the Commission published non-binding CRA guidance on 27 July 2026 and ENISA's NIS2 technical guidance followed Implementing Regulation (EU) 2024/2690, so your decision rules need periodic review against those documents. Before deciding, confirm whether you are an essential or important entity under NIS2, and whether a micro or small enterprise exemption from fines for missing the 24-hour early warning deadline applies to you under Article 64(10) of the CRA.
When is outside help worth buying for NIS2 and CRA reporting?
Outside help is most useful when the reporting path touches several products, when you need a tested runbook before 11 September 2026, or when your team has no one who can write and rehearse incident content under pressure. DeployOpen plans, implements, documents and tests self-hosted platforms and runs security testing and cyber range exercises, so a fixed-scope engagement could cover the intake system, runbooks, templates and a tabletop or live-fire drill inside your own infrastructure. DeployOpen does not issue audit reports or certifications, and ENISA and national authorities decide how submissions are assessed. Ask any provider for a written scope, the named deliverables, what is one-time and what is a retainer, and how the work will be tested before the first real event.
How to confirm your reporting obligations in your own environment
This sequence turns the two reporting regimes into a documented, product-by-product and entity-by-entity map, so you know which clock starts for which incident before one happens. Each step closes with a record your compliance lead and the national authority can review.
Inventory products and services
Start with a register that lists every product with digital elements you make or distribute and every service your organization delivers to customers. For each product, record the version, the placement date on the EU market, whether it is installed software or a hosted service, and who owns it. Keep service records separate so that NIS2 incident scope and CRA product scope are not mixed up. The step is done when engineering, product and legal have signed off on the list and nothing in production is missing from it.
Check Article 14 timing per product
For each product on the register, determine whether the Article 14 reporting obligations apply, using the placement date and the rule that these obligations reach in-scope products whenever they were placed on the market. Record the date from which the Article 14 reporting obligations apply, then map the early warning, notification and final report stages to your vulnerability and incident handling workflow for that product. The output is a per-product table showing which stage applies, which recipient receives it, and who on the response team is accountable for starting each clock.
Confirm NIS2 sector and classification
Decide whether your organization is an in-scope entity under NIS2 by checking its sector against Annex I or Annex II and its size and activities against the entity criteria. Then confirm with the national competent authority or CSIRT in each Member State where you operate whether you are classed as essential or important, since that classification drives supervision. Ask the authority which CSIRT receives your NIS2 notifications and how the national transposition law applies to your sector. The step is complete when you hold written confirmation of classification and reporting recipients, and the SME exemptions you may or may not rely on are documented with counsel's review.
Run a tabletop on one shared incident
Build one illustrative scenario in which a vulnerability in a product also disrupts a service you run for customers. Walk the team through both clocks at the same time: the NIS2 early warning, notification and final report for the service, and the CRA early warning, notification and final report for the product, with the simultaneous notice to the designated CSIRT and ENISA. Record where the two timelines conflict on information, approvals or who signs, and where the same facts can be reused. The output is a tabletop report with named owners, open questions and changes to the runbook. Label the scenario as illustrative in the exercise record.
Confirm recipients and submission channel
Check the ENISA guidance on the Single Reporting Platform for how manufacturer notifications are submitted, what fields are required, and how notifications reach the CSIRT designated as coordinator. Confirm with your national CSIRT how NIS2 submissions are made in each country. Test account access, authentication and internal routing before you need them, and store the approved contact points for both channels. The step is done when a named person can submit to each recipient, the credentials are held by at least two people, and the evidence of each submission is retained in your incident system.
What changes for your team when CRA reporting starts
From 11 September 2026, manufacturer reporting obligations under Article 14 of the Cyber Resilience Act apply. Any in-scope manufacturer must send notifications of actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform, with each notification going to the CSIRT designated as coordinator and made available to ENISA at the same time. The practical first step is to confirm whether your products fall under the regulation at all. Under Article 69, products placed on the market before 11 December 2027 are only in scope if they are substantially modified from that date, but the Article 14 reporting duties reach all in-scope products whenever they were placed on the market. Many organizations that are NIS2 entities will not be CRA product manufacturers, and a company whose software is delivered only as a service may face different questions under the regulation's guidance. Confirm your product scope with counsel before building a reporting process around it.
For manufacturers that are in scope, the operational work sits in three places. First, one intake point for incident and vulnerability reports, so that a security engineer who spots an exploited flaw in a shipped product knows exactly where to escalate it and who owns the clock. Second, a documented awareness timestamp for each report, recorded when the manufacturer first becomes aware, because the 24-hour early warning, the 72-hour notification and the final report stages all run from that point. Third, content templates for each stage, covering whether unlawful or malicious acts are suspected in the early warning, and the information the 72-hour notification and the final report must carry. Ask your legal or compliance team to confirm the exact content fields against the regulation and the current ENISA guidance before you finalize templates, since the Article 14 requirements are the authoritative source.
How DeployOpen helps software makers build dual reporting processes
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including the incident handling and reporting workflows that a software maker needs for NIS2 and the Cyber Resilience Act. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- The written scope separates NIS2 entity reporting from CRA product reporting so each obligation has its own owner and trigger.
- We confirm which products, services and entity roles are in scope, including whether any product is a CRA product with digital elements.
- The scope lists the internal decision points, such as who classifies a significant incident and who decides on a CRA severe incident.
How we build
- We set up one intake process that records each incident once and routes it to the NIS2 CSIRT workflow, the CRA Single Reporting Platform workflow, or both.
- Stage templates cover the early warning, the incident notification and the final report, with fields that match each regime's content requirements.
- We test the workflow with tabletop exercises so the 24-hour and 72-hour clocks are tested before a real event starts.
How we hand over
- You receive the runbooks, reporting templates, decision records and role assignments, written so your own staff can operate them.
- Each decision point, including the basis for suspecting unlawful or malicious acts, is documented with the evidence reviewed at the time.
- We walk your incident response, legal and product teams through the handover so responsibilities are clear before the first report is due.
How we support
- Ongoing support, upgrades and continuous testing of the reporting workflow are available as retainers after handover.
- Retainers can cover updates when the Commission, ENISA or national authorities change guidance, so the process keeps matching current requirements.
- Confirm with your national competent authority and the CRA Single Reporting Platform guidance which channels and forms apply to your entity.
