DORA Compliance for Mobile Apps: Mapping Security Findings to Regulatory Requirements

DORA compliance for mobile applications is the process of identifying, testing, and documenting mobile ICT risks in line with Regulation (EU) 2022/2554, covering Articles 8, 9, 10, 24, and 25, through vulnerability assessments, security testing, and audit-ready evidence generation that financial institutions can present to regulators, auditors, and internal governance bodies.

The EU's Digital Operational Resilience Act has changed the way financial institutions must think about technology risk. Security is no longer demonstrated through periodic assessments alone. Regulated organizations must be able to demonstrate that ICT risks are continuously identified, managed, tested, and documented across the systems that support their critical services.

For many financial institutions, the mobile application is one of those systems. According to Forrester's Digital Experience Review™: Europe Mobile Banking Apps, Q3 2024, 85% of European online banking customers use mobile apps frequently. The same research found that 25% of European banking customers cite security concerns about their personal or financial information as a reason for not using mobile banking apps more. This is a gap that DORA now requires financial institutions to address systematically rather than reactively.

DORA does not classify every mobile application as a critical system by default. Its relevance depends on how the application supports the financial entity's business functions, information assets, and ICT services. A customer-facing banking, payments, or insurance app may support critical functions and should be assessed within the wider ICT risk context.

A weakness in authentication, cryptography, local data storage, network communication, or an API can affect more than the security of a single release. It can expose customer data, enable fraud, disrupt an important service, and weaken the organization's wider operational resilience.

The challenge is that mobile application security reports and regulatory requirements speak different languages.

A security team identifies findings such as insecure data storage, weak encryption, broken access controls, or exposed APIs. A risk or compliance team needs to understand which regulatory requirements may be affected, what evidence is available, and how the issue is being remediated.

Appknox helps connect the two.

How does DORA apply to financial entities?

Regulation (EU) 2022/2554, commonly known as DORA, has been applicable since 17 January 2025. It establishes a common digital operational resilience framework for financial entities across the European Union.

DORA applies to 21 categories of financial entity, including credit institutions, investment firms, payment institutions, insurance undertakings, crypto-asset service providers, and data reporting service providers. Its requirements extend across ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing and supervisory oversight.

DORA is therefore much broader than application security. No vulnerability scan or testing platform can, by itself, establish that an organization is DORA-compliant.

Mobile application security testing can, however, support important parts of a DORA program. It helps organizations identify technical weaknesses, test the security of ICT systems, prioritize remediation, and retain evidence of the controls and assessments applied to mobile applications.

Enforcement is active in 2026

National competent authorities are now conducting active enforcement reviews following the informal supervision period that characterized 2025.

Under Articles 50 to 52 of Regulation (EU) 2022/2554, financial entities found in material breach of DORA face administrative fines of up to 2% of total annual worldwide turnover or €10 million, whichever is higher. Individual members of the management body may face personal fines under national implementing measures, with most member states adopting caps of up to €1 million.
Importantly, a single ICT incident involving personal data can trigger simultaneous enforcement under both DORA and GDPR.

DORA and NIS2

Financial entities subject to DORA are also typically subject to NIS2. DORA operates as lex specialis relative to NIS2 for financial entities under Article 4 of the regulation, meaning DORA's more specific requirements take precedence over NIS2 for such entities.

Organizations with existing EBA ICT and Security Risk Guideline programs should assess those programs against DORA's requirements, as DORA introduces more prescriptive obligations in several areas, particularly around resilience testing and third-party oversight.

The gap between mobile security testing and compliance evidence

Security testing produces valuable technical information. But turning that information into compliance evidence often remains a manual exercise.

When a vulnerability is found, teams may still have to determine which DORA requirement it relates to, how it could affect the organization's ICT risk posture, what evidence should be retained for an audit, and which issues should receive priority based on both security and regulatory impact.

This translation becomes harder at scale. A financial institution may operate several mobile applications, support Android and iOS releases, connect to numerous APIs, and generate findings across static, dynamic, and API security testing.

Manually interpreting every applicable result against the regulation introduces time delays, inconsistency, and unnecessary reliance on individual subject-matter experts.

Appknox reduces that burden by mapping applicable mobile application security findings to relevant DORA requirements.

Which DORA articles apply to mobile application security?

The current Appknox mapping covers applicable findings related to Articles 8, 9, 10, and 25 of DORA. Appknox testing results can also support the broader testing, prioritization, and remediation processes described in Article 24.

Article 8: Identification

