CRA Article 14: a technical guide to vulnerability and incident reporting

Analytical brief

Key findings

• CRA Article 14 reporting obligations apply from 11 September 2026, before most other CRA requirements.
• Meeting the 24- and 72-hour deadlines requires product inventory, SBOM, reachability analysis, telemetry, CTI, and decision-making to be connected before an incident occurs.
• A high CVSS score or public PoC does not by itself prove active exploitation, the manufacturer needs reliable evidence and a product-specific impact assessment.

Scope

A technical and operational preparation guide for manufacturers facing the vulnerability and incident reporting obligations established by CRA Article 14.

Limitations

This article is based on the European Commission's non-binding guidance of 27 July 2026 and does not constitute legal advice, authoritative interpretation of EU law rests with the Court of Justice of the European Union.

Technical scenario: when a vulnerability signal becomes a regulatory issue

A manufacturer’s PSIRT receives intelligence that a vulnerability in a third-party component may be under active exploitation. The component appears in three maintained product versions, two older firmware branches, and a cloud-dependent feature used only by some deployments. A public exploit exists, scanning has increased, and one customer has supplied incomplete logs showing unusual child-process execution.

The immediate question is no longer only whether the component must be patched. The manufacturer must determine which product builds contain the vulnerable code, whether the relevant path is reachable and exposed, whether the observed activity is malicious exploitation of its product, and when the available evidence becomes reliable enough to start the CRA Article 14 reporting clock.

That decision connects engineering facts to a legal threshold. A component match may start triage; it does not necessarily establish awareness. Conversely, waiting for a fully confirmed customer compromise may set the threshold too high. The organisation needs a defensible method for assessing product-specific exploitability, evidence quality, and the point at which it has a reasonable degree of certainty. Once that awareness point is reached, the first reporting deadline is no later than 24 hours away.

From 11 September 2026, manufacturers must report actively exploited vulnerabilities contained in products with digital elements and severe incidents affecting the security of those products. Reports are made through the reporting arrangements involving the designated coordinating Computer Security Incident Response Team, ENISA, and the Single Reporting Platform, or SRP.

European Commission guidance is not a legally binding instrument in its own right. It presents the Commission’s interpretation of the CRA and practical application examples, but authoritative interpretation of the legislation may be provided by the Court of Justice of the European Union.

What Article 14 actually requires

Article 14 creates two related reporting tracks. The first concerns a vulnerability contained in a product where the manufacturer has reliable evidence that a malicious actor exploited it without the system owner’s permission. The second concerns a severe incident affecting the security of a product.

Reporting trigger	Technical threshold	Central assessment question
Actively exploited vulnerability	Reliable evidence supports malicious exploitation of a vulnerability contained in the product	Does the evidence concern an exploitable path in this product, rather than the ecosystem only?
Severe incident affecting product security	The event affects or may affect availability, authenticity, integrity or confidentiality, or involves malicious-code introduction or execution	Is the event severe in the context of the product and its users?

A high CVSS score, an available public proof of concept, inclusion in CISA KEV or another exploited-vulnerability catalogue, internet scanning, and threat-actor claims can justify urgent investigation. None automatically proves that the manufacturer’s particular product contains a reachable, maliciously exploited vulnerability. Good-faith security testing performed with authorisation is also different from malicious exploitation.

The reporting periods are prescribed by law and cannot be made distinctive by rewording them. The operational difference lies in the technical evidence that the organisation can produce at each stage.

Reporting phase	Actively exploited vulnerability	Severe incident	Internal evidence expected
Initial warning	Within 24 hours of awareness	Within 24 hours of awareness	Product identity, trigger type, initial geography and contact details
Follow-up notification	Within 72 hours of awareness	Within 72 hours of awareness	Initial scope, impact, mitigations and user actions
Final submission	Within 14 days after a corrective or mitigating measure becomes available	Within one month after the 72-hour notification	Root cause, severity, remediation, residual risk and known threat information

The early warning is not expected to contain a completed investigation. It records the initial verified position while technical work continues. Unknown information should be marked as unknown rather than filled with unsupported assumptions.

Operational timeline from signal to final report

The useful timeline begins with the evidence, not with a generic list of CRA milestones.

