A CVE Is Not an Article 14 Report: What Actually Makes a Vulnerability Reportable?

A practical guide to deciding when a CVE, supplier advisory, KEV entry, scanner result, or zero-day becomes a mandatory vulnerability report under Article 14 of the Cyber Resilience Act.

The short answer

A CVE is an identifier and a vulnerability record. An Article 14 report is a legal notification about a particular reportable event affecting a manufacturer’s product.

The two objects are related, but they are not interchangeable. A CVE record can exist where:

• the manufacturer’s product does not contain the affected component;
• the component is present but the affected version is not;
• the vulnerable code is present but unreachable in the product;
• exploitation is technically possible but has never occurred maliciously;
• exploitation has occurred elsewhere but not in the manufacturer’s product; or
• the available information remains too uncertain to establish the Article 14 condition.

In all those cases, the CVE may require urgent vulnerability analysis or remediation without yet being a mandatory Article 14 vulnerability report.

The converse is equally important. A vulnerability can be reportable without a CVE ID, without a public advisory, without a CVSS score, and before a patch exists. A maliciously exploited zero-day can meet Article 14 as soon as the manufacturer has reliable evidence and reaches the CRA awareness threshold.¹

ImportantThe governing distinction

The presence of a CVE answers: which publicly disclosed vulnerability are we discussing? Article 14 asks: has this manufacturer become aware, with the required degree of certainty, of malicious exploitation of a vulnerability contained in its product—or of a separate severe incident affecting product security?

Start with the objects, not their acronyms

The CVE Programme exists to identify, define, and catalogue publicly disclosed cybersecurity vulnerabilities. A CVE ID is a unique reference to a specific vulnerability; the associated record contains descriptive and affected-product information and enables different tools and parties to correlate data about the same issue.²

The shorthand CVE is itself ambiguous: practitioners may mean the identifier, the published record, or the vulnerability described by that record. A reserved or rejected identifier also has a different evidentiary meaning from a published record. None of those CVE states is an Article 14 notification.

That is a necessary coordination function. It is not a legal determination under the CRA. The most common vulnerability artefacts answer different questions.

Artefact or signal	Question it can help answer	What it does not establish by itself
CVE ID and CVE record	Which publicly disclosed vulnerability is being discussed, and which products or versions are claimed to be affected?	That the vulnerability is present, reachable, or exploited in the manufacturer’s actual product state; that Article 14 applies.
CPE, package URL, scanner or SCA match	Does an observed name, package, or version appear to correspond to an affected component?	Exact identity, backported fixes, runtime reachability, malicious exploitation, or legal reportability.
SBOM or build manifest	Is a component or dependency included in a particular product build or release?	That the component is affected, exploitable in context, or maliciously exploited.
VEX statement	What is a supplier’s or manufacturer’s current status and rationale for a vulnerability in a specific product context—for example, affected or not affected?	Independent proof of exploitation or a final Article 14 decision.
CVSS score and vector	What are the technical characteristics and relative severity of the vulnerability under the metrics used?	Whether the product is actually affected, whether exploitation has occurred, or whether the CRA threshold is met.
EPSS probability	What is the modelled probability that a published CVE will be exploited in the wild in the next 30 days?	That exploitation has already occurred, that this product is affected, or that the score is a complete risk or legal measure.
Known Exploited Vulnerabilities entry	Has the issuing authority concluded that evidence of active exploitation exists for the listed vulnerability?	That the manufacturer’s precise product contains the vulnerable condition or, under current Commission guidance, that it has been exploited in that product.
Supplier advisory or threat-intelligence report	Which versions, configurations, campaigns, indicators, and exploitation claims may be relevant?	Automatic reliability, product applicability, or legal awareness without assessment.
Customer telemetry, forensic artefacts, or incident evidence	Did exploitation or compromise occur in an identified deployment, and how is it connected to the product?	A complete root-cause analysis; nevertheless, sufficiently reliable and specific evidence may establish awareness before the investigation is complete.

Table 1: Vulnerability artefacts answer different technical and legal questions.

CVSS version 4.0 is an open framework for communicating vulnerability characteristics and severity. FIRST expressly distinguishes the Base score’s severity function from a complete risk assessment; Threat and Environmental metrics add context, but regulatory requirements and organisational consequences remain outside CVSS.³ Even the CVSS v4.0 Threat metric value Attacked is a threat-assessment input, not a CRA determination: its source, product applicability, reliability, and relationship to the manufacturer’s product must still be assessed.

EPSS answers another question again. It estimates the probability that a published CVE will be exploited in the wild during the next 30 days. FIRST states that EPSS is not a complete risk score and does not determine whether a vulnerability affects a specific environment or whether compensating controls apply.⁴

A CISA Known Exploited Vulnerabilities (KEV) entry is a materially stronger exploitation signal because CISA adds vulnerabilities based on evidence of active exploitation.⁵ It is therefore an input that should receive urgent assessment. It is still not a universal declaration that every downstream product containing the component has suffered the exploitation required by the current Commission interpretation of Article 14. Where the KEV entry and its supporting sources identify the manufacturer’s exact product as the exploited product, however, that evidence may contribute to—or, depending on its specificity and reliability, establish—the required reasonable certainty without waiting for a local customer compromise.

The Article 14 vulnerability test

Article 14(1) requires a manufacturer to notify an actively exploited vulnerability contained in the product with digital elements that it becomes aware of.⁶

