The CRA vulnerability final-report deadline does not run from initial awareness or from the 72-hour notification. Its specific trigger is the availability of a corrective or mitigating measure. Manufacturers therefore need to record when that measure became available and connect the remediation record to the final SRP submission.
The Vulnerability Final Report Has Its Own Deadline
The final-report stage for an actively exploited vulnerability follows a different clock from the first two Article 14 stages. The 24-hour early warning and 72-hour vulnerability notification are measured from manufacturer awareness. Article 14(2)(c), by contrast, requires the final report no later than 14 days after a corrective or mitigating measure becomes available. That distinction should be represented directly in the manufacturer's reporting tracker. Reusing the awareness timestamp for every Article 14 deadline can produce an incorrect final-report date. The reporting owner should record the date and time on which the relevant corrective or mitigating measure became available and calculate the final-report deadline from that event.
- 24-hour stage: calculated from manufacturer awareness.
- 72-hour stage: calculated from manufacturer awareness.
- Final vulnerability report: calculated from availability of a corrective or mitigating measure.
- Record the measure-availability timestamp in the regulatory case.
The Final Report Describes the Vulnerability
Article 14 requires the final report to include at least a description of the vulnerability, including its severity and impact. By the final-report stage, the manufacturer should normally have a more developed understanding than was available during the 72-hour notification. The description should identify the security weakness in a way that is consistent with the affected product and version record and should explain the consequences relevant to the product. Severity and impact should be supported by the technical assessment rather than presented as unexplained labels. Where identifiers such as a CVE or EUVD identifier exist and are appropriate for the SRP fields, they can help maintain consistency across vulnerability handling, customer communication and regulatory reporting.
- Describe the vulnerability clearly.
- State its severity.
- Explain its impact.
- Keep product and version information consistent with earlier reporting stages.
- Use relevant vulnerability identifiers where available and appropriate.
Malicious-Actor Information Is Required Where Available
Article 14(2)(c) requires information concerning any malicious actor that has exploited or is exploiting the vulnerability where that information is available. The qualification where available is important. The manufacturer should provide reliable information obtained through its investigation or trusted sources, but the Regulation does not require a company to invent an attribution conclusion where the actor remains unknown. Product-security and incident-response teams should distinguish observed attack infrastructure, techniques or campaign information from a stronger conclusion about actor identity. If attribution remains unresolved, the final report should accurately reflect the available evidence rather than overstate certainty.
- Provide malicious-actor information where it is available.
- Do not turn incomplete attribution into unsupported certainty.
- Preserve the evidence supporting any actor information.
- Keep technical indicators and attribution conclusions distinct.
The Report Must Explain the Security Update or Corrective Measures
The final report must provide details about the security update or other corrective measures made available to remedy the vulnerability. This connects Article 14 reporting directly to the manufacturer's remediation process. The regulatory case should therefore identify which product versions are affected, which update or corrective measure addresses the vulnerability, when that measure became available and how users can obtain or apply it. Where a temporary mitigating measure preceded the permanent update, the record should clearly distinguish the two. This information also provides the basis for determining when the 14-day final-report period began.
- Identify the security update or corrective measure.
- Identify the affected and corrected product versions.
- Record when the measure became available.
- Distinguish temporary mitigation from permanent correction.
- Keep remediation evidence connected to the SRP case.
The 72-Hour Notification and Final Report Serve Different Purposes
The 72-hour vulnerability notification is designed to provide general information as available while the investigation and remediation work can still be developing. The final report is the later, more developed regulatory record. It includes the vulnerability's severity and impact, malicious-actor information where available and the corrective measures made available to remedy it. Manufacturers should therefore carry information forward from earlier stages while updating it as the evidence matures. The final report should not simply reproduce the initial notification if material facts, impact analysis or corrective measures have changed.
- Carry forward accurate information from earlier stages.
- Update the vulnerability assessment as evidence develops.
- Add final corrective-measure details.
- Resolve or clearly identify material uncertainties.
- Keep the reporting timeline auditable.
An Intermediate Report Can Be Requested
Article 14(6) allows the CSIRT designated as coordinator that initially receives the notification to request an intermediate report on relevant status updates where necessary. The existence of a later final-report deadline therefore does not mean the manufacturer can remain silent throughout the intervening period. The reporting owner should keep investigation, mitigation and remediation status current and maintain contact with the technical team. If an intermediate report is requested, the organisation should be able to provide a coherent status update without rebuilding the entire incident or vulnerability timeline from separate systems.
- Keep the Article 14 regulatory case open.
- Maintain current investigation status.
- Maintain current mitigation and remediation status.
- Prepare for a CSIRT request for an intermediate report.
Build the Final Report From the Remediation Record
The most reliable workflow is to build the final-report evidence alongside vulnerability remediation rather than at the end of the 14-day period. A case record can contain the vulnerability description, affected products and versions, severity, impact, exploitation evidence, malicious-actor information, mitigation history, security-update details, measure-availability timestamp and links to the earlier Article 14 submissions. The product-security team can maintain technical evidence while the regulatory owner tracks reporting completeness and deadlines. This reduces the chance that remediation is completed operationally but the regulatory report lacks the information necessary to explain what was fixed and when.
- Connect the vulnerability ticket to the Article 14 case.
- Record the corrective-measure availability timestamp.
- Maintain severity and impact evidence.
- Maintain malicious-actor information where available.
- Maintain security-update and corrected-version details.
- Track final submission through the SRP.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.