DORA MFA Requirements: Strong Authentication Compliance Guide

DORA MFA Requirements at a Glance

• DORA requires strong authentication: Article 9 requires financial entities to implement strong authentication mechanisms based on their data classification and ICT risk assessment.
• MFA is mandatory for privileged access: The Regulatory Technical Standard on ICT risk management requires MFA for all privileged access and for access to systems that support critical or important functions.
• It is risk-based, not optional: Entities must assess their ICT assets and decide where strong authentication is needed. Undocumented gaps and exceptions are a compliance finding.
• It applies to the workforce, not customers: DORA’s authentication requirements cover employees, contractors, and other workforce members. Customer authentication is governed separately by PSD2.
• ICT third-party providers are in scope: Providers that serve financial entities, including those outside the EU, are affected, and critical providers face direct EU oversight.
• Penalties are severe: Financial entities can be fined up to 2% of total annual worldwide turnover, individuals up to €1 million, and critical ICT providers up to 1% of average daily worldwide turnover for each day of non-compliance.

What is DORA?

The Digital Operational Resilience Act (DORA) is Regulation (EU) 2022/2554, an EU law that strengthens the digital operational resilience of the financial sector. It was adopted on December 14, 2022, entered into force on January 16, 2023, and became fully applicable on January 17, 2025, after a two-year implementation window. DORA was created because the financial sector depends heavily on technology and on third-party technology providers, which makes it vulnerable to cyberattacks and IT disruptions that can cascade across borders and threaten financial stability.
 
DORA is a regulation, not a directive. This is an important distinction. Unlike the NIS2 Directive, which each member state must transpose into national law, DORA applies directly and uniformly across all EU member states without the need for national transposition. The same core requirements apply everywhere in the EU, though member states set their own penalty frameworks. DORA is supplemented by a set of Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) that specify its requirements in detail, including the authentication requirements that matter for MFA.
 
DORA covers four main areas: ICT risk management, ICT-related incident reporting, digital operational resilience testing, and ICT third-party risk management. It also establishes an EU-level oversight framework for the most critical technology providers to the financial sector. For financial entities, 2025 was largely a transition year, and 2026 is the year supervisory authorities move to active enforcement.

Who Does DORA Apply To?

DORA applies to a broad range of financial entities operating in the EU, around 20 categories in total, as well as to the ICT third-party providers that serve them. In-scope organizations include:

• Banks and credit institutions: Traditional banking organizations of all sizes operating in the EU.
• Investment firms and trading venues: Investment firms, trading platforms, and central securities depositories.
• Insurance and reinsurance undertakings: Insurers, reinsurers, and insurance intermediaries.
• Payment and e-money institutions: Payment service providers, electronic money institutions, and account information service providers.
• Crypto-asset and crowdfunding providers: Crypto-asset service providers and crowdfunding platforms brought into scope alongside more traditional entities.
• ICT third-party service providers: Cloud providers, data centers, software vendors, and other technology firms that provide services to financial entities. Providers designated as critical face direct oversight from EU authorities.

A proportionality principle applies, so smaller entities such as microenterprises face simplified requirements. However, core obligations still apply regardless of size. The inclusion of ICT third-party providers is one of DORA’s most significant features, because it extends the regulation’s reach well beyond financial entities themselves.
 
A note for Canadian and other non-EU organizations: DORA has extraterritorial reach. A non-EU technology provider that supplies services to EU financial entities can fall within DORA’s scope, and a provider designated as a critical ICT third-party provider must establish an EU subsidiary within 12 months of designation. In November 2025, the European authorities named the first critical ICT third-party providers, a list that included major global technology firms. Even where DORA does not apply directly, EU financial clients increasingly require DORA-aligned security measures, including strong authentication, from their providers through contracts. Canadian financial entities with EU operations should expect to comply directly.

What Are the DORA Requirements?

DORA’s requirements span ICT risk management, incident reporting, resilience testing, and third-party risk. The authentication requirements most relevant to MFA sit within the ICT risk management framework in Article 9 and are developed further in the Regulatory Technical Standard on ICT risk management. The table below maps the key provisions to their MFA relevance and how LoginTC supports them.
 

Article 9: Protection and Prevention

Article 9 sits within DORA’s ICT risk management framework and sets out the protective measures financial entities must take to secure their systems and data. Among these, Article 9(4)(d) requires entities to implement policies and protocols for strong authentication mechanisms, based on relevant standards and dedicated control systems, and to protect cryptographic keys. Crucially, the requirement is tied to the results of the entity’s data classification and ICT risk assessment. In other words, DORA requires an entity to assess its ICT assets and processes and then decide where strong authentication is needed to reduce risk.

