CRA Art.14 Explained: What Software Manufacturers Must Report to ENISA Before September 2026

Post #1 in the sota.io CRA Art.14 Vulnerability Reporting Operations Series

On 11 September 2026, Article 14 of the EU Cyber Resilience Act (Regulation (EU) 2024/2847) becomes enforceable. From that date, manufacturers of products with digital elements — software, firmware, connected hardware — must notify both their national CSIRT coordinator and ENISA within 24 hours whenever they become aware of an actively exploited vulnerability in their product.

Missing that 24-hour window is not a technical failure. It is a regulatory breach that carries fines up to EUR 15 million or 2.5% of worldwide annual turnover under CRA Article 64. Most SaaS teams are not operationally ready for this timeline today.

This post explains exactly what Article 14 requires, who it applies to, what the three reporting tiers look like in practice, and where reports must go.

What Is CRA Article 14?

Article 14 of Regulation (EU) 2024/2847 is titled "Reporting obligations of manufacturers." It is one of the CRA's earliest-applying provisions: while most manufacturer obligations (Article 13, Annex I essential requirements, CE marking) apply from 11 December 2027, Article 14 has its own earlier date of 11 September 2026.

The regulation entered into force on 10 December 2024. The phased application schedule (Article 71) means:

• 11 June 2026 — Chapter IV (notification of conformity assessment bodies) applies
• 11 September 2026 — Article 14 reporting obligations apply
• 11 December 2027 — Full regulation applies (main manufacturer obligations)

Article 14 creates two parallel reporting tracks: one for actively exploited vulnerabilities and one for severe incidents. Both use the same infrastructure (the Art.16 single reporting platform), but have slightly different final-report deadlines.

Who Must Comply

Article 14 applies to manufacturers — entities that develop or produce a product with digital elements and place it on the EU market under their own name or trademark (or have it designed or manufactured and market it under their name). This explicitly includes:

• SaaS platforms where the software component is a product placed on the market
• Firmware developers for connected hardware
• Software vendors whose products have digital network interfaces
• Companies selling commercial software — even if delivered as a service when the underlying software is a "product with digital elements"

Open-source software stewards (Article 24) face reduced obligations and cannot be fined under Article 64. Individual non-commercial FOSS contributors are exempt.

Importers and distributors have their own obligations under Articles 19 and 20 but the Article 14 reporting framework primarily targets manufacturers. When an importer or distributor places a product under its own brand name, it assumes manufacturer obligations under Article 21 — including Article 14 duties.

The Two Reporting Triggers

Trigger 1: Actively Exploited Vulnerability

An actively exploited vulnerability means a security flaw in your product that threat actors are currently using in the wild — not just disclosed or theoretical, but actively weaponised. The CRA clock starts the moment the manufacturer becomes aware of the exploitation.

Trigger 2: Severe Incident with Security Impact

A severe incident is a security event that has a significant impact on the product's availability, authenticity, integrity, or confidentiality and that threatens the security of the product's users or the network to which it is connected. A ransomware event affecting your SaaS platform's availability at scale would typically qualify.

The definitions are intentionally broad. If you are uncertain whether an event qualifies, the CRA's intent favours notification over silence.

The Three-Tier Reporting System

Article 14 structures reporting in three sequential steps for each trigger. The clocks run from the point of manufacturer awareness.

Tier 1 — Early Warning (24 Hours)

Within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, the manufacturer must submit an early warning to:

1. The CSIRT designated as coordinator for CRA purposes in the manufacturer's Member State
2. ENISA

The early warning is intentionally minimal — it signals that something significant has been detected and that a fuller report is coming. It does not require a complete technical root-cause analysis.

Critical nuance: Reports go to both the CSIRT coordinator and ENISA. They are submitted via the Art.16 single reporting platform (see below). The CSIRT is the designated national coordinator, not any CSIRT you happen to know.

Tier 2 — Full Notification (72 Hours)

