CRA Article 14: the September 2026 milestone most manufacturers are not ready for

A misunderstood milestone

December 2027 is the date that captures most attention in Cyber Resilience Act briefings. It is the full compliance deadline: the date from which every product placed on the EU market must meet all essential requirements, carry a complete technical file, and bear the CRA CE marking. That deadline is real and binding.

But Regulation (EU) 2024/2847 contains an intermediate milestone of a fundamentally different character: the obligations of Article 14 take effect on 11 September 2026, fifteen months before full compliance. They concern neither product design, nor the technical file, nor CE marking. They concern a manufacturer's operational capacity to detect an actively exploited vulnerability and notify competent authorities within binding deadlines.

What makes this milestone distinctive is its retroactive scope. These obligations apply to all products on the market, regardless of when they were placed there. A manufacturer whose alarm systems or IoT gateways were put on sale in 2017 is subject to Article 14 from 11 September 2026, provided units are still installed at customer premises. There is no exemption based on a product's age or date of first commercialisation.

The notification chain: three levels, three deadlines

Article 14§3 of the CRA sets out the notification sequence applicable when a manufacturer becomes aware of an actively exploited vulnerability:

• Early warning (Article 14§3(a)) : within 24 hours of becoming aware. Minimum content: confirmation of the vulnerability's existence, indication of whether remediation is under way, preliminary information on the exploitation vector;
• Full notification (Article 14§3(b)) : within 72 hours. Extended content: preliminary severity assessment, affected products and versions, remediation progress, available mitigations;
• Final report (Article 14§3(c)) : within 14 days of patch availability for exploited vulnerabilities. Full content: detailed vulnerability description, root cause analysis, deployed corrective measures, known exploitation indicators.

For severe incidents (Article 14§3, second subparagraph), the final report is due within one month of the full notification, a longer deadline but with correspondingly extended documentation requirements.

The definition of a severe incident warrants attention. The CRA defines a severe security incident as any event with actual or potential impact on a product's capacity to protect the availability, authenticity, integrity or confidentiality of data or services, or that has led, or may have led, to execution of malicious code on the product or in its operational environment. This definition, read strictly, potentially encompasses any security incident that led to a partial or complete compromise of a product unit. Manufacturers must document their internal criteria for identifying a severe incident, failing which they risk notifying only the most obvious cases.

What "actively exploited" means

The concept of an actively exploited vulnerability is central to Article 14. It is not equivalent to published vulnerability or vulnerability with a high CVSS score. A vulnerability is actively exploited when there is evidence of its actual use in attacks: correlation with threat reporting, alerts from CERT-EU, entries in the EUVD (European Vulnerability Database) or equivalent flagged as exploited in the wild.

In practice, this means the manufacturer must maintain active monitoring of vulnerabilities affecting its components. A vulnerability published in the NVD or EUVD with an "exploited in the wild" designation triggers the Article 14 obligation from the moment the manufacturer becomes aware of it, including if they learn of it via a third party or security researcher.

The standard of proof for "becoming aware" is not precisely defined in the regulation text. The Commission's guidance document (public consultation, March 2026) clarifies, however, that a manufacturer cannot shelter behind a deficient organisation to claim ignorance of a publicly documented exploited vulnerability affecting its products. Monitoring vulnerability databases and correlating against the SBOM is the practical demonstration of reasonable diligence.

The minimum infrastructure required before September 2026

Meeting the notification chain, in particular the 24-hour deadline, requires organisational and technical infrastructure that cannot be improvised. The minimum to be operational by 11 September 2026 is:

1. An up-to-date, correlatable SBOM

The SBOM (Software Bill of Materials) is the technical prerequisite for the 24-hour deadline. Without a complete and current SBOM, it is impossible to assess within hours whether a published vulnerability affects a product in service. For a manufacturer managing ten product families across successive generations, manual identification of affected components can take several days, a timeline incompatible with Article 14.

The SBOM format must be machine-readable to enable automatic correlation with vulnerability databases. The two formats recognised by the EUVD are CycloneDX and SPDX. The minimum content required by the CRA (Annex VII §3f) covers first-level dependencies with their name, version, supplier and licence identifier.

2. A designated PSIRT function

A PSIRT (Product Security Incident Response Team) is not necessarily a dedicated team. In an SME, it can be a distributed function across two or three people with complementary roles : a technical expert for vulnerability triage and CVSS assessment, a procedural profile for documentation and authority notifications, and a backup for continuity. What is required is that the function is designated, formalised, and that the people involved have been trained on Article 14's deadlines and obligations.

Experience from compliance programmes in the sector shows that the primary cause of notification deadline failures is not technical. It is the absence of a clear decision-making process covering who validates the notification and in what timeframe. The internal vulnerability handling procedure must explicitly document this decision circuit.

3. A published CVD policy

The CVD (Coordinated Vulnerability Disclosure) policy is a public document committing the manufacturer to its process for receiving, handling and disclosing vulnerabilities reported by third parties. It is required by Annex I Part II of the CRA and must be publicly accessible before 11 September 2026.