Article 3(42) defines an actively exploited vulnerability as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.⁷

The legal text therefore supplies several cumulative elements. As an operational abstraction—not as a formula contained in the Regulation—the mandatory vulnerability path can be represented as:

R_{v} = M \land C \land E \land A

where:

• M means that the organisation is acting as the manufacturer of an in-scope product for the event being assessed;
• C means that the vulnerability is contained in that product with digital elements;
• E means that reliable evidence establishes unauthorised exploitation by a malicious actor, including the product-specific interpretation discussed below; and
• A means that, after a prompt initial assessment, the manufacturer has reached the awareness threshold described in the Commission guidance.

If any element is absent or not yet established, Article 14(1) is not yet triggered on those facts. This does not mean that remediation, customer support, supplier escalation, contractual notification, voluntary reporting, or another regulatory obligation disappears.

The component interpretation is product-specific

The exact wording deserves care. Article 3(42) refers to exploitation in a system, while Article 14(1) requires the actively exploited vulnerability to be contained in the product. The Commission’s 2026 guidance reads those provisions together in a product-specific manner for integrated components.

According to point 218 of that guidance, where a third-party component contains a vulnerability, the final-product manufacturer is not required to make a mandatory Article 14 report if the vulnerability:

• cannot be exploited in its product—for example because the vulnerable code is unreachable; or
• has not been exploited in its product.⁸

Where the component vulnerability is contained in and actively exploited in the final product, the final-product manufacturer must notify it. If the component was separately placed on the market, its manufacturer can independently have a notification obligation.⁹¹⁰

This product-specific reading is Commission guidance rather than additional wording enacted in Article 14. It is non-binding, but it is the clearest current official implementation position and should be stated explicitly whenever an organisation builds its decision criteria around it.

Awareness is not the first database match

The Commission guidance treats a manufacturer as having become aware when, after an initial assessment, it has a reasonable degree of certainty that a vulnerability contained in its product is being actively exploited.¹¹

The first CVE match, advisory, or customer allegation does not automatically equal awareness. It initiates assessment. The manufacturer should assess a suspicious event immediately, and it cannot postpone awareness until every forensic question, affected serial number, root cause, or mitigation has been resolved.

That distinction is necessary because Article 14 uses progressive reporting: a limited early warning is followed by a fuller notification as the investigation develops.

The severe-incident path does not require a CVE

Article 14 also contains a separate mandatory trigger: a severe incident having an impact on the security of the product with digital elements.¹²

An incident is severe under Article 14(5) where it:

• negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions; or
• has led, or is capable of leading, to malicious code being introduced or executed in the product or in the network and information systems of a user.¹³ The manufacturer may therefore need to report a severe product-security incident even if:
• no vulnerability has yet been identified;
• no CVE has been assigned;
• the compromise originated in a build, signing, update, or remote-processing mechanism rather than a catalogued product flaw; or
• the investigation cannot yet determine the complete attack chain.

The decision logic must test the vulnerability and incident paths independently.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    SIGNAL["CVE, advisory, scanner, KEV,<br/>supplier, customer or incident signal"]:::context
    ROLE{"Manufacturer of an<br/>in-scope product?"}:::test
    MAP["Map exact product, version,<br/>configuration and component"]:::product
    CONTAINED{"Vulnerability contained and<br/>exploitable in this product?"}:::test
    EXPLOITED{"Reliable evidence of malicious,<br/>unauthorised exploitation in<br/>this product?"}:::test
    INCIDENT{"Separate severe incident<br/>affecting product security?"}:::test
    ASSESS[Prompt initial assessment]:::product
    AWARE{"Reasonable degree<br/>of certainty reached?"}:::test
    REPORT["Record awareness;<br/>start Article 14 reporting<br/>and user communication"]:::product
    OTHER["Document rationale;<br/>continue applicable remediation,<br/>escalation or voluntary reporting"]:::context
    OUT["Route to the responsible actor<br/>or other applicable regime"]:::context
    SIGNAL --> ROLE
    ROLE -- No --> OUT
    ROLE -- Yes --> MAP
    MAP --> CONTAINED
    CONTAINED -- Yes --> EXPLOITED
    CONTAINED -- No --> INCIDENT
    EXPLOITED -- Yes --> ASSESS
    EXPLOITED -- No --> INCIDENT
    INCIDENT -- Yes --> ASSESS
    INCIDENT -- No --> OTHER
    ASSESS --> AWARE
    AWARE -- Yes --> REPORT
    AWARE -- No --> OTHER
    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef test fill:#ffffff,stroke:#4f5962,stroke-width:1.5px,color:#252a2e;
    classDef context fill:#ffffff,stroke:#7a7a7a,stroke-width:1.5px,stroke-dasharray:5 5,color:#404040;

Figure 1: A CVE or advisory begins product-specific assessment; it does not itself satisfy either Article 14 trigger.

The sequence in Figure 1 is not a substitute for case-specific analysis. Its purpose is to prevent a tool classification from silently becoming a legal conclusion.

What common signals actually mean

The examples below assume that the organisation is the manufacturer of an in-scope product. Different facts can change the conclusion.