The RTS on ICT Risk Management

DORA’s high-level requirements are made concrete by the Regulatory Technical Standard on ICT risk management, Commission Delegated Regulation (EU) 2024/1774. This standard has legal force and adds prescriptive detail. On authentication, it specifies that strong authentication, including multi-factor authentication, must be applied to all privileged access and to access to all systems that support critical or important functions. This is the provision that turns DORA’s general “strong authentication” language into a concrete MFA obligation. The standard also brings service accounts explicitly into scope, requiring entities to maintain an inventory of them and apply appropriate controls.

Strong Authentication Versus MFA

DORA generally uses the phrase “strong authentication” rather than “MFA.” In practice, the requirement is met through multi-factor authentication: the use of at least two independent factors from different categories, being something you know, such as a password; something you have, such as a hardware token or authenticator app; and something you are, such as a biometric. The RTS makes clear that MFA is the expected mechanism for privileged and critical-function access. DORA’s authentication requirements apply to the workforce, meaning employees and contractors. Customer authentication for financial services is governed by separate legislation, the revised Payment Services Directive (PSD2).

Is MFA Required by DORA?

Yes. DORA requires strong authentication under Article 9, and the accompanying Regulatory Technical Standard on ICT risk management makes multi-factor authentication mandatory for all privileged access and for access to systems that support critical or important functions. This is not guidance. The RTS is a technical standard with legal force, so MFA on privileged accounts is a binding obligation for in-scope financial entities.
 
The requirement is risk-based, which shapes how it applies but does not weaken it. DORA expects entities to conduct an ICT risk assessment, classify their assets, and determine where strong authentication is needed to reduce risk. For privileged access and critical-function systems, the RTS removes the discretion: MFA is required. For other access, the entity must assess and document its decisions. Supervisors have been clear that undocumented MFA exceptions are a compliance finding, and that exceptions must be justified, risk-accepted by management, and mitigated with compensating controls.
 
Early DORA examinations have highlighted a consistent theme: the gap between what policies say and what evidence shows. Supervisors are not accepting well-written authentication policies at face value. They are asking for operational evidence that the controls are actually running, such as access review outputs, service account inventories, and exception logs. An entity that cannot produce this evidence has a gap regardless of what its policy states.
 
The technical expectation is also rising. For privileged access, phishing-resistant methods such as FIDO2 security keys are increasingly preferred over weaker factors such as SMS codes. The bottom line for financial entities is clear: MFA is legally required for privileged and critical-function access, it must be provable with evidence, and for the highest-risk access it should be phishing-resistant.

Consequences of DORA Non-Compliance

DORA establishes a strict penalty regime, and it applies differently to financial entities, individuals, and critical ICT third-party providers.
 
For financial entities, competent authorities can impose fines of up to 2% of total annual worldwide turnover, or up to 1% of average daily worldwide turnover for certain ongoing breaches. Because DORA is a regulation rather than a directive, member states set the specific national penalty frameworks, and some have gone well beyond the baseline. Individual members of the management body can face personal fines of up to €1 million, reflecting DORA’s emphasis on management accountability under Article 5, which makes the board responsible for the ICT risk management framework.
 
Critical ICT third-party providers face a separate penalty regime enforced directly at the EU level by a lead overseer. The lead overseer can impose periodic penalty payments of up to 1% of the provider’s average daily worldwide turnover for each day of non-compliance, for up to six months. For a large cloud provider, this can amount to a very substantial daily figure. In the most extreme cases, the lead overseer can recommend that financial entities suspend or terminate their arrangements with a non-compliant provider.
 
Beyond fines, supervisors can issue binding instructions, require specific remediation, restrict business activities, and publicly name non-compliant firms. In EU financial markets, public naming often draws more board attention than a monetary penalty. DORA also connects to other regimes: a single major incident could expose an entity to a DORA penalty, a GDPR penalty, and personal liability at the same time. With enforcement moving from a transition posture in 2025 to active supervision in 2026, the practical exposure is real and growing.

How to Implement MFA for DORA Compliance

1. Classify Your ICT Assets and Assess Risk

DORA ties authentication requirements to your data classification and ICT risk assessment, so start there. Identify and classify your ICT assets, and determine which systems support critical or important functions. This classification drives your MFA scope, because the RTS requires MFA for privileged access and for access to critical-function systems. A documented risk assessment is also the evidence that supports your authentication decisions during a supervisory review.