Operational point	Regulatory effect	Required internal capability
Signal received	The reporting clock has not necessarily started	Intake, case creation and evidence preservation
Initial assessment	Product relevance and evidence quality are evaluated	PSIRT, CTI and Engineering triage
Reasonable certainty reached	The Article 14 reporting period begins	Formal timestamp and regulatory escalation
Within 24 hours	Early warning must be submitted	Minimum verified information package
Within 72 hours	Expanded notification must be submitted	Product scope, impact, evidence and mitigations
Corrective or mitigating measure available	The final vulnerability-report deadline begins	Patch, workaround and remediation evidence

The first signal and the legal awareness moment are not necessarily the same timestamp. Receipt of an unverified report starts prompt triage. Awareness arises when the initial assessment produces a reasonable degree of certainty that the reporting conditions are met. The assessment cannot be used as an unlimited delay mechanism.

For a severe incident, the final-report period is different: the final submission is due within one month after the 72-hour notification. For an actively exploited vulnerability, the final report is due within 14 days after a corrective or mitigating measure becomes available.

Awareness and reasonable degree of certainty

The Commission guidance connects awareness to the result of an initial assessment. A manufacturer is considered aware when it has a reasonable degree of certainty that a vulnerability in its product is being actively exploited or that a severe incident affecting the product’s security has occurred.

Reasonable certainty is neither the first rumour nor absolute forensic proof. It is a decision supported by evidence of sufficient quality and relevance. The assessment should record what was known, which product configurations were evaluated, which alternative explanations remained, who made the decision, and why the threshold was or was not reached.

Decision timestamp	Evidence represented
signal_received_at	First external or internal indication preserved in the case record
triage_started_at	Initial assessment assigned and begun
product_relevance_at	Affected component, version or incident linked to an in-scope product
exploitability_assessed_at	Reachability, exposure and exploitation prerequisites evaluated
reasonable_certainty_at	Evidence threshold reached and rationale approved
article14_clock_started_at	Reporting clock formally recorded; normally aligned with reasonable certainty
early_warning_submitted_at	24-hour submission completed
notification_submitted_at	72-hour submission completed
mitigation_available_at	Corrective or mitigating measure made available
final_report_submitted_at	Applicable final report completed
users_notified_at	Affected users, and where appropriate a broader group of users, informed

The record should preserve the evidence available at each point, not merely the final conclusion. A later discovery does not change what the organisation reasonably knew earlier, but it may require an update to the report and the user communication.

Product-specific exploitability

An SBOM establishes component presence. It does not establish regulatory reportability.

Article 14 analysis also needs the affected product versions, component reachability, runtime exposure, enabled functionality, exploitation prerequisites, product-specific malicious-exploitation evidence, compensating controls, and the awareness timestamp. Article 14 readiness depends on whether the organisation can correlate a vulnerability with affected builds, deployed variants, remote-processing dependencies, supported versions, customer populations and exploitation evidence within a few hours.

Layer	Technical question	Example evidence
Dependency	Is the affected component present?	SBOM, package manifest, firmware inventory
Version	Is the affected version used?	Lock file, build metadata, image digest
Reachability	Can the vulnerable function be reached?	Call graph, code analysis, runtime tracing
Exposure	Can an attacker access the vulnerable interface?	Network mapping, API exposure, protocol configuration
Preconditions	Are the required privileges or states present?	Authentication model, feature flags, deployment settings
Exploitation	Is there evidence of malicious use?	Telemetry, logs, forensic artefacts, customer reports
Impact	Did exploitation affect security properties?	CIA impact, code execution, persistence or lateral movement
Mitigation	Is exploitation effectively blocked?	WAF rules, ACL, disabled feature, sandboxing or patch

The result should identify the evaluated build, configuration and deployment model. A conclusion derived from a cloud-enabled enterprise version may not apply to an offline firmware branch, and the reverse is equally true.

Third-party components

Third-party component analysis must distinguish several states that are often collapsed into one alert: component presence, vulnerable-version presence, code reachability, runtime exposure, exploit prerequisites, successful exploitation, exploitation in another vendor’s product, and exploitation in the manufacturer’s own product.

A vulnerability affecting a component somewhere in the ecosystem is not automatically an actively exploited vulnerability contained in every downstream product.

