Mobile Banking Apps Under the CRA: Navigating Remote Data Processing Obligations for Financial Entities

Financial entities are used to thinking about cybersecurity through the lens of entity-level regulation: DORA, NIS2 and supervisory expectations. The Cyber Resilience Act^[1] (the “CRA”) introduces a different perspective – it regulates individual products. For example, a mobile banking app published in an app store is a product with digital elements (governed by the CRA). CRA vulnerability and incident reporting requirements already apply from 11 September 2026 and the main obligations become applicable on 11 December 2027. ^[2] The question of where the “product” ends and the bank’s wider IT estate begins has therefore become key. The Commission’s Guidance on the Application of the CRA (the “Guidance”) addresses precisely this question, using a mobile banking application as its first illustrative use case. ^[3] This article explains that use case, what it means for the boundary between in-scope remote data processing and external dependencies, and how third-party SaaS integrations should be handled. The Guidance is not binding, but it sets out the Commission’s interpretation and will shape how market surveillance authorities approach compliance. ^[4]

The banking app as a product with digital elements

A mobile application that a user downloads from e.g., an app store and installs on a smartphone or laptop executes on the user’s device and is therefore a product with digital elements; where it is placed on the market in the course of a commercial activity, it may thereby fall within the CRA.^[5] By contrast, a web application accessed exclusively through a browser is not itself a product, unless it supports the functionality of one.^[6] The distinction matters for banks offering both a native app and online banking: the native app is the CRA product, and the browser-based service is relevant only insofar as it supports that product.

Crucially, the CRA defines a product with digital elements as a software or hardware product and its remote data processing solutions.^[7] A bank cannot therefore confine its compliance analysis to the software on the customer’s phone. 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 its responsibility, and the absence of which would prevent the product from performing one of its functions.^[8]

The RDPS test in brief

The Guidance reduces the definition to two decisive and cumulative questions (once processing takes place “at a distance”): (i) would the absence of the processing prevent the product from performing one of its functions; and (ii) is the software designed and developed by the manufacturer, or under its responsibility? Only if both answers are affirmative does the processing qualify as an RDPS. If the first answer is yes but the second is no, the third-party solution is to be treated like a component. If the first answer is no, the processing falls outside RDPS but its risks must still be assessed.^[9]

Two limiting principles frame the test. First, recital 11 of the CRA makes clear that RDPS requirements do not entail measures to manage the security of a manufacturer’s network and information systems as a whole.^[10] Second, the Commission expressly excludes internal systems such as HR, payroll, CRM and CI/CD pipelines, as well as security testing activities, from the notion of RDPS.^[11] For a bank, this is an important signal: the CRA is not a backdoor route to regulating core banking infrastructure as a product.

The banking interface versus the ledger

The Commission’s use case describes a financial entity that places a mobile banking app on the market, supported by self-hosted infrastructure. The customer is authenticated through a “banking interface” developed and hosted by the entity, which receives the app’s requests and returns responses. That interface verifies identity by querying the account-management system and, when a transfer is initiated, submits a request to the ledger system. The account-management and ledger systems, logically segregated from the banking interface, record the transaction, and the ledger returns the status via the interface to the customer.^[12]

The banking interface is an RDPS. It is necessary for the app to authenticate the customer, submit instructions and return the resulting status, and it is designed and developed under the bank’s responsibility. It must therefore be included in the cybersecurity risk assessment and in the implementation of the essential requirements for the product as a whole.^[13]

The account-management and ledger systems are not RDPS. The app does not interact with them directly, but only through the banking interface, and the subsequent processing of an instruction, including recording, settlement and clearing, is carried out by systems with which the app has no direct contact.^[14] Notably, the final Guidance refines the reasoning of the consultation draft. The draft stated that these systems did not support one of the app’s functions; the final text concedes that their availability may be necessary for a function to be completed, but anchors the exclusion in the absence of direct interaction.^[15] This “direct interaction” criterion is now the operative boundary: RDPS is limited to the software modules responsible for the product’s functionality and the interfaces those modules use with external services.^[16]

For financial entities, the practical lesson is architectural. Logical segregation between customer-facing interfaces and core systems is not merely good security practice; it also helps to delimit the scope of the conformity assessment. A monolithic back end in which the app talks directly to the ledger would be harder to carve out.

External dependencies remain within the risk assessment