The minimum content of a CVD policy compliant with the CRA and prEN 40000-1-3 (vulnerability handling, §5.3.3) includes: one or more accessible contact mechanisms (dedicated security@ address, web form), the manufacturer's expectations for the content of a report, the response and acknowledgement deadlines the manufacturer commits to, the embargo strategy (the period during which the vulnerability will not be publicly disclosed to allow remediation), and the conditions for public acknowledgement of researchers.

One frequently overlooked element is the legal safe harbour clause. A CVD policy that exposes researchers to legal action for unauthorised disclosure discourages reporting and leaves the manufacturer blind to its own vulnerabilities. Most reference CVD policies (ISO/IEC 29147, CERT Coordination Center) include an explicit non-prosecution commitment for researchers who comply with the policy. External legal review of this point before publication is recommended.

4. An operational reporting channel

The reporting channel must be accessible and functional before 11 September 2026. Technical implementation is straightforward : a dedicated email address (security@) and, for manufacturers with a product website, a /.well-known/security.txt file compliant with RFC 9116. This file contains contact information, optional encryption keys, and the URL of the CVD policy.

The security.txt is a convention that enables security researchers to identify the reporting channel quickly rather than searching across the website. It has no specific regulatory value, but its absence is a negative signal in any compliance review.

5. Registration on the ENISA single reporting platform

Article 14 provides that notifications are transmitted to ENISA via a single reporting platform, whose deployment is expected before 11 September 2026. Manufacturers established in France also notify ANSSI, pursuant to Article 14§8 which allows competent national authorities (national CSIRTs) to receive this information. The registration process on the ENISA platform must be anticipated, not left to the deadline.

The legacy product problem

The retroactivity of Article 14 raises a fundamental question for manufacturers: what to do with products that are no longer in active development, whose technical support is reduced or non-existent, but whose units are still installed at customer premises?

The CRA text provides no exemption for legacy products. The notification obligation applies as long as a product unit is “made available on the market”, a concept that covers products in service with end users, whether or not the manufacturer still commercialises them (recital 43 and article 3(22)). The only clear regulatory exit is having formally documented that the support period has ended, with a reasonable justification based on the product's expected useful life.

The recommended approach for manufacturers with a legacy product portfolio is:

1. Compile a list of all products whose units may still be in service at customer premises;
2. For each product or family, assess whether a reasonable support period is still running, taking into account expected useful life, contractual commitments, active maintenance or monitoring service contracts;
3. For products whose support period is reasonably exhausted: formally document this decision and its justification, and communicate it to customers where possible;
4. For products still within the support period: include their perimeter in the SBOM/EUVD monitoring scope.

The last point is the most demanding for manufacturers whose oldest products were developed before SBOM practice was widespread. For embedded firmware from the early 2010s, the component list is often not formalised. A retrospective analysis is required: inventory of libraries included in the firmware build, identification of versions, correlation with published CVEs. This is a laborious exercise but unavoidable if units of these products remain in service.

What a market surveillance authority looks for

Article 14 obligations do not only create reporting obligations : they create an audit trail that market surveillance authorities can use. An ENISA notification records the existence of a vulnerability, the manufacturer's date of awareness, and the remediation timeline. Should a market surveillance authority (MSA) subsequently receive a user complaint or investigate an incident involving that product, the notification will be the first document it examines.

The questions an MSA asks in an Article 14 review are:

• Did the manufacturer have an SBOM covering this product at the time of notification? If not, how could it assess within 24 hours whether the vulnerability affected the product?
• Was the CVD policy published before the notification date? A manufacturer that publishes its CVD policy on the day it notifies a vulnerability exposes its file to challenge;
• Is the time elapsed between the vulnerability's publication (or its appearance in threat intelligence feeds) and the manufacturer's notification consistent with active monitoring of its components? A gap of several weeks between a known exploit's publication and the notification raises questions about reasonable diligence;
• Was the patch delivery accompanied by user communication, and could users apply the patch via an update mechanism described in the product documentation?

These questions are not theoretical. They are, in substance, the same questions asked in current RED Directive reviews of post-market security non-conformities. The CRA formalises and tightens a framework that already existed, partially, in the practice of the most active MSAs.

What remains uncertain as of today

Three operational unknowns remain to be resolved before September 2026:

1. The ENISA reporting platform: its deployment timeline, interface and notification format requirements. ENISA has communicated on its deployment schedule, but manufacturers who have not begun early registration testing risk a last-minute surprise;
2. The operational definition of in-scope products: Implementing Regulation (EU) 2025/2392 specifies Annex III categories, but grey areas remain for certain hybrid products' classification as "important" or "default". A pre-emptive opinion request from the competent national authority (in France, ANSSI or ANFR depending on the sector) is an option for contentious cases ;
3. National authorities' interpretation of "becoming aware": the Commission's guidance document provides clarifications, but national interpretation may vary. The decisional practice emerging from early notifications will resolve these uncertainties.

None of these unknowns justifies deferring compliance infrastructure. SBOM, PSIRT, CVD policy and reporting channel are non-contentious prerequisites that every prudent manufacturer should have operational before the deadline.