2. Inventory Privileged Accounts and Access Paths

Map every privileged account and every access path into critical-function systems, including administrator accounts, remote access, and service accounts, which DORA brings explicitly into scope. Distinguish privileged from standard access, and document the purpose of each privileged and service account. This inventory becomes your MFA deployment target and a key piece of audit evidence.

3. Select a Strong Authentication Solution

Choose an MFA solution that can enforce strong authentication across the access points in scope, including remote access, privileged accounts, and the applications and infrastructure behind critical functions. Look for support for RADIUS, LDAP, and Active Directory to cover the systems common in financial environments, and consider whether you need cloud, on-premises, or hybrid deployment based on your infrastructure and data handling requirements. For legacy financial applications that cannot integrate with modern identity systems, plan for an access proxy or privileged access approach that can enforce MFA without rewriting the application.

4. Prioritize Phishing-Resistant Factors for Privileged Access

Because supervisory expectations favor phishing-resistant authentication for high-risk access, deploy methods such as FIDO2 security keys or smart cards for privileged accounts and administrators. DORA’s Article 9 explicitly ties strong authentication to protection against phishing, so phishing-resistant factors align directly with the requirement for your most sensitive access.

5. Deploy MFA Across Privileged and Critical-Function Access

Roll out MFA to all privileged access and all access to critical-function systems, which the RTS makes mandatory. Include remote access and third-party and vendor access, which fall under DORA’s third-party risk requirements. Avoid the common coverage gaps that show up in examinations, such as MFA on the VPN while critical applications remain password-only, or vendor access that bypasses MFA through shared accounts. Make coverage explicit and complete.

6. Document Everything and Assign Board Accountability

DORA is evidence-based and places accountability on the management body under Article 5. Document your authentication policy, the systems and accounts covered, and any exceptions with their justification and management sign-off. Have the management body approve and oversee the framework. Keep the risk assessment, the policy, the account inventories, and the exception log together, since these are exactly what a supervisor will ask for.

7. Enable Logging and Review Regularly

Ensure your MFA solution logs all authentication events, including successful and failed attempts and MFA challenges, and forward them to your monitoring or SIEM platform. DORA expects entities to detect and respond to incidents quickly, and authentication logs are central to that. Establish regular access reviews and produce the review outputs, since supervisors expect to see evidence that controls are running over time, not just documented once.

Where DORA MFA Deployments Get Difficult

For many financial entities, the hardest part of DORA authentication compliance is not the modern cloud environment but the legacy systems and the third-party relationships that sit around it.
 
Financial institutions frequently run core systems that are decades old and were never designed to integrate with modern identity platforms. These systems often hold or support critical functions, which places them squarely within the scope of the MFA requirement, yet they cannot easily accept a standard MFA integration. The practical answer is to enforce MFA at the access layer, through RADIUS, an access proxy, or a privileged access approach, so that strong authentication is required before a user reaches the legacy system, without rewriting the application itself.
 
Third-party and vendor access is the other common gap. DORA places heavy emphasis on ICT third-party risk, and examinations frequently find vendor access that bypasses MFA through shared accounts or legacy support tooling. Every third-party path into a critical-function system needs the same strong authentication as internal access, and those arrangements need to be reflected in contracts and monitored over time. Addressing legacy systems and third-party access early is often what separates a smooth DORA examination from a difficult one.

DORA MFA Best Practices

• Tie MFA scope to your asset classification: DORA links authentication to your ICT risk assessment and data classification. Use that classification to define where MFA is mandatory, and keep the assessment as evidence for supervisors.
• Make MFA coverage explicit and provable: The most common examination finding is the gap between policy and evidence. Maintain access review outputs, service account inventories, and exception logs that demonstrate MFA is actually enforced, not just described.
• Prioritize phishing-resistant authentication for privileged access: FIDO2 security keys and smart cards align with DORA’s emphasis on protection against phishing and are the strongest option for the privileged accounts attackers target first.
• Bring service accounts into scope: The RTS explicitly covers service accounts. Inventory them, document their purpose, and apply appropriate controls rather than leaving them as unmanaged standing access.
• Close third-party and vendor gaps: Vendor access that bypasses MFA is a frequent finding. Enforce strong authentication on all third-party access to critical-function systems and reflect it in your contracts.
• Govern exceptions formally: Where MFA cannot be applied, document the exception, justify it, have management risk-accept it, and add compensating controls. Undocumented exceptions are a compliance finding.