Within 72 hours of manufacturer awareness, a full notification must be submitted containing:

• A description of the vulnerability or incident
• The product(s) affected
• An initial severity assessment
• Available information about threat actors or exploitation techniques
• Whether a corrective or mitigating measure is being prepared

This is the report that ENISA and the CSIRT will act on operationally. It must be substantive enough for the authority to understand the nature and scope of the issue.

Tier 3 — Final Report

The final report deadline differs by trigger type:

The final report must include a full description of the vulnerability or incident, its root cause if known, the corrective or mitigating measures taken or planned, and any information that may assist other affected manufacturers or users.

Where Reports Go: The Art.16 Single Reporting Platform

Reports under Article 14 must be submitted via the single reporting platform established under Article 16. This platform is operated by ENISA and serves as the central routing hub for CRA notifications across the EU.

When a manufacturer submits to the Art.16 platform, ENISA automatically routes the information to:

• The relevant national CSIRT coordinator
• Where relevant, other competent authorities or Member States

This means manufacturers do not need to separately contact each national authority. Submitting to the Art.16 platform fulfils the notification obligation to both the CSIRT and ENISA simultaneously.

The platform was not yet live at the time of publication — ENISA is building it in preparation for the 11 September 2026 application date. Watch ENISA's CRA implementation page for go-live announcements.

What CRA Art.14 Is NOT

To avoid compliance confusion, it helps to be explicit about what falls outside Article 14's scope:

Not a substitute for NIS2 reporting. NIS2 (Directive (EU) 2022/2555, Article 23) has its own incident reporting regime for essential and important entities — 24h early warning, 72h incident notification, 1-month final report. If your SaaS is also classified as an essential or important entity under NIS2, you have two parallel reporting regimes. They use different definitions of "incident," different authorities, and different timelines. CRA Art.14 is about the product; NIS2 Art.23 is about the service.

Not a GDPR personal data breach notification. GDPR Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach. CRA Art.14 reports go to the CSIRT/ENISA. These are separate obligations to separate authorities triggered by different events.

Not a retrospective requirement. Article 14 applies from 11 September 2026. Vulnerabilities discovered and remediated before that date do not need to be reported under Art.14.

Not applicable to all software. The CRA covers "products with digital elements" placed on the EU market. Pure internal software, software never placed on the market, and individual non-commercial FOSS contributions are out of scope.

Penalties for Non-Compliance

Article 64 of the CRA sets the penalty framework. Violations of the Article 14 reporting obligations fall under the top tier:

• Up to EUR 15 million or 2.5% of total worldwide annual turnover (whichever is higher) for breaches of the essential requirements (Annex I) and the Article 13/14 manufacturer obligations

For a EUR 50 million ARR SaaS company, that is up to EUR 1.25 million for a single missed 24-hour notification. Multiply by the number of actively exploited vulnerabilities in a year.

Practical Gaps in Most SaaS Operations Today

Most SaaS incident response processes are built around detection and internal escalation — not regulatory notification. The 24-hour window from manufacturer awareness creates several operational gaps:

Gap 1: Awareness definition ambiguity. When does your organisation "become aware"? When a security researcher emails your disclosed address? When a SOC alert fires? When an engineer confirms exploitation? The CRA clock starts at the moment the manufacturer as an organisation has knowledge — not when the CISO is personally briefed. Internal awareness processes need to be defined and logged.

Gap 2: 24/7 notification capability. The 24-hour window does not pause for weekends or holidays. If an actively exploited vulnerability is confirmed at 23:00 on a Friday, the early warning is due by 23:00 Saturday. Most SaaS incident processes lack an on-call chain with authority to make regulatory notifications.

Gap 3: Platform registration. The Art.16 platform requires prior registration. Manufacturers cannot create an account during the incident. Get registered before September 2026.

Gap 4: CSIRT coordinator identification. Manufacturers must know which national CSIRT is the designated coordinator for CRA purposes in their Member State. This is not always the same CSIRT you contact for other purposes. Check ENISA's CSIRT directory.