Article 8 requires financial entities to identify, classify, and adequately document ICT-supported business functions, information assets, and ICT assets, as well as their dependencies. It also requires entities to identify sources of ICT risk and assess cyber threats and vulnerabilities relevant to their ICT-supported functions and assets.

Mobile SAST, DAST, and API security testing can support the identification and assessment of ICT risks by revealing vulnerabilities in the application, its runtime behavior, and its communication with backend services.

Article 9: Protection and prevention

Article 9 requires financial entities to implement appropriate ICT security policies, procedures, protocols, and tools to protect the availability, authenticity, integrity, and confidentiality of data.

It covers areas including access controls, authentication, data and system protection, secure configurations, cryptography, and vulnerability and patch management. Many findings from mobile applications are directly related to these safeguards, including weaknesses in authentication, authorization, sensitive data storage, encryption, transport security, application configuration, or the exposure of confidential information.

When Appknox identifies an applicable weakness, its DORA mapping helps users understand the technical and regulatory significance of the finding within the framework of Article 9, offering actionable context regarding the specific security controls or risk categories involved.

Article 10: Detection

Article 10 focuses on mechanisms to promptly detect anomalous activity, ICT network performance issues, and ICT-related incidents. It also requires financial entities to define alert thresholds and criteria that trigger incident detection and response processes.

Only Appknox findings that clearly relate to these detection requirements are mapped to Article 10. The presence of the mapping does not mean every mobile vulnerability is a detection failure. It identifies cases in which the weakness may affect, bypass, or expose limitations in security monitoring or incident-detection mechanisms.

Article 24: General requirements for digital operational resilience testing

Article 24 establishes the broader requirements governing a financial entity's digital operational resilience testing program. It requires testing to follow a risk-based approach and to include procedures for prioritizing, classifying, and remediating issues identified through testing.

Financial entities must also ensure that appropriate tests are conducted at least once a year on ICT systems and applications that support critical or important functions.

The resulting test reports and findings can provide supporting evidence for identified risks and help organizations prioritize and remediate issues as part of their broader DORA program.

Appknox testing does not, by itself, establish compliance. Financial entities remain responsible for defining the scope and frequency of their testing program, ensuring tester independence, managing remediation, and validating that identified weaknesses have been resolved.

Article 25: Testing of ICT tools and systems

Article 25 is especially relevant to application security. It requires a digital operational resilience testing program to include appropriate tests such as vulnerability assessments and scans, open-source analyses, network security assessments, source-code reviews where feasible, scenario-based tests, compatibility and performance testing, and penetration testing.

Third-party SDK risk and SBOM under DORA

DORA's ICT third-party risk management provisions under Articles 28 to 44 extend beyond contracted ICT service providers to include the software components embedded within applications. Mobile applications frequently incorporate third-party SDKs (analytics, payment, authentication, and advertising libraries) that are compiled into the binary at build time and not written by the financial institution's own development team.

These SDKs introduce supply chain risk directly relevant to DORA's requirements for ICT asset identification and vulnerability management. A financial institution cannot adequately manage ICT risk without visibility into the third-party components operating within its mobile applications.

Appknox generates a software bill of materials (SBOM) from the compiled binary for every release, in standard formats such as CycloneDX and SPDX. This gives security and compliance teams a complete inventory of third-party dependencies present in each application build, supporting the identification and documentation obligations under Article 8 and the vulnerability management requirements under Article 9.
When a CVE is published for a component in the SBOM, the affected application and its relevant DORA context can be identified immediately rather than reconstructed manually during an audit.

Cross-platform frameworks

DORA compliance requirements apply to mobile applications regardless of how they were built. Appknox performs binary analysis on the compiled application artifact (the .apk file on Android or the .ipa file on iOS) without requiring access to source code.

This means that applications built with cross-platform frameworks including Flutter, React Native, Xamarin, and Ionic receive the same depth of SAST, DAST, and API security testing as natively developed applications, with the same DORA mapping applied to applicable findings.

Financial institutions that deliver services through cross-platform applications are not outside the scope of DORA's ICT risk management and testing requirements.

Together, these provisions create several points at which mobile application security testing can contribute to a financial entity's DORA program. The table below shows the relationship between relevant security activities, DORA requirements, and the evidence Appknox can provide.

Note: Appknox's current finding-level DORA mapping covers applicable test cases under Articles 8, 9, 10, and 25. Article 24 is included because Appknox testing results can support the broader testing, prioritization, and remediation processes it describes; findings are not currently mapped directly to Article 24. The SBOM row references Articles 28–44 in the context of ICT asset and third-party visibility; Appknox's finding-level mapping does not currently extend to every provision within those articles.

