What Software Vendors Need to Do Right Now

The Cyber Resilience Act is no longer a future concern. With the first hard deadline — mandatory vulnerability reporting — arriving on 11 September 2026, and the European Commission having only just published its draft implementation guidance for consultation in March 2026, the window for preparation is narrowing in real time.

This piece looks at where the CRA stands today, what the practical obligations mean for software vendors, and where the genuine risk concentrations lie.

Where Things Stand in March 2026

The CRA entered into force on 10 December 2024. Since then, implementation has been moving on several parallel tracks.

The Commission published its first CRA implementation FAQ in December 2025, followed by draft implementation guidance released for stakeholder feedback this month — guidance specifically required under Article 26 of the Act, with a particular focus on helping SMEs navigate their obligations. Separately, the standardisation work commissioned from CEN, CENELEC, and ETSI is progressing, with several vertical standards — covering products including browsers, VPNs, password managers, antivirus software, and SIEM systems — having moved to the mature draft stage. Full harmonised standards are targeted for publication by October 2026.

ENISA is building the Single Reporting Platform through which manufacturers will file vulnerability and incident reports. It is expected to be operational — with a testing period before — by the September 2026 reporting deadline.

The compliance timeline is staged: reporting obligations from 11 September 2026; conformity assessment body notification provisions from 11 June 2026; full application of all CRA requirements from 11 December 2027.

That December 2027 date feels distant. September 2026 does not.

The 24-Hour Problem

The most operationally demanding provision in the near-term CRA timeline is the vulnerability reporting obligation. From September 2026, manufacturers must notify an actively exploited vulnerability to the relevant national CSIRT within 24 hours of becoming aware of it. A full notification follows within 72 hours. A final report is due within 14 days of a corrective measure being available.

The 24-hour early warning is the provision most organisations are underestimating. It requires three things to work simultaneously: the capability to detect active exploitation of a vulnerability in your product; the organisational processes to escalate and triage that information; and the ability to produce a structured notification under time pressure.

Many software vendors — particularly SMEs — have none of these in place today. The notification requirement does not build capability; it assumes it. Organisations that wait until August 2026 to start building monitoring and incident response infrastructure will not be ready. The timeline for establishing and testing those processes is measured in quarters, not weeks.

The SBOM Obligation: Harder Than It Looks

The requirement to maintain a software bill of materials — a complete, machine-readable, standardised inventory of all components in a product — is generating significant attention, and for good reason. For industrial software with complex dependency trees and long support lifetimes, it is arguably the most demanding structural obligation in the Act.

The challenge is not conceptual. Knowing what is in your product matters for security, and the industry has broadly accepted that. The challenge is operational. As security researchers at the Open Source Security Foundation have noted, the SBOM should not be a static compliance artefact. It needs to be a live instrument — continuously updated as dependencies change, used actively to monitor for newly disclosed vulnerabilities across every component in scope.

For industrial vendors, where products may carry support obligations of ten years or more, this means committing to vulnerability monitoring for components that may themselves become unsupported by their original authors. The supply chain complexity in that scenario — tracking second-order dependencies over a decade, across a product that may itself evolve — is substantial.

The Substantial Modification Question

One of the more consequential interpretive questions in the CRA is what constitutes a “substantial modification” — because substantial modification of a product that was placed on the market before December 2027 triggers full CRA conformity obligations for the modified version.

Legal analysis from DLA Piper’s cybersecurity team, published in February 2026, offers useful practical framing: routine security patches, bug fixes, and minor functional changes are generally not substantial modifications. But changes that add or alter product functions in ways that increase cybersecurity risk, or that alter the product’s intended purpose beyond what was foreseen in the original risk assessment, do trigger the obligation. The compliance entity for the modified product becomes whoever made the modification — even if that is not the original manufacturer.

For vendors who continuously update their products — which increasingly means most software vendors — this creates an ongoing assessment obligation. Every meaningful update needs to be evaluated against the substantial modification threshold. That evaluation needs to be documented.

The SME Exposure

The CRA applies to any manufacturer placing a product with digital elements on the EU market, regardless of where the manufacturer is based or how large it is. The explicit focus of the Commission’s Article 26 guidance obligation on SMEs reflects a recognition that smaller vendors face disproportionate compliance challenges.

The challenge is real. Large technology companies can establish dedicated security and compliance teams. SMEs often cannot. For smaller vendors in industrial supply chains — many of whom produce specialised software components that feed into larger systems — the risk is not just direct non-compliance. It is exclusion from supplier lists as larger system integrators tighten their own CRA compliance requirements upstream.

The Module H conformity route — which allows compliance to be demonstrated through audit of a manufacturer’s quality management system rather than product-by-product testing — is attracting interest precisely because it offers a potentially more scalable pathway for organisations with mature internal processes. However, the criteria for its application under the CRA are still being developed, and no confirmed guidance on its implementation has been published as of March 2026.

What Vendors Should Be Doing Now

The practical priorities for software vendors in the current window are reasonably clear, even as some regulatory details remain unresolved.

The first priority is scoping. The CRA’s product classification — default, important (Annex III), critical (Annex IV) — determines the conformity assessment pathway. Knowing which classification applies to each product in a portfolio is the prerequisite for every subsequent compliance decision. The Commission is expected to update the Annex III and IV lists as further delegated acts are adopted, so this is not a one-time assessment.

The second priority is SBOM infrastructure. Establishing tooling, process, and ownership for software bill of materials generation and maintenance is a foundational step that benefits compliance preparation and operational security simultaneously. Given the lead time required to achieve reliable SBOM coverage across complex product portfolios, this work should already be underway.

The third priority is incident response and reporting readiness for the September 2026 deadline. This means building or acquiring the monitoring capability to detect actively exploited vulnerabilities, designing the internal escalation workflow that can produce a 24-hour notification, and testing the process before the deadline makes it mandatory.

The fourth priority is supply chain review. The CRA places obligations on manufacturers, but those obligations depend in part on the security properties of components sourced from third parties. Supplier contracts and due diligence procedures need to be updated to reflect CRA requirements, with priority given to suppliers of critical components.

The Broader Context

The CRA does not exist in isolation. It sits alongside NIS2 — already applicable — and DORA in the financial sector. For organisations subject to multiple overlapping regimes, the reporting obligations interact: a vulnerability involving personal data may trigger simultaneous GDPR notification obligations; an organisation subject to NIS2 may face additional early-warning requirements. The Commission’s guidance is beginning to address these overlaps, but the multi-regime compliance landscape remains complex.

What the CRA adds to that landscape is product-level accountability. Not how an organisation responds to incidents — that is NIS2 and DORA territory — but whether the products themselves were built to a standard that reduces the likelihood of those incidents occurring in the first place.

That is the structural ambition of the Act. And the clock, as of September 2026, will start measuring whether the industry has risen to it.

---

Sources referenced in this piece include the European Commission’s CRA implementation page and factsheet (digital-strategy.ec.europa.eu), the Hogan Lovells 2026 CRA compliance guide, DLA Piper’s February 2026 CRA legal roadmap, the Open Source Security Foundation’s CRA resource pages, and SGS’s October 2025 CRA implementation status update.

The Quantum Space examines the structural components of digital trust: identity, cryptography, security, and licensing. This analysis is offered for informational purposes and does not constitute legal advice.