Does the CRA Reach Your Cloud Backend? The Remote Data Processing Test, Explained
Most hardware manufacturers assume their CRA obligations stop at the product's casing. Firmware, sure. Companion app, maybe. But the cloud backend that the device quietly phones home to? Someone else's compliance problem, surely - it's just infrastructure.
The Commission's July 2026 implementation guidance says that assumption is wrong for a specific, well-defined category of backend, and getting the classification wrong means missing Annex I obligations, a risk assessment, and a Declaration of Conformity that should cover infrastructure you already run.
The three-part test
A backend counts as a remote data processing solution (RDPS) - and is treated as part of your product - when three conditions are true at the same time:
- It runs at a distance. The processing happens away from the user's device, not on it.
- The product needs it for a function. Without it, the product can't do something it's supposed to do.
- You built it, or had it built for you. It's your design and your responsibility, not someone else's off-the-shelf product you simply licensed.
The guidance puts it plainly: a backend is remote data processing when it runs at a distance, your product needs it to perform a function, and you built it or had it built for you.
Ownership decides it, not who runs the servers
The most common misreading is assuming that hosting arrangements matter - that using a third-party cloud provider gets you out of scope. They don't. What matters is who designed the service, not who operates the infrastructure it runs on. A bespoke backend you commissioned from a contractor is still yours for this test, even if it runs entirely on someone else's servers.
"Function" is also deliberately read broadly. It's not limited to the feature on the box - sending commands to the device, file sync, user onboarding, remote configuration, security updates and authentication all count. A thermostat you can also operate with the physical dial doesn't get an exemption for its app-based control path just because a manual fallback exists; the remote path still needs a scope assessment on its own terms.
Three buckets, one decision per backend dependency
Every backend your product depends on lands in exactly one of three categories:
| Category | Test result | What follows |
|---|---|---|
| RDPS | Distance + function-critical + you built it | Full CRA conformity scope: Annex I requirements, risk assessment, Declaration of Conformity, vulnerability handling |
| Component | Distance + function-critical, but a third party's product | Integration risk assessment and supplier due diligence, not full conformity duties |
| Out of scope | Not needed for the function, or pure connectivity | No conformity duty, though basic communication-risk assessment still applies (cellular networks are excepted) |
Worked examples make the line clearer:
- In scope (RDPS): your own REST API syncing a companion app's data; your proprietary smart-home cloud controlling connected devices; a bespoke inference service you commissioned, even if it runs on someone else's GPUs.
- Component, not RDPS: a licensed identity provider like Auth0 or Okta; an off-the-shelf storage SaaS you integrated; a third-party LLM API called for a feature; a vendor-run support chat isolated from core product functions.
- Out of scope entirely: your internal CI/CD, CRM or payroll systems; the cellular or Wi-Fi connectivity itself; telemetry collected purely for statistics, not needed for any function; a marketing site your app happens to link to.
The line moves with the contract, not the vendor
The guidance's sharpest point: the same vendor can land on either side of the line depending on what you bought from them. Have a provider build you bespoke infrastructure and it's yours for RDPS purposes, however impressive their engineering. License their existing, unmodified product instead, and it's a component with a lighter due-diligence duty. Same company, different contract, different answer - which means "who's our cloud vendor" is the wrong question. The right one is "did we have this built for us, or did we buy what already existed."
What to actually do with this
Walk through every function your product markets, trace each one to whatever backend makes it work, and classify that dependency into one of the three buckets. Where you land on RDPS, that backend needs to show up in your technical file, your risk assessment and your Declaration of Conformity exactly as if it were a physical component - because under the CRA, that's precisely what it is.
Related reading
Three Weeks Into CRA Reporting: What Early Users Learned and What a "Disclosure Delay" Really Means
Article 14 reporting has been live for three weeks. Here is what early users of ENISA's Single Reporting Platform report, what a "disclosure delay" does and does not change, and the four things worth doing this week.
CRA SBOM Requirements: What Goes Inside, Which Format Versions to Use, and Where VEX Fits
The CRA says your SBOM must be machine-readable but not what fields it needs. Here is what goes inside, which CycloneDX and SPDX versions still count, and why VEX is optional.
Does the Cyber Resilience Act Require Penetration Testing?
The CRA never mentions penetration testing. Annex I, Part II, point 3 requires "effective and regular" security tests - here is what that means in practice.