A note on threat-led penetration testing: The security testing described above should not be confused with the threat-led penetration testing requirements set out in Articles 26 and 27 of DORA. TLPT is an advanced testing regime applicable to designated financial entities and is subject to separate requirements covering scope, methodology, testers, risk management, remediation, and supervisory involvement. Appknox's automated SAST, DAST, and API security testing can support an organization's broader security testing program, but does not, by itself, satisfy DORA's TLPT requirements.

How Appknox maps mobile vulnerabilities to DORA requirements

Appknox developed its DORA mapping by reviewing regulations and identifying provisions directly related to mobile application security. Individual SAST, DAST, and API security test cases were then assessed against those provisions.

A mapping was assigned only where a defensible technical and regulatory relationship could be established. Not every Appknox test case receives a DORA reference, and the presence of a vulnerability does not, independently, establish that the financial entity has violated DORA.

For applicable vulnerabilities, users can see the relevant DORA requirement and an explanation of how the vulnerability may affect that requirement. The mapping is intended to support compliance analysis, remediation, and evidence collection. It is not a legal determination of compliance.

This creates a traceable relationship:

Security test → technical finding → DORA requirement → remediation

Instead of starting with the regulation and manually searching for relevant technical evidence, teams can begin with a specific vulnerability and immediately understand its potential compliance implications. The examples below illustrate how specific Appknox findings connect to DORA requirements.

These mappings identify the DORA requirements that may be affected by a vulnerability. They do not independently establish a regulatory breach or determine the organization's overall compliance status.

Download the DORA Mobile App Compliance Evidence Checklist

A working tool for security and compliance teams preparing mobile application evidence for DORA audits. Covers which articles apply, what evidence each requires, what Appknox generates, and what your team is responsible for separately.

Download the checklist →

Turning mobile security findings into actionable DORA compliance evidence

Mapping vulnerabilities to DORA requirements provides value to several teams.

For application security teams

The mapping adds regulatory context to security findings. This helps AppSec teams explain why a vulnerability matters beyond its severity score and prioritize weaknesses that may affect both security and compliance obligations.

For developers

Developers receive a clearer explanation of the risk being remediated. The finding is no longer an isolated security ticket. It is connected to the control objective the organization is expected to maintain.

For risk and compliance teams

Compliance teams gain traceability between regulatory requirements and application-level evidence. This reduces the need to manually interpret technical reports or repeatedly ask security teams to reconstruct the relationship during audits.

For auditors and leadership

Mapped reports can provide supporting evidence that relevant mobile application risks were identified, assessed, and routed for remediation. They also help leadership demonstrate a repeatable connection between security testing and the organization's ICT risk management program.

An example of the difference in practice

The following is an anonymized example based on patterns observed across enterprise mobile security programs. Organization and individual details are not disclosed.

A European insurance group that tested its customer-facing mobile applications with Appknox mapped all identified vulnerabilities to relevant DORA requirements within the same scan workflow. Their compliance team reported that the time required to prepare mobile application security evidence for internal DORA review was reduced from a manual process spanning several weeks to a single sprint cycle. The SBOM generated per release gave the ICT risk function immediate visibility into third-party SDK dependencies, which had previously required separate manual analysis before each audit.

See the DORA Mobile App Compliance Evidence Checklist in action

The checklist is structured by team, with separate columns for security and compliance responsibilities, status tracking, and links to evidence. It maps directly to the Appknox scan workflow, so both teams work from the same document.

Download the checklist →

Building DORA evidence into the mobile release lifecycle

DORA testing should not become an exercise performed only when an audit is approaching. The strongest evidence is produced as part of normal application development and release processes.

Financial institutions can incorporate mobile application security testing at several stages.

During development: use static testing to identify weaknesses in application code before release.

During pre-production validation: use dynamic testing to observe the application's runtime behavior and test its security controls.

Across the application and backend: test APIs for weaknesses in authentication, authorization, data exposure, and business logic.

Before a material release: review unresolved findings and determine whether they fall within the organization's risk tolerance.

After testing: retain the report, DORA mapping, SBOM, remediation record, and any formally approved risk decision as part of the release evidence.

This does not turn every scan into a compliance verdict.

It creates a consistent, traceable record showing what was tested, which risks were found, how those risks relate to relevant requirements, and what the organization did in response.

Article 13 of DORA requires financial entities to review incidents and testing outcomes to improve their ICT risk management arrangements over time. Retaining findings, remediation records, and risk acceptance decisions as part of each release creates the evidence base for that review, without requiring a separate learning exercise.

