CRA: is your cloud backend part of the product you must secure?

A mobile application, connected device or software package may appear to be a clearly bounded product.

But what happens when its operation depends on an API or remote service?

The Cyber Resilience Act does not necessarily limit the product to what is installed on the user's premises or device. A product with digital elements includes a software or hardware product and its remote data processing solutions when the conditions in the Regulation are met.1

Guidance published by the European Commission on 27 July 2026 specifically clarifies this scope.2

For manufacturers and software vendors, the question becomes practical: where does the product that we have to secure actually end?

The backend can be part of the product

The CRA defines remote data processing as data processing at a distance for which the software is designed and developed by the manufacturer, or under the manufacturer's responsibility, and whose absence would prevent the product with digital elements from performing one of its functions.1

Two elements therefore matter in particular: the relationship with the manufacturer and whether the remote service is necessary for a product function.

Consider a connected camera.

The camera captures video locally. But its configuration application calls a remote API. Authentication runs through the manufacturer's backend. Some security features and updates also depend on remote services.

The product actually delivered to the user may therefore extend beyond camera + application.

The relevant chain can be broader:

device → application → API → backend → remote functions.

The Commission explicitly identifies remote data processing solutions among the scope questions clarified by its 2026 guidance.2

Not every cloud service automatically becomes part of the product

It would be equally misleading to conclude that every cloud service consumed by an application automatically becomes part of the product under the CRA.

The relationship between the remote service and the function provided needs to be reconstructed.

A simple starting question is: what happens if this remote service disappears?

If the product continues to perform all its functions, the service plays a different role from one whose absence makes a product function impossible.

Teams then need to determine who designed or commissioned the relevant software and under whose responsibility it operates.

The analysis becomes:

product function → remote processing required? → software designed by or under the responsibility of the manufacturer? → dependency essential to the function?

This avoids two opposite errors: treating the entire cloud stack as part of the product, or assuming that cloud services can never be part of it.

A cybersecurity question becomes an architecture question

The difficulty appears quickly when product teams lack a consolidated view of dependencies.

A user-facing function can involve a local application, API, authentication service, business backend, database, update service and several third-party components.

To determine the relevant scope, teams need to reconstruct:

function → software → flow → API → remote service → operator.

They can then distinguish dependencies directly associated with the product from underlying technical dependencies.

This distinction matters for risk assessment, vulnerability management and security maintenance.

Constructed case: a connected camera and its cloud

Imagine a security camera sold in the European Union.

It provides four functions: capturing video; allowing remote viewing from a mobile app; sending an alert when movement is detected; and receiving security updates.

Video capture works locally. User authentication, however, depends on a backend operated under the manufacturer's responsibility. Notifications also rely on remote infrastructure. Some configuration data is stored in the cloud.

Each function should therefore be considered separately.

Local capture: the function can continue without the backend.

Remote viewing: it depends on authentication and remote APIs.

Notifications: they require remote processing.

Updates: they depend on infrastructure controlled by the manufacturer.

A hardware-only representation would hide an important part of how the product actually operates.

The useful unit of analysis is no longer only the physical component. It is the function provided to the user and the elements required to perform it.

Scope needs to remain understandable throughout the product lifecycle

The challenge does not end when the product is placed on the market.

Architectures evolve. A service can be replaced. An API can be outsourced. A previously local function can move to the cloud. A new provider can be introduced.

The CRA also establishes cybersecurity requirements across the product lifecycle and addresses support periods. The July 2026 guidance devotes significant attention to their interpretation.2

Security scope should therefore not be treated as a snapshot taken only at design time.

Organisations need to follow the evolution of:

product → functions → components → remote services → responsibilities.

Since 11 September 2026, the question is even more concrete

The CRA's main requirements will apply from 11 December 2027, but not every obligation waits until then.

Since 11 September 2026, the CRA reporting obligations have already applied.3

Manufacturers must report certain actively exploited vulnerabilities and severe incidents affecting the security of their products.

That makes scope knowledge even more important.

When a vulnerability affects a backend, API or remote component, the manufacturer needs to determine quickly: which products depend on it? which versions are affected? which functions are impacted? is the remote service within the product scope? which users may be exposed?

The boundary between product and infrastructure is therefore no longer merely regulatory terminology. It affects the ability to understand and manage a cybersecurity event.

Map the product through its functions

A useful representation can start simply:

product → function → component → flow → remote service → responsible party.

It can then be enriched with versions, software dependencies, processed data, providers, vulnerabilities, support periods and update mechanisms.

This representation keeps a clear distinction between the product visible to the user and the architecture actually required for it to operate.

That second boundary is precisely what the CRA now requires manufacturers to understand.