Over the years, I have worked with various financial institutions, fintech companies, and crypto businesses across Europe, and one similarity that I have observed is that organisations often know they must meet regulatory requirements but are unsure which framework governs licensing, which covers cybersecurity, and how they both align.
- MiCA (Regulation EU 2023/1114) is a European law that governs crypto-asset markets and Crypto-Asset Service Providers (CASPs) operating their business in Europe
- DORA (Regulation EU 2022/2554) governs the cybersecurity requirements of financial organisations operating within Europe.
MiCA and DORA serve different purposes; they are closely interconnected. MiCA establishes the regulatory framework for crypto-asset issuers and Crypto-Asset Service Providers (CASPs), while DORA defines the cybersecurity, ICT risk management, and penetration testing requirements that these regulated entities must implement. Together, they establish the regulatory and cybersecurity framework operating in the EU.
In this guide, I explain the meaning and applicability of both acts, the requirements of both acts, how MiCA and DORA intersect, the penetration testing requirements introduced under DORA, and the practical steps fintechs and CASPs should take to achieve compliance in 2026.
What is DORA?
DORA (Digital Operational Resilience Act – Regulation EU 2022/2554) is an EU law that requires financial companies to make sure their IT systems can handle cyberattacks, technical failures, and other disruptions. DORA became fully effective in 25 EU nations altogether. It unifies risk management across 20+ different types of financial entities and their critical tech vendors.
In 2026, DORA covers:
- ICT risk management
- ICT third-party risk management
- ICT-related incidents
- Information sharing
- Digital operational resilience testing
Who does DORA apply to?
DORA applies to the following:
- Banking and Lending organisations
- Payment institutions, account information service providers, and electronic money institutions, and exempted e-money institutions.
- Investment firms, Alternative Investment Fund Managers (AIFMs), UCITS management companies, and crowdfunding service providers
- Trading venues, central counterparties (CCPs), central securities depositories (CSDs), trade repositories, and securitisation repositories.
- Crypto-asset service providers (CASPs) authorised under MiCA and issuers of asset-referenced tokens.
- Insurance and reinsurance undertakings, insurance/reinsurance/ancillary insurance intermediaries, and institutions for occupational retirement provision (IORPs).
- Credit rating agencies, administrators of critical benchmarks, and data reporting service providers.
- ICT third-party service providers – companies that provide digital and data services to financial entities, such as cloud computing services, software vendors, data analytics providers, and data centres.
Cybersecurity Requirements under DORA
Cybersecurity requirements under DORA are structured around five core pillars. These five pillars are part of the Act.

