CRA Vulnerability Handling: What Every Manufacturer Needs to Know Before September 2026

The European Union's Cyber Resilience Act (CRA) represents a seismic shift in how software and connected devices are regulated. For the first time, cybersecurity is no longer just a best practice; it's a prerequisite for market access. If you manufacture products with digital elements (PDEs) and sell them in the EU, the clock is ticking. You have until September 2026 to overhaul your vulnerability handling processes or face substantial penalties.

While the CRA covers a broad spectrum of cybersecurity requirements, from secure-by-design principles to incident reporting, the most operationally demanding obligations fall under the purview of this new process. This isn't just about patching bugs faster; it's about building a fully auditable infrastructure for receiving, triaging, fixing, and disclosing security vulnerabilities.

Let's break down exactly what the CRA requires and the practical steps your engineering and security teams need to start taking today.

The Scope: Does the CRA Apply to You?

Before diving into the requirements, let's establish who is affected. The CRA's reach is intentionally vast.

• Products with Digital Elements (PDEs): This encompasses essentially any hardware or software product that has a data connection (logical or physical). This includes IoT devices, smart home appliances, industrial control systems, networking equipment, operating systems, password managers, and most commercial software applications.
• The "Economic Operator": The primary burden falls on the . However, importers and distributors also have obligations to verify that the manufacturer has met their requirements. If an importer or distributor places a product on the market under their own name, or modifies a product substantially, they become the manufacturer under the CRA.
• Open Source Exception (with caveats): Free and open-source software (FOSS) is generally excluded unless it is supplied as part of a commercial activity (e.g., you charge for support, enterprise features, or host it as a SaaS).

If your product fits this description, the vulnerability handling requirements in Annex I, Part II are now part of your legal compliance checklist.

The Core Vulnerability Handling Obligations

The CRA mandates that manufacturers establish a systematic, documented approach to vulnerability management for the entire supported lifetime of the product (or 5 years, whichever is shorter). Here are the key pillars you must implement:

1. The Coordinated Vulnerability Disclosure (CVD) Process

You can no longer rely on researchers guessing who to email when they find a flaw. The CRA requires a formalized CVD process.

• Public Contact Point: You must provide a highly visible, easily accessible single point of contact for security researchers to report vulnerabilities. This shouldn't be a generic support form; it needs to be a dedicated security channel (e.g., [email protected] or a dedicated portal).
• Timely Acknowledgment: When a report is submitted, you must acknowledge receipt within a strictly defined timeframe (industry best practice and draft standards suggest 48 hours).
• Secure Communication: Researchers must have a way to report vulnerabilities securely to prevent interception (e.g., PGP encryption or a secure submission portal).

2. Triage, Remediation, and Timelines

It's not enough to just receive the reports; you must actively manage them.

• Investigation: You must promptly investigate reported vulnerabilities.
• Remediation: You are legally obligated to address and fix vulnerabilities without delay.
• Security Updates: Updates must be provided to users free of charge, securely, and seamlessly (automatically, where technically feasible). The updates must be clearly distinct from feature updates.

3. The SBOM Foundation

You cannot fix what you don't know you have. The CRA elevates the Software Bill of Materials (SBOM) from a "nice-to-have" to a mandatory artifact.

• Continuous Maintenance: You must draw up and consistently maintain an SBOM detailing the components and dependencies of your PDE.
• Vulnerability Correlation: The SBOM must be continuously checked against known vulnerability databases (like the NVD or ENISA's upcoming database) to identify inherited risks.

4. Public Disclosure and Advisories

Once a vulnerability is fixed, the process isn't over.

• Security Advisories: You must publicly disclose the vulnerability and the available fix.
• Machine-Readable Formats: The industry is rapidly moving toward (and regulators will likely expect) machine-readable advisories, such as the OASIS Common Security Advisory Framework (CSAF 2.0).
• Transparency: The advisory must detail the affected versions, the severity (CVSS score), the impact, and clear instructions for remediation.

5. Mandatory Reporting to Authorities (Article 14)

This is perhaps the most daunting new requirement for many manufacturers. Under Article 14, if you discover an in your product, you must notify the relevant national Computer Security Incident Response Team (CSIRT) or ENISA.

• The 24-Hour Rule: You must provide an initial early warning notification within of becoming aware of the active exploitation.
• Follow-up: A more detailed vulnerability notification must follow within 72 hours, with a final report required 14 days after a mitigating measure is available.

(Note: Severe security incidents have similar, parallel reporting timelines).

Practical Steps to Prepare for September 2026

Building this infrastructure takes time. If you wait until early 2026 to start, you will likely miss the deadline. Here is the operational roadmap you should begin executing now.

Step 1: Establish Your "Front Door" (Q3/Q4 2025)

Stop running your security program out of a shared inbox.

• Publish a Vulnerability Disclosure Policy (VDP): Clearly state your rules of engagement for researchers. What is in scope? What are your expected response times? Look to ISO/IEC 29147 for guidance.
• Deploy a Secure Intake Mechanism: Implement a CVD portal or a secure, PGP-backed email system. Ensure you have the tooling to guarantee that 48-hour acknowledgment window. This is the exact problem CVD Portal was built to solve.

Step 2: Build the Internal Engine (Q1/Q2 2026)

You need the internal plumbing to route and fix what comes through the front door.

• Define Your Minimum Viable PSIRT: Determine who is responsible for triaging reports, driving the engineering fix, and communicating with the researcher. Even in a small startup, these roles must be explicitly assigned.
• Automate SBOM Generation: Integrate SBOM generation (e.g., using CycloneDX or SPDX) into your CI/CD pipeline. Manual generation is not sustainable.
• Implement Vulnerability Scanning: Use tools (SCA, DAST, SAST) to continuously scan your codebase and your SBOM against known CVEs.

Step 3: Formalize Incident Response and Reporting (Q2/Q3 2026)

The 24-hour Article 14 reporting window is unforgiving. You cannot figure out your reporting protocol while an active exploit is burning through your customer base.

• Draft Standard Operating Procedures (SOPs): Create playbooks for how a submitted vulnerability moves from Inbox -> Jira Ticket -> PR -> Release.
• Establish the CSIRT Bridge: Know exactly who, how, and where you need to submit your Article 14 notifications in the member state where you are established. Draft the templates now.
• Prepare for Machine-Readable Output: Structure your internal vulnerability data so it can be easily exported to CSAF 2.0 or whatever schema ENISA ultimately mandates.

The Cost of Non-Compliance

The CRA isn't just guidelines; it has teeth. Non-compliance with essential cybersecurity requirements (which includes vulnerability handling) can result in fines of up to , whichever is higher. Fines for failing to meet reporting obligations (Article 14) can reach €10 million or 2% of turnover.

Beyond the fines, market surveillance authorities have the power to recall or withdraw your products from the EU market entirely.

Conclusion

The Cyber Resilience Act forces a maturation of the European software and hardware industry. Coordinated Vulnerability Disclosure is no longer the exclusive domain of tech giants with massive security budgets; it is a baseline requirement for doing business.

The timeline is aggressive, but achievable if you start building the infrastructure now. Focus first on your "front door"—your intake process and policy—and systematically build the internal engines required to triage, fix, and report. The era of silent patching and ignored researcher emails is over.