DORA, NIS2, and existing ICT risk programs

Financial entities that have invested in EBA ICT and Security Risk Guideline compliance or NIS2 programs should assess how those programs map to DORA's requirements. As noted above, DORA operates as lex specialis relative to NIS2 for financial entities under Article 4, meaning DORA's more specific obligations take precedence where they apply.

Existing vulnerability management, incident response, and third-party risk programs may already satisfy elements of DORA's requirements. The key question is whether those programs produce the evidence, documentation, and testing outcomes that DORA specifically requires, including regular testing of ICT systems and applications that support critical or important functions, as required by Article 24.

Mobile application security testing programs that currently meet EBA ICT guidelines will need to confirm they also satisfy DORA's more detailed testing and third-party risk provisions, particularly regarding SBOM, SDK visibility, and the frequency and documentation of tests.

DORA applicability beyond the European Union

DORA's third-party ICT risk management provisions apply to ICT service providers, regardless of where they are located. A technology company based outside the EU that provides ICT services to an EU financial entity, including mobile application development, SDK supply, or API infrastructure, is within scope of DORA's third-party oversight requirements as they apply to the regulated financial institution contracting those services.

For financial institutions in the GCC, Asia-Pacific, or other regions that serve or are owned by EU-regulated entities, DORA compliance for mobile applications is therefore not solely a European concern. The ICT risk identification, testing, and documentation obligations that apply to the EU parent or partner entity extend, through contractual and oversight obligations, to the third-party ICT services those entities rely on.

Appknox works with financial institutions and technology teams in these markets to support the mobile application security evidence requirements that flow from their DORA obligations.

What Appknox does for your DORA program

Appknox is an enterprise mobile application security testing platform that combines binary SAST, AI-led automated DAST on real physical devices, API security testing, and SBOM generation in a single CI/CD-integrated workflow. No source code is required at any stage.

Binary SAST analyzes the compiled .apk or .ipa artifact rather than source code. It covers every component in the binary, including third-party SDKs and build-time configurations that source code review cannot reach. For DORA purposes, this supports Articles 8, 9, and 25 by surfacing vulnerabilities in the application as it ships to users.

AI-led automated DAST on real physical devices tests the running application under authenticated sessions, identifying runtime vulnerabilities such as certificate pinning failures, session handling weaknesses, and API authentication gaps that only appear when the app is executing. Testing on real devices rather than emulators surfaces hardware-specific behaviors and real network conditions that emulator-based testing cannot replicate.

API security testing covers the backend endpoints the mobile application communicates with, testing for authentication and authorization weaknesses, sensitive data exposure, business logic bypass, and deprecated or undocumented endpoints. Mobile apps frequently call API endpoints that are not tested alongside web application security programs, making mobile-specific API testing a distinct DORA requirement.

SBOM generation produces a complete software bill of materials from the compiled binary on every release, in CycloneDX or SPDX format. This gives security and compliance teams full visibility into third-party SDK dependencies, supporting the ICT asset identification requirements under Article 8 and the third-party risk visibility obligations relevant to Articles 28 to 44.

KnoxIQ is Appknox's AI-powered exploitability validation layer. It reduces false positives to below 1% by confirming exploitability before a finding reaches the development team. This means every finding in the DORA mapping has been validated as real, not just flagged by pattern matching. Security teams spend their time on confirmed issues rather than false alarms.

DORA finding-level mapping connects each applicable vulnerability to the specific DORA article it may affect, as described in the mapping section above. Compliance teams receive a report that shows the regulatory significance of each finding without having to manually cross-reference regulations.

CI/CD integration embeds all of the above into the existing development pipeline. Appknox integrates natively with nine platforms: GitHub Action, Jenkins Pipeline, CircleCI Pipeline, App Center Build, Bitbucket Pipeline, Bitrise Workflow, GitLab, Azure Pipeline, and ArmorCode. Findings route directly to Jira, Slack, ServiceNow, and GitHub Issues, so the development team receives security and DORA-mapped evidence within the same build cycle.

Storeknox monitors official and third-party app stores for cloned, repackaged, or tampered versions of an organization's mobile applications after they ship. For financial institutions, the presence of a fake or compromised version of their banking app is both a security incident and an operational resilience risk with direct DORA relevance.

