CRA Article 14 Workflows
Article 14 of the Cyber Resilience Act (CRA) imposes stringent reporting obligations on manufacturers concerning actively exploited vulnerabilities and severe security incidents. Compliance requires rapid identification, assessment, and notification to relevant national authorities and ENISA. The CVD Portal provides dedicated workflows specifically designed to automate and manage the demanding requirements of Article 14.
The portal includes automated triggers that escalate vulnerabilities identified as 'actively exploited' directly into the Article 14 workflow. This initiates aggressive, specialized SLA timers, ensuring that the mandatory 24-hour "early warning" and 72-hour comprehensive notifications are prepared and dispatched on time. The workflow includes pre-formatted templates aligned with ENISA reporting standards, guiding your compliance officers through the necessary data collection and submission processes.
Failure to comply with Article 14 reporting timelines can result in significant regulatory penalties. The portal's robust tracking and automated escalation mechanisms significantly reduce this risk, providing a structured, auditable path for handling the most critical security incidents and ensuring full transparency with European cybersecurity authorities.
When the clock starts
Every Article 14 deadline runs from the moment the manufacturer becomes aware. Commission guidance C(2026) 5252 defines that moment. On detecting a suspicious event, or receiving a report from a researcher, customer, authority or media organisation, assess it immediately. Awareness arises when that initial assessment gives a reasonable degree of certainty that a vulnerability in the product is being actively exploited, or that a severe incident has compromised the product's security.
Receiving a report does not by itself start the clock. A short, documented triage window sits in front of it. That window is not open-ended, and the guidance stresses prompt action where the vulnerability may pose a significant risk.
The Commission aligned this test with recital 31 of Implementing Regulation (EU) 2024/2690 under NIS2 and with the EDPB guidelines on personal data breach notification, so one awareness determination can anchor several reporting regimes. Record the timestamp and the reasoning when you set the "became aware" field, because that field drives every downstream deadline in the portal.
Spotting exploitation early
Because the 24-hour deadline runs from awareness, early detection is a compliance matter and not only an operational one. The portal watches every vulnerability your advisories and SBOM reference against five exploitation catalogues and surfaces the evidence beside the "Actively exploited in the wild" flag, including whether the report is ahead of the CISA KEV catalogue.
The portal never sets that flag automatically. Only you can determine whether your own product is affected, and a third-party feed must not start a statutory clock on your behalf. See Exploitation Signals.
Deadlines and scope
The early warning is due without undue delay and within 24 hours of becoming aware. A fuller notification follows within 72 hours. The complete report is due within 14 days after a corrective or mitigating measure becomes available for an actively exploited vulnerability, or within one month after the 72-hour notification for a severe incident.
Three scope points follow from the guidance. The obligations apply from 11 September 2026 to every product in scope, including products placed on the market before 11 December 2027. They continue after a product's support period ends, unlike the vulnerability-handling requirements in Annex I Part II. And exploitation a manufacturer already knew about before 11 September 2026 is not reportable, because the obligation attaches to becoming aware rather than to the vulnerability existing.
A vulnerability in an integrated third-party component is reportable only where it is actively exploited in your product. Where the vulnerable code is unreachable, the mandatory report falls away, while voluntary notification under Article 15 and upstream reporting under Article 13(6) both remain.
Informing users
Article 14(8) requires impacted users to be informed, and where appropriate all users. The guidance reads this in a risk-based way. Informing users does not mean publishing indiscriminately, and detail may be confined to the customers concerned, particularly for products used in sensitive or essential environments where publication could increase risk. Broader disclosure becomes appropriate once the issue is addressed, and Annex I Part II separately requires public disclosure of fixed vulnerabilities once a security update is available.