As a CRA compliance platform that itself operates as SaaS, we at Kunnus know this question firsthand: How does the Cyber Resilience Act affect Software-as-a-Service? The answer is more nuanced than it first appears – and has far-reaching consequences for SaaS providers across Europe.
The Principle: SaaS Does Not Directly Fall Under the CRA
The CRA regulates "products with digital elements" that are "placed on the market" in the EU. Software-as-a-Service is not placed on the market in the traditional sense – it is provided as a service. Users do not install software locally but access the application through a browser or API.
This distinction is intentional: the CRA is meant to regulate products, not services. For regulating services and operators, the EU created the NIS2 Directive. SaaS providers classified as essential or important entities fall under NIS2 – not the CRA.
But this clean separation has limits. In practice, the line between product and service increasingly blurs, and the CRA explicitly addresses some of these gray areas.
When SaaS Does Fall Under the CRA
There are three important scenarios where SaaS providers are directly or indirectly affected by the CRA.
Scenario 1: Remote data processing as part of a product. When a SaaS service functions as remote data processing for a hardware product and is provided by the same manufacturer, this remote processing falls under the CRA. This affects, for example, cloud backends for IoT devices where the cloud component is necessary for the device's core function. A smart home hub that cannot function without the manufacturer's cloud service pulls that cloud service into the CRA's scope.
The decisive criteria: the remote processing must be designed and provided by the product manufacturer, and the product must require this remote processing for its essential functions. Purely optional cloud features or third-party services are not captured.
Scenario 2: Downloadable software. When a SaaS provider offers a locally installable software component alongside the cloud service – such as a desktop app, browser plugin, or mobile app – that component falls under the CRA as a standalone product. The SaaS backend itself remains outside the scope, but the local client is treated as a product with digital elements.
Scenario 3: SaaS as part of the supply chain. Even when a SaaS product does not directly fall under the CRA, manufacturers of CRA-obligated products can pass down supplier requirements to SaaS providers. If your SaaS service is embedded in the development process or infrastructure of a CRA-obligated product, customers will increasingly demand security evidence and SBOM information.
Impact on the SaaS Market
Even SaaS providers not directly subject to the CRA will feel the regulation's effects.
Increased customer requirements. Manufacturers who must comply with the CRA will increasingly demand security evidence from their software suppliers – including SaaS providers. This includes information about open-source components used, vulnerability management processes, and security certifications. SaaS providers who proactively supply this information gain a competitive advantage.
SBOM demand. The CRA establishes the SBOM as a standard for software component transparency. This expectation will extend to SaaS even without a direct legal obligation. Customers will ask: What libraries and frameworks does your SaaS product use? How quickly do you respond to vulnerabilities in those components?
Security by design as market standard. CRA principles – security by design, secure defaults, continuous vulnerability management – will establish themselves as industry standards. SaaS providers who do not implement these principles will find it harder to win enterprise customers.
What SaaS Providers Should Do Now
Even without direct CRA applicability, SaaS providers should act proactively.
Clarify NIS2 status. Check whether your company falls under the NIS2 Directive. Many SaaS providers, particularly in digital infrastructure and cloud computing, qualify as essential or important entities and must meet NIS2 requirements.
Identify local software components. If you provide desktop apps, mobile apps, browser extensions, CLI tools, or SDKs alongside your cloud service, these fall under the CRA. Create a complete inventory and begin the conformity assessment.
Build SBOM capability. Develop the ability to create and maintain SBOMs for your software products – even if there is no legal requirement for SaaS (yet). This is becoming a hygiene factor in enterprise sales.
Formalize vulnerability management. Establish a documented vulnerability management process, including coordinated disclosure. Publish a security.txt file and make it easy for security researchers to report vulnerabilities.
Review remote data processing. If your SaaS service functions as a backend for hardware products, clarify with the hardware manufacturers whether your services qualify as remote data processing under the CRA. If so, you must meet CRA requirements for that portion of your service.
How Kunnus as a SaaS Platform Enables CRA Compliance
Kunnus is itself a SaaS product – and simultaneously helps manufacturers implement CRA compliance for their products. We understand the challenges from both sides: as a SaaS provider that must meet its customers' security expectations, and as a platform that digitizes the entire CRA compliance process.
From SBOM management through vulnerability monitoring to documentation and audit preparation – Kunnus brings all CRA-relevant processes together in a single platform. This lets manufacturers focus on their core competency while compliance administration runs automatically in the background.
Unsure whether and how the CRA affects your SaaS product? Start with our free CRA readiness assessment – it gives you clarity about your situation and next steps within minutes.