Compliance evidence per build. Every Appknox scan generates per-build compliance evidence mapped to OWASP MASVS v2, OWASP Mobile Top 10 2024, PCI-DSS v4.0, GDPR, HIPAA, SAMA, MAS TRM, and RBI, as well as the DORA article mapping. Financial institutions operating across multiple regulatory frameworks can generate evidence for all of them from a single scan.

Scans complete in under 60 minutes. Appknox is rated 4.8/5 on Gartner Peer Insights across 300+ enterprise teams.

What Appknox does not do

Appknox does not certify an application or organization as DORA-compliant. Compliance depends on the financial entity's complete governance, risk management, incident response, resilience testing, third-party oversight, documentation, and supervisory obligations. Appknox automated testing does not satisfy DORA's TLPT requirements under Articles 26 and 27, which are a separate advanced testing regime for designated financial entities.

Make mobile application security part of your DORA program

For financial institutions, mobile applications are not merely customer-facing interfaces. They are part of the ICT environment through which critical and important services are delivered.

Testing them is essential. Being able to connect the results of that testing to regulatory requirements makes the evidence significantly more useful.

With DORA mapping in Appknox, security and compliance teams can move from a technical vulnerability report to a clearer view of regulatory relevance, helping them prioritize remediation, reduce manual effort in preparing mobile application security evidence for audits, and build that evidence into every release.

See how Appknox can help you test mobile applications and map applicable findings to DORA requirements.

Book a demo →

Disclaimer: This article is provided for general informational purposes and does not constitute legal or regulatory advice. Organizations should consult their legal and compliance advisers when assessing their obligations under DORA.

Frequently asked questions

How does Appknox support DORA compliance for mobile applications?

Appknox helps financial institutions identify mobile application vulnerabilities and connect applicable findings to relevant requirements under Articles 8, 9, 10, and 25 of DORA. This gives security, development, risk, and compliance teams a traceable relationship among technical findings, regulatory requirements, and remediation activities, without requiring manual interpretation of each result against the regulations.

What information does the Appknox DORA mapping provide?

For applicable vulnerabilities, Appknox identifies the relevant DORA requirement and explains how the finding may affect it. This adds regulatory context to technical results and helps teams prioritize remediation, prepare evidence for mobile application security, and respond more efficiently to internal reviews and audit requests.

How can Appknox reports support DORA audits?

Appknox reports provide technical evidence showing that a mobile application was tested, which vulnerabilities were identified, which applicable DORA requirements may be affected, and what remediation was recommended. Financial institutions can retain this alongside remediation records, retest results, risk decisions, and governance evidence required by their wider DORA program.

How does Appknox address third-party SDK risk under DORA?

Appknox generates a software bill of materials from the compiled binary on every release, covering all third-party SDK dependencies present in the application at build time. This supports the ICT asset identification requirements under Article 8 and the third-party risk visibility obligations relevant to Articles 28 to 44, without requiring source code access or separate manual analysis.

How does Appknox fit into a DORA digital operational resilience testing program?

Appknox provides continuous, repeatable mobile application security testing, including binary SAST, AI-led automated DAST on real devices, and API security testing, that helps financial institutions identify and remediate weaknesses as part of their risk-based testing program. The resulting reports and DORA-mapped findings can provide supporting evidence for the testing documentation requirements under Articles 24 and 25.

How does Appknox complement threat-led penetration testing under DORA?

Appknox provides continuous, automated mobile application security testing that helps financial institutions identify and remediate weaknesses before more advanced testing is required. TLPT under Articles 26 and 27 is a separate regime for designated financial entities with a specific scope, methodology, and supervisory requirements; Appknox automated testing does not satisfy those requirements but can strengthen routine mobile security assessments and inform the TLPT scope.

Sources and further reading

• Regulation (EU) 2022/2554: Digital Operational Resilience Act: EUR-Lex
• Digital Operational Resilience Act overview: European Banking Authority
• DORA application from 17 January 2025: European Commission
• Commission Delegated Regulation (EU) 2024/1774, including detailed ICT risk-management and vulnerability-management requirements: EUR-Lex
• DORA implementing and delegated acts: European Commission
• Forrester Digital Experience Review: Europe Mobile Banking Apps, Q3 2024: Forrester Research
• ECB Payments Statistics, First Half of 2025: European Central Bank
• Eurostat, Digitalization in Europe 2025: European Commission

This article was written with the assistance of the Appknox security and R&D team, based on a direct review of Regulation (EU) 2022/2554 and its implementing acts, and on direct experience conducting mobile application security testing for financial services organizations across the BFSI, insurance, and payments sectors. The regulatory mapping in this article was reviewed by the Appknox security research and compliance team.