DORA and Mobile App Security: What Financial Institutions Need to Know

And unlike a backend system sitting behind several layers of infrastructure, the mobile application itself is distributed directly to customers.

An attacker can download it.

It handles authentication. It communicates with backend services. It processes sensitive data. It may use device permissions and cryptographic functions. It may depend on third-party components.

A weakness in any of these areas can introduce risk.

Consider a few examples.

Sensitive information might be stored insecurely on the device.

An authentication mechanism might be implemented incorrectly.

A security control might be possible to bypass.

A secret might be embedded inside the application package.

An attacker might be able to reverse engineer part of the application and learn how it works.

None of these automatically means that a financial institution has suffered a major incident.

But they are the kinds of weaknesses security teams need to identify, assess, and address when managing application risk.

DORA entered into application on 17 January 2025 and establishes a harmonised framework for digital operational resilience across the EU financial sector. Its scope includes ICT risk management, incident management and reporting, resilience testing, and ICT third-party risk. European Securities and Markets Authority: DORA

One of the important ideas behind DORA is that resilience cannot be separated from technology risk.

Financial institutions need to understand the ICT systems supporting their services, identify weaknesses, test their resilience, and address issues they uncover.

That includes applications.

DORA's Article 24 establishes requirements for a digital operational resilience testing programme. For financial entities other than microenterprises, Article 24(6) goes further: appropriate tests must be conducted at least once a year on all ICT systems and applications supporting critical or important functions. DORA consolidated text on EUR-Lex

Article 25 then provides examples of appropriate testing activities, including vulnerability assessments and scans, open-source analyses, network security assessments, source-code reviews where feasible, and penetration testing. DORA consolidated text on EUR-Lex

That does not mean every financial institution needs to perform every one of these tests on every application.

DORA takes a risk-based approach.

But it does make one thing clear:

Testing the technology behind critical financial services needs to be a recurring part of the resilience programme.

So what should you actually look for in a mobile application?

A mobile security assessment should not stop at a list of vulnerabilities.

The more useful question is:

Start with what the application contains and what it leaves behind.

Is sensitive information stored locally?

Are credentials, tokens, keys, or other secrets embedded in the application?

Could sensitive information appear in logs or other accessible locations?

These issues can become particularly important for applications handling financial or personal information.

How does the application establish a user's identity?

How are sessions managed?

What happens when credentials or tokens expire?

Can authentication controls be bypassed?

A mobile application should not be trusted simply because the user has successfully logged in once. The application and its backend services still need to enforce appropriate security controls throughout the session.

Mobile applications frequently rely on encryption to protect information and communications.

But saying 'the app uses encryption' does not tell you whether the implementation is secure.

Security testing should consider how cryptographic functions are implemented, how keys are handled, and how the application establishes and validates secure communication with backend services.

A mobile application is distributed to users.

That means an attacker can obtain the application package and analyse it.

They may try to understand its logic, inspect its components, modify it, or bypass security controls.

This is one reason mobile application security needs to consider not only vulnerabilities but also the application's resistance to analysis and tampering.

Modern applications rarely consist entirely of code written by the development team.

SDKs, libraries, frameworks, and other third-party components can introduce their own security and maintenance considerations.

Knowing what is inside the application is therefore part of understanding its security posture.

This is where we need to draw an important boundary.

A mobile application may communicate with dozens of APIs, and those APIs can introduce serious security risks of their own.

Broken authorization, authentication weaknesses, excessive data exposure, and business logic flaws can all affect the security of a financial service.

But mobile application security and API security are not the same thing.

A secure mobile application does not automatically mean its APIs are secure.

API endpoints need to be assessed separately as part of the organization's broader application and API security programme.

Suppose a mobile security assessment identifies a weakness.

The obvious next step is remediation.

But remediation is not always the only layer of defence available.

Some mobile threats involve attackers analysing the application itself, running it in controlled environments, capturing sensitive information, or attempting to modify its behaviour.

This is where application protection can complement security testing.

Testing asks: what can we find?

Protection asks: how can we make the application harder to attack?

The two serve different purposes.

Aquila is built around three parts of the mobile security lifecycle:

Scan. Protect. Monitor.

Aquila provides static and dynamic mobile application testing to help identify security weaknesses in mobile applications.