What Needs to Be Ready Before 11 September 2026

Based on the Article 14 obligations, here is the minimum operational readiness checklist for manufacturers:

• Classify your products: Confirm which of your software products qualify as "products with digital elements" under the CRA. If you place software on the EU market, you likely qualify.
• Identify your CSIRT coordinator: Confirm the designated national CSIRT for CRA reporting in your primary Member State(s) of establishment.
• Register on the Art.16 platform: Watch ENISA's CRA page for registration opening. Register as soon as available — do not wait for an incident.
• Define "manufacturer awareness": Write a policy defining at what point your organisation is "aware" for CRA purposes. Tie it to a concrete escalation trigger (e.g., confirmed exploitation in threat intelligence feed, SOC severity-1 alert closed with exploitation confirmed).
• Establish 24/7 notification authority: Designate who can submit CRA reports outside business hours. Include in on-call runbooks.
• Draft early warning template: Prepare a minimal Art.14 Tier 1 template so the 24-hour submission is a fill-in exercise, not a writing exercise, during an active incident.
• Audit vulnerability detection coverage: Confirm your monitoring covers actively exploited vulnerability indicators — not just CVE publication, but exploitation signals (threat intel feeds, ENISA's EUVD, CISA KEV).
• Integrate with SBOM process: Annex I Part II requires manufacturers to identify and document vulnerabilities in components. This is the foundation for knowing which products are affected when an exploited CVE drops.
• Test the process: Run a tabletop exercise simulating discovery of an actively exploited CVE at 22:00 on a Sunday. Can you get an early warning out within 24 hours? What breaks?

The SBOM Connection

Article 14 does not exist in isolation. The reporting obligations assume the manufacturer has sufficient product component visibility to know which products are affected by a given vulnerability within hours of detecting exploitation. Without a current SBOM (software bill of materials), "which products are affected?" can take days to answer — breaking the 24-hour window before the notification is even drafted.

The SBOM requirement is anchored in Annex I Part II (vulnerability handling requirements) and detailed in Annex VII (technical documentation). A CRA-compliant SBOM covers:

• All open-source and third-party components by name, version, and known CVEs
• Maintained throughout the product lifecycle
• Updated whenever a component is added, removed, or updated

Post #4 of this series covers SBOM integration with the Art.14 reporting process in detail.

Summary: Art.14 in Three Sentences

Article 14 of the CRA requires manufacturers to notify both the national CSIRT coordinator and ENISA within 24 hours of becoming aware of an actively exploited vulnerability or severe incident — followed by a fuller 72-hour notification and a 14-day (vulnerability) or 1-month (incident) final report, all submitted via the Art.16 single reporting platform. This obligation applies from 11 September 2026, nearly 15 months before the main CRA requirements kick in on 11 December 2027. The operational challenge is not the content of the reports but the speed: 24 hours leaves no room for internal debate, and most SaaS incident response processes are not designed for regulatory notification at that pace.

What's Next in This Series

This is Post #1 of the CRA Art.14 Vulnerability Reporting Operations series:

1. [This post] Art.14 Explained: What Manufacturers Must Report to ENISA Before September 2026
2. 24-Hour ENISA Alert: Developer Ops Guide — Building the operational process for the 24h early warning
3. 72-Hour Full Report Template — What SaaS providers must document in the Tier 2 notification
4. SBOM Integration — How software bill of materials links to Art.14 reporting obligations
5. Compliance Finale — Complete September 2026 vulnerability reporting checklist

Regulation text: Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), OJ L, 2024/2847, 20 November 2024. Article 14 = Reporting obligations of manufacturers; Article 16 = Single reporting platform; Article 64 = Penalties; Article 71 = Entry into force and application.

This post is for informational purposes only and does not constitute legal advice. Consult qualified EU cybersecurity law counsel for compliance decisions.