Cyber Resilience Act for Software & SaaS Makers

The EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) subjects manufacturers of products with digital elements to horizontal cybersecurity requirements. For software and SaaS providers the central question is: is my product in scope - and if so, which part of it? This page provides a technical-organisational orientation. It offers guidance, not binding individual advice; a legal assessment in the specific case remains reserved for legal counsel.

Why standalone software is in scope

A product with digital elements (Art. 3(1)) is a software or hardware product together with its remote data processing solutions, including components placed on the market separately. The condition (Art. 2(1)) is that the intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Standalone software, that is applications placed or made available on the market, therefore counts, in principle, as a product with digital elements and falls within the CRA’s scope.

Core duties for software makers

As a manufacturer (Art. 13) you carry the main burden of obligations. The key action areas:

Self-assessment or notified body?

A notified body is by no means required for every product. The CRA distinguishes four tiers (Art. 32, Annex VIII): the unclassified default case, important products of Class I and Class II, and critical products. Default-category products self-assess (Module A). Important Class I products may also do so, provided harmonised standards, common specifications or a European cybersecurity certification scheme (assurance level at least “substantial”) are fully applied; otherwise a third-party assessment is needed (Module B+C or H). Third-party assessment is required in every case for Class II and critical products, and for Class I whenever standards, common specifications or a scheme are not applied in full. Examples named in Annex III include password managers, identity and access management, browsers, VPNs, SIEM software and operating systems (Class I), as well as firewalls, IDS/IPS and hypervisors (Class II). “Important” is not the same as “critical”.

SBOM - yes, but with no fixed format

Annex I Part II requires a software bill of materials (SBOM) in a commonly used, machine-readable format covering at least top-level dependencies. Important: the Regulation prescribes no specific format - so it is not correct that the CRA mandates CycloneDX or SPDX. Examples of machine-readable formats are CycloneDX and SPDX (ISO/IEC 5962); what counts for the requirement is the content, at least the top-level dependencies. The Commission may later specify the format and elements by implementing act (Art. 13(24)); such an implementing act had not been adopted when we checked on 9 October 2026. The SBOM is moreover a compliance artefact disclosed to authorities on reasoned request - there is no obligation to publish it. Details in our knowledge article on the CRA's SBOM requirements.

Timeline & roadmap

The CRA entered into force on 10 December 2024 - but no directly enforceable obligations follow from that date. Application is staggered (Art. 71(2)):

The Art. 14 deadlines are staggered: early warning without undue delay and in any event within 24 hours of becoming aware, notification within 72 hours; the final report follows no later than 14 days after a corrective or mitigating measure is available for vulnerabilities, and within one month of the notification for severe incidents. Reportable are actively exploited vulnerabilities and severe incidents having an impact on the security of the product.

Recommended roadmap to 2027: (1) clarify scope and possible classification per product; (2) establish risk assessment and security-by-design measures; (3) integrate the vulnerability process, CVD policy and SBOM generation into the CI/CD pipeline; (4) set up Art. 14 reporting processes immediately if not yet done, as they have been mandatory since September 2026; (5) complete technical documentation (Annex VII), the EU DoC and conformity assessment before December 2027. A deeper overview is available on our CRA overview page.

For software teams it makes sense to start early: much of what is required - SBOM generation, separating security from feature updates, a documented CVD policy, secure update distribution - can be implemented as part of existing development and release processes rather than as a special project shortly before the deadline. The Art. 14 reporting obligations have already applied since September 2026 and cover products that were already on the market at that point; a working reporting and response process should therefore be prioritised. Anyone making architecture decisions today should plan for the minimum five-year support period from the outset.