EU CRA for software and SaaS
Your software ships on schedule, and its evidence keeps pace.
Installed clients, mobile apps and SDKs are products under the Cyber Resilience Act, a backend can belong to one as remote data processing, and your own open-source projects count once you monetise them. With that settled, your release process sets how much documentation an update creates.
Last reviewed:
- Applies in full
- 11 December 2027
- Early warning
- 24 hours · Art. 14(2)(a)
- Support period
- at least 5 years · Art. 13(8)
- Most common class here
- Default product
Which software counts as a product with digital elements under the EU Cyber Resilience Act?
Under the EU Cyber Resilience Act, software counts as a product with digital elements when it is supplied to users and executes on their systems (Art. 3(1) EU CRA; EU Commission guidance (C(2026) 5252), section 2.2). Desktop clients qualify even when built with web technologies, and so do mobile apps, browser extensions, command-line tools and SDKs. Applications that run only in a browser, including progressive web apps, are not products, and neither are informational websites (recitals 11 and 12).
Product classes
Which software products does the Cyber Resilience Act cover, and in which class?
The Cyber Resilience Act reaches software made available in the course of a commercial activity, paid or free (Art. 3(22) EU CRA). The manufacturer is whoever markets the software under its own name or trademark (Art. 3(13)). The classes given are an estimate based on typical core functionality.
Spread in this sector
Pick a product
Desktop client for Windows, macOS or Linux, including Electron apps
Why this class
No Annex III or IV category; self-assessment under Art. 32(1).
Conformity route
- 1Risk assessment
- 2Self-assessment (module A)
- EU declaration of conformity + CE
Self-assessment by the manufacturer, Art. 32(1) EU CRA.
An assessment based on typical core functions. Your product's intended purpose and design decide.
All product examples as a table+
| Product | EU CRA class | Why |
|---|---|---|
| Desktop client for Windows, macOS or Linux, including Electron apps | Default product | No Annex III or IV category; self-assessment under Art. 32(1). |
| Mobile app, browser extension or command-line tool | Default product | Annex III only if the core function matches a listed category. |
| Commercially licensed SDK or library | Default product | A component placed on the market separately, Art. 3(1). |
| Source code licensed to customers who compile it themselves | Default product | Placed on the market per EU Commission guidance, section 2.3 (Example 7). |
| Engineering software for programming controllers and devices | Default product | No category in Annex III or IV. |
| Office, graphics or CAD software, computer game | Default product | No category in Annex III or IV. |
| Identity or privileged access management software | Important product, class I (Annex III) | Annex III Class I No. 1. |
| Password manager, including open source sold with paid support | Important product, class I (Annex III) | Annex III Class I No. 3; as free and open-source software it may use the Art. 32(1) procedures if its technical documentation is public (Art. 32(5)). |
| VPN client, anti-malware software | Important product, class I (Annex III) | Annex III Class I Nos. 5 and 4. |
| SIEM or network management system | Important product, class I (Annex III) | Annex III Class I Nos. 7 and 6; module A if a harmonised standard is applied in full (Art. 32(2)). |
| Operating system, standalone or embedded browser | Important product, class I (Annex III) | Annex III Class I Nos. 11 and 2. |
| Hypervisor, container runtime, software firewall or IDS/IPS | Important product, class II (Annex III) | Annex III Class II Nos. 1 and 2; third-party assessment under Art. 32(3). Chapter IV on notified bodies has applied since 11 June 2026. |
Your product isn't listed? The maturity assessment gives a first classification for your own product. Start the EU CRA assessment →
Annex IV has no software-only category; its critical products are hardware such as smart cards, secure elements and smart meter gateways. Open-source projects stay outside unless the maintainer monetises them, for instance by charging for binaries or selling a paid edition with support; donations and sponsoring do not count (EU Commission guidance, section 3.1). A beta may be offered for a limited testing period with a visible non-compliance notice (Art. 4(3) EU CRA).
Obligations
What does the EU Cyber Resilience Act require of software vendors?
- 01
An SBOM for each version you ship
Annex I, Part II, point 1 EU CRA requires manufacturers to document the components of their product, including through a software bill of materials in a commonly used, machine-readable format that covers at least the top-level dependencies.
- 02
Due diligence on third-party code
Art. 13(5) and (6) EU CRA
When integrating third-party components, including open-source software that was never placed on the market, manufacturers exercise due diligence (Art. 13(5) EU CRA). They are not responsible for the component's own compliance (EU Commission guidance, section 3.4). A vulnerability they find in a component goes to whoever maintains it, together with any fix they have written (Art. 13(6)).
- 03
Patching can stop at the latest version
Once substantially modified successor versions are on the market, Art. 13(10) EU CRA lets a software manufacturer limit vulnerability remediation to the version it placed last. Users of earlier versions must then get the latest one free of charge and bear no additional cost for adapting their hardware or software environment.
- 04
A 24-hour early warning to CSIRT and ENISA
Art. 14(1) and (2), Art. 69(3) EU CRA
Manufacturers report an actively exploited vulnerability to the CSIRT designated as coordinator and to ENISA simultaneously, through the single reporting platform under Art. 16 EU CRA (Art. 14(1)). The early warning has been due within 24 hours of awareness since 11 September 2026 (Art. 14(2)(a)); the notification follows within 72 hours and the final report no later than 14 days after a fix is available. Art. 69(3) extends the reporting duty to software placed on the market before 11 December 2027.
Related regulation
Which other EU rules apply to software vendors alongside the Cyber Resilience Act?
AI Act, Regulation (EU) 2024/1689
Software classified as a high-risk AI system under Art. 6 AI Act is deemed to meet the cybersecurity requirements of Art. 15 AI Act if it fulfils Annex I EU CRA and its EU declaration of conformity shows this (Art. 12(1)).
NIS2 Directive (EU) 2022/2555
One company can answer to NIS2 for the cloud service it runs and to the EU CRA for the clients it ships. A cloud provider's NIS2 evidence under Implementing Regulation (EU) 2024/2690 can be reused for third-party services (EU Commission guidance, section 8.2).
DORA, Regulation (EU) 2022/2554
Financial-sector software can fall under DORA and the EU CRA at once, and DORA evidence counts as reusable assurance (EU Commission guidance, section 8.2).
Medical devices, Regulations (EU) 2017/745 and 2017/746
Art. 2(2)(a) and (b) EU CRA exclude software that is a medical device or an in vitro diagnostic device under either regulation.
In practice
Where software teams lose time
A third party's SaaS inside your product
Section 8.1 of the EU Commission guidance treats an external login provider, payment service or support chat as a third-party component. When that service changes, the risk assessment needs revising (section 8.2), which only works if the contract obliges the provider to tell you.
Features that go live behind a flag
Teams that ship features dark and switch them on later need those features in the original risk assessment. Only then does activation stay clear of a substantial modification (EU Commission guidance, section 4.3, Examples 42 and 43).
The product boundary moves with the architecture
A desktop shell or a browser extension turns a web app into a product where there was none. Moving logic from the client into the backend shifts what the documentation has to cover as remote data processing.
Dependencies nobody maintains
When a transitive dependency comes from an abandoned project, a report under Art. 13(6) EU CRA has no recipient. Your team writes the fix and carries it as a fork through the support period.
With Kunnus
How Kunnus supports software vendors
Kunnus covers the Cyber Resilience Act layer of conformity; NIS2 or DORA obligations stay in the processes you run for them.

