Under DORA, a mobile banking app that supports a critical or important function needs resilience testing at least once a year. Most testing programmes still treat it as a thin client on top of the API, and miss the parts of it that only exist on the device.
The Digital Operational Resilience Act has applied across the EU since 17 January 2025. Most of the discussion since then has been about two things: threat-led penetration testing for the largest institutions, and the oversight of critical third-party providers such as cloud platforms.
Both matter. But ask how a retail customer actually reaches their bank today, and the answer for most people is not a branch, a website or a data centre. It is an app on their phone. They log in with it, move money with it, approve payments with it and talk to support through it.
That app is one of the most exposed pieces of software a bank runs. It is installed on hardware the bank does not control, in the hands of anyone who downloads it. And in a lot of DORA testing programmes I have seen discussed, it is covered by testing the API behind it and assuming the rest follows.
This piece sets out what DORA asks for, why the mobile app is in scope, and what testing it properly involves.
What DORA requires from resilience testing
DORA's testing rules sit in Chapter IV, Articles 24 to 27, and they work in two tiers.
The baseline applies to almost every financial entity in scope. Article 24 requires a digital operational resilience testing programme as part of the ICT risk management framework. Article 24(6) then requires financial entities, other than microenterprises, to test all ICT systems and applications supporting critical or important functions at least yearly. The tests must be carried out by independent parties, internal or external. Microenterprises follow a lighter, risk-based approach.
Article 25 sets out what those tests can be. The list is broad: vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing. Supervisors treat the list as examples. The obligation is to choose tests that fit the risk.
The advanced tier applies only to selected entities. Articles 26 and 27 cover threat-led penetration testing, or TLPT. Competent authorities decide which institutions must do it. Those institutions run it at least every three years, against live production systems supporting several critical or important functions, following Delegated Regulation (EU) 2025/1190, which is aligned with the TIBER-EU framework. The detailed rules are in Delegated Regulation (EU) 2025/1190.
The important point for most banks, payment institutions and insurers is that TLPT does not replace the baseline. Even an institution selected for TLPT still owes annual testing in the years between.
Does DORA cover mobile banking apps?
DORA never mentions mobile apps by name. It does not need to. The scoping question is not which channel something is, but whether it supports a critical or important function.
DORA defines a critical or important function as one whose disruption would materially impair the entity's financial performance, the soundness or continuity of its services, or its regulatory compliance. For a retail bank, payment institution or neobank, the functions customers rely on most, such as account access, payments and payment approval, increasingly run through the app.
If that is true for your institution, the app is not a peripheral channel. It is one of the ICT applications supporting a critical or important function, and the annual testing obligation applies to it in its own right, not only through the backend it calls.
There is a practical test for whether your programme reflects that. Look at last year's testing scope and check whether the mobile binary, both platforms, appears in it as a target. If the only mobile-related line is the API, the app was assumed rather than tested.
What testing a mobile banking app should cover under DORA
Article 25's menu maps onto a mobile app more directly than people expect. Five areas carry most of the risk.
The binary. Source code review where feasible and open source analysis both apply to what ships to the device. That means checking the compiled iOS and Android apps for embedded secrets, hardcoded endpoints, debug code left in release builds, and the libraries bundled inside them. Anything in the binary should be treated as readable by anyone who installs the app.
Authentication and payment approval. Banking apps carry strong customer authentication: device binding, biometrics, long-lived refresh tokens and in-app approval of payments made elsewhere. These flows have no web equivalent. Testing has to show they cannot be bypassed, replayed or moved to another device, because they are often the last check before money moves.
What the app leaves on the device. Tokens, cached account data and logs written to local storage, and whether any of it survives logout. A phone can be lost, shared or compromised by another app, and the bank does not control which.
Every API version still in use. Customers do not all update. Older app versions keep calling older API endpoints, sometimes with weaker checks than the current ones. End-to-end testing that only follows the current app misses them. The scope should include every version you still allow to connect.
Third-party SDKs. Banking apps routinely bundle code from analytics, fraud, identity and support vendors. Each SDK runs with the app's permissions and many send data to the vendor's own servers. That puts them inside open source analysis at minimum, and often inside the third-party risk conversation DORA already requires you to have.
Penetration testing ties these together. It is the test that shows whether an issue in one area, such as a token stored badly, actually becomes access to an account.
Can automated or AI pentesting satisfy DORA TLPT?
No, and any vendor implying otherwise is overreaching.
TLPT is a bespoke, intelligence-led red team exercise. It starts from threat intelligence specific to the institution, runs against live production, is overseen by the competent authority, and follows TIBER-EU. The testers must meet specific experience requirements. No platform, ours included, is a substitute for that.
Where continuous testing fits is everywhere else. The baseline under Articles 24 and 25 is a minimum, at least yearly. A mobile banking app ships far more often than that, on two platforms, while older versions stay live. An annual test sees one build of each. Testing that runs against each release covers the builds in between, keeps the evidence for the annual programme current, and means a TLPT team spends its time on the hard scenarios rather than on findings that could have been fixed months earlier.
The two are complementary. TLPT tells you whether a capable, motivated attacker could get through. Continuous testing makes sure the easy routes are already closed when they try.
What this does and does not settle
This is a testing view, not legal advice. Which functions count as critical or important is your institution's own assessment, and how your competent authority reads proportionality may differ from mine. Your compliance and legal teams own that call.
Testing is one pillar of five. DORA also covers ICT risk management, incident reporting, third-party risk and information sharing. A strong mobile testing programme helps with the evidence for some of those. It does not make you compliant on its own.
A clean test is not proof of resilience. It shows what the test reached, in the time it had. That is exactly why the scope matters more than the result.
Where Deus Rex sits
Deus Rex tests web, iOS and Android across the binary, the runtime and the traffic, and it is in use on live mobile engagements now. Findings are confirmed by exploitation and come with the evidence attached, which gives an annual testing programme the evidence it needs, alongside its own prioritisation and remediation records.
We did not come to mobile through banking. Cyrex spent twelve years testing software for studios and enterprises that shipped on mobile to millions of users, with real money moving through the apps and people actively trying to break them. Payment flows, device-bound sessions and client-side checks were the everyday work. A banking app is the same problem with a regulator watching.
If your DORA testing scope lists the API but not the app, that is worth a conversation.
deusrex.ai
Written by
Tim De Wachter
CTO Deus Rex