How LoginTC Helps with DORA MFA Compliance

LoginTC is well suited to the environments financial entities operate, where strong authentication needs to reach not only modern applications but also the legacy core systems and third-party access paths that DORA scrutinizes. LoginTC integrates through RADIUS, LDAP, and Active Directory, so financial entities can enforce MFA across remote access, privileged accounts, and critical-function systems without replacing existing infrastructure.
 
For the Article 9 strong authentication requirement and the RTS obligation to apply MFA to privileged and critical-function access, LoginTC enforces MFA on the access points that matter, including remote access, Windows logon, VPNs, and administrator accounts. It supports phishing-resistant factors such as FIDO2 security keys and hardware tokens, which align with DORA’s emphasis on protection against phishing for privileged access. For legacy financial applications that cannot integrate with modern identity systems directly, enforcing MFA at the access layer allows strong authentication without changes to the application.
 
For financial entities that need to keep authentication infrastructure within their own environment, LoginTC’s on-premises deployment option provides that control. Detailed authentication logs and centralized administration give compliance teams the operational evidence DORA examinations require, such as records that authentication controls are running, which is exactly the kind of proof supervisors ask for rather than policy documents alone.
 
Explore LoginTC for Finance | View All Connectors

Frequently Asked Questions

Does DORA require MFA?

Yes. DORA Article 9 requires strong authentication, and the Regulatory Technical Standard on ICT risk management (Commission Delegated Regulation (EU) 2024/1774) makes multi-factor authentication mandatory for all privileged access and for access to systems supporting critical or important functions. The RTS has legal force, so MFA on privileged accounts is a binding requirement, not a recommendation. For other access, entities must assess where strong authentication is needed based on their ICT risk assessment.

Who does DORA apply to?

DORA applies to around 20 categories of financial entities operating in the EU, including banks, investment firms, insurers, payment institutions, crypto-asset service providers, and crowdfunding platforms, as well as the ICT third-party providers that serve them. Providers designated as critical face direct oversight from EU authorities. A proportionality principle gives smaller entities simplified requirements, but core obligations apply regardless of size.

What is the difference between DORA and NIS2?

Both are EU cybersecurity laws that require MFA, but they differ in scope and legal form. DORA is a regulation that applies directly and uniformly across the EU and is specific to the financial sector, where it takes precedence. NIS2 is a directive that each member state transposes into national law and covers a broad range of critical and important sectors. A financial entity is generally governed by DORA for ICT risk, while a group that includes non-financial entities may have subsidiaries under NIS2.

What types of MFA are acceptable under DORA?

DORA requires strong authentication using at least two independent factors from different categories: something you know, something you have, and something you are. The RTS expects MFA for privileged and critical-function access. Article 9 ties strong authentication to protection against phishing, so phishing-resistant methods such as FIDO2 security keys are strongly preferred for privileged access. Weaker methods such as SMS codes are increasingly seen as insufficient for high-risk access.

Does DORA apply to organizations outside the EU?

Yes, in certain cases. A non-EU ICT provider that serves EU financial entities can fall within DORA’s scope, and a provider designated as critical must establish an EU subsidiary within 12 months. Non-EU financial entities with EU operations are directly in scope for those operations. Even where DORA does not apply directly, EU financial clients typically require DORA-aligned security measures, including strong authentication, from their providers through contracts.

Does DORA cover customer authentication?

No. DORA’s authentication requirements apply to the workforce, meaning employees, contractors, and other internal users. Customer authentication for financial services, such as customers logging into online banking or authorizing payments, is governed by separate EU legislation, the revised Payment Services Directive (PSD2). DORA focuses on the operational resilience and internal security of the financial entity.

Does LoginTC need to be cloud-based to support DORA compliance?

No. DORA does not require a specific hosting model. Both cloud-based and on-premises LoginTC deployments can support DORA compliance. For financial entities that prefer to keep authentication infrastructure within their own controlled environment, or that need to enforce MFA on legacy core systems, LoginTC’s on-premises option and its ability to enforce MFA at the access layer are particularly useful.

Get a Free DORA MFA Strategy Session

Meeting DORA’s strong authentication requirement means more than switching on MFA. It means classifying your assets, covering privileged and critical-function access, handling legacy systems and third-party access that examinations focus on, and producing the operational evidence a supervisor will expect to see.
 
Our team helps financial entities and their technology providers deploy MFA that meets DORA’s requirements across modern and legacy systems, without disrupting core financial operations. If you are preparing for supervisory review or closing gaps in your authentication coverage, we are ready to help.