Treating Article 14 reporting as a standalone obligation is the most expensive way to comply with it. A manufacturer that builds a reporting capability in isolation, with no connection to how it develops products, tracks components, handles vulnerabilities, or manages risk, ends up with a process that only activates in a crisis and is brittle when it does.
The organisations that handle the CRA well take the opposite view. For them, an Article 14 report is the visible output of a programme that is already working. The detection that catches an exploited vulnerability, the inventory that identifies affected versions, the process that produces a fix, and the records that evidence it all exist because the manufacturer manages product security continuously. Reporting becomes a byproduct of good governance.
This closing post in our CRA reporting series shows how to make those connections. It builds on the earlier posts covering when reporting becomes mandatory, what must be reported, where reports go, the timelines, and internal detection and escalation. For a single-page overview of the whole reporting regime, see our guide to which CRA reporting obligations apply, when they start, and how to be ready.
Reporting sits on top of vulnerability handling
Article 14 reporting cannot function without Article 13 handling underneath it. The two are designed as a pair, and the dependency runs in one direction: handling feeds reporting.
Article 13 requires manufacturers to identify and document vulnerabilities, address them without delay through security updates, apply coordinated vulnerability disclosure, and provide a contact channel for reports. Every one of these capabilities is what makes a report possible. The disclosure channel is often where awareness of exploitation first forms. The remediation process is what produces the corrective measure that the final report describes. The disclosure coordination is what turns a resolved vulnerability into a public advisory.
A manufacturer that has a solid handling programme already possesses most of what reporting needs. One that has only built a reporting form has the visible tip with no machinery behind it. We set out what a handling programme involves in our guide to CRA vulnerability handling.
SBOM: knowing what is affected
When an exploited vulnerability appears, the first operational question is concrete: which of our products, in which versions, contain the affected component? An organisation that cannot answer this quickly cannot scope its report accurately or notify the right users.
This is where a software bill of materials earns its place. An SBOM is an inventory of the components in a product. Maintained well, it lets a manufacturer move from "there is an exploited flaw in library X" to "these three product lines, in these version ranges, ship that library" in minutes rather than days.
That capability serves reporting directly. The detailed notification has to identify affected products and versions. The user-notification duty depends on knowing who is exposed. And the same inventory drives the routine handling case, where a newly disclosed component vulnerability has to be assessed for reachability and impact. We made the broader argument for treating the SBOM as foundational in SBOM as a security foundation.
Secure development reduces what you ever have to report
The cheapest Article 14 report is the one you never have to file. Reporting volume is downstream of product quality, and product quality is downstream of how the product was built.
The CRA's essential requirements push manufacturers toward security by design across the development lifecycle: threat modelling, secure defaults, minimised attack surface, and disciplined handling of dependencies. A development process that bakes these in produces fewer exploitable vulnerabilities, which means fewer events that can ever reach the active-exploitation threshold. We covered this in security by design across product development.
The link to reporting is straightforward. Secure development lowers the rate at which reportable events occur. A manufacturer cannot eliminate them, but it can ensure that an Article 14 report is a rare, serious event rather than a recurring symptom of a weak build process. Reporting maturity and development maturity move together.
Post-market surveillance closes the loop
The CRA does not treat a product as finished when it ships. Manufacturers carry obligations across the support period: monitoring for vulnerabilities, providing security updates, and watching how the product behaves in the field. This post-market surveillance is the connective tissue between a single reported event and continuous risk management.
The loop works like this. Detection in the field surfaces a vulnerability or incident. Handling assesses and remediates it. Where it crosses the threshold, reporting notifies authorities and users. The lessons feed back into development and into the risk picture for the product line. The next iteration is more resilient, and the surveillance that caught this event is tuned by what it taught.
Seen this way, an Article 14 report is one observable point in a continuous cycle. The manufacturers who report well are running this loop deliberately, with the same telemetry, inventory, and processes serving detection, handling, reporting, and improvement.
The shared backbone: records and audit trail
Running across all of this is one capability that every part depends on: a reliable record of what happened and when. Vulnerability handling needs it to show issues were addressed without delay. Reporting needs it to evidence that deadlines ran from a defined moment of awareness and that each stage was filed. Risk management needs it to see patterns across events. Market surveillance authorities will ask for it.
A single, append-only audit trail that captures every report received, every triage decision, every escalation, and every notification sent is what ties the programme together and makes it defensible. It is also what protects the individuals who made good-faith decisions under pressure, because a documented decision is a defensible one.
How CVD Portal connects the pieces
CVD Portal is designed to make reporting a byproduct of the rest of the programme rather than a separate silo. The branded disclosure portal is the Article 13 intake channel. The triage workflow handles routine vulnerabilities and flags the rare reportable ones, so handling and reporting share one pipeline. Submissions carry product and version context, which feeds accurate scoping for notifications and for user communication. Report generation aligns to the Article 14 stages, and CSAF 2.0 advisory output supports coordinated public disclosure. Underneath everything sits a complete, immutable audit trail that serves handling, reporting, and surveillance at once. The platform is free to start, so the barrier to running this loop properly is low.
A readiness checklist
To judge whether your reporting is genuinely integrated with product and risk management, rather than bolted on, check that:
- The disclosure channel that triggers reporting is the same one that drives routine handling.
- You can identify affected products and versions from a maintained component inventory in minutes.
- Secure-development practices are reducing the rate of exploitable vulnerabilities over time.
- Post-market surveillance feeds field signals back into handling and development.
- A single audit trail evidences the full lifecycle of every event.
- Reporting is rare because the programme underneath it is healthy, not because the threshold is being ignored.
The bottom line
Article 14 reporting works when it is the visible output of a functioning product security programme. It depends on Article 13 handling beneath it, on an SBOM to scope impact, on secure development to keep reportable events rare, on post-market surveillance to close the loop, and on a shared audit trail to evidence the whole thing. Built that way, filing a report is a natural step in a process you already run, not an emergency improvisation.
That is the throughline of this series. Reporting is not a form you fill in when disaster strikes. It is what good product security looks like when it becomes visible to authorities and users. Manufacturers who internalise that will find the September 2026 deadline is a readiness checkpoint for a programme they should be running anyway.