Vulnerability Disclosure and Regulatory Reporting - Post Deployment
Vulnerability Disclosure and Regulatory Reporting - Phase 3: Post Deployment
Objective: Establish processes for coordinated vulnerability disclosure, communicate security information to affected users, and satisfy applicable CRA regulatory reporting obligations.
The CRA requires manufacturers to maintain coordinated vulnerability disclosure processes and provide mechanisms through which security researchers, customers, and other parties can report potential product vulnerabilities.
Manufacturers must also disclose appropriate information about fixed vulnerabilities once a security update becomes available, subject to the regulation’s provisions concerning disclosure timing and security risks. Such information includes affected products, vulnerability impact and severity, and actions users can take to remediate the issue.
In addition, Article 14 establishes mandatory regulatory reporting obligations for qualifying actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.
These reporting requirements have applied to manufacturers since September 11, 2026. They require early warning notifications within 24 hours of awareness, followed by more detailed notifications within 72 hours. Final reporting deadlines vary depending on whether the report concerns an actively exploited vulnerability or a severe security incident.
For DevOps and security operations teams, disclosure and reporting processes should integrate vulnerability intelligence, incident investigation, affected-product identification, remediation tracking, and communication workflows.
Organizations should establish procedures for determining whether a vulnerability meets the CRA’s regulatory reporting criteria, collecting required information, and submitting notifications through the designated reporting mechanisms.
Not every newly disclosed CVE triggers regulatory reporting. Article 14 applies to the specific categories of reportable vulnerabilities and incidents defined by the regulation.
CRA Requirements and Open-Source Tooling
| CRA Reference | Security Activity | CI/CD Implementation | Suggested Open-Source Tools |
|---|---|---|---|
| Annex I, Part II(5) | Coordinated vulnerability disclosure | Maintain and enforce a documented coordinated vulnerability disclosure policy. | GitHub Security Advisories, DefectDojo |
| Annex I, Part II(6) | Vulnerability reporting channels | Provide mechanisms and security contacts for reporting vulnerabilities in products and third-party components. | GitHub Private Vulnerability Reporting, security.txt |
| Annex I, Part II(4) | Public disclosure of fixed vulnerabilities | Publish appropriate information about fixed vulnerabilities, affected products, severity, impacts, and remediation actions, subject to CRA disclosure provisions. | GitHub Security Advisories, OSV, CSAF |
| Article 14(1)–(2) | Actively exploited vulnerability reporting | Establish procedures for identifying and reporting qualifying actively exploited vulnerabilities. | TheHive, DefectDojo, Ortelius |
| Article 14(3)–(5) | Severe security incident reporting | Identify, investigate, and escalate qualifying severe incidents affecting product security. | Wazuh, Falco, TheHive |
| Article 14(2), (4) | Regulatory notification timelines | Establish escalation workflows to meet applicable 24-hour, 72-hour, and final reporting deadlines. | TheHive, DefectDojo |
| Articles 14 and 16 | Regulatory notification submission | Collect required incident and vulnerability details and submit mandatory notifications through the ENISA CRA Single Reporting Platform. | TheHive, DefectDojo |
| Annex I, Part II(4), (8) | User security advisories | Communicate affected-product information, available security updates, and recommended remediation actions to users. | GitHub Security Advisories, CSAF |
| Article 13(6) | Upstream vulnerability coordination | Notify relevant third-party component maintainers of identified vulnerabilities and share applicable fixes as required. | GitHub Security Advisories, OSV |
CRA Regulatory Reporting Deadlines
The following timelines apply to qualifying actively exploited vulnerabilities and severe security incidents under Article 14.
| Reporting Requirement | Deadline | Required Action |
|---|---|---|
| Early warning notification | Within 24 hours of awareness | Submit an initial notification concerning a qualifying actively exploited vulnerability or severe security incident. |
| Vulnerability or incident notification | Within 72 hours of awareness | Submit a more detailed notification with available product, vulnerability or incident, and mitigation information. |
| Final report — actively exploited vulnerability | No later than 14 days after a corrective or mitigating measure becomes available | Provide the required final vulnerability information, including severity, impact, and corrective measures. |
| Final report — severe security incident | Within one month after submission of the 72-hour incident notification | Provide the required final incident analysis and corrective or mitigating measures. |
Mandatory notifications are submitted through the ENISA CRA Single Reporting Platform.
Reporting deadlines are triggered by awareness of qualifying events, rather than the publication of every CVE.
Expected Compliance Evidence
- Published coordinated vulnerability disclosure policy.
- Documented vulnerability reporting contacts and channels.
- Vulnerability reports and investigation records.
- Published security advisories and disclosure history.
- Affected-product identification and impact assessments.
- Reportability assessments for actively exploited vulnerabilities and severe incidents.
- Regulatory notification timestamps and submission records.
- Security incident investigation and root-cause analysis records.
- Remediation decisions and corrective action records.
- User notification and security update communication records.
Phase 3 Compliance Evidence Summary
Post Deployment activities should establish a continuous and traceable process for identifying vulnerabilities, determining affected products, implementing remediation, and communicating security information throughout the product support period.
Organizations should integrate SBOM monitoring, vulnerability intelligence, release inventories, and available deployment records to maintain visibility into software security after release.
When vulnerabilities are discovered, teams should document their relevance to supported products, assess exploitability and impact, assign remediation responsibilities, and preserve records of corrective actions.
Where practical, correlating vulnerable components with deployed product versions and operational endpoints can improve remediation prioritization and reduce the time required to identify affected environments.
For qualifying actively exploited vulnerabilities and severe security incidents, organizations must also maintain procedures capable of supporting statutory CRA reporting deadlines.
The resulting evidence should demonstrate that vulnerability handling is an ongoing operational process rather than a one-time activity performed during software development or release.
References
- EU Cyber Resilience Act — Regulation (EU) 2024/2847
- European Commission — Cyber Resilience Act Summary
- European Commission — CRA Reporting Obligations
- ENISA — CRA Single Reporting Platform
- NIST Secure Software Development Framework
Implementation Note: The CRA establishes obligations for covered manufacturers and, where applicable, other economic operators and open-source software stewards. The open-source tools listed are illustrative technica