Signal	Mandatory Article 14 vulnerability report on those facts?	Why
A scanner reports a CVE against a package name, but the manufacturer has not confirmed the package or version in the product.	No—not yet.	Identity and product containment remain unverified. The result requires prompt triage, not immediate legal classification.
The affected component and version are present, but the vulnerable function is compiled out, not loaded, unreachable, or otherwise not exploitable in the product.	Under current Commission guidance, no mandatory report for the final-product manufacturer on those facts.	The component vulnerability cannot be exploited in that product. The rationale and supporting evidence should be recorded.
The vulnerability is exploitable in the product and has a critical CVSS score, but there is no evidence of malicious exploitation.	No mandatory Article 14(1) report solely on those facts.	Exploitability and severity do not establish active malicious exploitation. Remediation can still be urgent.
EPSS assigns a very high probability of exploitation.	No.	EPSS is a prediction about future observed exploitation of a published CVE, not proof of exploitation or product applicability.
CISA adds the component CVE to KEV, but the manufacturer has no evidence that the vulnerability has been exploited in its final product.	Not automatically, under the current Commission product-specific interpretation.	KEV is strong evidence that exploitation exists in the wild and demands urgent assessment; product containment and product-specific exploitation still require analysis.
A reliable supplier advisory states that the exact product and versions are being exploited in malicious campaigns, and the manufacturer’s assessment confirms applicability.	Likely yes, once reasonable certainty is reached.	A manufacturer need not wait for one of its own customers to be compromised if reliable product-specific evidence establishes the trigger.
A customer provides trustworthy logs showing that an attacker used the product vulnerability without authorisation.	Likely yes, once the initial assessment confirms the evidence and product connection.	The facts directly correspond to the statutory definition.
An authorised laboratory or good-faith researcher successfully exploits the vulnerability during testing.	No—not solely because the test succeeded.	Recital 68 and the Commission FAQ distinguish good-faith testing from malicious unauthorised exploitation.
A zero-day is being exploited against the product, but no CVE or patch exists.	Yes, if reliable evidence and awareness are established.	Article 14 depends on the event, not on prior public cataloguing or remediation availability.
The product’s update infrastructure is compromised and distributes malicious code, but no vulnerability is yet known.	Possibly yes through the severe-incident path.	A CVE is unnecessary where Article 14(3) and (5) are independently satisfied.

Table 2: Common technical signals do not map one-to-one to Article 14 decisions.

Reliable evidence does not mean completed forensics

The CRA does not define a prescribed evidence hierarchy or a numerical confidence score for reliable evidence. The Commission guidance supplies the reasonable-degree-of-certainty threshold for awareness, but the quality of evidence remains fact-dependent.

A practical assessment should examine at least five dimensions.

Evidence dimension	Assessment question
Specificity	Does the evidence identify the manufacturer’s product, version, configuration, component, or deployment, or only a broad technology family?
Proximity	Is it direct product telemetry or forensic evidence, a first-hand customer report, a component supplier statement, or a distant repetition of another source?
Integrity and provenance	Can the logs, artefacts, report, or notification be authenticated and traced to their source?
Corroboration	Do independent indicators, affected-system behaviour, exploit traces, supplier analysis, or reproduced conditions support the same conclusion?
Purpose and authorisation	Does the evidence show malicious use without the system owner’s permission, or authorised testing, research, validation, or disclosure?

Table 3: Evidence-quality dimensions for the initial Article 14 assessment.

No single dimension is conclusive. A confidential authority notification identifying the exact exploited product may establish reasonable certainty without the manufacturer reproducing the exploit. Conversely, hundreds of unauthenticated social-media repetitions may add little evidence if they all trace back to one ambiguous claim.

The manufacturer does not necessarily need:

• the attacker’s identity—the final vulnerability report requests information about the malicious actor only where available;
• a completed root-cause analysis—the 24-hour and 72-hour stages are designed for progressive knowledge;
• a CVE ID or public disclosure;
• a patch or corrective measure; or
• proof that every deployed instance is affected.

It does need enough reliable, product-relevant evidence to reach reasonable certainty that the statutory event exists. Where that point has been reached, waiting for a perfect case file risks converting investigation discipline into reporting delay.

The component chain must preserve four different states

Supply-chain vulnerability handling often fails because one field called affected is used to represent four different propositions:

1. present—the component or code is included in the product;
2. vulnerable—the included version or implementation contains the flaw;
3. exploitable—the flaw can be exercised under the product’s practical operational conditions; and
4. exploited—reliable evidence shows malicious, unauthorised use in the product under the current Commission interpretation.

An SBOM is principally evidence for the first proposition. A supplier advisory and version analysis can support the second. Architecture, configuration, reachability, and VEX rationale support the third. Customer evidence, telemetry, authoritative product-specific intelligence, or forensics may support the fourth.

The decision record should never infer exploited directly from present. This distinction also prevents an opposite error: a component name absent from a top-level SBOM does not prove that the code is absent. The CRA SBOM minimum in Annex I, Part II covers at least top-level dependencies; transitive dependencies, statically linked code, forked libraries, embedded firmware, vendor modules, and backported fixes may require build evidence beyond a simple name match.¹⁴

An IT/OT example: a CVE in a PLC used inside a supplied machine or control system

Assume that a PLC manufacturer publishes an advisory for a CVE affecting a web-management function. The PLC has been integrated into a tracker-control cabinet, packaged machine, or other system sold under another supplier’s name and installed at an industrial plant.

The CVE does not answer the CRA question for every actor. The assessment should proceed as follows:

