CRA Security Responsibilities for Mobile-App Backends

Recital 11 Makes Mobile-App Backends an Express CRA Example

Recital 11 expressly describes a mobile application that requires access to an application programming interface or database supplied through a service developed by the manufacturer. The recital states that such a service falls within the CRA as a remote data processing solution. Manufacturers should therefore avoid treating their mobile application as only the code distributed through an app store where important product functions are actually delivered from their own backend.

• Mobile applications can include qualifying remote processing.
• Manufacturer-developed APIs can be part of the product.
• Remote databases can be part of the product.
• Document the local and remote architecture together.

Apply the Article 3(2) Test to Each Backend Function

Not every remote endpoint used by a mobile application is automatically RDPS. The manufacturer should identify the processing performed at a distance, confirm that the software is designed and developed by it or under its responsibility and determine whether the application loses a genuine product function if the processing is unavailable. The test can be applied to authentication, synchronisation, account management, payments, commands, storage and other product-facing services individually.

• Identify remote processing.
• Identify development responsibility.
• Identify the dependent app function.
• Record outage behaviour.
• Document the RDPS conclusion.

The Backend Belongs in the Cybersecurity Risk Assessment

Where backend software forms part of the product as RDPS, Article 13 requires the product's cybersecurity risk assessment to consider that remote element. The manufacturer should evaluate how compromise of APIs, databases, authentication logic, remote commands or backend configuration could affect users and the local application. The assessment should reflect the product as actually deployed rather than treating the backend as an unrelated operational system.

• Assess API compromise.
• Assess database compromise.
• Assess authentication compromise.
• Assess remote command abuse.
• Assess backend configuration risks.

Unauthorised Access Controls Apply to Product-Facing Backend Functions

Annex I requires products, where applicable based on the risk assessment, to protect against unauthorised access through appropriate control mechanisms, including authentication, identity or access management systems. For mobile backends this means access control cannot be considered solely a user-interface feature. Server-side authorisation, privilege enforcement, credential handling, session controls and administrative access can all influence whether the product resists unauthorised access.

• Enforce authorisation server-side.
• Protect administrative access.
• Control sessions and credentials.
• Apply least-privilege principles where appropriate.
• Detect or report unauthorised access where applicable.

Protect Data Confidentiality in Transit and at Rest

Annex I includes protection of confidentiality for stored, transmitted and otherwise processed data, including through state-of-the-art encryption mechanisms where applicable. Mobile products often send credentials, account data, device state, personal information or configuration values through their backend. Manufacturers should therefore address transport protection, backend storage, key management and access to sensitive data as part of the product security design.

• Protect data in transit.
• Protect relevant stored data.
• Manage encryption keys appropriately.
• Restrict backend access to sensitive information.

Protect Commands and Configuration From Unauthorised Modification

Annex I also requires protection of the integrity of data, commands, programs and configuration against unauthorised manipulation or modification. This is especially important where a mobile application sends commands to a remote service that controls a device or changes account configuration. The backend should authenticate requests, enforce authorisation and preserve integrity across the complete command path.

• Protect command integrity.
• Protect configuration integrity.
• Validate incoming requests.
• Prevent unauthorised state changes.
• Protect security-sensitive backend configuration.

Backend Availability Can Be a Product Cybersecurity Requirement

Annex I requires protection of the availability of essential and basic functions, including after incidents, where applicable according to the risk assessment. If a mobile application's important functions depend on remote processing, denial of service or backend failure can become a product-security issue. The manufacturer should determine which remote functions require resilience, capacity protections, fail-safe behaviour or recovery measures.

Limit the Mobile Backend Attack Surface

Annex I requires products to be designed to limit attack surfaces, including external interfaces. Product-facing APIs are external interfaces by design and should expose only the operations necessary for the intended functions. Deprecated endpoints, administrative interfaces, excessive permissions, debug services and unnecessary data access can all increase the attack surface of the mobile product.

• Minimise exposed endpoints.
• Remove unnecessary functionality.
• Restrict administrative interfaces.
• Review deprecated APIs.
• Limit privileges available through the backend.

Third-Party Cloud Hosting Does Not Remove Backend Responsibility

Manufacturer-developed backend software can remain RDPS when it runs on independently supplied infrastructure. The Commission's 2026 guidance distinguishes manufacturer-controlled application software from provider-controlled IaaS or PaaS layers. The manufacturer should therefore secure and document its own application layer while evaluating relevant risks created by the external cloud provider and its services.

• Separate application responsibility from infrastructure responsibility.
• Assess cloud provider security risks.
• Use available provider controls.
• Keep product-level responsibility with the manufacturer.

Deeper Backend Systems Need a Boundary Decision

Not every enterprise system behind a mobile API becomes RDPS. Commission guidance limits the product-facing remote solution to software modules responsible for product functionality and relevant interfaces. Systems performing later processing that do not directly interact with the product can remain external dependencies. Their risks may still need to be considered where they can affect the product.

• Identify product-facing modules.
• Identify interfaces used by the app.
• Separate later internal processing.
• Assess external dependency risk separately.

Backend Changes Need Product-Security Review

Mobile backends can change independently from the distributed app binary. New API versions, authentication mechanisms, database architectures, cloud providers or account requirements can change the product risk profile without a new app-store release. Manufacturers should therefore maintain change controls that trigger review of the cybersecurity risk assessment and technical documentation when backend changes materially alter security characteristics.

• Track backend versions.
• Review security-relevant API changes.
• Review authentication changes.
• Review cloud provider changes.
• Update CRA evidence where applicable.

Maintain a Mobile Backend CRA Architecture Record

A practical record should identify the mobile application, product-facing APIs, databases, authentication services, remote processing modules, underlying cloud provider, external dependencies and deeper systems outside the RDPS boundary. For each remote service, record the product function supported, manufacturer responsibility and principal security controls. This creates a stable foundation for risk assessment, testing and technical documentation.

• Map mobile application functions.
• Map APIs and databases.
• Map authentication.
• Identify third-party infrastructure.
• Identify RDPS boundaries.
• Review after architecture changes.