DORA testing for the apps your customers use.
DORA has applied since 17 January 2025. With its technical standards, it asks EU financial entities for weekly automated vulnerability scans of assets that support critical or important functions, static and dynamic security testing of internet-exposed applications, yearly tests, and threat-led penetration testing (TLPT) for identified entities. Ostorlab supports your testing obligations for mobile apps and the APIs behind them, on every release.
- Static and dynamic testing of the build you ship, with no source code needed
- Penetration testing by AI agents behind login, including one-time codes
- Third-party SDKs and native libraries tracked release after release
- Risk ratings, tickets and retests, so every fix can be proven
- Groundwork before your TLPT, not a replacement for it
- Who it applies to
- EU financial entities, including banks, payment and e-money institutions
- Applies since
- 17 January 2025
- How often
- Weekly automated scans of critical assets, yearly tests, TLPT every 3 years if identified
- Reference
- Regulation (EU) 2022/2554, Delegated Regulations (EU) 2024/1774 and 2025/1190
DORA's testing rules, date by date
DORA is in force and applies today. These are the dates and cadences your testing programme is measured against.
- 16 January 2023
DORA enters into force
Regulation (EU) 2022/2554 is published in the Official Journal on 27 December 2022 and enters into force 20 days later.
- 15 July 2024
ICT risk management RTS in force
Delegated Regulation (EU) 2024/1774 sets the detail on vulnerability and patch management, secure development and testing, and access control.
- 17 January 2025
DORA applies
In-scope financial entities must run their ICT risk management framework and digital operational resilience testing programme.
- 8 July 2025
TLPT RTS in force
Delegated Regulation (EU) 2025/1190 sets how threat-led penetration tests are scoped, run, closed and remediated.
- Ongoing
Weekly, yearly, every 3 years
Automated vulnerability scans of assets supporting critical or important functions at least weekly, tests of the systems and applications behind them at least yearly, and TLPT at least every 3 years for identified entities.
DORA's testing and security rules, applied to your mobile app
DORA sets the principles, and its technical standards set the detail. For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team.
- DORA, Article 8
Know which apps and components support critical functions
What the text says
Identify, classify and document all ICT-supported business functions and the information and ICT assets behind them, including their dependencies and the processes that rely on ICT third-party service providers. Review the classification at least yearly, and continuously assess cyber threats and ICT vulnerabilities.
Source:DORA, Article 8
What it means for your mobile app
A mobile banking app that customers use to log in, pay and manage accounts will usually support a critical or important function, and so will the APIs it calls and the SDKs it embeds. That classification drives how often and how deeply you must test.
How Ostorlab helps
Ostorlab shows what each release of your app contains: third-party SDKs and native libraries with their versions and their location in the app bundle, what the app and its SDKs exchange with backends over the network, and what personal data the app collects and shares.
What stays with you
The business-function classification, the inventory itself and its yearly review.
- Delegated Regulation (EU) 2024/1774, Article 10
Scan critical assets automatically, at least weekly
What the text says
Vulnerability management procedures must include automated vulnerability scanning and assessments, at least weekly for ICT assets supporting critical or important functions. You must also track third-party and open-source libraries, prioritise patches by criticality, verify remediation, and record every detected vulnerability until it is resolved.
What it means for your mobile app
Your mobile app and its APIs need an automated scanning cadence that holds even in weeks without a release, and a record of every finding from detection to fix.
How Ostorlab helps
Run automated scans from your CI/CD pipeline on every build and monitor store releases without manual triggers. Scheduled runs of your pipeline keep a weekly cadence between releases. Findings are rated critical, high, medium or low, tracked as tickets in the platform or in Jira and ServiceNow, and retested once the fix ships.
What stays with you
Patch deadlines and escalation procedures, and scanning of the rest of your ICT estate.
- Delegated Regulation (EU) 2024/1774, Article 16
Test code statically and dynamically before production
What the text says
Test and approve every ICT system before use and after maintenance, in proportion to its criticality. Testing includes source code reviews covering both static and dynamic testing, security testing for internet-exposed systems and applications, and an action plan for the vulnerabilities found. Third-party and open-source code is analysed and tested, where feasible, before deployment in production.
What it means for your mobile app
A mobile banking app is an internet-exposed application. Each release should pass static and dynamic security testing before it reaches the store, and the SDKs inside it are third-party code covered by the same rule.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA directly, with no source code needed, including taint analysis across embedded SDKs. Mobile DAST runs the app, keeps authenticated sessions and captures traffic, stack traces and screenshots. SCA fingerprints statically compiled libraries that manifest-based scanners can miss.
What stays with you
Reviews of source code outside the app, the release approval step and ownership of the action plan.
- DORA, Article 9(4)(d); Delegated Regulation (EU) 2024/1774, Article 21
Strong authentication, tested like any other control
What the text says
Implement policies and protocols for strong authentication mechanisms based on relevant standards. The RTS requires authentication methods commensurate with the classification and risk profile of each ICT asset, and strong authentication for access to assets supporting critical or important functions or that are publicly accessible.
Source:DORA, Article 9(4)(d); Delegated Regulation (EU) 2024/1774, Article 21
What it means for your mobile app
Login, one-time codes and step-up checks are authentication controls, and a flaw in how the backend enforces them is a flaw in those controls. They belong in the scope of your testing programme.
How Ostorlab helps
Ostorlab logs in with your test accounts, completes SMS, email or TOTP one-time codes, and tests login and logout, token refresh, timeouts, session invalidation and MFA enforcement, including step-up flows.
What stays with you
Staff and privileged access, identity lifecycle management and the choice of authentication standards.
- DORA, Articles 24 and 25
Run a risk-based testing programme, with yearly tests
What the text says
Establish, maintain and review a digital operational resilience testing programme as part of your ICT risk management framework. It provides for appropriate tests, such as vulnerability assessments and scans, open source analyses, source code reviews where feasible, scenario-based tests, end-to-end testing and penetration testing, with tests at least yearly on all ICT systems and applications supporting critical or important functions.
Source:DORA, Articles 24 and 25
What it means for your mobile app
Your mobile app needs a defined place in the programme: which tests run, how often, and on which build. A yearly pentest alone leaves every release in between untested.
How Ostorlab helps
Fast scans usually finish in 1 to 5 minutes and full scans in 15 to 45 minutes, so they fit every release. An AI-agent pentest goes deeper, typically in a few hours, with a working exploit you can replay for each AI-agent finding, for critical changes and your periodic deep tests.
What stays with you
The programme document, its risk-based design, and tests outside the application layer such as network, physical and performance testing.
- DORA, Article 24(4) and 24(5)
Use independent testers and prove every fix
What the text says
Tests must be undertaken by independent parties, internal or external, with sufficient resources and without conflicts of interest. You must prioritise, classify and remedy every issue the tests reveal, and have internal validation methods to confirm that each weakness is fully addressed.
What it means for your mobile app
The team that builds the app should not be the only one testing it, and a closed ticket is not proof: you need evidence that the fix works.
How Ostorlab helps
Your security or second-line team runs the tests and owns the results. Each finding comes with a risk rating, reproduction steps, request and response logs and screenshots, and retesting confirms whether the underlying issue is resolved.
What stays with you
Deciding who counts as independent in your organisation, and the validation sign-off.
- DORA, Articles 26 and 27; Delegated Regulation (EU) 2025/1190
TLPT at least every 3 years, if you are identified
What the text says
Entities identified by their competent authority must carry out threat-led penetration testing at least every 3 years, on live production systems supporting critical or important functions. Testers must meet Article 27, and significant credit institutions must use external testers. After the test, remediation plans and documentation go to the TLPT authority.
Source:DORA, Articles 26 and 27; Delegated Regulation (EU) 2025/1190
What it means for your mobile app
A TLPT is an intelligence-led red team exercise that runs over several months (see the phases below). App and API weaknesses that routine testing could have found use up red team time and end up in the remediation plan.
How Ostorlab helps
Ostorlab does not run TLPT and does not replace it. It helps you go into a TLPT with known app and API issues already fixed, and retest the app and API items of your remediation plan afterwards.
What stays with you
The TLPT itself: the control team, the threat intelligence provider, the red team testers and the dialogue with the TLPT authority.
- DORA, Articles 28 to 30
Manage testing vendors as ICT third parties
What the text says
Financial entities remain fully responsible for compliance when they use ICT third-party service providers, and keep a register of information on those arrangements. Contracts must cover data protection and, for services supporting critical or important functions, unrestricted rights of access, inspection and audit, and the provider's participation in TLPT.
Source:DORA, Articles 28 to 30
What it means for your mobile app
A SaaS testing platform that receives your app binaries and test credentials is a vendor your third-party risk process will review.
How Ostorlab helps
Ostorlab is SOC 2 Type II audited. On the Enterprise plan you can choose EU data residency or run scans on-premises, and with BYOK the AI runs on your own provider account with a spend cap per scan. SSO/SAML, role-based access control and audit logs are available as an add-on and included on Enterprise.
What stays with you
Your due diligence, the contract clauses and the register of information.
Summary of Regulation (EU) 2022/2554 and Delegated Regulations (EU) 2024/1774 and 2025/1190. Microenterprises and entities under the simplified framework have lighter obligations. This page is not legal advice.
What a TLPT involves, and where Ostorlab fits
The TLPT RTS sets out the phases below. Ostorlab has no role in the red team test itself: its place is before the test and after it.
- Before the test
Fix what is findable
Test your apps and APIs on every release, so known weaknesses are fixed before a red team spends time on them. This is where Ostorlab helps.
- Within 3 months
Preparation
After the TLPT authority's notification, the entity submits its initiation documents, including a project charter, then scopes the critical or important functions to test.
- About 4 weeks
Threat intelligence
A threat intelligence provider produces a targeted threat intelligence report. The RTS notes this typically takes about 4 weeks.
- At least 12 weeks
Active red team testing
Testers run their attack scenarios on live production systems for at least 12 weeks.
- Closure
Replay and purple teaming
The red team and the blue team replay the attack and review it together to learn from it.
- Within 8 weeks
Remediation plan
The entity sends a remediation plan with a root cause analysis, owners and priorities for each finding. Ostorlab can retest the app and API fixes it contains.
DORA, requirement by requirement
Where Ostorlab supports your mobile apps and their APIs, and the evidence you can keep for your testing programme.
| Requirement | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Inventory of apps, components and dependenciesDORA Art. 8 | Lists the SDKs and native libraries in each release with their versions, and shows which backends the app and its SDKs talk to. Details | Component identity, version and location in the app bundle, per release |
| Automated vulnerability scanning, at least weeklyRTS 2024/1774 Art. 10(2)(b) | Automated scans from your CI/CD pipeline on every build, including scheduled runs, and monitoring of store releases. Details | Scan results per build and per store release |
| Tracking of third-party and open-source librariesRTS 2024/1774 Art. 10(2)(d) | Fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Details | Mapped vulnerabilities with upgrade or replace recommendations, and closure tracked across releases |
| Record vulnerabilities and verify remediationRTS 2024/1774 Art. 10(2)(g) and (h) | Groups findings into tickets in the platform or in Jira and ServiceNow, and retests after the fix. | Ticket history and retest result for each finding |
| Static and dynamic testing of internet-exposed applicationsRTS 2024/1774 Art. 16(3) | Mobile SAST on the binary and Mobile DAST on the running app, before release. Details | Findings with decompiled source context, traffic, stack traces and screenshots |
| Third-party code analysed before productionRTS 2024/1774 Art. 16(8) | Taint analysis across embedded SDKs, and dependency analysis of the compiled app. Details | Findings attributed to the SDK or library they come from |
| Strong authentication mechanismsDORA Art. 9(4)(d); RTS Art. 21 | Logged-in testing with one-time codes, and checks of sessions, tokens, timeouts and MFA enforcement. Details | Findings on login, session and step-up flows with reproduction steps |
| Penetration and end-to-end testingDORA Art. 25(1) | AI-agent pentest of the app and its APIs, behind login, on the build you ship. Details | A working exploit you can replay for each AI-agent finding, and a coverage heatmap |
| Prioritise, remedy and validateDORA Art. 24(5) | Standard risk ratings, potential findings kept separate, and a retest loop. | Risk rating per finding and retest confirmation |
| TLPT preparation and remediationDORA Art. 26; RTS 2025/1190 | Clears findable app and API issues before the test, then retests the app and API items of the remediation plan. | Results before the TLPT and retests after it |
| ICT third-party risk for your testing vendorDORA Arts. 28 to 30 | SOC 2 Type II audit, EU data residency, on-premises scanning and BYOK. Details | SOC 2 Type II report, on request from the Trust Center |
Ostorlab covers the mobile apps and the APIs behind them. Requirements beyond the application layer, such as network, physical security, backup and incident management, stay with other tools and teams.
Put your mobile app into your DORA testing programme
A practical sequence for security teams. Adapt it to your own risk assessment.
Classify the app
Record which critical or important functions the app and its APIs support, and list the SDKs and backends it depends on.
Take a baseline
Scan each customer-facing app once to see where you stand. A free scan from the store takes minutes.
Set the cadence
Automated scans on every build, and at least weekly for apps supporting critical or important functions. Add a deeper AI-agent pentest for critical changes, and yearly tests of the full scope.
Cover logged-in flows
Add test accounts and one-time code delivery, so login, payments and account changes are tested, not only the login screen.
Wire findings into remediation
Send findings to Jira or ServiceNow with a rating, agree fix deadlines by severity, and retest every fix.
Keep the evidence
Keep scan results, tickets and retest outcomes for each release, so you can show auditors the programme and the validation step.
Prepare for TLPT
If you are identified for TLPT, clear known app and API weaknesses first, then retest the app items in the remediation plan.
Review the vendor
Take Ostorlab through your ICT third-party risk process: SOC 2 Type II report, data residency, on-premises and BYOK options.
This sequence is a suggestion, not a regulatory template. It is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- Mobile Agentic Deep ScanAI agents pentest the store build on every release, with a working exploit you can replay for each AI-agent finding.Learn more
- Mobile SASTBinary-based static analysis of APK, AAB and IPA files, with taint analysis across the app and its embedded SDKs.Learn more
- SCA and SBOMFind vulnerable dependencies, including statically compiled native libraries, and track their closure release after release.Learn more
- Authenticated testingTest login, one-time codes and step-up flows with your test accounts.Learn more
- API and backend testingIntercept app traffic even with TLS pinning, then test the APIs and backends behind accounts and payments.Learn more
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.Learn more
- Bring your own AI keyRun AI-agent scans on your own AI provider key with a spend cap per scan, so usage follows your internal policies.Learn more
- On-premises scanningScan staging apps, APIs and repositories behind your firewall or VPN, on infrastructure you control.Learn more
Trusted by banks and fintechs, including
Sources
The official texts this page is based on, checked on 27 September 2026.
- Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)Official Journal of the European Union. Articles 8 and 9 cover identification and protection; Chapter IV, Articles 24 to 27, covers resilience testing; Articles 28 to 30 cover ICT third-party risk
- Commission Delegated Regulation (EU) 2024/1774 on ICT risk management tools, methods, processes and policiesRegulatory technical standards, including vulnerability and patch management (Article 10), ICT systems acquisition, development and maintenance (Article 16) and access control (Article 21)
- Commission Delegated Regulation (EU) 2025/1190 on threat-led penetration testingRegulatory technical standards on who must run TLPT, internal testers, scope, methodology, closure and remediation
- ECB Banking Supervision: Addressing AI-enabled cybersecurity threats (PDF)Letter of 7 July 2026 asking significant institutions for an action plan built on DORA's requirements
Further reading from Ostorlab
Frequently asked questions
Straight answers on coverage, setup, and how results reach your team.
Can't find your answer? Book a demo or contact us.
Put your banking app into your DORA testing programme
Start with a free scan of your app from the store, or book a demo to plan testing across your releases.