1. Identify legal roles. The PLC supplier may be the manufacturer of the separately marketed PLC. The cabinet or system supplier may be the manufacturer of the integrated product. The plant owner is ordinarily a user unless its own activities create a different CRA role.
2. Identify the product state. Confirm PLC model, hardware revision, firmware, optional modules, enabled services, configuration, and whether remote data processing forms part of the regulated product boundary.
3. Test applicability. Determine whether the advisory covers that version, whether a backported fix exists, whether the affected function is present and reachable, and whether network or product controls change practical exploitability.
4. Assess exploitation evidence. A global advisory may establish that the PLC vulnerability is exploited somewhere. Under point 218 of the Commission guidance, the integrated-product manufacturer still needs to assess whether it has been exploited in its product before treating the event as its mandatory Article 14 vulnerability report.
5. Test the incident path separately. If the installed system has executed malicious code, lost integrity, or exposed sensitive or important functions, the integrated-product manufacturer must also assess the severe-incident trigger even if the exact CVE remains uncertain.
6. Route information without confusing obligations. The plant owner or maintainer should notify the relevant suppliers promptly and preserve evidence. The legal Article 14 notification remains the responsibility of the manufacturer whose trigger is met; operational contracts should define who supplies logs, configuration, containment support, and customer communications.

In OT, active validation on a live controller may create availability or safety risk. Product evidence, passive monitoring, controlled laboratory reproduction, and authorised maintenance-window testing may therefore be preferable to indiscriminate scanning. That affects the evidence method, not the legal threshold.

What if the customer discovers the vulnerability before the manufacturer?

A customer can learn about a vulnerability from its own SOC, an independent penetration test, a maintainer, a researcher, a supplier other than the product manufacturer, a scanner, threat intelligence, or forensic evidence from an incident. That discovery creates an operational need to act, but it does not by itself transfer the manufacturer’s Article 14 obligation to the customer.

The first question is the customer’s legal role. An organisation that has bought and operates a product is ordinarily a user. Configuring, maintaining, repairing, or monitoring the product—whether directly or through a delegated maintainer—does not by itself make that organisation the manufacturer. The conclusion can change if the organisation is also an importer or distributor, places the product on the market under its own name or trademark, or substantially modifies it and then makes it available on the market. Importers and distributors also have express CRA duties to inform the manufacturer without undue delay when they become aware of a vulnerability, once those provisions apply.¹⁵

For a customer acting only as a user, four propositions must remain separate:

1. the customer knows or suspects that a vulnerability exists;
2. the customer has evidence that its deployed product is affected or exploitable;
3. the customer has evidence of malicious, unauthorised exploitation; and
4. the manufacturer has received and assessed enough reliable evidence to reach its own CRA awareness threshold.

The customer’s discovery time and the manufacturer’s awareness time are therefore not necessarily the same:

t_{\mathrm{customer\ discovery}} \leq t_{\mathrm{manufacturer\ receipt}} \leq t_{\mathrm{manufacturer\ awareness}}

The inequalities can collapse to minutes where a customer supplies authenticated, product-specific forensic evidence. They can remain separated where the first signal is an imprecise scanner match. The manufacturer cannot, however, use the distinction as a reason to leave credible evidence unassessed: current Commission guidance requires a prompt initial assessment, and the reporting clock starts when that assessment provides a reasonable degree of certainty—not when the investigation is complete.

ImportantCustomer notice is evidence, not a substitute report

Telling the manufacturer does not itself file the manufacturer’s Article 14 notification. It supplies information from which the manufacturer may become aware and must make its reporting decision. Conversely, telling only a reseller, field maintainer, system integrator, or helpdesk should not be assumed to notify the manufacturer unless that party is an authorised intake channel or is contractually required to relay the case. The customer should use the manufacturer’s published product-security or vulnerability-reporting channel and obtain a timestamped acknowledgement.

The customer should run the following practical process without waiting for the manufacturer to confirm the vulnerability:

1. Protect the operation. Apply safe containment or compensating controls, prioritising human safety and service continuity. In OT, do not reproduce an exploit on live equipment merely to strengthen the report.
2. Preserve evidence. Retain original logs, timestamps and time-zone information, packet captures, alerts, relevant configuration, hashes, memory or disk artefacts where justified, and the chain of custody. Preserve a read-only copy before making changes where operationally possible.
3. Define the affected object. Record the product, model, serial or asset identifier, hardware revision, firmware or software release, build, enabled functions, network exposure, relevant component, and operational context. A component name or CVE match alone is insufficient.
4. Separate vulnerability evidence from exploitation evidence. State whether the finding came from authorised testing, a failed attack, suspicious telemetry, or confirmed malicious exploitation. Do not describe an authorised penetration test as active exploitation under Article 14.
5. Notify the manufacturer securely. Use its PSIRT, coordinated-vulnerability-disclosure, or designated security contact; if none is available, use a support channel that can create a traceable case and require escalation to product security. Include the minimum evidence needed for rapid assessment, while protecting personal data, credentials, trade secrets, and exploitable technical detail.
6. Set coordination expectations. Request acknowledgement, a case identifier, a secure exchange method, the responsible team, the next update time, and a mitigation path. Public disclosure and customer protection are different decisions: unrestricted publication of exploit detail may increase harm, while an indefinite embargo can leave users exposed.
7. Escalate when necessary. If the manufacturer cannot be identified, has ceased operating, lacks a usable channel, or does not respond proportionately to a credible report, the customer can approach the national CSIRT designated as coordinator for coordinated vulnerability disclosure. NIS2 Article 12 requires that coordinator to act as a trusted intermediary and permits natural or legal persons to report anonymously when they request it.¹⁶
8. Keep independent obligations open. Contractual notification, sectoral reporting, personal-data-breach assessment, safety reporting, criminal reporting, insurance conditions, and the customer’s own incident duties are not suspended while the manufacturer investigates.

