CRA Reporting Starts 11 September 2026: What NIS2 Organisations Must Do Now

Your client ships smart HVAC controllers to office buildings across Europe. On 12 September 2026, a researcher tells them attackers are actively exploiting a flaw in the controller firmware. From that moment, your client has 24 hours to file an early warning with their national CSIRT and ENISA.

That obligation is new. CRA reporting under Article 14 of the Cyber Resilience Act becomes applicable on 11 September 2026 — a full 15 months before the rest of the regulation. If you advise NIS2-regulated organisations that also manufacture or sell products with digital elements, this deadline is yours too.

Most consultants have filed the CRA away as a 2027 problem. The reporting piece is a 2026 problem, and it lands in two weeks.

CRA reporting obligations start on 11 September 2026

From 11 September 2026, manufacturers of products with digital elements must report two things: actively exploited vulnerabilities in their products, and severe incidents that affect the security of those products.

The scope is wide. Routers, smart locks, industrial controllers, IP cameras, firmware, and standalone software all qualify as products with digital elements. The obligation covers products already on the market today — not just products shipped after the deadline.

Reports go through the CRA Single Reporting Platform operated by ENISA. The manufacturer files once; the notification reaches the CSIRT of the member state where it has its main establishment, and ENISA sees it simultaneously. The European Commission has confirmed the platform is in final testing and will be operational by 11 September 2026.

Note what triggers the duty: actively exploited means someone is using the flaw in the wild. A vulnerability found in an internal code review stays internal — for now, handled under normal coordinated vulnerability disclosure practice.

The CRA is not NIS2 — and many of your clients sit under both

NIS2 regulates entities: how an organisation runs its networks, its risk management, its incident response. The CRA regulates products: what a manufacturer ships, how it handles vulnerabilities in that product, and how long it provides security updates.

Take a mid-sized medical device manufacturer. Under NIS2 it is an important entity in the health sector — its factories, IT, and incident handling fall under the ten Article 21 measures. Every device it ships is separately covered by the CRA. Two regimes, one company, different obligations, different regulators.

The reporting paths are separate too. NIS2 incident reports go to the competent authority or CSIRT for the affected service. CRA reports go through the Single Reporting Platform for the affected product. Filing one does not discharge the other.

NIS2 vs ISO 27001 — Requirements Comparison
◈NIS2 Only
Mandatory incident reporting to authorities (24h / 72h)
Board-level personal liability for cybersecurity
Supply chain security obligations for essential entities
Sector-specific regulatory obligations
⬡Shared Requirements
Information security risk management
Access control and identity management
Business continuity and disaster recovery
Security awareness and training
◇ISO 27001 Only
Internal audit and management review cycles
Statement of Applicability (SoA) documentation
Formal certification and third-party audit
◈NIS2 Only
Mandatory incident reporting to authorities (24h / 72h)
Board-level personal liability for cybersecurity
Supply chain security obligations for essential entities
Sector-specific regulatory obligations
⬡Shared Requirements
Information security risk management
Access control and identity management
Business continuity and disaster recovery
Security awareness and training
◇ISO 27001 Only
Internal audit and management review cycles
Statement of Applicability (SoA) documentation
Formal certification and third-party audit
The centre column shows requirements that both NIS2 and ISO 27001 share

One event can start two reporting clocks

Here is where it gets operational. Suppose that HVAC manufacturer is also a NIS2 important entity, and the exploited firmware flaw lets attackers pivot into its own production network. That single event triggers both regimes at once.

Under the CRA, the clock runs: early warning within 24 hours, full notification within 72 hours, and a final report no later than 14 days after a corrective measure is available for an exploited vulnerability. For severe product incidents, the final report is due within one month.

Under NIS2, a parallel clock runs for the significant incident on the entity side: early warning within 24 hours, incident notification within 72 hours, final report within one month. The NIS2 deadlines have applied since 2024–2025 depending on member state; the official reporting templates are now standardised.

