What Article 14(6) actually says
Where necessary, the CSIRT designated as coordinator initially receiving the notification may request manufacturers to provide an intermediate report on relevant status updates about the actively exploited vulnerability or severe incident having an impact on the security of the product with digital elements.
That is the whole limb. It authorises a CSIRT request; it does not add a fourth mandatory stage to the manufacturer calendar. Official submission still goes through ENISA's Single Reporting Platform to the coordinating CSIRT — see which CSIRT.
The mandatory CRA chain stays three stages (+ users)
For an actively exploited vulnerability: early warning within 24 hours of becoming aware (Article 14(2)(a)), vulnerability notification within 72 hours (Article 14(2)(b)), final report no later than 14 days after a corrective or mitigating measure is available (Article 14(2)(c)). For a severe incident: the parallel Article 14(4) cascade, with the final due within one month after the 72-hour incident notification. Detail: reporting deadlines, when the measure starts the 14-day final, and the final report page. Article 14(8) user notice is separate again — not an “intermediate.”
Article 14 has applied from 11 September 2026 (Article 71(2)), including for in-scope products already on the market (Article 69(3)). The intermediate limb applied with that package; it did not wait for a later “status-update” go-live.
Why DORA and NIS2 vocabulary misleads
DORA builds intermediate reporting into the major ICT-incident cascade: initial, then intermediate within 72 hours of the initial (Delegated Regulation (EU) 2025/301 Article 5), then final. Teams copy that shape onto CRA and invent a CRA intermediate due date the Regulation does not set. See Article 14 vs DORA.
NIS2 Article 23(4)(c) does use “intermediate report on request” — closer to CRA’s wording than DORA is. That still does not make a NIS2 intermediate the CRA Article 14(6) reply, or cancel either duty when both apply. See Article 14 vs NIS2. Neighbouring confusion with GDPR Art 33/34 is different again: GDPR has no “intermediate report” stage in that sense.
What to keep ready (even before a request)
Because the request can arrive between the 72-hour filing and the final — or while the final clock is already running — treat status as a living case file, not a document you rebuild from scratch. Record the request, what you sent, when, and any SRP reference in the evidence log. Reconcile facts against the report template and SRP fields checklist so the intermediate does not contradict the early warning, 72-hour notification, or upcoming final.
“Relevant status updates” is fact-specific: progress on investigation, changes in exploitation or impact, new corrective or mitigating measures available to users, revised sensitivity of the notified information. Do not treat silence from the CSIRT as permission to skip the final when its own trigger is met — and do not invent an intermediate filing just because DORA would have required one by now.
The trap: “we owe an intermediate at T+72h from the 72-hour filing”
Two failure modes show up in triage. First: the team calendars a CRA intermediate on the DORA Delegated Reg schedule and either burns effort on an unsolicited SRP update or, worse, treats that invented step as the real close-out and under-prepares the final. Second: a dual-scope manufacturer answers a NIS2 intermediate and assumes the CRA CSIRT is covered. Article 14(6) is request-driven and product/SRP-facing; until the coordinating CSIRT asks, your mandatory CRA work is still the 24-hour, 72-hour, final, and user-notice limbs.
Questions people ask
- Is there a mandatory CRA intermediate report between the 72-hour notification and the final?
- No. Article 14’s mandatory manufacturer filings are the early warning, the 72-hour notification, and the final report (plus user notice under Article 14(8) where it applies). Article 14(6) only says that, where necessary, the CSIRT designated as coordinator that initially received the notification may request an intermediate report on relevant status updates. Until that request arrives, there is no Article 14 intermediate deadline to miss.
- Who can ask for the Article 14(6) intermediate report?
- The CSIRT designated as coordinator that initially received the notification — the same coordinating CSIRT your early warning and 72-hour filings went to via the Single Reporting Platform. The text does not invent a separate “intermediate” portal or a second CSIRT pick just for status updates.
- Does Article 14(6) apply to both actively exploited vulnerabilities and severe incidents?
- Yes. The intermediate report covers relevant status updates about the actively exploited vulnerability or the severe incident having an impact on the security of the product with digital elements — the same two tracks Article 14(1) and (3) open.
- Is this the same as the DORA intermediate report?
- No. DORA Article 19 plus Delegated Regulation (EU) 2025/301 Article 5 put a scheduled intermediate report on the financial-entity calendar (within 72 hours of the initial notification, with updates as needed). CRA Article 14(6) is request-driven and product/CSIRT-facing. Matching the word “intermediate” does not merge the calendars or let a DORA intermediate close an SRP case.
- Is this the same as the NIS2 intermediate report?
- Same shape of wording, different duty. NIS2 Article 23(4)(c) also lets the CSIRT or competent authority request an intermediate report. That does not create a standing CRA intermediate clock, and a NIS2 status update does not substitute for an Article 14(6) reply (or the reverse). Parallel entity and product cases still need their own recipients.
- Does answering an intermediate request change when the final report is due?
- No. Article 14(6) does not rewrite the final-report triggers. For an AEV, Article 14(2)(c) still runs from when a corrective or mitigating measure is available (14 days). For a severe incident, Article 14(4)(c) still closes within one month after the 72-hour incident notification. Keep the intermediate reply consistent with what you already filed and with what you will put in the final.