The static analysis runs against the compiled .apk or .ipa, which means the assessment covers the application package itself, including third-party code and libraries bundled into it alongside your own code.

The goal is to give security and development teams visibility into the application's security posture and the issues that require attention.

This can support the routine testing programme required under DORA Articles 24 and 25, but it is not a substitute for every form of testing those articles may require.

Some applications also need additional protection against analysis, tampering, and other forms of abuse.

Aquila provides protection capabilities including:

These controls can make certain attack techniques more difficult and add another defensive layer to the application.

They do not replace secure development or vulnerability remediation. They complement them.

The application does not stop being exposed to threats after it is released.

Aquila also provides application behaviour monitoring to help organizations identify unusual activity and potential threats.

This extends the security conversation beyond the initial assessment.

What DORA testing does not mean

It would be a mistake to reduce DORA to 'run a security scan once a year.'

DORA's testing requirements have different layers.

Articles 24 and 25 establish the broader digital operational resilience testing programme and include recurring testing of ICT systems and applications supporting critical or important functions. Article 26 introduces a separate, more advanced requirement for threat-led penetration testing (TLPT) for financial entities identified as being in scope, while Article 27 sets requirements for the testers conducting that work. DORA consolidated text on EUR-Lex

Aquila's automated static and dynamic testing can support the routine testing programme under Articles 24 and 25, but it does not satisfy DORA's TLPT requirements under Articles 26 and 27.

TLPT has its own eligibility, scope, methodology, tester-independence, and supervisory requirements. For entities identified as being subject to TLPT, the testing is conducted at least every three years. EBA: Threat-Led Penetration Testing under DORA

That distinction matters.

A mobile security scan can tell you a great deal about the security of an application. It is not the same thing as an intelligence-led, threat-led penetration test.

DORA is an EU regulation. It does not automatically apply to every financial institution or technology company outside the EU.

But that does not mean organizations outside Europe can ignore it.

There are two different things to understand here.

An organization outside the EU may provide ICT services to an EU financial institution.

In that situation, the EU financial institution remains responsible for managing the ICT risks associated with its third-party relationships. DORA sets requirements for those contractual arrangements, including provisions around security measures, incident support, continuity, monitoring, audit, and other areas. DORA consolidated text on EUR-Lex

So a Nigerian software or technology company does not need to be an EU financial entity directly subject to DORA for DORA-related security expectations to become relevant to the relationship.

For most technology providers outside the EU, this is the more relevant issue.

DORA also created a separate EU-level oversight framework for ICT third-party providers that are formally designated as Critical ICT Third-Party Providers, or CTPPs.

This is a much narrower category.

On 18 November 2025, the European Supervisory Authorities published the first list of designated CTPPs under DORA. The designation followed a criticality assessment based on factors including systemic importance, support for critical or important functions, and substitutability. EBA: ESAs designate Critical ICT Third-Party Providers

Being a technology provider to an EU financial institution does not automatically make a company a CTPP.

For most vendors, the relevant issue is the security and resilience expectations that flow through their contractual relationship with the financial institution they serve.

Direct EU-level oversight is a separate regime for providers that meet DORA's criticality criteria and are formally designated.

DORA is not a mobile security checklist, and a mobile security platform cannot make an organization DORA compliant.

DORA covers a much wider range of responsibilities, including ICT risk management, incident management, resilience testing, governance, and third-party risk.

Mobile application security is one part of that larger programme.

For the mobile layer, a practical security lifecycle can be straightforward:

Understand → Test → Remediate → Protect → Monitor → Repeat

Understand the applications you have and what they support.

Test them regularly.

Review and remediate the findings.

Add protection where it makes sense.

Monitor what happens after deployment.

Then repeat the process as the application changes.

That recurring approach matters because mobile applications are not static. New releases introduce new functionality. Dependencies change. Authentication flows change. Security controls change.

DORA reinforces the importance of maintaining that testing discipline. For financial entities other than microenterprises, Article 24(6) requires appropriate tests at least yearly on ICT systems and applications supporting critical or important functions. DORA consolidated text on EUR-Lex

Aquila can support the mobile application security layer of that broader programme through testing, protection, and monitoring.

It does not replace API security testing, TLPT, incident response, governance, third-party risk management, or the other controls required under DORA.

It does one thing very specifically:

It helps teams understand, protect, and monitor the security of their mobile applications.