CRA Remote Data Processing Solutions Scope Explained

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 you designed a remote data processing solution (or had it designed) and the product could not perform one of its functions without it, it’s within the CRA remote data processing solutions scope. The product and that 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 the remote half of your product.

The “One of Its Functions” Test

So, how do you determine if your remote service is captured? The key is the functionality test in the CRA’s definition. Ask yourself two things: did we design this remote solution, or have it designed under our responsibility? And would its absence prevent the product from performing one of its functions, not just its main one? If both answers are yes, 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: Robot Vacuum
  A robot vacuum relies on the manufacturer’s cloud to store its maps and let users schedule cleaning from an app. It can still clean when started by hand, but map-based and remote cleaning stop working without the server. The vacuum is the product, and the manufacturer’s cloud is its remote data processing solution. Both are within the CRA’s reach. (A type-approved car would not be: vehicles under Regulation (EU) 2019/2144 are excluded from the CRA.)

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 one of its functions? The law does not say the main function, so a secondary feature counts too. If the product would lose any function you sold it with when that remote connection is gone, and you designed the remote side, then the solution is in scope.

Think of it this way: if a feature advertised to the customer disappears when the manufacturer’s servers are unreachable, 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)
Would the product lose one of its functions without the solution?	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.
Was the remote processing designed by or for the manufacturer?	A voice assistant speaker that processes commands on a remote server. Without the server, it’s just a speaker—not a voice assistant.	A smart TV that opens a third-party weather website in its browser. The website was not designed by or for the TV manufacturer, so it is not the TV’s remote data processing solution.

As you can see, the question is whether a function depends on it, not whether it is the headline feature. If the product would lose any of its functions without a remote component you designed, you need to treat it as part of the product for CRA purposes.

This decision tree helps visualise the logic. If the product needs your remote solution to perform a function, the CRA treats them as one and the same.

A Closer Look at Exclusions and Grey Areas

Even with this test, there are grey areas, particularly around cloud services that support products. Two limits come straight from the definition: a service designed and developed outside the manufacturer’s responsibility is not the product’s remote data processing solution, and a pure SaaS offering with nothing placed on the market as a product is a NIS2 matter rather than a CRA one.

This means it’s more important than ever for manufacturers to carefully document why a specific remote service is or is not needed for one of the product’s functions. 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 buys a licence and its employee first installs a desktop project management application. (A purely hosted SaaS tool with nothing installed is outside the CRA.)
• 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.

In Regulus, free for manufacturers: check whether the CRA applies to your product, with the article behind each answer.

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: would the product lose one of its functions without the remote processing?

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, unless the drone is certified under the EU aviation safety rules (Regulation (EU) 2018/1139), which takes it out of the CRA.

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 “intelligent energy saving” is one of its functions, and it 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 was designed by the manufacturer, and without it the product loses a function. That dependency is the 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 VII, 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 draw up an SBOM in a commonly used, machine-readable format covering at the very least the top-level dependencies of the product. Good practice goes further and covers 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 must be at least five years, unless the product is expected to be in use for less time.

The most dramatic change is the reporting timeline. Manufacturers must send an early warning of any actively exploited vulnerability within 24 hours of becoming aware of it, through the single reporting platform, to the CSIRT designated as coordinator and to ENISA (the EU Agency for Cybersecurity) at the same time. 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.

1. 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.

2. 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”?

3. 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. A connected-device manufacturer, for example, needs 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” (Annex III, Class I or II) or “Critical” (Annex IV) face much stricter conformity assessment procedures, often requiring third-party involvement.

Your key tasks are:

1. 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 listed in Annexes III and IV of the regulation. A practical example: a consumer-grade smart lightbulb is likely Default Class, a router is Class I, and a smart meter gateway is critical.
2. 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 VII. 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, and for Class I when harmonised standards, common specifications or a suitable certification scheme are applied in full) or the third-party assessment (in the other cases) and officially issue the EU Declaration of Conformity.
• Operationalise Post-Market Processes: Finalise and test your vulnerability handling and 24-hour reporting workflows. The reporting obligations have applied since 11 September 2026, so this cannot wait for 2027.

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 all of its functions? And did you design that solution, or have it designed for you?

For instance, a backend API that the app’s manufacturer runs to feed real-time prices to its financial tracking app is in scope: the app can’t do its job without it. 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 one of the product’s functions relies on a remote solution designed by or for the manufacturer, 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.