The Cyber Resilience Act entered into force on December 10, 2024, with a phased application schedule that brings the vulnerability reporting obligations into effect in September 2026 and the full obligations in December 2027. Vendors selling products with digital elements into the EU market are now in the operational window where serious preparation is required, because the full obligations cannot be retrofitted onto a product line in the final quarters before application. This post is a working summary of where vendors should be in 2026.
The framing point: the CRA is a product regulation, not a service regulation. It covers products with digital elements placed on the EU market, with carve-outs for products covered by sector-specific regulation. The horizontal scope is intentionally broad, covering software, hardware, and components, and the obligations attach to the manufacturer with downstream obligations on importers and distributors. SaaS as a service is generally outside the CRA scope, but the software components in SaaS offerings sold or licensed for installation are typically in scope.
What classes of product are in scope and at what level?
Article 7 distinguishes between standard products, important products in Class I and Class II, and critical products. Standard products carry the baseline obligations and may use self-assessment for conformity. Class I and Class II important products require third-party conformity assessment or compliance with harmonized standards. Critical products require an EU certification scheme conformity assessment. The classifications are listed in Annexes III and IV, and they capture identity management systems, password managers, antivirus, hypervisors, public key infrastructure, smart card readers, and similar security-significant products.
For most vendors the practical classification work is determining whether their product falls into Class I or Class II, because the conformity assessment burden differs significantly. The harmonized standards under the CRA are being developed by ENISA and the European Standardization Organizations, with the first set expected in 2026 and 2027. Vendors that can demonstrate compliance with the harmonized standards will have a substantially simpler conformity assessment path than those that cannot.
What does the SBOM obligation actually require?
Annex I Part 1 paragraph 2(b) requires manufacturers to identify and document the components contained in the product with digital elements, including by drawing up an SBOM. The technical specifications for the SBOM are being developed but the practical expectation is alignment with the SPDX or CycloneDX standards at the level of detail specified in NTIA minimum elements, plus the additional CRA expectations around updates and vulnerability data.
The SBOM is not, however, the deliverable to the end customer in the general case. The CRA requires the manufacturer to maintain the SBOM and make it available to market surveillance authorities on request. Manufacturers may voluntarily publish SBOMs but are not required to. The internal operational obligation is therefore to produce and maintain SBOMs for every product placed on the market and to retain them for the support period plus five years. This is a record-keeping obligation more than a transparency obligation, but it is no less burdensome.
How do the vulnerability handling obligations work?
The vulnerability reporting obligations under Article 14 take effect on September 11, 2026, ahead of the broader application of the CRA in December 2027. Manufacturers must notify ENISA and the relevant CSIRT of any actively exploited vulnerability in their products with digital elements within 24 hours of becoming aware, with an intermediate report within 72 hours and a final report within 14 days. The notification covers vulnerabilities being actively exploited, not all vulnerabilities, but the threshold has been read carefully and the operational implication is that vendors need real-time signal on exploitation of vulnerabilities affecting their products.
The companion obligation under Annex I Part 2 requires manufacturers to operate a coordinated vulnerability disclosure process, to provide security updates without delay during the support period, and to communicate the existence of vulnerabilities and the corresponding fixes to users. The support period is defined as the period during which the product is expected to be used, with a minimum of five years for most products. Manufacturers that have historically operated with shorter support windows or ad hoc disclosure practices need to formalize and extend them substantially.
What about open source software?
The CRA treatment of open source software has been one of the most contentious aspects of the regulation. The final text introduces the concept of an open source software steward, a distinct obligation set lighter than that of a manufacturer, applicable to entities that systematically develop or contribute to open source software intended for commercial use. The threshold and operational expectations for stewards are being clarified through Commission guidance, with the first substantive guidance expected in 2026.
For commercial manufacturers, the practical implication is that incorporating open source components does not transfer the CRA obligations to the upstream maintainer. The downstream manufacturer remains responsible for the vulnerability handling, security update, and SBOM obligations for the product placed on the market, regardless of whether the components are open source or proprietary. The supply chain due diligence obligation under Annex I Part 1 paragraph 2(c) requires the manufacturer to exercise due diligence when integrating components from third parties, with the depth of diligence proportional to the role of the component.
How Safeguard Helps
Safeguard provides the operational infrastructure that CRA preparation actually requires. SBOMs are generated continuously for every build with the SPDX and CycloneDX detail the harmonized standards are converging on, retained across the support period plus five years. Griffin AI correlates published vulnerabilities with exploitation signal in near real time, supporting the 24-hour active exploitation notification under Article 14. Policy gates in CI enforce supply chain due diligence at the build stage, producing operating effectiveness evidence for conformity assessment. TPRM scoring of upstream components feeds the integration diligence obligation, and zero-CVE base images materially reduce the volume of security updates the support obligation has to produce. The result is a CRA program that operates as a byproduct of engineering rather than a separate compliance overhead racing against the 2026 and 2027 application dates.