The Cyber Resilience Act's general security and conformity obligations apply from 11 December 2027, but one provision lands earlier. Article 14 of Regulation (EU) 2024/2847 — the article on reporting obligations — applies from 11 September 2026. From that date onward, every manufacturer placing a product with digital elements on the EU market must notify both the designated coordinator CSIRT in its main establishment Member State and ENISA when an actively exploited vulnerability or a severe incident affecting product security is identified. Notifications must travel through a single reporting platform that ENISA is building under Article 16. The text is short — three pages — but the operational reshuffle for product security teams is substantial.
What does Article 14 require?
Article 14(1) imposes obligations on two categories of events: an actively exploited vulnerability contained in a product with digital elements, and a severe incident having an impact on the security of a product with digital elements. For each, the manufacturer must produce three artefacts on a staggered clock. An early warning is due no later than 24 hours after becoming aware of the event. A vulnerability or incident notification with available technical details is due within 72 hours. A final report follows within 14 days of a corrective measure being available, or one month for severe incidents. The first early warning is intentionally minimal: it states that the event is being assessed, identifies the Member State of the manufacturer's main establishment, and indicates the severity of the impact if known. Article 14 explicitly allows late updates if the manufacturer is still investigating; what it does not allow is silence.
Who exactly must report?
Manufacturers in the CRA sense — natural or legal persons that develop or manufacture products with digital elements, or have them developed or manufactured and market them under their own name or trademark. That definition pulls in software publishers, IoT vendors, firmware vendors, and hardware OEMs alike. Authorised representatives, importers, and distributors do not file Article 14 reports themselves, but they have duties under Articles 18-20 to ensure that the manufacturer is doing so, and to inform the manufacturer of any vulnerability they detect. Open-source software stewards have a parallel light-touch regime under Article 24 that includes vulnerability reporting but with a softened obligation: they cooperate with reporting rather than directly carrying the same deadlines.
What counts as "actively exploited"?
Article 3(40) defines an actively exploited vulnerability as one for which there is reliable evidence that the vulnerability is being used by a malicious actor in the wild. The Commission's draft delegated act on the conditions for delaying disclosure clarifies that PoC publication alone does not satisfy "actively exploited", but a single confirmed compromise of a deployed instance does. Honeypot evidence, telemetry from EDR partners, and customer-reported indicators all qualify if corroborated. The provision deliberately does not require the manufacturer to have remediated the issue — knowledge alone starts the 24-hour clock.
How does the single reporting platform work?
Article 16 obliges ENISA to operate a single reporting platform that interconnects national CSIRTs and provides a common front door. Manufacturers submit one notification; the platform routes it to the coordinator CSIRT in the relevant Member State and gives ENISA simultaneous read access. The platform is scheduled to be operational by 11 September 2026. ENISA has indicated that a testing period will precede mandatory live use, with API and structured form submission options. The expected payload aligns with the CSIRT Network Vulnerability Disclosure Policy, including CVE identifier (where assigned), affected product identifiers (PURL or CPE), CVSS v3.1 or v4.0 vector, exploitation evidence, and known mitigations.
# Illustrative Article 14 early warning payload (24-hour)
event_type: actively_exploited_vulnerability
reporter:
manufacturer: Acme Software SE
main_establishment_member_state: DE
contact: psirt@acme.example
product:
name: Acme Gateway
purl: pkg:generic/acme/gateway@4.2.1
version_range_affected: "<=4.2.1"
vulnerability:
cve_id: PENDING
severity_estimate: HIGH
exploitation_evidence: customer_telemetry_confirmed_compromise
first_observed_utc: 2026-09-22T08:14:00Z
status: assessment_in_progress
delay_dissemination_requested: false
What are the penalties for non-compliance?
Article 64 caps administrative fines for breach of Article 14 obligations at 15 million EUR or up to 2.5% of the total worldwide annual turnover for the preceding financial year, whichever is higher. The same ceiling applies to breaches of essential cybersecurity requirements in Annex I. Member States retain discretion on enforcement priorities. Importantly, the CRA borrows the GDPR-style "whichever is higher" formulation, so even a low-turnover manufacturer that misses a 24-hour deadline can face the 15 million EUR ceiling. Article 64(8) requires Member States to ensure fines are effective, proportionate and dissuasive, which historically pushes regulators toward making early enforcement examples.
How should PSIRTs prepare now?
Three operational changes need to be in place before September 2026. First, the 24-hour clock requires PSIRT on-call coverage with authority to file partial notifications without waiting for executive sign-off; current SLAs that route every PSIRT advisory through legal review will not survive the deadline. Second, an internal triage taxonomy must map "we have telemetry of exploitation" to a defined notification path, with predefined templates pre-populated with manufacturer details. Third, manufacturers should test integration with the ENISA platform during the trial window — Article 14 is silent on retransmission semantics if the platform is unavailable, and queueing behaviour will need to be exercised. Manufacturers headquartered outside the EU should designate their authorised representative and confirm which Member State's CSIRT acts as coordinator.
How Safeguard Helps
Safeguard maintains a continuously updated PSIRT inventory of every product line you ship, with SBOMs that map components to downstream customers — so when a vulnerability is confirmed exploited, the affected product list and severity estimate populate within minutes rather than hours. Reachability analysis lets your team distinguish a CVE in a transitively-included library that does not execute from a directly exploitable issue in shipping code, narrowing what actually triggers an Article 14 notification. Policy gates can pre-fill the structured payload required by the ENISA single reporting platform and route it through your incident workflow, including timer-driven escalations at the 24-hour, 72-hour, and 14-day milestones. Integration with VEX issuance lets you publish suppression statements to customers in lockstep with the regulator notification, keeping advisory consistency intact while you meet the Article 14 clock.