A component can be present but compiled without the affected feature. The vulnerable version can be installed while its code path remains unreachable. A reachable function can still require privileges, protocol states or deployment options that are absent. Exploitation against another product may establish ecosystem activity without proving malicious use against the manufacturer’s implementation.

The assessment should therefore answer two separate questions. First, is the vulnerability contained in the downstream product in a technically meaningful sense? Second, does reliable evidence support malicious exploitation relevant to that product or configuration? A negative Article 14 decision does not eliminate other duties. The manufacturer may still have to handle the vulnerability, preserve evidence, inform the component manufacturer or maintainer upstream where applicable, provide remediation, and continue monitoring for changed exploitation evidence.

CTI evidence model

CTI connects ecosystem reporting to product context. Vulnerability management can identify a vulnerable package and patch status; CTI, SOC and incident evidence help establish whether malicious exploitation is occurring and how strongly it relates to the manufacturer’s product.

Source	What it can prove	What it cannot prove	Suggested confidence
Product telemetry	Product-specific exploitation or abnormal execution	Whether other deployments are affected	High
Customer incident evidence	Real exploitation in a deployed environment	Full campaign scale	High
Security researcher report	Technical exploitability and affected code path	Malicious exploitation in the wild	Medium
Authoritative exploited-vulnerability catalogue	Confirmed exploitation of a vulnerability in the wider ecosystem	Exploitation of the manufacturer’s specific product	Medium
Honeypot or internet telemetry	Scanning or exploitation attempts	Successful compromise	Low to Medium
Malware analysis	Use of the vulnerability in an attack chain	Whether the manufacturer’s product was targeted	Medium
Internal SOC data	Attack chain, IOCs and post-exploitation behaviour	Customer-side activity outside available telemetry	High
Dark-web or forum reporting	Threat-actor interest or claimed exploit availability	Successful or product-specific exploitation	Low

Suggested confidence is a starting point, not a fixed rating. Source authenticity, collection method, corroboration, timing and product relevance can raise or lower it. CISA KEV and similar catalogues are authoritative signals of wider exploitation, but they do not automatically establish that every downstream product containing the component is reportable. A PoC proves technical possibility; scanning shows interest or attempts; a forum claim may show intent. Each still requires product-impact analysis.

Evidence should be correlated rather than counted mechanically. Three sources repeating the same vendor statement are not three independent confirmations. One well-preserved customer forensic record tied to the affected build may be more probative than many derivative threat-feed entries.

Article 14 evidence states

An internal evidence-state model makes the awareness decision reproducible without pretending to replace the CRA test.

Assessment state	Evidence threshold	Article 14 implication
Unsubstantiated	One unverified external signal	The clock does not necessarily start, but triage must begin
Technically plausible	A credible exploit path and an affected build are identified	Immediate product-impact assessment
Product-relevant	Exploitation is technically applicable to a deployed product configuration	PSIRT and Legal escalation
Reasonably certain	Reliable telemetry, forensic evidence or several independent sources support active exploitation	Awareness timestamp and Article 14 reporting clock
Confirmed impact	Successful compromise or user impact is confirmed	Reporting, remediation and user notification

This is an internal decision-support method, not an official CRA classification. The threshold remains the Regulation’s reporting condition as interpreted in the applicable legal context. Organisations should define who may move a case between states and what minimum evidence must be attached to that decision.

Reporting information package

The information package should grow with the reporting phase. The 24-hour warning requires a small verified core; the 72-hour notification adds technical scope and mitigations; the final report records root cause, remediation and residual risk.

Evidence group	Information to preserve	Primary reporting use
Product identity	Product name, model, version, build, firmware, SKU and support state	All phases
Market and deployment	EU markets, distribution, deployment model, remote-processing dependencies and affected user populations	Early warning and scope
Component context	Supplier, package, version, purl or CPE, image digest, SBOM reference and affected code path	Product-impact assessment
Exploitability	Reachability, exposure, prerequisites, enabled functionality and compensating controls	Awareness decision and 72-hour report
Exploitation evidence	Source, first-seen time, telemetry, IOCs, TTPs, forensic artefacts, confidence and corroboration	Trigger assessment and final report
Incident impact	Availability, authenticity, integrity, confidentiality and malicious-code execution	Severe-incident assessment
Remediation	Workaround, configuration change, patch, containment, eradication and residual risk	User notification and final report
Governance	Decision log, named owners, legal assessment, awareness timestamp, submissions and preserved report copies	Audit trail and deadline control

