The reporting timeline: What the CRA demands

When a manufacturer becomes aware of an exploitable vulnerability in a product subject to the CRA, the compliance sequence is unambiguous.

• 24 hours: Initial notification to the EU Vulnerability Database is required
• 72 hours: Confirmation of the ability to provide full notification must be submitted
• 14 days: A comprehensive report covering the vulnerability, its scope, and remediation status is due

Twenty-four hours from awareness to initial notification. Not twenty-four hours from remediation, not twenty-four hours from a final root-cause analysis, but twenty-four hours from the moment you know the vulnerability exists and is exploitable. The implication is clear: Any manual process in your vulnerability management workflow that cannot complete within that window is a compliance risk. Any gap in your component visibility that could delay awareness of a newly disclosed vulnerability is a compliance risk. Any ambiguity about who in your organization is responsible for initiating the notification process is a compliance risk.

The urgency embedded in these timelines is not arbitrary regulatory overreach. It reflects a documented and accelerating reality in the threat landscape. In 2018, the average time from vulnerability discovery to active exploitation was approximately two years. By 2026, that window has collapsed to 20 hours. Current forecasts project that by 2028, it will reach one minute. The CRA’s reporting structure is calibrated to this reality, and it demands that your operational processes be calibrated to it as well.

The notification infrastructure

Meeting a 24-hour notification requirement reliably requires automation. There is no manual workflow that scales to the volume of CVE disclosures in a modern software supply chain, executes within a 24-hour window consistently, and handles the cross-referencing of new disclosures against your full product portfolio. Organizations that attempt to operate CRA vulnerability reporting on manual processes will find themselves structurally unable to comply once volume and velocity increase.

The automation architecture you need has three functional components working in tight integration.

• Continuous monitoring: This means active surveillance of the EU Vulnerability Database, the U.S. NVD, and other authoritative vulnerability feeds (including Black Duck^® Security Advisories), with update cycles measured in hours, not days. An SLA of under 24 hours for every application means that knowing whether a product is impacted by a new CVE must be an automated determination, not a manual triage exercise.
• Comprehensive component inventory: Your SBOM capabilities need to cover every component in every product, because a vulnerability in a component you’re not tracking is one you won’t detect in time.
• Automated workflows: Systems must be able to cross-reference a newly disclosed vulnerability against your product portfolio, identify affected products, initiate the reporting sequence, and route the process through your defined response chain, all within the compliance window.

The “single point of contact” obligation

Parallel to the outbound reporting requirement is an inbound one. CRA Annex 1, Part 2 requires manufacturers to provide a single point of contact specifically for receiving vulnerability reports. Security researchers, customers, supply chain partners, and other parties who discover vulnerabilities in your products need a clearly designated, publicly accessible channel to report them. This is a legal obligation, not a best practice, and it must be prominently displayed and operational before September 2026.

By law, the manufacturer needs to have the ability to receive and handle vulnerability reports within a certain reasonable timeframe. That means your single point of contact isn’t just a disclosure form or an email address; it’s a process. Someone owns it, monitors it, triages incoming reports, and initiates your defined response sequence when a valid report arrives. The documentation of that process—ownership, escalation paths, response SLAs—belongs in your CRA compliance record alongside your SBOM artifacts and security testing reports.

Support periods: The life cycle obligation you define

One of the CRA’s most consequential requirements is also one of its most operationally nuanced: Manufacturers must define, declare, and honor a support period for every product they place on the EU market. During that declared support period, every CRA vulnerability handling obligation applies in full. According to Angelo D’Amato, rapporteur for two of the three horizontal CRA standards (the standards that apply across product categories), the stakes are explicit: “During the support period, you need to fix the vulnerability. If you’re not fixing the vulnerability during the support period, you will be fined or the product will be recalled.”

Defining your support period

The regulation deliberately gives manufacturers flexibility in determining appropriate support periods, but it doesn’t leave the decision entirely unconstrained. “Nobody a priori knows what the reasonable support time for some components will be,” D’Amato acknowledged. “You, as a manufacturer, do this analysis. There will be market surveillance that will compare your product with other products as state of the art, and they will check if there are discrepancies.”

The key principle is alignment with intended use. A consumer IoT device with an expected life cycle of three to five years demands a support period calibrated to that reality. An industrial control system deployed in critical infrastructure and expected to run for 15 years demands something very different. The standard isn’t what’s convenient for your product roadmap, it’s what’s appropriate given how your product is actually used in the market.

The practical guidance is: Analyze your product’s intended use case, survey comparable products in your market segment to understand state-of-the-art expectations, document your analysis with specificity, and then declare a support period you can actually honor. The documentation discipline matters as much as the decision itself. “Apply due diligence and make sure [you] document this due diligence while defining parameters like the support period for a specific market and industry,” D’Amato said. That documented rationale is your defense if market surveillance authorities question your determination.

Products no longer being actively developed but that are still within their support period are considered in maintenance mode. Reduced development investment doesn’t reduce compliance obligations—the vulnerability management obligations remain fully in force through the declared support period. Budget your maintenance mode operations accordingly.

What happens after the support period ends

The CRA creates a defined cliff at the end of a product’s declared support period. Once the declared period ends, manufacturers can continue maintaining and supporting the product voluntarily, but they’re no longer legally required to fix newly discovered vulnerabilities.

