Figuring out if your remote solution falls under the EU’s Cyber Resilience Act (CRA) is a major question for manufacturers. The short answer is this: if a remote data processing solution is essential for a product’s main function, it’s almost certainly within the CRA remote data processing solutions scope. The physical product and its necessary remote counterpart are treated as a single unit.
Is Your Remote Solution Covered by the CRA?
The Cyber Resilience Act introduces a new level of scrutiny for any “product with digital elements” (PDE) placed on the European market. This broad category covers everything from smart home devices and wearables to standalone software applications. The rules don’t stop at the device or software you sell; they extend to services operating in the background.
This is where the concept of a “remote data processing solution” becomes critical. The CRA defines this as any solution, designed by or under the responsibility of the manufacturer, that a product needs to perform one of its functions. Think of it as a mandatory digital partner to your physical product.
The Essential Functionality Test
So, how do you determine if your remote service is captured? The key is the “essential functionality” test. Ask yourself: can my product perform its primary intended purpose without this remote solution? If the answer is no, then the solution is in scope.
Practical Example 1: Smart Security Camera
The hardware is the camera itself. The remote data processing solution is the manufacturer-operated cloud service that processes video, detects motion, and sends alerts to your phone. Without this service, the camera is just a lens; it cannot perform its core security function. Therefore, both the camera and the cloud service fall under the CRA.Practical Example 2: Connected Car
A modern vehicle uses a remote server to receive critical over-the-air (OTA) updates for its engine control unit (ECU). These updates are vital for safety and performance. The car is the product, and the manufacturer’s update server is the essential remote solution. Both are within the CRA’s reach.
A common mistake is assuming that only paid services are in scope. The CRA applies if the product is part of a commercial activity, which includes free products supported by advertising or data monetisation. The dependency on the remote solution is the deciding factor, not its price tag.
Understanding this relationship is the first step toward compliance. For a deeper analysis of whether the CRA applies to your specific products, you might be interested in our guide on Cyber Resilience Act applicability. This linkage between a physical product and its digital brain is central to determining the full CRA remote data processing solutions scope for your portfolio.
Right, so how do you know if your remote data processing solution is actually caught by the Cyber Resilience Act? This is where a lot of confusion comes in, but the test regulators will use is actually quite straightforward.
It all boils down to one critical question: is the remote solution necessary for the product to perform its main function? We’re not talking about nice-to-have features or optional extras. If the product simply cannot do what you sold it to do without that remote connection, then the solution is almost certainly in scope.
Think of it this way: if the core value proposition advertised to the customer disappears when the internet connection drops, the CRA will see the product and the remote service as a single, inseparable entity.
The Core Functionality Test In Action
Let’s make this concrete with a couple of real-world examples. The line between in-scope and out-of-scope often depends on what makes the product “smart” in the first place.
Here is a simple table to help you think through this test for your own solutions.
CRA Scope Test for Remote Data Processing Solutions
| Functionality Test | In-Scope Example (Likely) | Out-of-Scope Example (Likely) |
|---|---|---|
| Is the solution required for the product’s primary advertised function? | A smart lock that authenticates users via a cloud server to unlock the door. Without the server, the main “keyless entry” feature fails. | An electric toothbrush that sends usage data to the manufacturer for product improvement analytics. The brush still cleans teeth without this connection. |
| Would a customer consider the product “broken” without the remote connection? | A security camera that streams live video to a mobile app via the manufacturer’s cloud. No cloud, no live stream. The product is useless. | A smart fridge that sends maintenance alerts to the manufacturer’s server. The fridge continues to cool food even if the server is offline. |
| Is the remote processing integral to the product’s identity? | A voice assistant speaker that processes commands on a remote server. Without the server, it’s just a speaker—not a voice assistant. | A connected car that offers an optional in-car weather app. The car’s primary function (driving) is entirely separate from the weather service. |
As you can see, the distinction is about necessity, not convenience. If the remote component is fundamental to the user experience you’ve promised, you need to treat it as part of the product for CRA purposes.
This decision tree helps visualise the logic. If your remote solution is essential for the product’s core purpose, the CRA treats them as one and the same.
A Closer Look at Exclusions and Grey Areas
Even with this test, there’s still a lot of debate, particularly around cloud services that support products. Industry groups are actively lobbying for clearer lines to be drawn. The big question is whether a service that is integral to a product with digital elements automatically inherits all CRA obligations.
A July 2023 position paper from DIGITALEUROPE proposes nine specific exclusion criteria (E1–E9) for Remote Data Processing Solutions (RDPS). It argues that services not providing core product functionality, or offline manufacturer activities like compiling software updates before they are sent, should be exempt.
This ongoing discussion means it’s more important than ever for manufacturers to carefully document why a specific remote service is or is not essential to the product’s main function. Your documented rationale will be your first line of defence in any regulatory conversation. For a deeper dive on this, you can read also our guide on the CRA scope.
Pinpointing When Your Compliance Clock Starts
Another crucial piece of the CRA remote data processing solutions scope is knowing when your obligations officially begin. The trigger isn’t your development kick-off or service launch date. Your compliance clock starts the moment a product is “placed on the market” in the EU for the first time.
This means the very first instance an individual product unit is made available for distribution or use in the EU as part of a commercial activity. Getting this timing right is absolutely vital for planning your development, documentation, and launch schedules.
So what does “placing on the market” mean in practice for remote solutions?
- For Bundled Products: Your obligations begin when the first hardware unit that relies on your remote service is sold or supplied in the EU. For example, if a French retailer receives the first shipment of a new smart thermostat model, the manufacturer’s CRA clock has started.
- For Standalone Software: It’s the moment the software is first downloaded or accessed by a user in the EU under a commercial agreement. For example, when a German company purchases a subscription and its employee first logs into a SaaS project management tool.
- For Services Updated Post-Launch: If you push a substantial modification to a product already on the market that changes its core function or security posture, that product is considered “newly” placed on the market. For instance, if a smart watch receives an update that adds a new health monitoring feature using a new cloud algorithm, that update re-triggers the full set of CRA obligations.
Understanding this specific trigger point is non-negotiable. It ensures your conformity assessments, technical documentation, and CE marking are all buttoned up before that first unit ever reaches a customer in the EU. A mistake here can result in costly recalls, market-access delays, and serious penalties.
How the CRA Reshapes Your Supply Chain
The Cyber Resilience Act’s reach extends far beyond the original product developer. It establishes a clear chain of accountability that follows a product from design to distribution, especially when it comes to the CRA remote data processing solutions scope.
Compliance is no longer a solo effort; it’s a team sport where every player in the supply chain—the manufacturer, importer, and distributor—has specific, legally binding duties. Knowing your role is crucial for keeping products moving into the EU market without facing major disruptions or legal penalties.
Let’s put this into practice. Imagine a German engineering firm that builds a smart sensor for industrial automation. This sensor is the “product with digital elements,” but it depends entirely on the company’s cloud server for real-time analytics and alerts. That server is its essential “remote data processing solution.”
The Manufacturer’s Core Duties
As the manufacturer, the German firm shoulders the heaviest compliance burden. Before that sensor can be sold, they are responsible for conducting a full cybersecurity risk assessment and a conformity assessment. This must prove that the entire product system—both the physical sensor and its remote server—meets the CRA’s essential requirements.
This process involves building out extensive technical documentation. This file serves as the definitive proof of compliance, detailing everything from the product’s architecture and security-by-design choices to its Software Bill of Materials (SBOM) and vulnerability handling plan.
Only after this is complete can the manufacturer draw up the EU Declaration of Conformity and affix the CE marking to the sensor. This mark is their public promise that the product and its remote solution are fully compliant.
The Importer as the First Gateway
Now, let’s say a French company wants to import these sensors to sell them within the EU. As the importer, this firm becomes the first official gateway into the Union market and has its own set of critical verification duties. They can’t just take the manufacturer’s word for it.
The importer is legally required to verify that the manufacturer has:
- Performed the correct conformity assessment procedure.
- Assembled the required technical documentation.
- Correctly affixed the CE marking to the product.
They must also add their own name and contact address to the product to ensure traceability. If an importer suspects a product is non-compliant, they must not place it on the market. For example, if the packaging lacks the importer’s address or the CE mark looks fraudulent, they are obligated to halt the process and inform both the manufacturer and the relevant market surveillance authorities.
By placing a product on the EU market, an importer is staking its own legal and financial reputation on that product’s compliance. They act as the regulatory backstop, preventing non-compliant goods from entering circulation.
The Distributor’s Final Checkpoint
Once the sensors are in the EU, a Spanish distribution company buys them from the French importer to sell to local factories. This distributor is the final link in the chain before the end-user, and their role is to act with “due care.”
Before making the product available to customers, the distributor must verify that it has the CE marking and comes with all necessary instructions and information, presented in a language their customers can easily understand. They also double-check that the manufacturer and importer have included their names and addresses for traceability.
If a distributor spots an issue, their obligation is the same as the importer’s: stop the sale and notify the parties up the supply chain. A practical example: if the distributor notices the user manual is only in German and they are selling in Spain, they must contact the importer to rectify this before selling the sensors. This model of shared accountability creates multiple checkpoints to catch non-compliant products, a topic we explore further in our overview of supply chain requirements for software.
Real-World Examples of In-Scope Remote Solutions
Definitions and theory only get you so far. To really understand the CRA remote data processing solutions scope, you need to see it applied to real products. The line between an in-scope and out-of-scope remote solution often boils down to a single, powerful question: is the remote processing essential for the product to do its main job?
Let’s walk through a few concrete scenarios. These examples are designed to give your product and engineering teams a clear mental model for spotting CRA-scoped solutions in your own product line-up.
Example 1: Connected Delivery Drones
Think about a company running a fleet of autonomous delivery drones. These drones aren’t just flying on their own; they’re designed to navigate busy cities, avoid no-fly zones, and land safely with their packages.
- The Product: The physical delivery drone.
- The Remote Data Processing Solution: A central command server, operated by the manufacturer, that provides real-time flight path calculations, geofencing updates, and emergency override commands.
Here, the dependency is absolute. Without a constant link to that command server, the drone simply cannot perform its core function of “autonomous delivery.” It can’t navigate safely, react to new obstacles, or follow flight regulations. The remote server isn’t an optional extra; it’s a non-negotiable part of the system. This makes it fall squarely within the CRA’s scope.
When a product’s safety and core function are tied directly to a remote service, the CRA treats them as a single entity. The drone and its server are not seen as separate—both must meet the CRA’s essential cybersecurity requirements.
Example 2: The Modern Smart Thermostat
Now consider a popular smart thermostat. Its main selling point is its ability to learn a household’s habits to automatically optimise heating and cooling, ultimately saving money on energy bills.
- The Product: The smart thermostat unit on the wall.
- The Remote Data Processing Solution: A cloud service that analyses historical usage data, runs machine learning models to predict heating needs, and pushes optimised schedules back to the device.
Sure, you can still walk up to the thermostat and change the temperature manually if the internet is down. But the “smart” features—the very reason customers chose this product—are completely dependent on the cloud. All the heavy lifting, the learning algorithms and data processing, happens on the manufacturer’s remote servers. Because its primary advertised function is “intelligent energy saving,” a function that is impossible without the remote service, that solution is in scope.
Example 3: Industrial Robotics and Remote Configuration
Imagine a factory that has just installed a new generation of high-precision industrial robots on its assembly line. A key feature of these robots is their adaptability—they can be reconfigured for different production runs and receive critical updates remotely.
- The Product: The industrial robot arm itself.
- The Remote Data Processing Solution: The manufacturer’s remote platform, used to push critical safety patches, update firmware, and upload new task configurations for different manufacturing jobs.
In this scenario, the remote platform is vital for the robot’s ongoing security, safety, and functionality. If the robot couldn’t receive a critical security patch, it could expose the entire factory network to a cyber-attack. If it couldn’t be reconfigured remotely for a new task, it would lose a huge part of its value. This direct link to both security and core functionality puts the remote platform firmly within the CRA remote data processing solutions scope.
The logic in each case is the same. The remote solution isn’t just a nice-to-have feature; it’s fundamental to the product’s primary purpose, safety, or identity. This dependency is the definitive test your teams should use when assessing your own products.
Your Documentation and Vulnerability Response Plan
Once you’ve confirmed your remote data processing solution falls under the CRA, it’s time to move from theory to action. Compliance isn’t just about having good intentions; it’s about proving them. This proof rests on two pillars: comprehensive documentation and a robust vulnerability management plan.
These aren’t just administrative box-ticking exercises. They are core operational requirements that demonstrate your product is secure by design and that you have a concrete plan to keep it that way. The CRA demands a clear, auditable trail—informal or purely reactive security practices simply won’t cut it anymore.
The First Pillar: Building Your Technical Documentation
Think of your technical documentation as the central evidence file for your product’s compliance. It’s the first thing market surveillance authorities will ask for, and it needs to tell a convincing story. Under Annex II, this file must be meticulously organised and hold several critical components.
Cybersecurity Risk Assessment: This is your foundation. You must document a thorough analysis of every potential cybersecurity risk tied to your product and its remote solution. It’s not a simple checklist. It’s a deep dive into threats, their potential impact, and the specific mitigations you’ve put in place. For a smart lock, for instance, you’d assess risks from replay attacks to credential stuffing on the remote server.
Software Bill of Materials (SBOM): You are required to create a detailed, machine-readable SBOM that lists every single software component. This covers your proprietary code and, crucially, all the open-source libraries used in your product and the remote solution. An SBOM for a fitness tracker’s app would detail every third-party library for Bluetooth, data sync, and UI elements.
Security-by-Design Evidence: You must prove security was baked in from the start, not bolted on at the end. This means documenting your secure development lifecycle (SDL), including evidence of threat modelling sessions, code reviews, and penetration testing reports. For example, you might include the report from a third-party pen test performed on your remote API before launch.
Your documentation must tell the complete story of your product’s security journey. It should show a regulator that every security decision was deliberate, from initial design to the final build, covering the entire CRA remote data processing solutions scope.
The Second Pillar: Structuring Your Vulnerability Response
The CRA’s rules on vulnerability handling are strict, time-sensitive, and will likely change how you manage security flaws forever. You are now on the hook for managing vulnerabilities for the product’s entire support period—which is typically at least five years.
The most dramatic change is the reporting timeline. Manufacturers must notify ENISA (the EU Agency for Cybersecurity) and the relevant national CSIRT of any actively exploited vulnerability within 24 hours of becoming aware of it. That tiny window demands a highly efficient, well-rehearsed internal process. For more on this, our detailed explanation of CRA reporting obligations under Article 14 can help you prepare.
To meet these demands, you absolutely need a formal plan.
Establish a Coordinated Disclosure Policy: Publicly post how security researchers can report vulnerabilities to you. Define your scope, the right communication channels (like a dedicated security email), and what they can expect from you in terms of response times.
Define Internal Triage and Assessment: Create a clear workflow for what happens the moment a vulnerability report lands. Who validates the issue? How will you score its severity using a standard like CVSS? And critically, who has the authority to declare it “actively exploited”?
Prepare for Rapid Reporting: Don’t try to figure this out during a live incident. Have a pre-defined process and designated people ready to make that 24-hour notification to ENISA. A SaaS company, for example, must have a 24/7 on-call security rotation empowered to make that call. Your plan should also address modern challenges, such as preventing AI hallucinations in any AI-driven systems.
By building out these two pillars, you turn abstract regulatory threats into a clear, manageable operational plan.
Your Compliance Roadmap to the 2027 Deadline
That December 2027 deadline for full Cyber Resilience Act compliance isn’t some far-off concept anymore. It’s a hard date that demands a clear plan, especially for organisations whose products fall under the CRA remote data processing solutions scope. A structured roadmap isn’t just a nice-to-have; it’s the only way to avoid a last-minute crisis.
Trying to tackle this in the final year is a recipe for failure. The work involves deep technical assessments, overhauling documentation, and making fundamental operational changes—none of which can be rushed. The only way to keep your products on the EU market without interruption is to start now with a methodical, phased approach.
Phase 1: Starting Now
The first and most important step is getting a complete picture of your product portfolio. You simply can’t secure what you don’t know you have. This initial phase is all about discovery.
Your immediate priority needs to be a full product portfolio audit. The goal here is to identify every single product—both software and hardware—that has a remote data processing element as part of its core function.
- Action: Build a master inventory of every product you sell or plan to sell in the EU.
- Example: A smart home device manufacturer would list its smart plugs, cameras, and thermostats. For each, they’d need to document the cloud services used for control and data analysis, as these are the in-scope remote solutions.
- Outcome: You’ll end up with a comprehensive list of all potential “products with digital elements” and the remote services they depend on.
Phase 2: Late 2024 to Early 2025
Once your inventory is locked down, the next phase is all about risk classification and deep analysis. This is where you shift from identifying what you have to understanding how the CRA applies to each product.
At this stage, you’ll apply the CRA’s risk criteria directly to your products. You’ll classify them based on their potential cybersecurity impact, which in turn determines the conformity assessment path you must follow.
Under the CRA, products are categorised by risk. The vast majority will be “Default Class,” but products listed as “Important” or “Critical” face much stricter conformity assessment procedures, often requiring third-party involvement.
Your key tasks are:
- Classify Products: Go through your list and determine if your products are Default Class or if they fall into the higher-risk “Important” or “Critical” categories defined by the European Commission. A practical example: a consumer-grade smart lightbulb is likely Default Class, while an industrial control system for a power grid would be Critical Class.
- Conduct Detailed Risk Assessments: For every in-scope product, you need to perform a thorough cybersecurity risk assessment as outlined in the CRA. This means identifying threats, analysing their potential impact, and documenting the security controls you have in place.
Phase 3: Mid-2025 to Mid-2027
This final stretch is the most intensive. It’s focused on execution—pulling together all your evidence and formalising your compliance processes before the clock runs out.
During this period, you’ll be finalising all the required documentation and getting your organisation ready for its ongoing post-market obligations. As you build out your documentation and vulnerability response plans, it’s wise to look at established industry certifications; learning about SOC 2 Compliance for RON Platforms can offer valuable insights into data security and integrity best practices.
Your final steps include:
- Complete Technical Documentation: Assemble the complete technical file required by Annex II. This includes your risk assessment, SBOM, and all evidence of your security-by-design approach.
- Perform Conformity Assessments: Carry out the self-assessment (for Default Class) or the third-party assessment (for higher-risk classes) and officially issue the EU Declaration of Conformity.
- Operationalise Post-Market Processes: Finalise and test your vulnerability handling and 24-hour reporting workflows. You need to be sure you can meet these ongoing obligations from day one.
Frequently Asked Questions
Working out how the CRA remote data processing solutions scope applies to your own products can be confusing. Below are some clear, practical answers to the most common questions we hear from manufacturers and product security teams.
Does a Simple API for Data Retrieval Fall Under the CRA?
It all boils down to a test of “necessity”. Ask yourself: if the remote solution stopped working, would the product still be able to perform its main advertised function?
For instance, an API that feeds real-time stock prices to a financial tracking app is absolutely essential. The app can’t do its core job without it, so that remote solution is definitely in scope. On the other hand, an API that just lets a user download a PDF manual is a secondary feature, not a core function, placing it outside the CRA’s direct reach.
The critical factor is dependency. If the product’s advertised purpose relies on the data from the remote solution, that solution becomes part of the regulated system.
Who Is Responsible if My Product Uses AWS for Backend Processing?
You, the product manufacturer, are. The Cyber Resilience Act is unambiguous here: the manufacturer of the final product placed on the EU market must ensure the entire system is compliant.
While a cloud provider like AWS gives you secure infrastructure, that’s just one piece of the puzzle. You are still responsible for making sure your specific application, its configurations, and all your data handling practices running on top of that infrastructure meet every single CRA cybersecurity requirement. You cannot simply delegate or outsource this final legal accountability.
What if My Remote Data Processing Solution Is Hosted Outside the EU?
The physical location of your servers makes no difference. The CRA’s authority is tied to where the product is placed on the market, not where the manufacturer or its infrastructure is physically located.
This means if you sell your product to customers anywhere in the EU, it must comply with the CRA. A classic example is a product sold in Germany that relies on a remote server in the United States for its functionality. The whole system—both the physical product in Germany and the US-based server—must be fully compliant with CRA regulations.
Importers have a legal duty to verify this compliance before placing the product on the EU market. This makes global compliance a basic requirement for market access, rendering geography irrelevant to your obligations.
Navigating the complexities of the CRA and understanding its scope for your products can be a major challenge. Regulus provides a clear, step-by-step software platform to assess applicability, map requirements, and build your compliance documentation efficiently. Gain clarity and confidence in your path to the 2027 deadline by visiting https://goregulus.com.
