Digital Omnibus: the Council wants national incident entry points. What it means for CRA reporting
· 4 min read · CRA news
In short: on 21 October 2026 the Council agreed its negotiating position on the Digital Omnibus. It rejects one EU-wide incident portal run by ENISA and wants a national entry point in each Member State instead. Nothing is law yet, and CRA reporting through ENISA's platform continues unchanged.
- This is an analysis piece: the Council position is 25 days old, but a law-firm briefing of 13 November 2026 shows why it matters now.
- Your CRA Article 14 duties (24 hours, 72 hours, final report) apply today and are not changed by this text.
- The Council's text would let a CRA severe-incident notification count for part of NIS2 reporting. One incident can still trigger GDPR duties separately.
What the Council agreed
The Commission's Digital Omnibus proposal of November 2025 would have created one reporting channel, run by ENISA, for incidents under several EU laws. According to the site kontorbund, that proposal is COM(2025) 837 of 19 November 2025. On 21 October 2026 the Council agreed its mandate and went another way. Per the IAPP and law firm Addleshaw Goddard, each Member State would run its own entry point, and ENISA would keep only an information point that tells organisations where to report.
A reading of the Council text by regreportingdesk adds detail: ENISA's information point could not accept, transmit or store a notification, and each Member State would have to maintain a national entry point. The same source reports a 30-month period before reporting through national entry points applies, against the 18 months the Commission proposed. We have not read the mandate text ourselves, so treat those numbers as that site's reading.
The text is a negotiating position. The IAPP and Lewis Silkin both note that the Parliament must adopt its own position first, and Addleshaw Goddard does not expect talks before March 2027. Lewis Silkin reports that EU leaders aim to finish the simplification packages by the end of 2027.
What does not change for CRA reporting
The Cyber Resilience Act already has its own channel. Under Article 14, manufacturers notify actively exploited vulnerabilities and severe incidents to the coordinating CSIRT and ENISA through the single reporting platform of Article 16. The deadlines are 24 hours for the early warning and 72 hours for the notification. The final report follows 14 days after a fix is available for a vulnerability, or one month after the incident notification for an incident. ENISA says the platform has been live since 11 September 2026.
The Council's press release does not name the CRA, according to kontorbund, and the IAPP, Lewis Silkin and Addleshaw Goddard summaries do not mention it either. Only regreportingdesk states that the Council design leaves the Article 16 platform alone. So the safe conclusion is limited: nothing we read suggests a change, and nothing in the proposals is in force.
Where the two regimes meet
The Council text proposes a new NIS2 provision, Article 23(12). Regreportingdesk reads it this way: a manufacturer's severe-incident notification under the CRA would satisfy the information-reporting part of NIS2 Article 23(4), where it contains what NIS2 requires. It would not replace any GDPR or DORA obligation. That fits the practical point made on 13 November by Pillsbury: one incident can trigger CRA, GDPR and NIS2 duties at once, each with its own test and clock, and the Omnibus would also lengthen the GDPR deadline from 72 to 96 hours for breaches that carry a high risk.
| Question | Today | If the Council text prevails |
|---|---|---|
| Where do I file a CRA report? | ENISA's single reporting platform | Same, per regreportingdesk's reading |
| CRA early warning | 24 hours after awareness | No change proposed that we could find |
| GDPR breach to authority | 72 hours, directly | 96 hours, high-risk breaches only, later via national entry point |
| NIS2 and CRA for one incident | Separate reports | CRA notification may count for part of NIS2 |
What we would do
For a team that ships mobile apps, the Omnibus is a reason to prepare, not to wait. Our reading is that nothing here lets you relax your 24-hour readiness, and that the useful work is the same whichever text wins.
- Write down who can decide that a vulnerability is actively exploited, and who files with ENISA. Our vulnerability reporting guide covers the steps.
- If your app processes personal data, add a line to your incident runbook for the separate GDPR notification, with its own clock and owner.
- Check whether you are also an essential or important entity under NIS2 in any Member State. If so, keep both timelines side by side.
- Keep one incident log with the time you became aware, the decision and the reasoning. It serves every regime.
- Do not redesign processes around the Omnibus yet: the final text may differ and national entry points would not apply for years.
Work out your 24-hour, 72-hour and final-report dates from the moment you become aware of an issue.
Open the reporting deadlines toolSources
- Regulation (EU) 2024/2847, Article 14 (text as published in the Official Journal), via Springlex, and Article 16.
- ENISA: The CRA Single Reporting Platform is launched (11 September 2026).
- IAPP: EU member states finalize Digital Omnibus negotiating stance (22 October 2026).
- Addleshaw Goddard: EU Digital Omnibus, the Council adopts its position.
- regreportingdesk: Digital Omnibus incident reporting, the Council mandate (reading of the mandate text).
- kontorbund: The EU Digital Omnibus, the single entry point and where the Council stands.
- Lewis Silkin: Digital rulebook, simplification of EU data protection and cyber rules (9 November 2026).
- Pillsbury: Europe's new data breach reporting rules, the Cyber Resilience Act (13 November 2026).
This article summarises proposals that are not yet law, as reported by secondary sources, and EU law for practical use. It is not legal advice. Related: CRA vulnerability reporting for app teams · Does the CRA apply to mobile apps?