Same event, two filings, two recipients, two evidence trails. An incident response runbook that only knows about NIS2 is now half a runbook.

NIS2 Incident Reporting Timeline
24h
⚡
Early Warning
Notify the competent authority (CSIRT/NCA) within 24 hours of becoming aware of a significant incident.
Step 1
72h
📋
Incident Notification
Submit a detailed notification within 72 hours with an initial assessment of severity, impact and indicators of compromise.
Step 2
1mo
📊
Final Report
Deliver a comprehensive final report within one month covering root cause, remediation taken and cross-border impact.
Step 3
24h
⚡
Early Warning
Notify the competent authority (CSIRT/NCA) within 24 hours of becoming aware of a significant incident.
72h
📋
Incident Notification
Submit a detailed notification within 72 hours with an initial assessment of severity, impact and indicators of compromise.
1mo
📊
Final Report
Deliver a comprehensive final report within one month covering root cause, remediation taken and cross-border impact.

The penalties stack

The CRA carries fines of up to €15 million or 2.5% of global annual turnover — and that top tier explicitly includes violations of the Article 14 reporting duties. NIS2 adds up to €10 million or 2% for essential entities and €7 million or 1.4% for important entities.

These are separate legal bases. A manufacturer that misses both filings on the same event faces exposure under both regulations, plus GDPR if personal data is involved. Regulators do not offset one fine against the other.

The non-financial consequences follow the same pattern as NIS2: market surveillance authorities can force corrective actions, restrict a product's availability, or pull it from the EU market entirely. For a product company, that hurts more than the fine.

NIS2 Penalty Escalation — Beyond the Fine
!
Trigger event
Non-Compliance Detected or Incident Occurs
A supervisory authority identifies a compliance gap or an organisation fails to meet NIS2 requirements
Authorities can impose
▼
Non-Monetary Penalties
1
Compliance orders with binding deadlines
2
Mandatory security audits at your expense
3
Public disclosure of violations
4
Binding instructions on specific security measures
Escalates to
▼
Operational & Personal Consequences
1
Suspension of certifications or operating licences
2
Temporary ban on management functions for individuals
3
Public naming of responsible natural persons
Trigger
Non-monetary
Operational / personal

What MSPs and consultants should do before 11 September

Start with an inventory question you can answer this week: which of your clients place products with digital elements on the EU market? Manufacturer, importer, and even white-label reseller roles all carry CRA duties. If a client rebrands third-party hardware and sells it under their own name, they count as the manufacturer.

For each client that qualifies, five actions matter now.

First, determine the main establishment. That decides which national CSIRT receives their reports through the platform.

Second, wire detection to reporting. A 24-hour deadline fails at 3 a.m. on a Saturday unless exploitation reports from researchers, customers, and monitoring feed a defined on-call path. This is the same discipline NIS2 already demands of vulnerability handling under Article 21(2)(e) — extend it to the product side.

Third, update the incident response runbook so one triage decides both questions: is this a NIS2 significant incident, and is this a CRA reportable event? One severity matrix, two output paths.

Fourth, check the supplier chain. If your client integrates third-party components, their supplier contracts should oblige upstream vendors to pass exploitation intelligence downstream fast enough to meet the 24-hour clock.

Fifth, register for the Single Reporting Platform as soon as onboarding opens, not on the day of the first incident.

For MSPs, this is also a service opportunity. Clients who scrambled through NIS2 registration now face a second regime with tighter clocks. The advisor who maps both in one assessment wins the retainer.

Two weeks is enough — if you start with the gap

You do not need a finished CRA programme by 11 September. You need to know which clients are in scope, where their reports go, and whether their incident process can hit a 24-hour deadline. That is a gap analysis, not a transformation project.

Run a free NIS2 quick scan for each product-shipping client to establish their compliance posture on the entity side — then extend the findings to the product side. The organisations that handle September well will be the ones that knew their gaps in August.