Blackfort TechnologyCyber 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 trigger (Art. 2(1)) is a direct or indirect logical or physical data connection to a device or network. Standalone software — applications placed or made available on the market — therefore typically counts as a product with digital elements and falls within the CRA's scope. This is the decisive point for software makers: the CRA concerns not only „devices“ but also pure software products.
The boundary: SaaS vs. product
Standalone SaaS or pure cloud services are, as a rule, NOT automatically covered by the CRA — they are typically assigned to the NIS2 Directive (Directive (EU) 2022/2555). One important special case, however, remains in scope: a remote data processing solution that is integral to a product (Art. 3(2)) — a cloud or back-end function whose absence would stop a product function and which is provided by or under the responsibility of the manufacturer — counts as part of that product with digital elements and is therefore covered. Example: a companion app that does not work without the manufacturer-operated cloud pulls that back-end component into the CRA framework. The boundary is genuinely ambiguous at the edges and will be further clarified by future Commission guidance; where in doubt, assess conservatively. We offer an initial mapping of your portfolio via our scope assessment.
Core duties for software makers
As a manufacturer (Art. 13) you carry the main burden of obligations. The key action areas:
Security-by-design
Meeting the essential cybersecurity requirements of Annex I Part I: secure default configuration, minimising the attack surface, protecting confidentiality and integrity, access control. The basis is a documented cybersecurity risk assessment mapped to Annex I.
Vulnerability handling
Processes under Annex I Part II across the whole support period: identify and document vulnerabilities and components (incl. an SBOM), remediate without delay via security updates, test regularly, disclose fixed vulnerabilities once an update is available.
CVD policy & reporting
A mandatory coordinated vulnerability disclosure (CVD) policy including a contact address. Plus the reporting obligations under Art. 14 via the Single Reporting Platform.
Updates & support
Secure update distribution, updates without delay and free of charge, security updates separated from feature updates where feasible. Support period of at least 5 years (or shorter expected use).
Technical documentation
Technical documentation under Annex VII (architecture, SBOM, CVD policy, update distribution, risk assessment, test reports) — to be retained for at least 10 years or the support period.
Conformity, EU DoC & CE
Conformity assessment under Art. 32, EU Declaration of Conformity (Art. 28, Annex V), CE marking (Art. 30). In case of non-conformity: corrective action, withdrawal or recall.
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. Most products with digital elements self-assess (Module A). Important Class I products may also do so, provided harmonised standards, common specifications or a certification scheme are fully applied; otherwise a third-party assessment is needed. A notified body is mandatory only for Class II and critical products. 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. Established formats such as CycloneDX, SPDX (ISO/IEC 5962) or SWID satisfy the requirement as recognised formats (guidance, not statute). The Commission may later specify a format by implementing act; none exists yet. 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)):
| Date | What applies |
|---|---|
| 10 Dec 2024 | Entry into force (no enforceable manufacturer duties yet) |
| 11 Jun 2026 | Chapter IV — provisions on notified bodies / conformity-assessment bodies |
| 11 Sep 2026 | Manufacturer reporting obligations (Art. 14) via the Single Reporting Platform |
| 11 Dec 2027 | General application: essential requirements (Annex I), conformity assessment, CE marking |
The Art. 14 reporting deadlines follow a cascade: an early warning within 24 hours of awareness, a notification within 72 hours, and a final report for vulnerabilities within 14 days of a fix becoming available, whereas for severe incidents it is within one month of the notification — so the two deadlines are not identical.
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 before 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 already apply from September 2026 and cover products that are 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.
Note: These explanations are general technical-organisational information, not legal advice within the meaning of the German Legal Services Act (RDG). Classifications and the CRA-versus-NIS2 allocation depend on the individual case and may change with Commission guidance.
Frequently asked questions
Does my SaaS application fall under the Cyber Resilience Act?
Is standalone software really covered by the CRA?
Does the CRA mandate CycloneDX or SPDX as the SBOM format?
Do I need a notified body as a software maker?
By when must I meet the CRA requirements?
Let's talk about your CRA readiness
Unsure whether your software or SaaS solution falls under the CRA? We map your portfolio technically and organisationally and develop a robust roadmap to 2027 — talk to Blackfort Technology in Bonn.
Request a first call Check eligibility