Which triggers and deadlines does Art. 14 set?
Art. 14 CRA knows two triggers with three notifications each: the actively exploited vulnerability (paragraphs 1 and 2) and the severe incident having an impact on the security of the product (paragraphs 3 and 4). The addressees are simultaneously the CSIRT designated as coordinator and ENISA, via the single reporting platform under Art. 16. The clock starts with awareness – per ENISA: with a reasonable degree of certainty – and runs on weekends too.
| Notification | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | without undue delay, at the latest 24 hours after awareness (para. 2(a)) | without undue delay, at the latest 24 hours after awareness (para. 4(a)) |
| Notification | at the latest 72 hours after awareness (para. 2(b)) – not after the early warning | at the latest 72 hours after awareness (para. 4(b)) |
| Final report | at the latest 14 days after a corrective or mitigating measure is available (para. 2(c)) | at the latest one month after the 72-hour notification (para. 4(c)) |
The often-quoted formula “24/72 hours and 14 days” therefore applies only to vulnerabilities; for incidents the final deadline is one month. What is fixed before exploitation is not reportable: a CVE entry or a public proof of concept alone is not active exploitation. Art. 14(8) additionally requires informing affected users; Art. 13(6) requires reporting identified vulnerabilities back to the component's maintainer.
Art. 69(2) exempts products placed on the market before 11 December 2027 from the substantive requirements – as long as they are not substantially modified. Paragraph 3 expressly does not exempt them from the reporting obligation: the obligations laid down in Art. 14 apply to all products with digital elements within scope that were placed on the market before 11 December 2027. An institution whose app has been in the store for years and which owes no conformity assessment before December 2027 has been obliged since 11 September 2026 to issue an early warning within 24 hours.
Reporting clock: When do the CRA and DORA deadlines expire?
Enter the time at which your institution had a reasonable degree of certainty about the active exploitation or the incident. The clock calculates the CRA deadlines and – if the matter is at the same time a major ICT-related incident under DORA – the DORA deadlines from Delegated Regulation (EU) 2025/301. All inputs stay in the browser; nothing is stored or transmitted.
What can the ENISA platform do in its initial build?
The Single Reporting Platform went live on 11 September 2026 – the same day the obligation became applicable; the access guide and manual appeared the day before. ENISA expressly speaks of an “initial operating capability”. Four limitations matter for reporting readiness:
- No API: submission is only possible via the web interface. Every toolchain ends with a person filling in a form in a browser – with 24 hours, an availability question for people, not systems.
- English only.
- No voluntary reports under Art. 15 in the initial build.
- No status page: whether the platform is currently reachable cannot be evidenced.
Access: EU Login with multi-factor authentication; a primary representative can invite further representatives. No prior registration is required; according to the German BSI, registration and reporting are possible within minutes. Which CSIRT is competent is determined by Art. 14(7) by the main establishment – but the platform does not implement this itself: the manufacturer must select the coordinating CSIRT; a wrong selection can render the report ineffective.
Whom does an institution in Austria report to?
For Austria, CERT.at is designated as coordinating CSIRT (ENISA list of 4 September 2026); reports via the platform reach CERT.at and ENISA simultaneously. We did not find an Austrian legal act formally pronouncing the designation – it is evidenced by the ENISA list and CERT.at's own statement.
If the platform is unavailable, the ENISA FAQ (version of 17 September 2026, question 25) says to wait for restoration and submit afterwards; if the manufacturer considers immediate notification necessary, it may contact its CSIRT directly and submit the platform report later. Germany has specified the fallback route (e-mail to CERT-Bund), as has Ireland. For Austria no fallback procedure was published at the time of our check. The 24-hour deadline runs regardless of whether the prescribed channel is reachable: the direct contact route to CERT.at must be known, documented and rehearsed alongside the platform.
Does a CRA report increase liability?
No. Art. 17(4) clarifies that a report as such does not establish increased liability. Art. 64(10) exempts micro and small enterprises from fines if they miss the early-warning deadline – the duty itself remains, and for banks and insurers the exemption does not apply anyway. Breaches of Art. 14 fall into the top fine bracket: up to EUR 15 million or 2.5 percent of worldwide annual turnover.
How do CRA and DORA reports relate to each other?
Art. 14 CRA obliges the manufacturer at product level; DORA obliges the financial entity at operator level. One incident can trigger both duties, and neither offsets the other – Union law provides no mechanism for it. The same applies to NIS 2 (Art. 23 NIS 2); recital 72 CRA merely suggests national single entry points to the Member States.
| CRA (Art. 14) | DORA (Delegated Regulation (EU) 2025/301) | |
|---|---|---|
| Obliged party | manufacturer of the product | financial entity as operator |
| Trigger | actively exploited vulnerability; severe incident affecting the product | major ICT-related incident after classification |
| First notification | early warning within 24 hours of awareness | as soon as possible, no later than 4 hours after classification and 24 hours after detection; if classified more than 24 hours after detection: 4 hours after classification |
| Second notification | within 72 hours of awareness | intermediate report within 72 hours of submitting the initial notification |
| Final | 14 days after the fix (vulnerability) / one month after the 72-hour notification (incident) | within one month of submitting the last intermediate report |
| Addressee | coordinating CSIRT (Austria: CERT.at) and ENISA via the SRP | FMA |
How does an institution become ready to report?
Six steps: inventory products, name decision-makers, set up MFA accounts, adapt supplier contracts, keep a runbook and rehearse.
- Inventory the products for which the institution is the manufacturer – including old versions in the store.
- Name one person who owns the “reasonable degree of certainty” decision; staff triage continuously, not in batches.
- Create EU Login accounts with MFA for primary and secondary representatives; record CERT.at as coordinator in advance.
- Align the development partner's information duties contractually with the 24-hour clock (who detects, who informs, who reports).
- One runbook for CRA, DORA and GDPR with separate clocks and addressees; document the fallback route to CERT.at.
- Rehearse with fictitious material; no test reports in live operation.
Frequently asked questions
Does the 72-hour deadline only start after the early warning?
No. Both deadlines run from the moment the manufacturer becomes aware (Art. 14(2)(b), (4)(b) CRA). The early warning does not shift the 72-hour notification.
Must every vulnerability be reported?
No. Only actively exploited vulnerabilities and severe incidents are reportable. What is fixed before exploitation falls under normal vulnerability handling under Annex I Part II.
Does the CRA report replace the DORA notification to the FMA?
No. Both duties exist side by side, with their own triggers, deadlines and addressees. Union law provides no offsetting.
What applies if the ENISA platform is unavailable?
According to the ENISA FAQ, wait for restoration and submit afterwards; in urgent cases the CSIRT can be contacted directly. The deadline is not suspended. For Austria no separate fallback procedure has been published.
Ing. Mag. Patrick Eiler
Patrick Eiler advises banks and insurers in Vienna on regulatory reporting, data architecture and AI compliance. More than twenty years in banking, insurance and financial services; speaker at the Hypo-Verband (expert session of 23 September 2026).