Under Article 13(17), manufacturers must provide an identifiable single point of contact through which users can report vulnerabilities. Under Article 15, manufacturers and other natural or legal persons may make voluntary vulnerability, cyber-threat, incident, and near-miss notifications; where a person other than the manufacturer notifies an actively exploited vulnerability or severe product-security incident, the receiving coordinating CSIRT must inform the manufacturer without undue delay.¹⁷

The application date matters: Articles 13 and 15 apply with the CRA generally from 11 December 2027, while Article 14 applies from 11 September 2026. The Commission’s current SRP information states that voluntary submissions are operationally possible, but an organisation handling a real 2026 case should verify the live platform function and applicable national procedure rather than assume that the later legal provisions have been brought forward.¹⁸

What changes when the customer is subject to NIS2?

NIS2 adds a second legal perspective. The CRA regulates the manufacturer and the security of a product with digital elements. NIS2 regulates an essential or important entity’s cybersecurity risk management and the continuity and security of the services it provides. The same technical evidence can therefore enter two processes with different duty holders, thresholds, clocks, and recipients.

Being subject to NIS2 does not make every vulnerability a reportable incident. NIS2 distinguishes a vulnerability from an incident. Under Article 23, the mandatory authority-notification trigger is a significant incident affecting the provision of the entity’s services—not the mere presence of a weakness, CVE, vulnerable component, or exploitable condition.¹⁹

Where the customer has found a vulnerability but no incident has occurred, Article 23 is not triggered solely by that finding. The information must nevertheless enter the organisation’s Article 21 risk-management system. The relevant measures expressly include incident handling, business continuity, supply-chain security, security in acquisition, development and maintenance—including vulnerability handling and disclosure—effectiveness assessment, cyber hygiene, access control, and asset management.²⁰

The operational distinction can be summarised as follows.

Customer’s evidence	Customer’s NIS2 path	Manufacturer’s CRA path
A CVE or advisory appears applicable, but no exploitation or security event is observed.	Record, assess, mitigate, engage the supplier, and monitor under Article 21. No Article 23 notification solely on those facts.	Assess product containment, exploitability, remediation, and customer support. No Article 14 report solely because the CVE exists.
Authorised testing demonstrates that the product can be exploited.	Treat the weakness through vulnerability handling, change control, and risk management. The authorised test is not by itself a significant incident.	Evidence of exploitability, but not malicious unauthorised exploitation; Article 14(1) is not triggered solely by the test.
Suspicious activity or an attempted exploit is blocked and no compromise is established.	Investigate as an event, cyber threat, or near miss; apply national and sector-specific criteria. It is not automatically a significant incident under the Directive’s baseline.	Reassess exploitation evidence and the severe-incident path; continue monitoring and remediation.
Malicious exploitation compromises the customer’s deployment, but the effect does not meet the applicable NIS2 significance threshold.	Handle the incident and preserve evidence; an Article 23 report is not mandatory under the EU baseline unless significance or another applicable reporting rule is established.	The customer’s reliable product-specific evidence may cause the manufacturer to reach Article 14 awareness and start its reporting clock.
Malicious exploitation causes or is capable of causing severe operational disruption, financial loss, or considerable material or non-material damage to others.	Assess the applicable EU, national, and sectoral significance criteria and, where met, begin Article 23 reporting without waiting for the manufacturer.	Independently assess Article 14(1) and the severe-product-incident path; report when the manufacturer’s threshold is met.

Table 4: The NIS2 customer process and the CRA manufacturer process use the same evidence but answer different legal questions.

For NIS2, an incident is significant under the Directive where it has caused or is capable of causing severe operational disruption of services or financial loss for the entity, or has affected or is capable of affecting other persons by causing considerable material or non-material damage. More specific thresholds may follow from national transposition, sectoral law, or—for the categories it covers—Commission Implementing Regulation (EU) 2024/2690. The customer must therefore use the criteria applicable to its entity, sector, and Member State rather than borrow the CRA definition of a severe product-security incident.²¹

Once the customer becomes aware of a significant incident, the NIS2 baseline requires:

• an early warning without undue delay and in any event within 24 hours;
• an incident notification without undue delay and in any event within 72 hours;
• an intermediate report when requested by the CSIRT or competent authority; and
• a final report no later than one month after the 72-hour notification, or a progress report at that point and a final report within one month after handling ends if the incident is still ongoing.²²

The NIS2 clock belongs to the customer and does not wait for a CVE, a vendor advisory, root-cause certainty, or the manufacturer’s CRA decision. In parallel, the manufacturer must not wait for the customer’s NIS2 filing or final forensics if the evidence already gives it reasonable certainty under Article 14.