Once awareness exists, affected users must be informed and, where appropriate, a broader group of users must receive information that enables them to mitigate the consequences. Depending on the risk, that can include affected versions, patch or workaround details, secure configuration, signs of exploitation, and recommended response actions. Sensitive exploit detail should be disclosed proportionately where premature publication would increase risk.

Article 14 decision tree

flowchart TD
    A[Signal received] --> B{Connected to an in-scope product?}
    B -- No --> Z[Record rationale and close or monitor]
    B -- Yes --> C{Vulnerability or incident?}

    C -- Vulnerability --> D{Vulnerability contained in the product?}
    D -- No --> Z
    D -- Yes --> E{Vulnerable path reachable?}
    E -- No --> Y[Record technical rationale and monitor]
    E -- Yes --> F{Reliable evidence of malicious exploitation?}
    F -- No --> Y
    F -- Yes --> G{Reasonable degree of certainty reached?}
    G -- No --> X[Continue urgent evidence collection]
    X --> G

    C -- Incident --> H{Availability, authenticity, integrity or confidentiality affected or potentially affected?}
    H -- Yes --> J{Reasonable degree of certainty that the incident is severe?}
    H -- No --> I{Malicious code introduced or executed?}
    I -- No --> Y
    I -- Yes --> J
    J -- No --> X

    G -- Yes --> K[Start 24-hour reporting workflow]
    J -- Yes --> K
    K --> L[Submit 72-hour notification]
    L --> M{Reporting track?}
    M -- Vulnerability --> N[Final report within 14 days after a corrective or mitigating measure is available]
    M -- Severe incident --> O[Final report within one month after the 72-hour notification]
    N --> P[Notify affected users where required]
    O --> P

The tree standardises the technical sequence; it does not replace product classification or legal assessment. A case can return to evidence collection as new telemetry, customer reports or engineering findings change the assessment.

Internal operating model and Article 14 Coordinator

Article 14 is a cross-functional process. PSIRT owns vulnerability coordination; CTI assesses exploitation; SOC preserves incident evidence; Engineering establishes code-level applicability; Product supplies version and market context; Legal assesses the reporting obligation; and customer-facing functions execute user communication.

Function	Article 14 responsibility
PSIRT / Product Security	Intake, technical coordination, product-impact decision, remediation and advisory
CTI	Exploitation assessment, source reliability, campaigns, TTPs, IOCs and evidence confidence
SOC / CSIRT	Detection, telemetry, forensic artefacts, incident scope and containment
Engineering	Component analysis, reachability, exposure, prerequisites, patch and workaround
Product Management	Product variants, deployment models, markets, customer populations and support state
Legal / Compliance	CRA scope, awareness threshold, reporting obligation, disclosure and user-notification review
Article 14 Coordinator	Regulatory workflow, reporting timeline, ENISA/SRP coordination, evidence package, follow-up submissions and audit trail
Customer Support / Response	Identification of affected users and controlled delivery of mitigation information

The Article 14 Coordinator is accountable for keeping the regulatory workflow executable. The role confirms the timeline, coordinates SRP submission, preserves the final evidence package and submitted reports, tracks follow-up and final deadlines, and maintains the audit trail. It does not replace Legal’s interpretation or Engineering’s technical conclusion.

Activity	PSIRT	CTI	SOC	Engineering	Legal	Article 14 Coordinator
Determine product exposure	A	C	C	R	I	I
Assess exploitation evidence	C	A/R	R	C	I	I
Establish awareness timestamp	R	C	C	C	A	R
Submit 24-hour warning	C	I	I	I	A	R
Submit 72-hour notification	R	C	C	C	A	R
Submit final report	R	C	C	C	A	R
Notify affected users	R	C	I	C	A	R

In the matrix, R means Responsible, A Accountable, C Consulted and I Informed. A smaller organisation may assign several functions to the same person, but the decisions and hand-offs should remain explicit.

The operating workflow should be organised around four evidence gates.

Gate 1 – Product relevance

The organisation confirms the affected product, version, component and deployment model. The case record identifies whether the signal concerns a maintained build, an older firmware branch, a remote-processing dependency or a third-party service.

