11.03.2026
Dr. Andreas Kotulla
Cyber Resilience Act
Software companies often rely on a familiar distinction: they regulate products, but not services. They have viewed cloud delivery models, subscription-based offerings, and remote processing as business innovations. They have also seen them as ways to reduce regulatory exposure. The EU Cyber Resilience Act (CRA) challenges this assumption. Under the CRA, the key question is not whether a company markets a solution as “SaaS.” It is whether the solution forms part of a “product with digital elements” that the company places on the market. When remote data processing is essential to a product’s core functionality, the cloud backend may fall within the regulatory scope.
The Legal Shift: Remote Data Processing as Part of the Product
The CRA defines “remote data processing” as data processing performed at a distance. The manufacturer designs, develops, or oversees it. Without this processing, the product cannot perform one of its functions.This distinction is significant. This means that when a connected device or locally installed software relies on backend infrastructure to function, the remote component counts as part of the product. It is not just an ancillary service. It becomes part of the regulated ecosystem.
This blurs the traditional SaaS versus product distinction. A locally installed endpoint agent that works only when connected to the vendor’s cloud may trigger CRA relevance. So can a smart device whose core analytics run remotely or a software product whose main features rely on cloud processing. The architectural choice to move functionality into the cloud does not automatically remove it from regulatory scrutiny. Instead, it shifts the analysis toward whether that functionality is essential.
Vulnerability Handling Follows the Architecture
Once the manufacturer treats remote processing as part of the product’s functionality, the CRA’s lifecycle obligations come into effect. Manufacturers must address and remediate vulnerabilities without delay, provide security updates where appropriate, and comply with reporting duties in case of actively exploited vulnerabilities or severe incidents. These obligations do not stop at the firmware or the downloadable binary. If the backend service is necessary for the product’s operation, vulnerabilities in that service may have regulatory consequences.
This is where is no longer an exemption. A critical flaw in a cloud-based authentication service, a vulnerable backend API, or an exploited open-source component can directly affect a product’s security on the EU market. The exploit may occur outside the EU. Still, the CRA’s reporting and handling obligations can apply if the product is marketed in the Union.
Copyleft and the Cloud: A subtle but important convergence
The implications extend beyond cybersecurity compliance. For companies that rely heavily on free and open-source software in their backend, integrating remote processing into the product’s core functionality adds complexity. This integration creates an additional layer of challenges. While the CRA does not alter copyright law, it changes how regulators view the boundaries of responsibility. When manufacturers treat remote components as part of the product lifecycle, due diligence, documentation, and vulnerability management obligations also apply to those components.
In practice, this brings remote infrastructures closer to the level of scrutiny traditionally associated with on device code. For organizations that have historically viewed SaaS deployment as reducing copyleft exposure, this regulatory convergence may require a re-evaluation of assumptions. Architectural decisions taken for licensing or distribution reasons may now have compliance and risk-management implications under product security law.
The SBOM Dimension: Visibility Into the Backend
Perhaps the most practical consequence of this shift concerns Software Bills of Materials (SBOMs) and Software Composition Analysis (SCA). If remote data processing is essential to a product’s core functionality, manufacturers must understand what is inside that backend environment. Open-source libraries, transitive dependencies, AI-generated components, and legacy code in cloud services all matter for risk assessments. They are also critical for vulnerability management.
An SBOM that covers only device firmware or client-side applications may no longer provide a complete compliance picture. To meet due diligence requirements under Article 13 and support vulnerability handling under Annex I, Part II, organizations may need backend SBOM visibility. They also need continuous dependency monitoring and structured processes to track and remediate vulnerabilities across distributed architectures.
This is not merely a documentation exercise. Without accurate inventory data, organizations struggle to assess exploitability, determine if a vulnerability affects the product, and respond effectively within regulatory timelines. The more essential the cloud component, the stronger the case for extending SBOM and SCA practices into the SaaS layer.
Strategic Implications for Product Design
The CRA does not prohibit SaaS models, nor does it automatically classify every cloud feature as regulated. Optional, clearly separable, and genuinely ancillary services may remain outside the scope of product obligations. The more tightly coupled the remote functionality is to the product’s intended purpose, the harder it becomes to argue that the backend falls outside the regulatory framework.
For product and compliance teams, this means architectural decisions must consider not only performance and scalability but also regulatory exposure. The line between service and product is no longer just commercial—it is a legal and operational question affecting support periods, vulnerability reporting, conformity assessments, and documentation strategies.
Beyond Scope: Building Trust in a Cloud-Centric World
Ultimately, the CRA reflects a broader principle: cybersecurity is not a one-time certification. It is a continuous responsibility throughout a product’s lifecycle. Whether functionality runs on a chipset, in a container, or in a remote data center, what matters is its role in enabling the product to operate.
Organizations that treat SaaS as a compliance escape may find the line between service and product thinner than expected. Those that invest early in supply-chain visibility, backend SBOM management, and structured vulnerability processes will navigate this evolving landscape more effectively.
If you need help understanding how remote architectures, open source components, and SBOM-driven transparency interact under the CRA, contact us.