Banking Apps Under the EU Cyber Resilience Act: Scope, Remote Data Processing and the New Reporting Obligations

Update (July 2026): The Commission has now formally adopted its CRA application guidance (C(2026) 5252 final, 27 July 2026), and the mobile banking app worked example this article walks through is retained in the adopted text. The adopted guidance also adds a useful clarification: the CRA applies to the banking app your customers install. Online banking accessed purely through a web browser is not itself a product with digital elements, though back-end software may still be in scope as remote data processing. It also confirms the reporting obligations from 11 September 2026 apply to apps already on the market, and continue even after a product’s support period ends. Read our follow-up: App or Browser? 

If your bank offers a mobile banking app, the EU Cyber Resilience Act (CRA) applies to you, even though the app is free to download. The European Commission’s FAQ guidance uses the banking app as one of its worked examples, and it’s worth understanding what it says.

Many financial institutions have assumed the Cyber Resilience Act is aimed at technology companies rather than banks. It’s an understandable assumption: customers download banking apps for free, and a bank’s core business is financial services, not software.

The Commission’s FAQ guidance clarifies the position. A banking app is a product with digital elements, the bank is its manufacturer, and parts of the back-end infrastructure the app relies on form part of the product too. This article walks through the banking app use case in the guidance, explains how remote data processing is treated, and connects this to the reporting obligations that apply from 11 September 2026.

Why a Free Banking App Is Still a Commercial Product

A common misconception about the CRA is that it only applies to products sold for a price. The regulation’s definition of ‘manufacturer’ says otherwise. Under Article 3(13), a manufacturer is anyone who develops or manufactures products with digital elements and markets them under their name or trademark, whether for payment, monetisation, or free of charge.

Your customers don’t pay to download the app, but the app is the channel through which they access banking services that generate revenue for your institution. The FAQ guidance confirms that where software is provided through which a manufacturer monetises other products or services, that software is placed on the market in the course of a commercial activity.

Remote Data Processing: The Product Doesn’t Stop at the Phone

One of the most significant concepts in the CRA for app providers is remote data processing. Article 3(1) defines a product with digital elements as a software or hardware product and its remote data processing solutions. In other words, the product isn’t just the app installed on the customer’s phone—it includes certain back-end software as well.

Article 3(2) 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 the absence of which would prevent the product from performing one of its functions.

The FAQ guidance breaks this into three elements, and it’s worth understanding each one:

1. Is the data processing ‘at a distance’?

Remote data processing typically takes place outside the user’s environment—a cloud-based function accessed from a mobile app is the classic example. Importantly, the guidance makes clear that remote data processing doesn’t have to run on third-party cloud infrastructure. A solution running on the manufacturer’s own servers, on-premises or in a private cloud, is just as likely to qualify as one running on a public cloud.

2. Would its absence prevent the product from performing one of its functions?

The notion of ‘functions’ is broad. It isn’t limited to the product’s core purpose, it covers both the functions users directly experience and those that support the product’s overall performance. The guidance lists examples including sending commands to a device, synchronising files, onboarding users, receiving updates, and identity and access management.

By contrast, remote processing that the product could function without, such as telemetry collected purely for statistics or future product development—doesn’t meet this test.

3. Was the software designed and developed by the manufacturer, or under its responsibility?

Software developed in-house naturally qualifies. So does software built by an external provider specifically for the manufacturer, what the guidance describes as tailor-made solutions built solely on the manufacturer’s behalf, based on its designs and specifications, where the manufacturer owns rather than licenses the technology.

Notably, who operates the solution is not the deciding factor. If a bank designs and develops a back-end service that a third party then operates, the bank remains responsible for that service’s compliance as part of the product.

If all three elements are met, the software is a remote data processing solution (RDPS) and forms part of the product. That has practical consequences: the RDPS must be included in the cybersecurity risk assessment, covered by the essential cybersecurity requirements, described in the technical documentation—and, as we’ll see below, considered when meeting the CRA’s reporting obligations.

The Banking App Use Case: Where the Boundaries Fall

The FAQ guidance applies this framework to a worked example of a financial entity placing a banking app on the market, with back-end systems supporting authentication, authorisation, account management and payments.

The banking API layer: part of the product

When a customer initiates a transfer, the request goes to the banking API layer—developed by the financial entity and self-hosted. The API authenticates the customer by querying the account management system and submits a request to the ledger system.

The API layer is necessary for the app to support financial transactions, and it’s designed and developed under the bank’s responsibility. Both parts of the RDPS test are met, so the banking API layer is an RDPS and part of the product. It must be included in the cybersecurity risk assessment and in the implementation of the essential cybersecurity requirements for the product as a whole.