Falling outside RDPS does not mean falling outside the bank’s CRA analysis. The CRA establishes two complementary obligations: a cybersecurity risk assessment for the product under Article 13(2), and due diligence regarding integrated components under Article 13(5).^[17] Where risks originate outside the product, the CRA does not require the manufacturer to control or govern the external environment; it requires the manufacturer to identify those risks and mitigate them through the design of the product itself. The CRA regulates how the product responds to external risks, not how back-end infrastructure is organized, staffed or operated.^[18]

The Guidance accordingly describes back-end systems as “external dependencies” that must be assessed and mitigated through product-level measures.^[19] In the banking use case, compromise of the ledger could allow an attacker to influence transaction results displayed in the app. The bank must address that risk through measures such as strong authentication of back-end interfaces, integrity protection of transaction data, secure communication channels and verification of responses received by the app.^[20] In other words, the ledger is out of scope, but its potential to undermine the app is very much in scope. Risk assessments should therefore map dependencies explicitly, document why each one is or is not an RDPS, and link each relevant threat to concrete controls in the app or the banking interface.

Third-party SaaS: chat, notifications and beyond

Modern banking apps integrate a range of third-party services. The Guidance distinguishes cloud service models: software deployed by the manufacturer on third-party IaaS or PaaS may qualify as RDPS, whereas a third-party SaaS application, offered as a fully developed product with limited configuration, is not designed and developed by or under the responsibility of the manufacturer.^[21]

The use case applies this to an integrated customer-support chat built and operated by a third party. The chat is necessary for one of the app’s functions but is not an RDPS. It should nonetheless be treated like a third-party component: the chat channel could be used to impersonate the bank or deliver malicious content, and the bank must mitigate those risks through product-level measures such as isolating the chat from core banking features, controlling data flows and validating content, and must exercise due diligence on the SaaS provider.^[22] The same logic applies where SaaS elements are integrated in a way that affects the product’s security: the manufacturer must address the risks on the product itself and exercise due diligence proportionate to the risk.^[23]

The consultation draft also contained a transaction-notification example: notification logic written by the bank and deployed on a third-party PaaS was an RDPS, while the PaaS itself was to be treated like a component.^[24] Although dropped from the final use case, the example remains a useful illustration of the general PaaS analysis. Banks should note that tailor-made code remains an RDPS regardless of who hosts it, since it is design and development, not operation, that is decisive.

Several practical consequences follow. The technical documentation must state that the product has RDPS or relies on third-party remote solutions and describe them.^[25] Evidence of compliance with DORA, among other assurance artefacts, may be re-used in support of the manufacturer’s assessment and due diligence.^[26] Contracts and SLAs with third-party providers should embed security guarantees, including vulnerability handling, and require providers to notify changes, which may trigger a revised risk assessment; a major change by the provider does not, however, amount to a substantial modification of the bank’s product.^[27] For banks, this creates a welcome opportunity to align DORA ICT third-party risk processes with CRA due diligence rather than build parallel workstreams, although the Commission has signaled that further guidance on the CRA–DORA interplay may follow.^[28]

Critical voices raised

It worthwhile to know that Svenska Bankföreningen (the Swedish Bankers’ Association (the “Association”)) has taken a clear position on the issue of CRA-DORA interplay/overlap. In its consultation response of 14 April 2026 on the Swedish inquiry into supplementary provisions to the CRA (SOU 2025:115), it raised no objections to the proposed national implementation but warned of overlapping and duplicative requirements in relation to DORA.^[29] The Association noted that, although DORA is not a product regulation, it applies precisely to the systems through which financial services are delivered via digital channels, and is supervised by Finansinspektionen (the Swedish Financial Supervisory Authority) already. Applying the CRA on top would, in the Association’s view, add complexity and cost without strengthening security, for example through parallel incident reporting to Finansinspektionen under DORA as well as to ENISA and the NCSC under the CRA.

The Associate therefore argues that financial services provided through digital channels, such as mobile banking apps, payment cards, ATMs and payment terminals, should be exempted by a delegated act under Article 2(5) CRA, which allows the Commission to exclude products already covered by Union rules offering the same or a higher level of protection. It points out that DORA covers the full lifecycle of these systems, including governance, risk management, incident and vulnerability handling and customer communication, and urges that such a delegated act be adopted as soon as possible, mirroring DORA’s recognition as lex specialis under NIS2. Until any such exemption is adopted, however, the Commission’s Guidance confirms that banking apps remain within the CRA, and financial entities should plan accordingly.