NIS2 may also require customer-facing communication. Where appropriate, the entity must notify recipients of significant incidents likely to affect adversely the provision of its services; it must also communicate without undue delay to recipients potentially affected by a significant cyber threat the measures or remedies they can take and, where appropriate, the threat itself.²³ That communication is about the entity’s services and recipients. It does not replace the manufacturer’s separate Article 14(8) duty to inform impacted product users.

ImportantOne case, two independent notification tests

For a NIS2 customer, the internal case should branch immediately: * NIS2 branch: has an incident occurred in the customer’s network and information systems, and is it significant for the services the customer provides? * CRA evidence branch: does the information show that a vulnerability contained in the manufacturer’s product has been maliciously exploited, or that a severe product-security incident has occurred? The customer owns the first decision. The manufacturer owns the second. Each party should exchange the evidence necessary for the other decision without assuming that one party’s notification discharges the other’s obligation.

A mature NIS2 customer should therefore implement one intake record with two controlled workstreams: operational containment and NIS2 significance assessment on one side; vendor notification and coordinated vulnerability disclosure on the other. The record should preserve separate awareness times, decision owners, recipients, deadlines, evidence releases, and status updates. If the same legal entity is both product manufacturer and NIS2 entity, it must test both roles. The CRA’s “report once” language describes submission of a CRA notification through the SRP; it is not a general rule that one CRA filing automatically fulfils NIS2, GDPR, DORA, sectoral, or national reporting duties. CRA Recital 72 merely encourages Member States to consider national single entry points for complementary regimes.²⁴

Reporting, remediation, and disclosure are separate decisions

A CVE can activate several processes whose triggers and recipients differ.

Process	Core question	Typical recipient or output
Article 14 mandatory notification	Is there an actively exploited vulnerability contained in the product, or a severe incident, of which the manufacturer is aware?	Coordinating CSIRT and ENISA through the SRP.
Article 14(8) user information	Which impacted users—and, where appropriate, all users—need information and deployable mitigation or corrective measures after awareness?	Affected customers and users through proportionate communication.
Vulnerability handling and remediation	Is the product vulnerable, what risk does it create, and how should it be corrected or mitigated?	Product-security, engineering, suppliers, release management, and customers.
Public disclosure of a fixed vulnerability	Once a security update is available under the full CRA regime, what information must be published and when is delay justified?	Public advisory or equivalent disclosure under Annex I, Part II, point (4).
CVE coordination	Should a public vulnerability identifier and record be assigned, updated, disputed, or rejected?	CNA, CVE Programme, suppliers, researchers, and coordinators.
Voluntary Article 15 notification	Would notifying a vulnerability, cyber threat, incident, or near miss support coordination even though the mandatory threshold is not met?	CSIRT designated as coordinator or ENISA.

Table 5: A single technical flaw can enter several processes without satisfying all of their triggers.

Treating those processes as one workflow creates predictable errors. A team may disclose too much while exploitation is active, delay remediation while debating legal reportability, or assume that obtaining a CVE ID has discharged Article 14. It has not.

The minimum decision record

For every potentially relevant CVE, zero-day, advisory, KEV entry, or customer report, the decision record should preserve:

• the signal, source, receipt time, and original evidence;
• the manufacturer entity and product with digital elements being assessed;
• product family, model, release, firmware, configuration, and remote-processing boundary;
• component identity and the evidence connecting it to the product build;
• affected-version analysis, fixes, forks, and backports;
• reachability and practical exploitability reasoning;
• evidence for or against malicious unauthorised exploitation in the product;
• the separate Article 14(5) severe-incident assessment;
• source reliability, corroboration, uncertainty, and unresolved questions;
• the time at which the signal was received;
• the time at which reasonable certainty was reached, if it was reached;
• the decision owner, approver, conclusion, and legal rationale;
• reassessment triggers if the event is not currently reportable; and
• links to remediation, supplier, customer-communication, voluntary-reporting, and authority-notification workstreams.

The conclusion should not be merely CVE not reportable. It should identify the missing or satisfied element:

• component not present;
• affected version not present;
• vulnerability not exploitable in product context;
• no reliable evidence of malicious exploitation;
• exploitation exists elsewhere but not in this product under current guidance;
• evidence insufficient—assessment remains open;
• actively exploited vulnerability established—Article 14(1) triggered; or
• separate severe incident established—Article 14(3) triggered.

When the threshold is met

Once the manufacturer reaches a reasonable degree of certainty, the Article 14 clock is not suspended until a CVE, CVSS vector, patch, or final root cause becomes available. For an actively exploited vulnerability, the manufacturer submits:

• an early warning without undue delay and in any event within 24 hours of awareness;
• a vulnerability notification without undue delay and in any event within 72 hours of awareness; and
• a final report no later than 14 days after a corrective or mitigating measure becomes available.²⁵

The manufacturer must also inform impacted users and, where appropriate, all users under Article 14(8), providing mitigation and corrective measures where necessary. That communication is risk-based and need not indiscriminately publish exploit detail while doing so would increase risk.²⁶

Article 14 applies from 11 September 2026, including to in-scope products placed on the market before the CRA applies generally and, according to the Commission guidance, to unsupported products.²⁷

A practical review checklist

When a CVE enters the organisation, ask:

