One of the most confusing parts of the Cyber Resilience Act for companies with cloud architectures isn't about security requirements. It's about the boundaries of responsibility and ownership in the cloud – and a more fundamental question beneath it all: is your cloud backend even part of the product the CRA regulates?
The answer isn't as clean as you'd hope. And it hinges on something that has nothing to do with whether you're using cloud at all. We know – it could stand to be simpler. Stick with us:
The CRA regulates "products with digital elements" – hardware and software with network connectivity. But a pure web application that users access exclusively through a browser is, according to the Commission's guidance, typically not a product with digital elements.
The browser is the user's software, not yours. You're delivering a service, not an installed product – and that distinction changes everything.
Many SaaS companies that run everything in a browser are not manufacturers under the CRA and are therefore not subject to the requirements that apply to manufacturers.
That's the good news. Here's what you do need to watch.
Remote Data Processing Solutions (RDPS) is the term the CRA uses when a cloud backend is an integrated part of a product. What matters isn't where your code runs – it's what it does for the product.
The Commission's guidance poses three questions, and your backend only qualifies as RDPS if you can answer yes to all three:
A mobile app that calls your API to fetch real-time data. Firmware in an IoT device that communicates with your cloud to carry out one of its functions – whether that's the device's primary purpose or a supporting one. An installed desktop application that syncs with your backend. In all of these cases, your backend is likely RDPS – and part of the product in the CRA's sense.
When you use cloud infrastructure from a third-party provider, the critical question is which layer you're actually responsible for.
IaaS (Infrastructure as a Service): You're renting virtual servers and network capacity. The software you run on that infrastructure is your responsibility – and qualifies as RDPS if the conditions are met. The hypervisor layer and underlying infrastructure are the provider's component, not yours.
PaaS (Platform as a Service): You deploy your application code to a managed platform. Your code is still your RDPS. The platform runtime itself belongs to the provider.
SaaS (Software as a Service): You're using a third-party application. It's an external component – not your RDPS. But it doesn't disappear from your compliance picture either (more on that below).
A useful rule of thumb: what you designed and built is yours. What you bought and integrated is a component.
That’s manageable, right?
Your architecture might land in a position where your cloud backend is a third-party component – something you rely on but didn't build yourself. That doesn't exempt you from all obligations.
The CRA requires that you assess what happens to your product's security if that component fails or is compromised.
You need to document that you've evaluated your provider's security posture. And you need to implement controls in your own product – authentication, integrity verification, and isolation – that reduce the risk introduced by the dependency.
That's a long way from full RDPS compliance. But it's far from nothing. And it's an area many companies consistently get wrong.
Here are three common architectures and the RDPS assessment each one lands on.
Scenario A – Pure SaaS via browser: Your company delivers a project management tool that users access through Chrome. Everything runs in your cloud. There's no installed client. → Likely not a product with digital elements. Not RDPS. CRA manufacturer requirements typically don't apply.
Scenario B – Mobile app with cloud backend: You have an app in the App Store that uses your API to fetch real-time data and run calculations. Without the API, the app doesn't work. → The app is the product. Your API is RDPS. Both are within CRA scope.
Scenario C – IoT device with cloud control: You sell a smart sensor that sends data to your cloud for analysis and receives commands in return. The device can't operate independently. → The device is a product with digital elements. The cloud backend is RDPS. Full manufacturer compliance applies.
If you're a manufacturer with RDPS, the same core requirements apply as for any other software under the CRA. Security has to be built in from the start – vulnerability management, access control, encryption, and a minimal attack surface aren't options you layer on later. They're design principles.
You need to document your security architecture and be able to report actively exploited vulnerabilities to the relevant authorities within 24 hours. And you need to provide support for the full lifetime of the product – or clearly state when that support ends.
The requirements apply to the product as a whole, including your RDPS backend.
Questions about RDPS scope, third-party components, and documentation requirements can feel abstract until they apply to your specific architecture.
These steps are about putting what you've read here into practice.
Step one: Map your architecture. Identify all cloud components and run them through the three questions: Does processing happen outside the user's device? Is the product functionally dependent on it? Did you design and build it?
Step two: Draw the line between RDPS and third-party components. That boundary determines which requirements you're directly accountable for – and which call for due diligence on your vendors.
Step three: Start building your documentation now. The CRA's security documentation requirements aren't something you put together the day before the deadline. Start with the technical documentation of your architecture and the security decisions behind it.
Scoping cloud under the CRA is rarely black-and-white, as most architectures contain elements that pull in different directions.
If you're not sure where yours lands, you're not alone. NorthGRC brings over 20 years of advisory experience, and we can help you map your RDPS scope and build the compliance documentation you need.