The account management and ledger systems: external dependencies

The account management and ledger systems sit behind the API layer, logically segregated from it. Because they don’t interact directly with the app and don’t support one of its functions, they fall outside the definition of RDPS.

That doesn’t mean they can be ignored. The guidance describes them as external dependencies that may give rise to significant cybersecurity risks for the product—for example, a compromised ledger system could allow an attacker to influence transaction results that are then displayed in the app. Those risks need to be identified in the risk assessment and mitigated through controls implemented at the product level, such as verification of responses and graceful degradation.

Helpfully, the guidance also confirms that the intent of the CRA is not to bring the bank’s entire environment into scope. CRA requirements apply only to those parts of the system where data intended for the provision of product functions is stored or processed. Segregating systems and data makes it easier to draw that line, and the underlying hardware infrastructure sits outside the scope of the product altogether (though risks from it still feed into the risk assessment).

Third-party services: components, not RDPS

The use case also covers two common third-party scenarios:

• A third-party customer support chat (SaaS): necessary for one of the app’s functions, but not designed or developed under the bank’s responsibility—so not an RDPS. It’s treated like a third-party component: the bank assesses the risks it introduces (such as an attacker using the chat channel to impersonate the bank), mitigates them through product-level measures like isolating the chat from core banking features, and exercises due diligence on the provider.
• Notification code running on a third-party platform (PaaS): the bank writes and deploys its own notification logic on a cloud provider’s platform. The bank’s own code qualifies as RDPS; the provider’s underlying platform doesn’t, but is treated like a component, with risks assessed and due diligence exercised.

Why This Matters Now: Reporting Obligations From 11 September 2026

The scoping questions above are not just an academic exercise. From 11 September 2026, manufacturers are required to report actively exploited vulnerabilities and severe incidents impacting the security of their products with digital elements—and the FAQ guidance is explicit that the product for these purposes includes its remote data processing solutions.

For a bank, that means the reporting obligation extends to the banking API layer and any other back-end software qualifying as RDPS. An actively exploited vulnerability in the API layer is a reportable event, just as one in the mobile app itself would be.

How the reporting process works

The timelines under Article 14 are structured in stages:

Manufacturers report once, through the CRA Single Reporting Platform. The notification goes to the CSIRT designated as coordinator in the Member State of the manufacturer’s main establishment and is made available simultaneously to ENISA.

When does the clock start?

The guidance addresses a practical question: when is a manufacturer deemed to have ‘become aware’? A manufacturer is regarded as aware when, after an initial assessment of a suspicious event, it has a reasonable degree of certainty that a vulnerability in its product is being actively exploited or that a severe incident has compromised the product’s security. The emphasis is on prompt action to carry out that initial assessment—particularly where the vulnerability may pose a significant risk.

Informing users

Alongside notifying authorities, manufacturers must inform impacted users—and where appropriate, all users—of actively exploited vulnerabilities and severe incidents. The guidance takes a proportionate, risk-based view here: informing users does not mean indiscriminate public disclosure. For products used in sensitive environments, such as banking, detailed information can be limited to the users or customers concerned, with broader disclosure considered once the vulnerability has been adequately addressed.

What This Means in Practice

Bringing the threads together, a bank offering a mobile app will want to:

• Map the product boundary. Identify which back-end software qualifies as RDPS (like the banking API layer), which systems are external dependencies (like the ledger), and which integrated services are third-party components. Documenting this in the technical documentation is a CRA requirement in itself.
• Cover the whole product in the risk assessment. The assessment should address risks in the RDPS, risks from third-party components and cloud services, and risks arising from the wider environment—mitigated through product-level controls.
• Extend vulnerability handling and incident response to the RDPS. Detection, assessment and escalation processes need to cover the API layer and other back-end RDPS, so that the 24-hour early warning is achievable if a vulnerability there is actively exploited.
• Prepare for the Single Reporting Platform. Ensure incident response playbooks reflect the staged notification timelines and identify the coordinating CSIRT for your main establishment.
• Exercise due diligence on third parties. For providers of components and cloud services, the guidance points to evidence such as NIS 2 compliance, European cybersecurity certification, or conformity with standards like ISO/IEC 27001.

A Sensible Starting Point

The banking app use case is one of the more useful parts of the FAQ guidance because it shows how the Commission expects manufacturers to reason about product boundaries in a real architecture: app, API layer, segregated core systems, and a mix of third-party services. For most banks, the underlying security practices are already in place—the work lies in mapping them to the CRA’s structure of product, RDPS, components and dependencies, and making sure reporting processes reach every part of that product.

With the reporting obligations applying from 11 September 2026, that mapping exercise is a sensible place to start.