Worked example
How much evidence does a software portfolio produce in a year?
Assume a vendor builds seven locally running artefacts and one shared backend from a single codebase and ships every two weeks.
- 1ArtefactsDesktop client for Windows, macOS and Linux, iOS and Android apps, a CLI, a browser extension
- 2Products7, as builds per operating system are separate products (EU Commission guidance, section 2.1)
- 3Backend1 dossier, declared in all 7 sets of technical documentation (section 8.2)
- 4Not in the dossierusage telemetry for statistics, the CI/CD pipeline and the CRM (section 8.1)
- 5Per year7 products × 26 releases = 182 SBOMs and 182 recorded substantial-modification checks
- 6Across the support period910 SBOMs over 5 years, the minimum under Art. 13(8) EU CRA
Example with assumed figures, not market data.
Frequently asked questions
Does the Cyber Resilience Act apply to SaaS?+
Recital 12 of the Cyber Resilience Act assigns SaaS, as a cloud service model, to the NIS2 Directive (EU) 2022/2555, which covers providers from medium-sized enterprise upwards. A smaller provider running only a cloud service may therefore fall under neither. The EU CRA comes in once the vendor ships software that runs on the customer's side and depends on the service, such as a sync client or a plugin. Our article on SaaS under the Cyber Resilience Act goes further.
When does a backend count as remote data processing?+
A backend is remote data processing under Art. 3(2) EU CRA when two questions from section 8.1 of the EU Commission guidance both get a yes. Would a product function fail without it, including onboarding, sync, configuration, update distribution or login? And did the manufacturer develop the software or have it built to its specifications? Who operates the backend and where it runs make no difference. A browser front end can qualify the same way, for example an authentication portal issuing tokens to a desktop client.
Which software categories are important products under Annex III?+
Annex III EU CRA Class I Nos. 1 to 11 and Class II Nos. 1 and 2 can all be pure software. Only the core functionality decides, according to section 6.1 of the EU Commission guidance: SOAR software is not a SIEM (Example 59), nor is a log collector without correlation (Example 60).
What are the obligations of open-source software stewards?+
An open-source software steward is a legal person, other than a manufacturer, that supports free and open-source software intended for commercial activities on a sustained basis (Art. 3(14) EU CRA). Art. 24 requires a documented cybersecurity policy and cooperation with market surveillance. Steward status is assessed per project. A steward that takes part in development reports actively exploited vulnerabilities under Art. 14(1); one that provides infrastructure reports severe incidents under Art. 14(3) (EU Commission guidance, section 3.3).
How does continuous deployment fit the EU CRA?+
Continuous deployment works under the Cyber Resilience Act when releases are checked for substantial modification as defined in Art. 3(30) EU CRA. Section 4.3 of the EU Commission guidance gives four criteria: new threat vectors, new attack scenarios, changed likelihood and changed impact of known scenarios. Security updates rarely qualify; a remember-me login storing tokens locally does (Example 44). Releases below that threshold keep the original date of placing on the market (section 2.1).
What support period must a software vendor declare?+
The support period under Art. 13(8) EU CRA reflects the expected time of use and lasts at least five years, unless the product is expected to be in use for less. The end date is stated at purchase with at least month and year (Art. 13(19)), and a substantially modified version gets its own declared period.
Where does your software portfolio stand?
The EU CRA assessment gives a quick first estimate of class, obligations and next steps for your software portfolio.
Further reading
Other sectors
EU CRA compliance in other industries
Source: Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal of the EU. https://eur-lex.europa.eu/eli/reg/2024/2847/oj
This page is an orientation on the Cyber Resilience Act for this sector, not legal advice. Whether and how the regulation applies to a specific product depends on its intended purpose and design.