Concluding remarks

The Commission’s banking use case offers financial entities a workable boundary: the app and the interfaces it talks to directly are the product; the ledger, account-management and wider core systems are not. Yet the boundary is one of scope, not of responsibility. Banks must still assess the risks those dependencies pose, design the app and its interfaces to withstand them, and treat integrated SaaS services as components subject to due diligence. Entities that document their architecture carefully, segregate customer-facing interfaces from core systems, and leverage their existing DORA frameworks will be well placed to demonstrate compliance before December 2027.

[1]Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), OJ L, 20.11.2024, ELI: http://data.europa.eu/eli/reg/2024/2847/oj (the “CRA”).

[2]CRA, recital 126: the Regulation applies from 11 December 2027, save that the reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026 and the provisions on notification of conformity assessment bodies from 11 June 2026.

[3]European Commission, Guidance on the Application of the Cyber Resilience Act, Annex to Commission Notice C(2026) 5252, 27 July 2026 (the “Guidance”), section 8.3.1 (“Mobile banking application”). An earlier draft circulated for public consultation (3 March to 13 April 2026) contained a corresponding section 8.3.1 entitled “Banking application” (the “Draft Guidance”).

[4]Guidance, para. 8. Only the Court of Justice of the European Union may give an authoritative interpretation of the CRA; the examples in the Guidance are not intended to replace a case-by-case assessment.

[5]Guidance, section 2.1, Example 3; see also European Commission, FAQs on the EU Cyber Resilience Act (version of 3 December 2025), section 1, listing a mobile app downloadable via an app store as a product with digital elements.

[6]Guidance, section 2.1, Example 5.

[7]CRA, Article 3(1); Guidance, para. 178.

[8]CRA, Article 3(2); Guidance, paras. 180 and 184.

[9]Guidance, paras. 188–202 and the stylized flowchart at Figure 9.

[10]CRA, recital 11, quoted in Guidance, paras. 181–182.

[11]Guidance, para. 182, which excludes, inter alia, HR, payroll, CRM and CI/CD systems, as well as penetration testing, threat hunting and red teaming.

[12]Guidance, section 8.3.1, ‘Self-hosted infrastructure developed by the financial entity’.

[13]Guidance, section 8.3.1, ‘Implications for RDPS’, first bullet.

[14]Guidance, section 8.3.1, ‘Implications for RDPS’, second bullet; see also para. 205.

[15]Compare Draft Guidance, section 8.3.1 (stating that the ledger and account-management systems ‘do not interact directly with the app and do not support one of its functions’) with Guidance, section 8.3.1 (acknowledging that ‘their availability may be necessary for a function to be completed’ but limiting the CRA to parts of the system that interact directly with the product). The Draft Guidance also referred to a ‘banking API layer’ rather than a ‘banking interface’.

[16]Guidance, para. 205. See also Draft Guidance, para. 189, noting that the intent is not to cover the entire entity’s environment.

[17]CRA, Article 13(2) and (5); Guidance, section 7.3.

[18]Guidance, para. 169.

[19]Guidance, para. 206.

[20]Guidance, section 8.3.1, second bullet under ‘Implications for RDPS’.

[21]Guidance, paras. 197–201.

[22]Guidance, section 8.3.1, ‘Third-party SaaS for customer support’.

[23]Guidance, paras. 201–202(c).

[24]Draft Guidance, section 8.3.1, ‘Reliance on third-party PaaS for transaction notifications’. This example does not appear in the final Guidance, although the general PaaS analysis in Guidance, para. 199, is unchanged in substance.

[25]Guidance, para. 204.

[26]Guidance, para. 207(b). Regulation (EU) 2022/2554 of 14 December 2022 on digital operational resilience for the financial sector (DORA), OJ L 333, 27.12.2022, p. 1.

[27]Guidance, para. 208.

[28]Guidance, para. 9; CRA, recital 125.

[29]Svenska Bankföreningen, Remissyttrande: Betänkandet Kompletterande bestämmelser till EU:s cyberresiliensförordning (SOU 2025:115), 14 April 2026, ref. 2026/01/018 (Ministry of Finance ref. Fi2026/00065), signed by Hans Lindberg and Magnus Jacobson.