On this page
- The 24-hour and 72-hour limits both run from awareness, without undue delay.
- Actively exploited vulnerabilities and severe incidents have different final-report triggers.
- A recorded draft or internal milestone is not proof of external submission.
- Track elapsed time, retain the original timestamps and test the deputy handoff.
Which Article 14 events need deadline tracking?
Article 14 addresses actively exploited vulnerabilities contained in the product and severe incidents affecting its security. An ordinary dependency advisory is not automatically either trigger. Record what is known about the product, the vulnerability or incident and why the reporting criteria are met or still being assessed. Escalate uncertainty promptly; an internal review meeting does not postpone an obligation that has already arisen.
Article 14 of Regulation (EU) 2024/2847 is the binding source for the clocks. The Commission's reporting page explains the process, which applies from 11 September 2026. This guide focuses on maintaining the case; the reporting overview provides the broader context.
Keep the reporting clocks separate
The initial deadlines are maximum limits, alongside the obligation to act without undue delay. The 72-hour notification is measured from awareness, not from the early warning. The final-report clock depends on the event type. Later-stage information need not be duplicated where it has already been provided as the relevant provisions allow.
| Reporting stage | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | Without undue delay, within 24 hours of awareness | Without undue delay, within 24 hours of awareness |
| Notification | Without undue delay, within 72 hours of awareness | Without undue delay, within 72 hours of awareness |
| Final report | No later than 14 days after a corrective or mitigating measure is available | Within one month after submission of the incident notification |
Preserve awareness separately from data entry
Keep the original signal, when it reached the organisation, when the manufacturer became aware of the reportable situation, who assessed it and the supporting rationale. These timestamps may differ. Neither a scanner's collection time nor a case-creation time automatically establishes legal awareness.
A practical record uses an unambiguous timestamp with an offset and a normalised UTC value for calculations. Display local time for the people acting on it. Treat the hour-based limits as elapsed hours; do not pause the internal clock over weekends or holidays. Arrange earlier internal escalation targets so staff availability does not determine whether the deadline is met.
If the awareness record was entered incorrectly, retain the original value, the corrected value, the reason and who made the correction. Recalculate the operational deadlines transparently. Do not edit history simply to make an overdue action appear timely.
Work through a weekend example
This fictional example assumes the manufacturer becomes aware of a reportable situation at 16:00 UTC on Friday 18 September 2026. The early-warning limit is 16:00 UTC on Saturday 19 September. The notification limit is 16:00 UTC on Monday 21 September. Opening the internal case at 09:00 UTC on Saturday does not shift either limit.
If the event is an actively exploited vulnerability and a corrective or mitigating measure becomes available at 10:00 UTC on 22 September, the 14-day final-report limit falls at 10:00 UTC on 6 October. Retain evidence of when the measure became available, not just when a developer marked a fix complete.
If it is instead a severe incident and the incident notification is submitted at 12:00 UTC on 20 September, the final report is due within one month of that submission. Track the corresponding 20 October date, rather than substituting 30 days or calculating from awareness. For month-end and other legal time-calculation edge cases, confirm the applicable calculation and set an earlier internal target.
Build a case that another person can take over
Keep the product and affected-version references, case type, awareness basis, owner and deputy, reporting decision, current stage and next action together. Link the relevant SBOM, assessment or investigation evidence without copying unnecessary secrets or personal data into the case summary. The following fields are an operational design suggestion, not a replacement for the official submission form.
- Identity: manufacturer, product, affected versions and internal case reference.
- Basis: signal, awareness timestamp, reporting rationale and reviewer.
- Clocks: initial limits, final-report basis, internal reminders and escalation owner.
- Actions: drafts, approved content, submission timestamps and receipts.
- Follow-up: corrective measures, user communication, authority requests and remaining uncertainty.
Separate preparation from delivery through the SRP
ENISA's SRP guidance provides the current platform instructions. Its FAQ says that the initial release does not provide a submission API. Internal automation therefore must not be marketed as an authority integration without evidence of the supported channel and its availability.
Assign an authorised submitter and verify their access before an incident. After submission, retain the acknowledgement or reference and the material sent. Mark prepared, approved for submission, submitted and acknowledged distinctly in your operating record. If delivery fails, preserve the failure and escalate through the current official guidance; an internal success badge cannot establish receipt.
Keep follow-up visible after the first notification
The early warning does not close the case. Track the next stage, final-report basis, any requested intermediate updates and relevant user communication. If a corrective measure is not yet available, record that fact and continue active follow-up rather than inventing a measure date to populate the timer.
Keep CRA reporting alongside any other potentially applicable notification duties, with separate legal analyses, recipients and records. Similar 24-hour or 72-hour language in another regime does not make the events, forms or completion evidence interchangeable. Avoid marking every regulatory task complete because one notification was sent.
Where ConformOps fits
ConformOps Continuous provides release-linked reporting cases, awareness-based initial clocks, event records, final-deadline bases and a named runbook. A severe-incident notification event establishes its month-based final deadline; availability of a corrective or mitigating measure establishes the vulnerability final deadline. Drills remain marked separately from live cases.
ConformOps does not submit to ENISA or a CSIRT. It supports the internal record and handoff; the authorised submitter performs the external action. Run a drill with a weekend deadline, late case entry and an unavailable primary owner before relying on the workflow. The in-house guide explains how to set up those responsibilities.
Frequently asked questions
Does the CRA 72-hour clock start after the early warning?
No. Both the 24-hour early-warning limit and the 72-hour notification limit run from the manufacturer's awareness of the relevant reportable situation, alongside the requirement to act without undue delay.
Are the 24-hour and 72-hour limits business hours?
Plan and track them as elapsed hours, including weekends, with deputies and earlier internal escalation targets. Do not build a business-hours pause into the operational tracker.
When is the Article 14 final report due?
For an actively exploited vulnerability, no later than 14 days after a corrective or mitigating measure is available. For a severe incident, within one month after submission of the incident notification. These are different starting events.
Does opening a case count as reporting?
No. It records internal work. Keep the actual external submission and its receipt or acknowledgement separately identifiable.
Can an old product still create a reporting obligation?
Yes. ENISA's reporting FAQ explains that the Article 14 obligations apply from 11 September 2026 to in-scope products, including products placed on the market before 11 December 2027. Review the awareness and transition facts for the actual case.