Gate 2 – Technical exploitability

Engineering and Product Security establish component and vulnerable-version presence, reachability, runtime exposure, enabled functionality, exploit prerequisites and the effect of compensating controls. The conclusion is tied to specific builds and configurations.

Gate 3 – Active exploitation evidence

CTI and SOC assess whether reliable evidence supports malicious exploitation. They preserve source provenance, distinguish attempts from successful exploitation, test whether apparently independent reports share one origin, and link observed behaviour to the affected product path.

Gate 4 – Regulatory awareness

PSIRT, Legal and the Article 14 Coordinator determine whether reasonable certainty has been reached. They record the decision, evidence, responsible persons and awareness timestamp. If the threshold is met, the coordinator starts deadline tracking immediately.

The 24-hour action is to submit the minimum verified warning while the investigation continues. The 72-hour action expands product scope, impact, mitigation, exploitation context and recommended user actions. The applicable final report then records root cause, severity, remediation, residual risk and known threat information. Every submission and material update should be retained with its timestamp and approver.

Remote data processing and cloud dependencies

Products with digital elements can include standalone software, mobile and desktop applications, browser extensions, devices, embedded firmware and separately marketed hardware components. An informational website or a browser-only web application operating on a remote server is not automatically a product with digital elements merely because users access it digitally.

The assessment changes where remote processing supports a product function and was designed and developed by the manufacturer, or under its responsibility. Such a remote data processing solution, or RDPS, can form part of the product. Relevant functions can include identity and access management, device commands, configuration or file synchronisation, and automated functional or security updates. The processing can operate in a public cloud, private cloud or the manufacturer’s own environment.

Solution or service	Product-context assessment
Mobile or desktop application	Generally a product with digital elements when supplied for execution in the user’s environment
Browser extension	Can be a product with digital elements
Informational website	Generally not a product with digital elements
Browser-only remote web application	Generally not a product by itself
Manufacturer backend required for a device	May be an RDPS forming part of the product
Manufacturer application hosted on IaaS or PaaS	The manufacturer’s application may be an RDPS even though infrastructure is supplied by a third party
Complete third-party SaaS	Generally not the manufacturer’s RDPS, but remains a dependency requiring risk assessment
Analytics service not required for product use	Generally not an RDPS when it is not necessary for a product function

Article 14 implication: a vulnerability in manufacturer-designed remote processing may be reportable when that processing forms part of the product and is required for one of its functions. For IaaS and PaaS, the manufacturer can remain responsible for the security of its own application. A complete third-party SaaS is generally treated differently, but incidents and vulnerabilities in that dependency still require assessment for downstream product effects.

FOSS and downstream responsibility

The CRA distinguishes an individual contributor, a project maintainer, a manufacturer placing a product on the market in the course of commercial activity, and an open-source software steward. Commit access or an accepted pull request does not by itself make a contributor responsible for the entire project.

FOSS role or activity	Relevant distinction
Individual contribution or pull request	Generally does not create responsibility for the entire project
FOSS supplied free of charge without monetisation	Generally outside commercial placing on the market
Voluntary donations not required for access	Do not necessarily make the supply commercial
Security fixes or versions available only to paying users	May amount to paid supply
Paid enterprise distribution	The commercial product version may fall within the CRA
Consulting sold separately from a freely available project	Consulting alone does not necessarily make the FOSS a commercial product
Legal entity systematically supporting FOSS for commercial use	May qualify as an open-source software steward, depending on its actual role

A steward providing only non-technical support is treated differently from one supplying engineering resources and directly participating in development. The exact reporting responsibility follows the actor’s role and activities rather than its label.

Article 14 implication: a manufacturer integrating an open-source component remains responsible for assessing whether active exploitation is contained in its downstream product. Upstream exploitation evidence can trigger urgent triage, but downstream reportability still depends on product context and the Article 14 conditions.

Existing products and support periods

Article 69(3) separates Article 14 from the broader transitional treatment of existing products. A product may remain outside most retrospective CRA product requirements and still remain inside the Article 14 reporting perimeter.

Article 14 applies from 11 September 2026 to in-scope products, including products placed on the market before the CRA’s full application on 11 December 2027. The assessment therefore needs reliable placing-on-the-market, version and deployment records for products already in customer environments.

