"We are just SaaS, so the CRA does not apply to us." Sometimes that is true. Often it is half true, because somewhere in the delivery there is an agent, a CLI, a Helm chart or a mobile app that changes the answer.
This article walks through how to decide whether your organisation is covered by the Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, in six steps: whether you place a product with digital elements on the market, whether you do it in the course of a commercial activity, which exemptions exist, when SaaS and remote data processing are pulled in, how open source is treated, and whether the product is important or critical. At the end you will find typical cases and a checklist for the DevSecOps team.
Questions about this topic? Get in touch with us!
This is a technical walkthrough, not legal advice. If you are unsure whether your product is in scope, talk to a lawyer. The legal references were checked on 2 November 2026.
By the Agency 42 team · Last reviewed 2 November 2026
The short answer
You are covered by the CRA as a manufacturer if you develop, or have someone develop, a product with digital elements and make it available on the EU market under your own name or trademark, in the course of a commercial activity. That holds even if the product is free. A pure web service that users only reach through a browser is usually not a product, but it can be pulled in if a product needs it to work.
Think of the CRA as customs. It does not matter what you call the parcel. What matters is what is inside, who sends it and where it is going.
Step 1: Do you place a product with digital elements on the market?
The CRA applies to products with digital elements made available on the market whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network (Article 2(1)). The definition in Article 3(1) covers software and hardware, and also their remote data processing solutions.
The Commission's guidance from July 2026 draws the line. Software that is downloaded, installed or otherwise delivered to the user and runs on the user's systems is a product. Software that runs remotely and is only accessed by the user is not, on its own (points 20 to 21 and example 5).
For a platform team this means the following are often products when you ship them to customers:
- an agent or operator that the customer installs in their cluster,
- a CLI or desktop application,
- container images and Helm charts that the customer runs in their own environment,
- a mobile app or firmware.
Step 2: Is it a commercial activity?
Making available on the market means supply for distribution or use in the EU "in the course of a commercial activity, whether in return for payment or free of charge" (Article 3(22)). Free is therefore not an exemption. Recital 15 mentions, among other things, monetisation through other services and the use of personal data.
Tools used only internally and never supplied to anyone else are normally not made available on the market. An internal platform team is therefore rarely the manufacturer of its own tooling. That changes the day the tooling is delivered to customers.
Step 3: Does an exemption apply?
Article 2 excludes products already covered by certain sector rules: medical devices and in vitro diagnostics, motor vehicles, certified aeronautical products and marine equipment. Identical spare parts are excluded, and so are products developed exclusively for national security or defence.
Article 4 also allows prototypes at trade fairs and unfinished software for limited testing, as long as it is clearly indicated that the product does not yet comply.
One point many people miss: products placed on the market before 11 December 2027 are only covered if they undergo a substantial modification after that date. The reporting obligation in Article 14 still applies to all products, and it has applied since 11 September 2026 (Articles 69 and 71).
Step 4: SaaS and remote data processing
This is where it gets interesting if you run everything on Kubernetes. Under Article 3(2), remote data processing is "data processing at a distance for which the software is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions".
The guidance breaks this down into three questions (point 184):
- Is the processing done at a distance?
- Would the product lose a function without it?
- Did you design and develop the software, or was it built under your responsibility?
If the answer to all three is yes, the backend service is part of the product. The guidance lists examples such as remote control, synchronisation, configuration, distribution of updates, and identity and access management (point 190). An authentication portal that issues the tokens a product needs can be included (point 194). Telemetry collected purely for statistics or future development is not (point 192).
Two details matter in particular for platform teams:
- Who operates it does not matter (point 196). Design and development decide. If you built the API your agent talks to, it is your responsibility even if a partner runs the cluster.
- Third-party IaaS and PaaS do not move the responsibility (points 198 to 199). Your code running in someone else's cloud can be remote data processing. A finished third-party SaaS product is not, but it should be risk-assessed much like a third-party component (points 200 to 201).
And the pure web service? Recital 12 reminds us that SaaS, PaaS and IaaS are handled by NIS2, as transposed into national law in each member state.
Step 5: Open source: manufacturer, steward or contributor?
The CRA distinguishes three roles.
- Contributors who submit code to a project they are not responsible for are not covered (recital 18). The guidance notes that commit rights alone do not make someone a maintainer (point 49 and example 13).
- Open-source software stewards are legal persons that provide sustained support for the development of open-source software intended for commercial activities (Article 3(14)), for example certain foundations and companies that publish open source in a business context. They have a lighter regime built around a cybersecurity policy and cooperation with authorities (Article 24), and they cannot be fined (Article 64(10)).
- Manufacturers are those who monetise the product, for example by charging for it. The guidance describes how a free community edition and a paid edition can be different products, with different roles for the same company (points 51 to 54).
Most of what runs in a Kubernetes cluster is open source that you integrate. That does not make you responsible for the component itself, but as a manufacturer you must exercise due diligence when choosing components (Article 13(5)) and report vulnerabilities you find to whoever maintains the component (Article 13(6)). This is where a good SBOM pays off, see CRA SBOM requirements.
Simply hosting code in an open repository or a package registry is not making it available on the market either (recital 20).
Step 6: Default, important or critical product?
Most products are "default" and self-assessed. Products whose core functionality matches a category in Annex III are important, and the categories in Annex IV are critical (Articles 7 and 8). Integrating, say, an operating system does not in itself make a product an operating system.
Categories that touch the platform world:
- Class I: among others identity and access management, VPNs, network management, SIEM, PKI and operating systems.
- Class II: "Hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments", as well as firewalls and intrusion detection.
For class I, harmonised standards or equivalent are needed to self-assess, otherwise third-party assessment is required. Class II requires third-party assessment or certification. Open source listed in Annex III can be self-assessed if the technical documentation is made public (Article 32).
Typical cases from the platform world
| What you do | Likely position under the CRA | Next step |
|---|---|---|
| Web app reached only through a browser, running in your cluster | Not a product on its own | Check NIS2 and your national transposition |
| Agent or operator the customer installs, plus your API | Product, the API can be remote data processing | Include the backend in risk assessment and SBOM |
| Open source with a paid enterprise edition | Manufacturer for the paid edition, possibly steward for the community edition | Separate products, policies and support |
| Consultancy that installs open source for a customer without substantial modification | Not placing it on the market (guidance, example 19) | Help the customer with due diligence and documentation |
The table is a map, not a legal opinion.
Checklist for the DevSecOps team
- List everything you ship. Images, charts, binaries, apps and firmware.
- Map the remote data processing. Which services in the cluster does the product need to work? They belong to the product.
- Link an SBOM to every delivery. Including backend services that count as remote data processing.
- Document component choices. Why did you pick this component, and how do you track its vulnerabilities?
- Have an Article 14 process in place now. It has applied since September 2026.
A small nod to 42: the answer to whether you are covered is rarely 42, but it is almost always in Article 3.
Summary
- The CRA covers products with digital elements supplied in the course of a commercial activity, even when they are free.
- A pure web service is usually not a product, but a backend the product needs can be remote data processing.
- Open source has three roles: contributor, steward and manufacturer.
- The reporting obligation has applied to all products since 11 September 2026.
Do a scope assessment now if:
- you ship something the customer installs or runs themselves,
- your app or agent talks to an API you built,
- you publish open source and sell a paid edition or support around it,
- your product isolates containers or virtualises operating systems.
Frequently asked questions
Does the CRA apply to SaaS?
A service that is only reached through a browser is usually not a product with digital elements. If the service is needed for a product, such as an app or an agent, to perform a function, it can count as remote data processing and be part of that product.
Does the CRA apply to open source?
Only when it is supplied in the course of a commercial activity. Contributors are not covered. Legal persons that provide sustained support for commercially used open source can be stewards with a lighter regime. Whoever monetises the product is the manufacturer.
We run everything in a public cloud. Is the cloud provider responsible?
No. Code you designed and developed can be remote data processing even when it runs on someone else's IaaS or PaaS. According to the Commission's guidance, who operates it is not decisive.
Do we become a manufacturer if we build on someone else's product?
Yes, if you place it on the market under your own name or trademark, or make a substantial modification to a product already on the market (Articles 21 and 22).
Want help working out whether the CRA applies to you?
We are a Kubernetes and DevSecOps team based in Malmö, Sweden, and we build secure CI/CD chains and platforms for teams that ship software. As part of our gap analysis against the CRA and NIS2 we help you map which of your products are in scope, which services count as remote data processing, and how SBOMs and vulnerability handling connect to each delivery. The mapping is a technical assessment and not legal advice. We have experience from the defence sector and from assignments for Danish public authorities. Contact us for a quote or book a first technical conversation.
Read more:
- Compliance: NIS2 and the CRA in the platform
- DevOps and DevSecOps
- CRA SBOM requirements
- Kubernetes hardening as NIS2 evidence
- Case studies
- Contact us
Sources
Checked on 2 November 2026.
- Regulation (EU) 2024/2847 (Cyber Resilience Act), in particular Articles 2, 3, 4, 7, 8, 13, 24, 32, 64, 69 and 71, recitals 11, 12, 15, 18 and 20, and Annexes III and IV. eur-lex.europa.eu
- European Commission, guidance on the application of the CRA, C(2026) 5252, 27 July 2026 (non-binding), in particular points 20 to 21, 49 to 59 and 184 to 201, and examples 5, 13 and 19. digital-strategy.ec.europa.eu
