Does emailing my national CSIRT satisfy Article 14?

Why an email to your CSIRT does not count

However fast you are, a message to your contact at the national team doesn’t start or stop either clock. Article 14 of Regulation (EU) 2024/2847 (the Cyber Resilience Act) does not let a manufacturer choose an arbitrary channel. Article 14(1) says the manufacturer “shall notify” an actively exploited vulnerability “via the single reporting platform established pursuant to Article 16,” and Article 14(3) says the same for a severe incident. Article 14(7) is explicit on mechanics: the notifications “shall be submitted via the single reporting platform referred to in Article 16 using one of the electronic notification end-points referred to in Article 16(1),” specifically the end-point of the CSIRT designated as coordinator (CDaC), by default for the Member State of the manufacturer’s main establishment, and it “shall be simultaneously accessible to ENISA.” Article 16(1) confirms ENISA establishes and manages that single reporting platform (SRP). ENISA’s own SRP FAQ describes the tool the same way: “The CRA Single Reporting Platform (SRP) is an online tool for manufacturers and open-source software stewards to meet their obligation to report actively exploited vulnerabilities.”

An email, phone call, or ticket sent straight to a national CSIRT is not one of the electronic notification end-points the statute names, and it does not make the notification “simultaneously accessible to ENISA” the way Article 14(7) requires. So even a prompt, well-documented email is not the notification Article 14 asks for; it is only submission through the SRP end-point of your CDaC that satisfies the obligation.

The one narrow exception ENISA itself describes

ENISA’s SRP FAQ addresses exactly the scenario of contacting a CSIRT directly, but only as a fallback for SRP downtime, not as an alternative channel: if the SRP is temporarily unavailable, manufacturers should wait until it comes back, and “if manufacturers consider immediate communication necessary before restoration, they may contact their designated CSIRT directly,” but “the notification must still be submitted through the SRP once it is available again.” In other words, even in that emergency scenario, direct CSIRT contact does not itself satisfy Article 14; the formal submission still has to happen through the platform.

What the 24-hour and 72-hour clocks actually run from

It is worth being precise about what the SRP does and does not control, because the channel requirement and the timing requirement are two different things. Article 14(2)(a) sets the early-warning deadline as “within 24 hours of the manufacturer becoming aware” of the actively exploited vulnerability, and Article 14(2)(b) sets the follow-up notification deadline as “within 72 hours of the manufacturer becoming aware.” Article 14(4) sets the identical 24-hour and 72-hour deadlines for severe incidents, again measured from the manufacturer becoming aware, not from any platform event. So the clocks start when the manufacturer becomes aware, and the SRP is the required channel through which that time-boxed obligation must be discharged, not the trigger that starts or stops the clock. ENISA’s SRP FAQ makes the same point about its own internal tracking: the platform’s timing counters “do not replace the responsibility of manufacturers… to comply with the obligations laid down in the CRA, including the requirement to report upon becoming aware, without undue delay and in any event within the timelines set out in Art. 14.”

The practical upshot is the same either way: an email to a CSIRT does not stop any clock and does not satisfy the obligation, because the obligation is to submit via the SRP end-point within the awareness-based deadline, and an email is neither the required channel nor evidence recognized by the statute as fulfilling it.

Unsettled: No source says what happens if the SRP submission is skipped entirely rather than just sent late, or whether an email could count as informal evidence of when you became aware even though it doesn’t satisfy the notification itself.

What a CSIRT relationship is still good for

The Act gives CSIRTs and direct manufacturer-CSIRT contact real roles that sit outside, and alongside, the Article 14 notification duty. Article 13(8) requires manufacturers to have coordinated vulnerability disclosure policies for vulnerabilities reported from internal or external sources, a different function from Article 14’s manufacturer-to-authority notification. Article 15 lets manufacturers voluntarily notify vulnerabilities, cyber threats, incidents, or near-misses “on a voluntary basis to a CSIRT designated as coordinator or ENISA,” but even these voluntary notifications are processed “in accordance with the procedure laid down in Article 16,” through the same platform infrastructure, not by ad hoc email. And Article 14(6) lets the CDaC that received a notification ask for intermediate status updates once a case is open, on top of whatever informal coordination already happens.

None of these substitute for the formal, timestamped notification. Submission through the SRP end-point of the CDaC, simultaneously accessible to ENISA, is what the statute treats as the notification event for Article 14 purposes, even though the deadlines themselves are pinned to the moment the manufacturer became aware, not to that submission. An email to a CSIRT, however well-intentioned or promptly sent, is neither.