The support period determines how long the manufacturer handles vulnerabilities effectively and must reflect reasonably expected use time, intended purpose, user expectations, dependencies and market practice. It is generally at least five years unless the product is reasonably expected to be used for a shorter period; a product expected to remain in use longer may require a longer support period. The end date must be disclosed at purchase, and users should be informed of end of support where technically feasible.

Reporting obligations may continue after the declared support period has ended, even when vulnerability-handling obligations no longer apply in the same way.

Article 14 implication: the end of vulnerability-handling support does not automatically remove Article 14 reporting obligations. Product ownership, version mapping, historical SBOMs, customer scope and an operational reporting contact may therefore need to remain available after routine patch support ends.

Substantial modifications and product versions

Not every change places a product on the market again. A bug fix or security patch that does not alter intended purpose and does not significantly affect the cybersecurity risk profile is not necessarily a substantial modification. A new remote-administration function, authentication model, exposed protocol or fundamental purpose can change that assessment.

Change	Product-version assessment
Minor bug fix	Generally not a substantial modification
Security patch removing a vulnerability	Generally not a substantial modification
Feature without a significant attack-surface change	Requires case-specific assessment
New remote-administration module	May be a substantial modification
Change to authentication or trust boundaries	May significantly change the cybersecurity risk profile
New external API or protocol	May create a materially different attack path
Fundamental change to intended purpose	Likely to require treatment as a substantially modified product

Where a software version is substantially modified and placed on the market, it may be treated as a new product, with a new conformity assessment and support-period decision where applicable.

Article 14 implication: product version and placing-on-the-market records affect which configuration must be assessed and reported. The evidence package must distinguish the affected version from earlier or later branches with different code, exposure and legal status.

Technical readiness model

Article 14 readiness is a data-correlation and evidence problem. The question is not whether individual controls exist, but whether they produce one defensible Article 14 decision quickly enough to support reporting and user protection.

Capability domain	Question the organisation must answer	Primary evidence
Product observability	Which versions, variants and deployments are affected?	Product inventory, SBOM, build records and dependency mapping
Exploitation intelligence	Is the vulnerability actively used against this product or configuration?	CTI, product telemetry, customer reports and forensic artefacts
Regulatory decisioning	When did the organisation reach a reasonable degree of certainty?	Decision log, evidence register, legal assessment and timestamps
Response execution	Can the organisation report, mitigate and notify users within the required time?	Reporting templates, SRP access, advisory workflow and patch process

These domains should be exercised together. A useful simulation starts with a realistic third-party signal and asks the team to identify affected builds, prove or reject reachability, assess exploitation evidence, establish the awareness timestamp, assemble the early warning, identify affected users and preserve the decision record. The result should expose missing correlations and unclear authority, not merely confirm that each team owns a tool.

Operational measures should follow the evidence gates: time to begin triage, time to determine product relevance, time to complete exploitability assessment, time to establish the awareness decision, time to identify affected users, submission timeliness, and the proportion of decisions with complete supporting records. These measures show where the 24- or 72-hour process would fail.

Conclusion

CRA Article 14 turns a vulnerability signal into a product-specific evidence decision. The manufacturer must connect component and build data, reachability, runtime exposure, exploitation evidence, incident impact, customer scope and legal assessment without confusing ecosystem activity with proof about its own product.

The critical timestamp is the point at which the initial assessment supports a reasonable degree of certainty. Reaching it requires neither waiting for perfect attribution nor treating every public exploit as a reportable event. It requires a traceable technical rationale based on the affected product and reliable evidence.

From 11 September 2026, that rationale must lead into an executable reporting process: the 24-hour early warning, the 72-hour notification, the appropriate final report, remediation and proportionate user communication. The strongest preparation is therefore not a standalone compliance document. It is an operating model in which PSIRT, CTI, SOC, Engineering, Product, Legal and the Article 14 Coordinator can produce and defend one decision.

Sources

1. European Commission, Commission guidance on the application of Regulation (EU) 2024/2847 – Cyber Resilience Act, C(2026) 5252 final, 27 July 2026
2. Regulation (EU) 2024/2847 of the European Parliament and of the Council – Cyber Resilience Act