1. Role: Which legal entity is the manufacturer of the product being assessed?
2. Product: What exact product, version, build, configuration, and remote-processing solution are involved?
3. Containment: Is the vulnerable code or component actually contained in that product state?
4. Applicability: Is the affected implementation and version present, without an equivalent fix or non-affected fork?
5. Exploitability: Can the vulnerability be exercised under practical operational conditions in this product?
6. Exploitation: What reliable evidence shows—or fails to show—malicious use without the system owner’s permission?
7. Product connection: For an integrated component, has exploitation occurred in this product under the current Commission interpretation?
8. Incident: Independently, has a severe product-security incident occurred under Article 14(5)?
9. Awareness: Has the initial assessment reached a reasonable degree of certainty, and at what time?
10. Action: Is the outcome mandatory reporting, continuing assessment, remediation without mandatory reporting, upstream escalation, user communication, voluntary notification, or a combination?

The checklist should be implemented as a decision record, not as an informal conversation between the vulnerability-management team and legal counsel. The 24-hour structure makes later reconstruction of undocumented reasoning a poor control.

The exact answer to the title

A CVE is not an Article 14 report because an identifier does not establish the legal event. The manufacturer’s decision must move through distinct propositions:

Identified does not mean present; present does not mean vulnerable; vulnerable does not mean exploitable; exploitable does not mean maliciously exploited; exploited somewhere does not automatically mean exploited in this product under the current Commission guidance; and none of those propositions starts the reporting clock until the manufacturer reaches the applicable awareness threshold. The reverse chain also matters. A maliciously exploited zero-day or a severe compromise can be reportable before the vulnerability ecosystem has produced an identifier, score, advisory, or patch.

The correct operational response to a CVE is therefore neither report every match nor report only confirmed customer breaches. It is to perform a prompt, product-specific, evidence-based assessment; preserve the reasoning; test both Article 14 triggers; and report as soon as reasonable certainty exists.

NoteImplementation support

Manufacturers and industrial organisations need this logic embedded across PSIRT, engineering, customer support, maintainers, suppliers, SOC, legal, and field operations. Product and component mapping, evidence criteria, case records, decision authority, customer escalation, and tabletop exercises should be designed as one operating process rather than as disconnected compliance documents.

CautionStatus of this guidance

This article explains Regulation (EU) 2024/2847 using European Commission implementation material and technical sources available on 16 August 2026. Commission FAQs and guidance are valuable but non-binding. Competent authorities and courts retain responsibility for authoritative legal interpretation. The article is practical guidance, not legal advice for a specific event.

See also cybersecurity longforms

The December 2025 Cyberattack on Poland’s Energy Sector

A detailed reconstruction of the incident, the malware, and the wider significance for energy and OT security

Cyber Resilience Act: The New Product-Security Baseline

Scope, legal roles, secure design, conformity, reporting, and lifecycle assurance across the digital-product supply chain

When an AI Evaluation Became a Cyber Intrusion

The OpenAI–Hugging Face incident and the two regimes of agentic cyber risk

See also regulation and compliance longforms

Cyber Resilience Act: The New Product-Security Baseline

Scope, legal roles, secure design, conformity, reporting, and lifecycle assurance across the digital-product supply chain

The EU Digital Battery Passport: Who Is Affected, What Must Be Done, and When

A practical guide to product scope, organisational responsibilities, data obligations, and the February 2027 deadline

See also posts

Does the CRA Require Vulnerability Scanning from 11 September 2026? No, but It Does Require a Reporting Decision Process

What manufacturers must have ready for Article 14, what customers can legitimately expect, and how scanners, SBOMs, telemetry, and threat intelligence fit

After the Hugging Face Intrusion: What the New Technical Record Changes

A technical update to the July 2026 reconstruction, based on OpenAI's Black Hat account and subsequent primary disclosures

The Withdrawal of HAWK

How a Galois involution cut the effective key-recovery dimension and ended a NIST post-quantum signature candidate

AI Mathematics Crosses the Systems Boundary

A technical commentary on proof abundance, research agents, and the infrastructure now inside the experiment

When Digital Trust Gets a Deadline

The U.S. 2030 post-quantum cryptography order, enterprise cryptographic debt, and why a federal mandate matters beyond America

When Vulnerability Databases Become Triage Systems

NIST’s NVD update, record CVE growth, and the economics of AI-scaled cyberattacks

Footnotes

1. European Commission. (2026). FAQs on the Cyber Resilience Act implementation, version 1.3, Sections 5.1–5.4. Shaping Europe’s digital future. Official FAQ page

2. CVE Programme. (2026). CVE Record lifecycle and CVE Programme FAQs. A CVE ID uniquely references a specific vulnerability, while the CVE record supplies descriptive and affected-product information for correlation across tools and parties. Official process and official FAQs

3. Forum of Incident Response and Security Teams. (2023–2026). Common Vulnerability Scoring System version 4.0, especially the specification and user guidance distinguishing vulnerability severity from complete risk. Official specification and official user guide

4. Forum of Incident Response and Security Teams. (2026). Exploit Prediction Scoring System. EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days and is not a complete risk or environment-applicability score. Official EPSS page and official FAQ

5. Cybersecurity and Infrastructure Security Agency. Known Exploited Vulnerabilities Catalog. CISA states that entries are added based on evidence of active exploitation. Official catalog

6. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), especially Recital 68, Articles 3(40)–(44), 14–16, 69(3), 71(2), and Annex I, Part II. Official Journal of the European Union. Official text

7. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), especially Recital 68, Articles 3(40)–(44), 14–16, 69(3), 71(2), and Annex I, Part II. Official Journal of the European Union. Official text

8. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.1, points 209–221. European Commission. Official publication

9. European Commission. (2026). FAQs on the Cyber Resilience Act implementation, version 1.3, Sections 5.1–5.4. Shaping Europe’s digital future. Official FAQ page

10. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.1, points 209–221. European Commission. Official publication

11. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.1, points 209–221. European Commission. Official publication

12. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), especially Recital 68, Articles 3(40)–(44), 14–16, 69(3), 71(2), and Annex I, Part II. Official Journal of the European Union. Official text

13. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), especially Recital 68, Articles 3(40)–(44), 14–16, 69(3), 71(2), and Annex I, Part II. Official Journal of the European Union. Official text

14. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), especially Recital 68, Articles 3(40)–(44), 14–16, 69(3), 71(2), and Annex I, Part II. Official Journal of the European Union. Official text

15. European Parliament and Council. (2024). Regulation (EU) 2024/2847 (Cyber Resilience Act), especially Articles 13(17), 15, 19(5), 20(4), 21, 22, and 71(2). Article 13(17) establishes the manufacturer’s single vulnerability contact; Articles 19(5) and 20(4) require importers and distributors to notify the manufacturer when they become aware of a vulnerability; Articles 21 and 22 identify circumstances in which another actor assumes manufacturer obligations; Article 15 provides voluntary reporting; and Article 71(2) sets the different application dates. Official text

16. European Parliament and Council. (2022). Directive (EU) 2022/2555 (NIS2 Directive), Article 12(1). Each Member State must designate a CSIRT as coordinator for coordinated vulnerability disclosure; it acts as a trusted intermediary, assists reporters, coordinates disclosure timelines, and enables anonymous reporting when requested. Official text

17. European Parliament and Council. (2024). Regulation (EU) 2024/2847 (Cyber Resilience Act), especially Articles 13(17), 15, 19(5), 20(4), 21, 22, and 71(2). Article 13(17) establishes the manufacturer’s single vulnerability contact; Articles 19(5) and 20(4) require importers and distributors to notify the manufacturer when they become aware of a vulnerability; Articles 21 and 22 identify circumstances in which another actor assumes manufacturer obligations; Article 15 provides voluntary reporting; and Article 71(2) sets the different application dates. Official text

18. European Commission. (2026). Cyber Resilience Act—Reporting obligations. The Commission describes the CRA Single Reporting Platform, states that manufacturers submit CRA notifications once through the SRP, and states that natural or legal persons can make voluntary notifications. Read together with Regulation (EU) 2024/2847, especially Articles 15–17, Recital 72, and Article 71(2). Official reporting page

19. European Parliament and Council. (2022). Directive (EU) 2022/2555 (NIS2 Directive), especially Articles 6(6), 21, and 23. Article 21 establishes cybersecurity risk-management measures, including vulnerability handling and disclosure; Article 23 limits mandatory notification to significant incidents and establishes the staged notification timetable and relevant recipient communications. Because NIS2 is a directive, organisations must also apply the law and procedures of the Member State having jurisdiction. Official text

20. European Parliament and Council. (2022). Directive (EU) 2022/2555 (NIS2 Directive), especially Articles 6(6), 21, and 23. Article 21 establishes cybersecurity risk-management measures, including vulnerability handling and disclosure; Article 23 limits mandatory notification to significant incidents and establishes the staged notification timetable and relevant recipient communications. Because NIS2 is a directive, organisations must also apply the law and procedures of the Member State having jurisdiction. Official text

21. European Commission. (2024). Commission Implementing Regulation (EU) 2024/2690, establishing technical and methodological requirements and detailed significance criteria for the NIS2 entity categories within its scope. Its criteria should not be applied indiscriminately to NIS2 sectors or entities outside that defined scope. Official text

22. European Parliament and Council. (2022). Directive (EU) 2022/2555 (NIS2 Directive), especially Articles 6(6), 21, and 23. Article 21 establishes cybersecurity risk-management measures, including vulnerability handling and disclosure; Article 23 limits mandatory notification to significant incidents and establishes the staged notification timetable and relevant recipient communications. Because NIS2 is a directive, organisations must also apply the law and procedures of the Member State having jurisdiction. Official text

23. European Parliament and Council. (2022). Directive (EU) 2022/2555 (NIS2 Directive), especially Articles 6(6), 21, and 23. Article 21 establishes cybersecurity risk-management measures, including vulnerability handling and disclosure; Article 23 limits mandatory notification to significant incidents and establishes the staged notification timetable and relevant recipient communications. Because NIS2 is a directive, organisations must also apply the law and procedures of the Member State having jurisdiction. Official text

24. European Commission. (2026). Cyber Resilience Act—Reporting obligations. The Commission describes the CRA Single Reporting Platform, states that manufacturers submit CRA notifications once through the SRP, and states that natural or legal persons can make voluntary notifications. Read together with Regulation (EU) 2024/2847, especially Articles 15–17, Recital 72, and Article 71(2). Official reporting page

25. European Parliament and Council. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), especially Recital 68, Articles 3(40)–(44), 14–16, 69(3), 71(2), and Annex I, Part II. Official Journal of the European Union. Official text

26. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.1, points 209–221. European Commission. Official publication

27. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.1, points 209–221. European Commission. Official publication