The 11 September deadline is real, and it is not NIS2

A deadline next week, and it belongs to another instrument

On 11 September 2026 a new European reporting obligation starts to apply. It is easy to file it mentally under NIS2, because it has the shape of article 23: a 24-hour early warning, a 72-hour notification, a final report, addressed to a national CSIRT. It is not NIS2. It is the Cyber Resilience Act, and it is the first part of that regulation to bite.

Everything else in the regulation — the essential cybersecurity requirements for products, the conformity assessment, the CE marking — waits until December 2027. The reporting duty does not wait. It arrives fifteen months ahead of the rest, on its own.

Who owes it

Manufacturers of products with digital elements. ENISA, which operates the platform the reports go through, adds open-source software stewards to the extent that they are involved with products with digital elements. If your organisation is in NIS2 scope as an operator of services and ships no product, this is not yours. If it also builds and places software or connected hardware on the EU market, it is — and the two duties sit in different parts of most organisations, which is the practical problem.

What triggers it, and why it is not the article 23 test

Two occurrences are reportable. Actively exploited vulnerabilities, which ENISA defines as vulnerabilities in products with digital elements for which there is reliable evidence that they have been exploited by a malicious actor. And severe incidents having an impact on the security of the product with digital elements.

Note what is absent: the article 23(3) significance test, with its severe operational disruption and its considerable damage to third parties. A vulnerability in your product that is under active exploitation is reportable on that fact alone. Your own services may be running perfectly. The subject of the CRA duty is the product, not the operator.

The clock looks familiar and ends somewhere else

• Early warning: without undue delay and in any case within 24 hours.
• Notification: without undue delay and in any case within 72 hours.
• Final report: within 14 days for an actively exploited vulnerability, or one month for a severe incident.

The first two steps match the rhythm a NIS2 team already runs. The third does not. NIS2 gives you a month for the final report; the CRA gives you fourteen days when the trigger was an exploited vulnerability. A team that has drilled the article 23 sequence and assumes the same tail will be two weeks late on the filing that matters most, because the final report is where the remediation is described.

Where it goes, and who receives it

Reports are filed through the Single Reporting Platform that ENISA is standing up for this date. A notification goes simultaneously to ENISA and to the CSIRT designated as the coordinator, and that coordinator then disseminates it to the other member states concerned. Which CSIRT coordinates is not a choice of convenience: ENISA states it is determined primarily by the main location of establishment, under article 14(7) of the regulation.

That is the point at which this becomes a NIS2 question after all. The coordinating CSIRT is one of the national teams listed on this site — the same body an entity in that member state deals with under its transposition law. Knowing which one it is, and having someone able to reach it, is work that has already been done in the NIS2 half of most organisations and rarely shared with the product half.

One event, two filings

The case to plan for is the overlap. An actively exploited vulnerability in a product you manufacture, which also degrades a service that puts you in NIS2 scope, owes both: a CRA article 14 report to ENISA and the coordinating CSIRT, and a NIS2 article 23 early warning to your own CSIRT or competent authority. Different recipients, different forms, different final-report deadlines, and no mechanism by which one discharges the other.

They run in parallel, like the GDPR and sector clocks already do. Mapping them once, per legal entity, against the product portfolio rather than only against the service portfolio, is the version of that exercise most organisations have not yet done.

Where this is sourced from

The dates, the triggers, the deadlines and the routing above are taken from the European Commission's own Cyber Resilience Act page and from ENISA's Single Reporting Platform pages, both read on 4 September 2026. We did not read article 14 in the Official Journal itself: EUR-Lex answered an automated challenge rather than the text on every route we tried, and a challenge page proves nothing either way. Before you build a process on this, read article 14 of Regulation (EU) 2024/2847 in the Official Journal. The operative wording is the regulation's, not ours, and not the Commission's summary of it.