5 Core Pillars of DORA
1st Pillar: ICT Risk Management Framework (Articles 5–16)
- Identification and Asset Mapping. Continuous identification of all ICT assets, dependencies, and business processes to maintain an up-to-date mapping of critical functions.
- Protection and Prevention. Implementation of robust security measures, access controls (identity and access management), encryption, data loss prevention (DLP), and system security controls.
- Detection mechanism. Real-time monitoring and anomaly detection capabilities to identify unauthorised network activity or system degradation.
- Business Continuity & Disaster Recovery (BCP/DR). Formulated response and recovery strategies, regular data backups, failover systems, and periodic testing to limit downtime during major incidents.
- Governance. Mandatory, continuous cybersecurity training for all staff, including board members and executive management.
2nd Pillar: ICT-Related Incident Management & Reporting (Articles 17–23)
- Decided Framework: Clearly defining incident thresholds based on criteria such as the number of affected clients/users, data loss, duration of downtime, geographic spread, and financial impact.
- Regulatory reporting: DORA imposes three reporting streams. Major ICT-related incidents must be reported to the relevant National Competent Authority (NCA) through a three-stage process:
-
- Initial Notification: As soon as possible, but within 4 hours of classifying it as major, and no later than 24 hours after becoming aware of the incident
- Intermediate Report: Within 72 hours after the Initial Notification
- Final Report: Within 1 month after the Intermediate Report (or the latest updated Intermediate Report.
3rd Pillar: Digital Operational Resilience Testing (Articles 24–27)
DORA’s Pillar 3 focuses on testing digital operational resilience. It requires financial entities to regularly test their ICT systems, controls, and processes to verify that they can withstand, respond to, and recover from cyber threats and operational disruptions. The testing framework identifies weaknesses before they result in significant incidents and ensures that resilience measures remain effective in practice.
4th Pillar: ICT Third-Party Risk Management (Articles 28–44)
- Rigorous security posture assessments and risk analyses before entering contracts with third-party ICT providers.
- Contracts must explicitly outline security controls, service level agreements (SLAs), data storage locations, audit/inspection rights, and timelines for incident reporting.
- Critical ICT Third-Party Providers (CTPPs) such as major cloud service providers (CSPs) are directly subjected to oversight by European Supervisory Authorities (ESAs: EBA, ESMA, EIOPA).
5th Pillar: Information & Intelligence Sharing (Article 45)
Protocol for sharing indicators of compromise (IOCs), tactics, techniques, and procedures (TTPs), and threat alerts within trusted communities to exchange threat intelligence.
What is MiCA?
MiCA stands for Markets in Crypto-Assets Regulation. It is an EU law that uniformly regulates digital assets, cryptocurrencies, stablecoins, and crypto service providers across all 27 EU member states. The act became fully applicable in the member states on 30.12.2024.
MiCA covers crypto-assets not already regulated by traditional financial rules, including utility tokens, asset-referenced tokens, and e-money tokens. It implements strict rules against market manipulation, insider trading, and consumer fraud.
Who does MiCA apply to?
As per Article 2(1) of the MiCA and related recitals, MiCA applies to individuals, companies, and other organisations involved in crypto-asset activities within the EU
On the following, MiCA is directly applicable:
1. Individuals or organisations that:
- Offer crypto-assets to the public, or
- Any person or entity making an offer of crypto-assets to the public or seeking to admit crypto-assets to a trading platform within the EU.
According to Articles 4(1)(a) and 5(1)(a), these offerors or applicants must generally be legal persons, meaning they can be companies or other registered entities.
2. Issuers of Crypto-Assets
Issuers are entities responsible for creating or issuing crypto-assets, including:
- Issuers of Asset-Referenced Tokens (ARTs)
- Issuers of Electronic Money Tokens (EMTs)
- Credit institutions (banks) and Electronic Money Institutions (EMIs) that issue crypto-assets, ARTs, or EMTs.
3. Crypto-Asset Service Providers (CASPs)
A Crypto-Asset Service Provider (CASP) is a legal entity that provides crypto-related services to clients as a business. If they provide the following services, MiCA is directly applicable to them:
- Safekeeping and managing crypto-assets for clients (custody)
- Operating crypto-asset trading platforms
- Exchanging crypto-assets for money or other crypto-assets
- Executing, receiving, or transmitting crypto-asset orders for clients
- Placing crypto-assets with investors
- Providing crypto-asset investment advice or portfolio management
- Transferring crypto-assets on behalf of clients
4. Trading Platform Operators
These are entities that operate crypto-asset trading platforms and decide to list crypto-assets either:
- On their own initiative, or
- Through an agreement with the person requesting the listing.
Cybersecurity Requirements under MiCA
In MiCA (Regulation EU 2023/1114), cybersecurity obligations for CASPs and issuers are explicitly laid out across several specific Articles:
- Article 14: Requires issuers of crypto-assets to implement resilient ICT systems, continuous operational monitoring, and disaster recovery plans.
- Article 38 & Article 60: Mandate that CASPs and ART/EMT issuers maintain robust internal governance controls, secure IT infrastructure, and risk management procedures to prevent sensitive data leaks, cyberattacks, and system outages.
- Article 70: Obligates CASPs that offer custody and administration of crypto-assets to implement strict wallet security, key management, cryptographic protection, and asset segregation.
- Article 73: Holds CASPs strictly liable for loss of client funds or crypto-assets resulting from cyberattacks, system failure, or ICT incidents.
How Does MiCA Handle Cybersecurity Implementation?
MiCA establishes the legal obligation for crypto entities to maintain secure IT systems and custody environments; it explicitly cross-references DORA for the actual technical standards:
Under MCA:
- Entities must follow DORA to identify threats and conduct continuous risk assessments.
- Entities must report technical breaches and cyberthreats to National Competent Authorities using DORA reporting templates.
- CASPs are mandated to conduct vulnerability testing and Threat-Led Penetration Testing (TLPT) under DORA.
Does MiCA Require Penetration Testing?
MiCA does not explicitly mandate penetration testing. Rather, it focuses on market conduct, licensing, consumer protection, and transparency. However, CASPs that fall within the scope of both MiCA and DORA must also comply with DORA’s ICT risk management and digital operational resilience requirements.
Therefore, the obligation to perform penetration testing does not arise directly under MiCA; it is effectively introduced through DORA.
Penetration Testing under DORA – Digital Operational Resilience Testing (Pillar 3)
Penetration testing forms an integral part of Pillar 3: Digital Operational Resilience Testing (Articles 24–27) under DORA. Pillar 3 requires financial entities to regularly test their ICT systems, controls, and processes to verify that they can withstand, respond to, and recover from cyber threats and operational disruptions.
To achieve this, DORA establishes a risk-based digital resilience testing framework + Standards (RTS) on Threat-Led Penetration Testing, categorising testing into two main types:
- Standard (Basic) Resilience Testing
- Threat-Led Penetration Testing (TLPT)
Standard Penetration Testing (Articles 24 & 25)
Standard penetration testing is mandatory for all regulated financial entities, including FinTechs and Crypto-Asset Service Providers (CASPs).
Vulnerability assessments and penetration tests are mandatory before deploying or redeploying any major system upgrades, API updates, or new smart contract code. Traditional application and network penetration testing must be conducted at least once per year across all ICT assets supporting critical or important functions (CIFs).
Threat-Led Penetration Testing (TLPT) (Articles 26 & 27)
TLPT is one step beyond traditional penetration testing. It is a full-scale, covert adversary simulation modelled after the European Central Bank’s TIBER-EU framework. Unlike conventional pentesting, TLPT must be executed directly on live, active production systems at least once every 3 years. It is mandatory for designated, high-impact financial entities, large payment institutions, and critical market infrastructures.
If a Fintech relies on external cloud providers, SaaS engines, or custodial key API partners for critical operations, those third-party vendors also need to conduct TLPT.
Scope of Penetration Testing under DORA
Under DORA, the scope of penetration testing boils down to three non-negotiable rules:
1. Critical or important functions (CIFs)
Testing must cover all systems, assets, and processes supporting core operations of the business.
2. Technical attack surface areas
Web platforms, mobile apps, customer gateways, and internal operational dashboards, REST, GraphQL, and microservice endpoints linking internal platforms with third-party networks, protocol logic, distributed ledger nodes, and Hardware Security Module (HSM) key, external IP ranges, DNS, WAFs, internal Active Directory, domain controllers, network segmentations, multi-cloud configurations, IAM roles, and CI/CD pipelines.
3. Any external ICT service provider
For Threat-Led Penetration Testing (TLPT), third-party vendors have to actively cooperate in the live test scenarios.
Standard Penetration Testing vs Threat-Led Penetration Testing (TLPT) under DORA
| Standard Penetration Testing | Threat-Led Penetration Testing (TLPT) | |
| Law | DORA Articles 24–25 | DORA Articles 26–27 and Commission Delegated Regulation (EU) 2025/1190 |
| Objective | Identify technical vulnerabilities before they can be exploited. | Evaluate the organisation’s overall cyber resilience against sophisticated real-world attacks. |
| Who needs to perform? | All financial entities within DORA’s scope, including in-scope CASPs. | Only financial entities designated by the National Competent Authority (NCA). |
| Testing methodology | Vulnerability-focused testing using predefined attack scenarios (OWASP, PTES, NIST SP 800-115). | Intelligence-led adversary simulation replicating real attackers’ tactics, techniques, and procedures (TIBER-EU based TTPs). |
| Testing frequency | Conducted regularly as part of the resilience testing programme
Annually for critical ICT assets. |
At least once every three years. |
| Systems covered | Applications, APIs, networks, cloud infrastructure, smart contracts, and ICT assets supporting Critical or Important Functions (CIFs). | Live production systems supporting Critical or Important Functions, including connected third-party ICT services where relevant. |
| Third-Party ICT Providers | May be included where they support Critical or Important Functions. | Included where their services are essential to the tested critical or important functions. |
| Supervisory | Self-managed & documented for audit. | Scoping specification must be formally approved by the National Competent Authority (NCA). |
MiCA and DORA Penetration Testing Checklist for 2026
The MiCA regulation sets the rules for CASPs and token issuers. DORA (Articles 24–27) focuses on strengthening their operational resilience against cyber threats. Under DORA, authorised CASPs are classified as financial entities and must follow a structured penetration testing program.
Below is a simple checklist covering the four main phases.

Phase 1: Scope and Planning
If the regulator has designated the organisation to undertake annual baseline penetration testing or Threat-Led Penetration Testing (TLPT), decide whether to use the option to carry out the assessments every three years. Specify the testing scope by identifying all the critical systems that need to be tested, such as custody infrastructure, wallets, trading platforms, payment gateways, and critical third-party providers like cloud hosting, blockchain nodes, and liquidity service providers.
Phase 2: Perform Annual Baseline Penetration Testing
Conduct an annual baseline penetration test of key management systems, API, mobile and web applications, and trading platforms to uncover security weaknesses. The evaluation should also include the assessment of the internal/external cloud infrastructure, the servers, containers, and environments, to identify vulnerabilities and misconfigurations that could be exploited.
Phase 3: Threat-Led Penetration Testing (TLPT)
When TLPT is needed, take the help of external Threat Intelligence and Red Team companies to simulate realistic attacks on live systems. Conduct Purple Team workshops after the exercise to discuss results, enhance detection, and bolster incident response.
Phase 4: Remediation Compliance
Address vulnerabilities identified, re-test to ensure the issues have been resolved. Report testing results and remediation activities in a compliance report to the National Competent Authority (where applicable) and report the overall result and remaining risks to senior management.
Important Timelines: The EU-wide transitional grandfathering periods for existing crypto firms are wrapping up. Depending on the EU member state, firms must achieve full compliance and authorization, including audited security infrastructure, by July 1, 2026 at the latest to avoid enforcement or forced shutdowns.
How Does QualySec Help Fintech Organisations Meet MiCA and DORA Penetration Testing Requirements?
Implementing MiCA and DORA requirements goes beyond checking vulnerabilities and requires a structured testing programme with independent validation and documentation that is ready for compliance. Qualysec can assist fintechs, Crypto-Asset Service Providers (CASPs), and other regulated financial firms throughout this process.
I. Annual Baseline Penetration Testing
To assist organisations in achieving annual resilience testing requirements under DORA, QualySec carries out manual penetration testing, supplemented by automated vulnerability scanning. Assessments cover web and mobile applications, APIs, cloud infrastructure, blockchain environments, smart contracts, and other critical ICT assets using recognised methodologies such as OWASP, NIST SP 800-115, and PTES.
II. Compliance-ready Reporting and Retesting.
Detailed reports including risk prioritisation, remediation advice, and findings are provided for each engagement along with a mapping to known standards like ISO 27001, SOC 2, and PCI DSS. After vulnerabilities are addressed, Qualysec conducts retesting to ensure vulnerabilities are sufficiently fixed and produces new documentation to aid internal audits and regulatory reviews.
III. Independent Third-Party Assurance
Both MiCA and DORA stress the need for independent security validation. QualySec is a CREST-accredited penetration testing company and will provide impartial security assessments with audit-ready documentation, providing organisations with credible evidence that they have been tested in line with recognised industry standards.
Key Takeaways
- Dual Compliance Imperative: Crypto businesses and financial institutions operating in the EU must comply with both MiCA (market conduct, licensing, and consumer protection) and DORA (digital operational resilience and cybersecurity).
- Regulatory vs. Technical Obligations: MiCA establishes the operational framework for Crypto-Asset Service Providers (CASPs), but explicitly cross-references DORA for technical cybersecurity execution and threat testing.
- Two-Tiered Testing Requirements: DORA establishes two distinct penetration testing mandates: Standard Resilience Testing (annual, baseline) and Threat-Led Penetration Testing (TLPT) (triennial, adversary simulation for designated entities).
- Action Plan: Achieving compliance requires identifying Critical or Important Functions (CIFs), establishing structured vulnerability management, executing threat simulations, and maintaining audit-ready remediation records.
Conclusion
For regulated crypto businesses, the only thing that’s certain is that conforming is no longer a matter of being authorised. Regulators now require organisations to demonstrate their ability to protect their systems, respond to incidents and maintain their operations when systems are attacked.
That’s exactly where MiCA and DORA go hand-in-hand. MiCA provides information to crypto enterprises about what they must do in order to function in the European market, whereas DORA provides information to crypto enterprises on how to build and maintain secure, resilient ICT systems. DORA consulting can help organisations interpret these requirements and align their cybersecurity and operational resilience practices accordingly. Reading one regulation without the other leads to gaps in compliance which many organisations are not aware of until years later.
Frequently Asked Questions (FAQs)
1. What are the MiCA regulations for 2026?
MiCA (Markets in Crypto-Assets Regulation) is the EU’s regulatory framework for crypto-assets and crypto businesses. It outlines the principles of licensing, oversight, integrity of the crypto asset market, consumer protection, and transparency for crypto-asset issuers and Crypto-Asset Service Providers (CASPs). The provisions on operational security obligations are included in MiCA, but detailed cybersecurity is provided in DORA.
2. Is DORA regulation applicable in the UK?
DORA is not automatically applicable as domestic UK law, but it directly impacts UK-based financial companies, Crypto-Asset Service Providers (CASPs, etec, with EU operations, EU clients, or providers of essential ICT services within the EU
3. What are the 5 pillars of DORA regulation?
The DORA regulation follows five main pillars:
- ICT risk management
- ICT-related incident management and reporting
- Digital operational resilience testing
- ICT third-party risk management
- Information and intelligence sharing
4. What are the main points of MiCA regulation?
MiCA sets up a uniform regulatory system for the crypto-asset markets in Europe. It includes licensing for crypto enterprises, governance rules and disclosure needs, market abuse prevention, consumer protection, and operational resilience. Organisations governed by MiCA have to mandatorily comply with the cybersecurity requirements of DORA.
5. Who is subject to DORA regulation?
The EU DORA Regulation covers various types of financial services institutions, such as banks, payment institutions, investment firms, insurance companies, electronic money institutions, trading venues, and Crypto-Asset Service Providers (CASPs) that are authorised under MiCA. It also provides supervision to third-party service providers of the regulated organisations, whose services are of critical importance.






