If Your Software or Connected Product Enters the EU Market, the Cyber Resilience Act May Apply

Article 3 defines a product with digital elements as a software or hardware product and its remote data processing solutions, while Article 2 sets the scope and connectivity criterion: the product must have a direct or indirect logical or physical data connection to a device or network ¹.

A useful first check has four parts: Is it software, hardware or a component supplied separately? Is it supplied on the EU market as part of a commercial activity? Does its intended or reasonably foreseeable use include a direct or indirect connection to a device or network? And does one of the CRA's exclusions apply? ¹

Check the exclusions. Some otherwise connected products are excluded because other sector rules already apply. These include specified medical and in-vitro diagnostic devices, certain motor-vehicle products, certified aviation products and marine equipment. The CRA also excludes certain identical replacement spare parts and products developed exclusively for national-security or defence purposes ¹.

Cloud-connected does not automatically mean CRA-covered. A manufacturer-controlled backend forms part of the product where it was designed or developed by, or under the responsibility of, the manufacturer and the product could not perform one of its functions without it. A general website or unrelated SaaS, PaaS or IaaS service is not automatically part of the product ^{1 2}.

The CRA also distinguishes economic-operator roles. Manufacturers have the primary design, risk-assessment, conformity, documentation, vulnerability-handling, reporting, and CE-marking obligations under Article 13 and related provisions ¹. Importers and distributors have their own obligations under Articles 19 and 20, including checks before placing or making products available on the market, and Articles 21 and 22 explain when manufacturer obligations can apply to importers, distributors, or other actors ¹.

Open source is not automatically exempt. Free and open-source software supplied outside a commercial activity falls outside the CRA's ordinary product rules. Monetised open-source products or components may be covered, while qualifying open-source software stewards follow a lighter, tailored set of duties ^{1 2}.

The easiest way to understand the CRA is to follow the product lifecycle.

Before placing the product on the market

Based on the product's cybersecurity risk assessment, and where relevant to that product, Annex I requires measures covering areas such as secure-by-design, protection against unauthorised access, confidentiality and integrity protections, attack-surface reduction and secure updates. This is where classification, the risk assessment, secure design, technical documentation and conformity assessment sit ¹.

Most products can use internal-control self-assessment. Important Class I products can self-assess only where the required standards, common specifications or eligible certification route is used; otherwise third-party assessment is needed. Important Class II and critical products follow the applicable third-party or certification route. Annex III lists important products in Classes I and II; Annex IV lists critical product categories ^{1 2}.

When placing it on the market

At this point the manufacturer draws up the EU declaration of conformity (Article 28), affixes the CE marking (Article 30), and provides user information and instructions—including the product's support-period end-date ¹.

Manufacturers must also set and document a support period that reflects how long the product is expected to be used. It will normally be at least five years, unless the expected use period is shorter. Security updates issued during that period must remain available for at least ten years after issue or for the rest of the support period, whichever is longer ¹.

After placement

Annex I Part II sets vulnerability-handling requirements, including processes to identify, document, remediate and disclose vulnerabilities, provide security updates and take corrective measures. The supporting process should include a coordinated vulnerability-disclosure policy and a software bill of materials (SBOM) in a commonly used, machine-readable format covering at least the product's top-level dependencies ¹.

From 11 September 2026, manufacturers report actively exploited vulnerabilities and severe security incidents through the CRA Single Reporting Platform. The process starts with an early warning within 24 hours, followed by a fuller notification within 72 hours. Final-report deadlines then differ for vulnerabilities and incidents ³.

The dates matter. The CRA entered into force in December 2024; the framework for notifying and assessing conformity-assessment bodies applies from 11 June 2026; Article 14 reporting obligations apply from 11 September 2026; and the main CRA obligations apply from 11 December 2027. Products placed on the market before 11 December 2027 are generally subject to the main CRA requirements only if they undergo a substantial modification from that date; the reporting rules are different, because Article 14 also covers in-scope products already made available before the main application date (Article 69) ^{1 2}.

Luxembourg implementation note. As of 15 July 2026, we have not identified a published Luxembourg designation of the CRA market-surveillance or notifying authorities. ILNAS's 2025 annual report indicates that the CRA market-surveillance functions expected to fall to ILNAS were still being developed. Check Legilux, ILNAS and Ministry of the Economy updates before relying on a national route ⁷.

Does being an SME change the rules?

There is no general SME exemption from the CRA. The CRA nevertheless includes targeted support and reduced conformity-assessment fees. Member States may establish regulatory sandboxes, and micro and small enterprises will be able to use a simplified technical-documentation form once the Commission adopts it. Micro and small manufacturers are also protected from administrative fines solely for missing the initial 24-hour reporting deadline—but the reporting duty itself still applies ^{1 2}.

Cyvalent 360 Cyber Services / CISOaaS provides the practitioner-led scoping work: role mapping, product inventory, CRA exposure assessment, product-class review against Annexes III and IV, and a practical evidence plan for design, vulnerability handling, and conformity-readiness work ¹.

Cyvalent RGX maps CRA obligations to the control framework you already operate, such as ISO 27001, NIST CSF, or an internal secure-development framework. That makes evidence reuse visible: a secure-development process, vulnerability-management record, supplier-risk review, or access-control measure may support more than one regulatory or control-framework requirement.

The engagement output is a scoped operating view: which products appear relevant, which roles Cyvalent has identified for review, which CRA requirement areas need evidence, and how those requirements map to your existing control library.