This structure has strategic implications for portfolio management. Products in or approaching end-of-support status need clear life cycle communication to customers, so they can make informed decisions about continued use, upgrade timelines, and risk acceptance. The declaration of support period end helps ensure customers understand that they cannot assume ongoing protection. It’s a transparency obligation, and the communication around it needs to be as deliberate as the initial declaration.

The open source collaboration mandate: Article 13’s transformative requirement

The CRA introduces a vulnerability remediation obligation that breaks new ground: Manufacturers that discover vulnerabilities in upstream open source components that their products depend on are required to collaborate with those open source communities to fix the vulnerability at the source.

“One of the obligations in Article 13 is that if [manufacturers] have a vulnerability upstream in open source, they should collaborate to fix it,” explained D’Amato. “This creates a partnership between open source [projects] and manufacturers.” This is not the same as patching the vulnerability in your own product and moving on. It requires you to engage with the upstream project: Contributing the fix, reporting the issue through the project’s disclosure process, and participating in the remediation at the community level.

Why this changes your open source relationships

Most manufacturers currently consume open source passively. They identify the components they need, integrate them, monitor for known vulnerabilities, and apply patches to their own products when fixes become available. CRA Article 13 forces a shift from passive consumer to active participant. You need to know not just which open source components you depend on, but who maintains them, what their disclosure and contribution processes look like, and how to engage effectively when you have a vulnerability to report or a fix to contribute.

“Organizations truly need to have a good understanding of the open source they depend upon,” said D’Amato. “If there is something discovered, they need to know who to work with.”

The asymmetry here is important: The upstream open source maintainer has no visibility into your use of their component. You are the party with full context about the vulnerability’s impact on your product and your customers. Article 13 puts the burden of initiating the collaboration where it belongs—with the manufacturer that discovered the exploitable condition.

Building your open source engagement capability

Meeting the Article 13 obligation requires operational infrastructure that goes beyond vulnerability scanning. You need a clear picture of the upstream open source project’s health, governance, and contribution process for every significant open source dependency. You need a defined internal workflow for initiating upstream disclosures and coordinating your contributions through that process. And you need to document your collaboration activities in a way that demonstrates compliance if you’re ever subject to market surveillance scrutiny.

This is also a concrete prompt to engage with the open source communities you depend on—not reactively, when a vulnerability surfaces—but proactively. Manufacturers that have established relationships with the maintainers of their key upstream dependencies are in a fundamentally better position when Article 13 obligations activate than those who are discovering those maintainers’ names and processes for the first time in the middle of a vulnerability response.

The necessary integration: Reporting, support periods, and collaboration

Individually, CRA’s vulnerability reporting obligations, support period requirements, and Article 13 collaboration mandate each demand meaningful operational investment. Together, they define the shape of a mature, CRA-compliant vulnerability management program—one that operates continuously, documents everything, and treats the open source ecosystem as a partner rather than a dependency to be monitored at arm’s length.

The necessary integration architecture includes

• A continuous monitoring pipeline that ingests vulnerability disclosures from EU and global sources within hours, matches them against your component inventory, and automatically identifies affected products and initiates your response workflow. Point-in-time scanning is not compatible with 24-hour notification requirements.
• An SBOM infrastructure that gives you the component-level visibility required to detect and triage vulnerabilities across your full product portfolio, including embedded systems, firmware, containerized deployments, and supplier-provided components.
• Defined support period policies for every product, documented with explicit rationale tied to intended use, market context, and state-of-the-art analysis. These policies need to be registered in your compliance documentation and communicated clearly to customers and downstream supply chain partners.
• An open source engagement program with documented workflows for upstream disclosure, contribution, and collaboration—activated by Article 13 obligations and supported by ongoing relationship-building with the maintainer communities of your key dependencies.
• A single point of contact mechanism for inbound vulnerability reports, with defined ownership, monitoring cadence, triage process, and response SLAs documented as part of your CRA compliance record.

What to do now: Your immediate action priorities

September 2026’s reporting obligations are looming. The infrastructure you operate on that date is the infrastructure you’ll rely on when the first exploitable vulnerability surfaces in a product you’ve shipped into the EU market. That’s not a hypothetical. It’s a near-term certainty in any active software supply chain.

Your immediate priorities should be

• Establish your vulnerability intake mechanism—your single point of contact—now. Define ownership, publish the channel, document the process, and make sure it is operational before September 11, 2026.
• Define support periods for your in-market product portfolio with documented rationale. Every product subject to the CRA needs a declared support period before you can effectively manage your compliance obligations under it.
• Audit your vulnerability monitoring infrastructure for speed and coverage. If your current SLA for detecting new CVEs in products you’re actively shipping is measured in days rather than hours, you have a structural compliance gap to close before reporting obligations activate.
• Begin mapping your open source community relationships for each significant upstream dependency. Identify the open source project’s disclosure and contribution process. Establish the internal workflow you’ll use to engage those communities when Article 13 obligations arise.
• Automate your notification workflows—the 24-hour clock makes manual processes untenable at production scale. Design and test your automated notification pipeline before you need it.

The manufacturers that approach these obligations as operational infrastructure investments—not compliance checkboxes to satisfy once at deadline—are the ones that will meet the CRA’s requirements at speed and scale. Security can no longer be an afterthought in a world where vulnerabilities are exploited in hours, not months. The reporting infrastructure you build today is the competitive differentiator that defines your position in the EU market tomorrow.