DORA & Authentication Master Guide

A guide for managers and experts overseeing the areas of identity, security and compliance in organizations operating in regulated sectors.

1. Introduction: From Policy to Enforcement

The Digital Operational Resilience Act (DORA) was adopted by the European Parliament and the Council in December 2022 and entered into force on January 16, 2023. Full compliance with its provisions by financial institutions and ICT providers became mandatory on January 17, 2025. This important regulation marks a shift in the EU financial sector, from treating operational resilience as a best practice to making it a legal obligation.

Operational resilience

Operational resilience means an organization’s ability to keep its critical functions running even during major disruptions such as a cyberattack, system failure, human error, or the loss of a key supplier.

In the context of DORA, it means that a financial institution must be able to prevent ICT incidents, respond to them effectively, and recover quickly to ensure that financial services remain available without interruption.

The goal of DORA is to ensure that all financial institutions operating in the European Union, along with information and communication technology (ICT) providers, can maintain business continuity even during cyberattacks, system failures, or major technological incidents.

In practice, DORA turns digital resilience from a recommendation into a binding obligation.

Organizations must not only implement proper security measures but also be able to prove that they are in place, showing how they manage ICT risks, control user access, supervise third-party providers, and restore critical services after incidents.

Authentication, which until recently was seen mainly as a technical part of IT operations, has become a key element of DORA compliance. Articles 20 and 21 clearly define identity, access, and authentication management as fundamental pillars of operational resilience. From a regulatory point of view, authentication is no longer just a technical process. It has become a measurable compliance requirement. Financial institutions must use strong authentication, apply the principle of least privilege, and fully log and audit all identity-related activities.

Principle of Least Privilege (PoLP)
The principle of least privilege means giving users, systems, and applications only the minimum level of access needed to perform their tasks. This helps reduce the risk of mistakes, misuse, and the impact of possible breaches.

In the context of DORA, this means that access rights must match the user’s role, be reviewed regularly, and be revoked immediately when a person changes position or leaves the organization.

2. What is DORA and who does it apply to?

The DORA Regulation (Regulation (EU) 2022/2554) sets uniform requirements for technology risk management and cybersecurity across the financial sector in the European Union.

Unlike a directive, the regulation applies directly to all member states, meaning it does not need to be implemented into national law. As a result, all covered entities must meet the same requirements at the same time.

DORA applies to banks, credit institutions, investment firms, insurance companies, payment service providers, and other organizations operating in the financial market. Equally important, it also covers ICT service providers that support these institutions. This includes software vendors, cloud providers, identity and authentication management solutions, and other technology suppliers considered critical to the functioning of financial institutions. The regulation is built on the idea that the digital resilience of the entire sector depends not only on the security of individual banks or insurers but also on the reliability and protection provided by their technology partners.

DORA aims to harmonize and strengthen operational resilience across the entire financial ecosystem of the European Union. Its requirements are divided into several key areas: ICT risk management, incident reporting, resilience testing, third-party oversight, and identity and access management. All these areas share one common goal, to ensure that essential financial services remain available and secure, even during major technology disruptions.

Regulation and Directive

A regulation applies directly in all European Union member states and does not need to be implemented into national law. This means its rules take effect in the same way across the entire EU from the date specified.

A directive, on the other hand, sets a goal that each member state must achieve, but allows them to decide how to include it in their own national legislation. This process is called transposition.

ICT Risk Management

ICT risk management is the foundation of DORA. It requires institutions to identify and control risks related to the technologies they use. This includes software vulnerabilities, network configuration errors, dependencies on cloud infrastructure, and human factors such as access management and user awareness.

Each organization must create a risk management framework that covers the entire lifecycle of ICT assets, from acquisition to decommissioning. These processes should include clear procedures for detecting and responding to incidents, protecting systems from unauthorized access, ensuring business continuity, and restoring data after a cyberattack or technical failure.

DORA makes it clear that risk management is not a one-time task. It must be a continuous process that includes regular reviews, updates, and adjustments of security measures to reflect new and evolving threats.

Risk management as a continuous process

Risk management, as a continuous process, means constantly monitoring, assessing, and updating threats and security measures. An organization must continually respond to technological changes and emerging risks, not limit itself to periodic reviews.

In the context of DORA, this means that a financial institution should maintain continuous control over ICT risks, regularly test its security measures and be ready to demonstrate to the regulator at any time that its systems are resilient to incidents.

Third-Party Risk Oversight

The second pillar of DORA focuses on the control of ICT service providers. Many financial institutions depend on external partners for key technology components. From cloud and hosting services to user authentication. DORA requires that these relationships be managed with the same level of care and control as internal operations.

Organizations must keep a complete register of all ICT service providers, assess their security and resilience, and sign contracts that clearly define responsibilities for risk management, incident reporting, and business continuity. In some cases, regulators may classify a provider as critical, meaning that they will be subject to direct supervisory oversight.

In this way, DORA extends the concept of operational resilience across the entire supply chain, reducing the risk that a weak link on the technology partner’s side could cause disruptions across the financial system.

Critical ICT Third-Party Provider

A critical ICT service provider is an organization whose services or infrastructure are essential to the business continuity of financial institutions, and whose failure could cause major disruptions to the EU financial system. In practice, this refers to providers on which many institutions or key processes — such as cloud services, authentication, networking, or data processing — depend.

Under DORA, critical providers are designated by the European Supervisory Authorities (EBA, ESMA, and EIOPA). These providers are subject to direct oversight at the EU level, rather than being supervised only by national regulators.

Identity and Access Management as the Foundation for Compliance

Among all DORA requirements, information security and data protection in ICT systems play a key role. According to Article 9(2)(d) of the Regulation, financial institutions must ensure that all data is protected against risks arising from management errors, improper processing, or human factors. In practice, this means implementing both organizational and technical measures that guarantee the integrity, confidentiality, and availability of data at every stage of processing.

One of the most important parts of this requirement is identity and access control within ICT systems. Institutions should use authentication and authorization solutions that match the level of risk and the importance of the protected resources. This includes clear rules for granting and revoking access rights, limiting access according to the principle of least privilege, and performing regular access reviews and audits.

DORA treats these actions not as technical details, but as mandatory elements of operational risk control, subject to review and verification by supervisory authorities.

Why DORA is so important

DORA represents a major shift in how the European Union approaches digital risk. Cyber resilience is now seen as a core part of financial stability. Any incident that disrupts digital services can lead to real economic consequences. For this reason, the regulation replaces voluntary guidelines with binding and auditable requirements.

For security and compliance teams, this means that operational resilience is no longer just a goal — it is a regulatory obligation. Failure to comply with DORA can result in financial penalties, business restrictions, or a loss of trust from customers and partners.

Cyber resilience

Cyber resilience means an organization’s ability to prepare for, respond to, and recover from cyber incidents while continuing to operate its essential functions. In simple terms, it’s about staying secure and staying operational, even when facing cyberattacks, system failures, or other digital disruptions.

3. Governance & Accountability: Management, accountability and IAM requirements

One of the most important aspects of DORA is the shift in responsibility for digital security from the operational to the strategic level. The regulation clearly states that an organization’s management is responsible for the compliance and effectiveness of all implemented security measures. This marks a major change from previous practices, where cybersecurity was often seen as the sole responsibility of IT departments.

Management Responsibility

According to Article 5 of the DORA Regulation, the management body of a financial institution holds full responsibility for establishing, approving, supervising, and effectively implementing all elements of the ICT risk management framework. This includes both technical and organizational processes that ensure the integrity, availability, and security of IT systems.

Board members are required to actively participate in the digital risk management process, meaning they must understand key technological threats and their potential impact on business operations. Article 5(1) explicitly states that the board has ultimate responsibility for ICT risk management. This includes defining and approving security policies, setting clear roles and responsibilities for ICT functions, and ensuring proper oversight and reporting mechanisms.

In practice, DORA compliance cannot be delegated solely to IT or compliance teams. Board members must be able to demonstrate to supervisory authorities that they oversee the operation of security systems, including authentication, access management, and ICT incident monitoring processes.

DORA therefore establishes a new standard of corporate governance in the financial sector: digital resilience becomes an integral part of strategic management, with accountability clearly assigned to members of the management and supervisory boards.

Articles 20 and 21: ICT Incident Management and Reporting

Articles 20 and 21 of the DORA Regulation, included in Chapter IV, “Information and Communication Technology-related Incident Management, Classification, and Reporting,” establish the obligation to implement consistent processes for managing ICT incidents and reporting them to the relevant supervisory authorities. The regulation introduces unified classification criteria, standardized reporting templates, and a common format for sharing incident information across the European Union.

While these articles do not directly refer to authentication or identity management, they are closely connected. DORA requires that any event involving unauthorized access, incorrect authorization, or loss of data integrity be treated as an ICT incident that must be analyzed and, if necessary, reported. This means that effective identity and access management is not only a preventive measure but also an essential source of evidence, helping organizations quickly identify the root cause of incidents, assess their impact, and prepare reports that meet regulatory standards.

More broadly, Articles 20 and 21 emphasize that operational resilience goes beyond technical safeguards. It also requires a transparent, well-documented system for incident response, reporting, and continuous improvement, one that clearly includes authentication and access control processes.

Strong Authentication in the Context of DORA

DORA does not mandate a specific authentication technology but requires that the mechanisms used are resistant to social engineering, credential theft, and phishing attacks. In practice, this means that simple forms of 2FA based on SMS or email may not meet the regulation’s requirements if they do not provide a cryptographic link between the user, the device, and the system.

Strong authentication compliant with DORA should meet three key conditions:

1. Multi-factor authentication (MFA) – identity verification must be based on at least two independent factors (for example: knowledge, possession, or biometrics).
   
   

2. Resistance to phishing and session hijacking – authentication data must not be interceptable or reusable by attackers.
   
   

3. Logging and traceability – every login attempt, access request, or privilege escalation must be recorded and possible to reconstruct during an audit.

In the context of DORA, strong authentication is not an optional feature but one of the core proofs of regulatory compliance.

Identity Lifecycle Management

DORA requirements cover the entire lifecycle of a user’s identity, from creation to removal from the system. Every stage must be controlled and traceable. This includes:

• granting access only after identity verification and approval by authorized personnel,
  
  

• regularly reviewing active accounts and assigned roles,
  
  

• immediately revoking access after a role change or when the user leaves the organization,
  
  

• documenting all permission changes and login events.

In this sense, DORA strengthens the principle of least privilege (PoLP) by requiring not only its implementation but also documentation of how it is enforced. During an audit, the institution must be able to prove that each user has access only to what is necessary, and that every permission grant or revocation has been properly recorded.

Audit and verification of IAM processes

According to article 6 of the DORA Regulation (Regulation (EU) 2022/2554), financial institutions are required to regularly audit and review their ICT risk management frameworks. This means periodically testing the effectiveness of implemented security measures, documenting the results, and applying improvements based on audit findings and past incidents.

As part of these activities, institutions must maintain a complete and consistent record of all events related to user access and authentication. Logs should make it possible to identify the source, time, and nature of each activity in the system, remain protected from modification, and be ready for presentation during supervisory inspections or internal audits.

Incomplete records, outdated procedures, or the inability to reconstruct access history may be considered by supervisory authorities a serious breach of ICT risk management principles. Therefore, centralizing identity and log management is a key element in meeting DORA requirements and demonstrating compliance.

4. What does "strong authentication" mean in the context of DORA?

Strong authentication is a method of confirming a user's identity in which access to a system is granted after meeting at least two independent verification conditions. These may be factors based on knowledge (e.g., password or PIN), possession (e.g., device, token, hardware key), or biometric features (e.g., fingerprint, facial recognition). A key feature of strong authentication is that the loss of trustworthiness of one factor does not automatically lead to account compromise or access to resources. The security of the process relies on each factor operating independently, and effective verification requires their simultaneous confirmation.

In recent years, traditional passwords have been largely replaced by modern mechanisms based on public key cryptography. Standard-compliant solutions, such as passkeys developed by the FIDO Alliance, use pairs of cryptographic keys: a private key (securely stored on the user's device) and a public key (stored on the system). When logging in, the user confirms their identity locally, for example, using biometrics or a device code, and the system verifies the cryptographic signature without transmitting passwords or one-time codes.

This authentication model is resistant to phishing, credential harvesting, and man-in-the-middle attacks because the private key never leaves the device and each login session is unique. Passkey technology is currently recognized as a benchmark for implementing phishing-resistant authentication, compliant with security principles required by EU regulations.

Phishing-resistant authentication

Phishing-resistant authentication is a login method where user credentials cannot be intercepted or used on a fake website. The system recognizes the original domain and allows login only in a trusted environment.

Link to DORA Requirements

DORA requires financial institutions to ensure that access to data and systems is protected against unauthorized use, and that all user activities are monitored and recorded (Article 9(2)(d)). This means that implementing strong authentication is a practical way to meet key DORA requirements related to ICT risk management and operational security.

In line with DORA’s intent, strong authentication should:

• be consistent across the entire organization, regardless of applications or infrastructure,
  
  

• provide resistance to phishing and session hijacking,
  
  

• enable logging and auditing of all login attempts and privilege changes,
  
  

• and form an integral part of ICT risk management.
  
  

In this context, passkey-based mechanisms address not only technical security needs but also the evidential requirements under DORA. They allow organizations to demonstrate that authentication processes are effective, resistant to misuse, and compliant with the control principles described in the regulation.

Passkeys

Passkeys are a passwordless authentication method based on public key cryptography. Passkeys use a private key on the user’s device and a public key on the service. Login happens locally (e.g., via biometrics or PIN), making them phishing-resistant and unique to each site.

Passkeys are standardized by the FIDO Alliance and the World Wide Web Consortium (W3C) and are supported by major platforms such as Apple, Google, and Microsoft.

5. Convergence of DORA with other regulations

Although DORA is an EU regulation, its goals align with a global shift toward stronger digital resilience and secure authentication. Regulators worldwide now require multi-factor, phishing-resistant authentication and identity management based on the principle of least privilege.

NIS2 (EU)
Effective from October 2024, the NIS2 Directive extends cybersecurity requirements to sectors such as energy, transport, healthcare, and public administration. While DORA targets finance, both frameworks demand consistent ICT risk management, strong authentication, and fast incident reporting. Many organizations covered by NIS2 can therefore use similar processes and tools to meet DORA obligations.

PSD2 (EU)
The PSD2 Directive introduced Strong Customer Authentication (SCA) for electronic payments. While PSD2 applies only to payment services, its three-factor model, knowledge, possession, and biometrics, became the basis for modern security standards that DORA expands across the financial sector. Both stress the importance of verifying identity, authenticating access, and logging user actions as part of risk control.

NYDFS (USA)
In force since 2017, the New York Department of Financial Services (NYDFS) Cybersecurity Regulation requires MFA, protection against phishing and social engineering, incident management, and supplier oversight. DORA follows the same philosophy: institutions must not only prevent incidents but also prove their ability to detect, classify, and report them.

In essence, DORA is part of a global movement toward unified digital resilience, where strong authentication, auditability, and access control are universal standards across jurisdictions.

6. DORA Compliance Implementation Plan

Building DORA compliance is not a one-time technical project. It is an ongoing process that includes analyzing risks, improving authentication methods, updating internal policies, and creating a clear system for managing digital security. Operational resilience, as defined by DORA, is not a fixed state but the ability to respond, recover, and adapt when something goes wrong.

The first step is to check how well the organization already meets DORA’s requirements. This means reviewing all processes related to authentication, access control, incident management, and event logging to see what works well and what needs improvement.

The next step is to build a clear ICT risk management framework. Organizations must not only have written procedures but also be able to prove that they work in practice. This framework should include both technical and organizational areas, such as access rules, incident response, and regular testing of security measures.

Another important part is implementing strong authentication. Financial institutions should move away from passwords or SMS codes and start using modern, phishing-resistant methods like FIDO2 or passkeys. These methods must work across all systems, both new and old, without requiring code changes or complicated integrations.

Institutions also need to centralize logs and make sure all access and identity actions can be checked. It must always be possible to see who accessed what, when, and how. All records should be complete, secure, and ready to show to auditors or regulators. If logs are missing or inconsistent, it may be treated as a compliance issue.

Finally, compliance is not something you finish once. Organizations must regularly test their systems, review incidents, and update policies to stay ready for new threats and regulations.

In short, DORA compliance is not a list of tasks but a change in how an organization works. It means making digital security, identity management, and resilience part of everyday operations, building stronger protection and trust at the same time.

7. The most common audit errors and gaps

For many organizations, implementing DORA compliance is not only a matter of meeting legal requirements but also a test of operational maturity. While the regulation is clear in its objectives, practice shows that many institutions make the same mistakes, particularly in the areas of identity, authentication, and auditability.

The most common mistakes in DORA implementation

1. Treating DORA as an IT project, not a strategic initiative
   The biggest misconception is that DORA compliance is solely the responsibility of the security or IT department. In reality, the responsibility rests with management. A lack of management involvement results in fragmented implementation and a lack of consistency between security policies and the organization's actual practices.
   
   
   

2. Bypassing legacy apps in the authentication process
   Many institutions implement strong authentication exclusively for modern systems, excluding legacy applications that often store the most sensitive data. However, DORA doesn't distinguish between new and legacy systems, all systems must be protected and centrally monitored.
   
   
   

3. Lack of consistent logs and central access records
   A common problem during audits is the lack of complete data regarding who accessed which system, when, and how. Fragmented logs, a lack of correlation between systems, or the inability to reconstruct them are typical gaps that may be considered by regulators as serious violations of ICT risk management principles.
   
   
   

4. Equating MFA with phishing-resistant security
   Not every form of multi-factor authentication meets DORA requirements. Solutions based on passwords, SMS codes, or push notifications do not guarantee a cryptographic link between a user's identity and their device. The regulation requires phishing-resistant mechanisms, those that eliminate the possibility of credentials being compromised.
   
   
   

5. Lack of regular resilience testing and security policy reviews
   ICT risk management, as defined by DORA, is a continuous process. Organizations that limit themselves to a one-time certification or audit risk losing compliance after just a few months. Regular policy reviews, penetration testing, and procedural updates are essential to maintaining compliance over time.

Common audit gaps

Below are the most frequently mentioned deficiencies from the report European Central Bank – IT and Cybersecurity Risks: Key Observations 2024.

1. No control over access
   In many organizations, employees and administrators have overly broad permissions. There is no central control system showing who has access to what data and why.
   
   
   

2. Incomplete registration of security events
   Not all systems record information about logins and user activity. Some data is missing from central reports, making it difficult to determine exactly what happened.
   
   
   

3. Poor supervision of external suppliers
   Companies often lack a clear understanding of how their vendors protect data and respond to incidents. There is a lack of ongoing monitoring and clear rules for handling emergencies.
   
   
   

4. Outdated post-incident procedures
   Response plans for emergencies or cyberattacks are often outdated or have never been tested. Crisis communication guidelines are also sometimes missing.
   
   
   

5. Lack of order in data and systems
   Not all institutions know exactly which data is most important or where it is stored. This makes incident response and risk assessment more difficult.
   
   
   

6. Insufficient preparation for new DORA reporting rules
   Some organizations still lack processes that would allow them to report incidents in line with DORA requirements, in the correct format and within the required time frame.
   
   
   

8. How Secfense Supports DORA Compliance in IAM and Authentication

DORA requires identity and access management (IAM) processes to be consistent, auditable, and error-resistant. Organizations must ensure uniform authentication policies across all systems, including modern, cloud, and legacy systems, and ensure full traceability and reporting of every access attempt.

Secfense helps organizations meet DORA requirements by providing a security layer that can be implemented without any changes to application code, centralizing control over identity and authentication across the entire environment.

Thanks to this, financial institutions can:

• Use strong authentication across all applications, including legacy applications that don’t natively support modern login methods.
  
  

• Manage access policies centrally through a single administration panel, simplifying DORA compliance and ensuring consistent configuration across the entire environment.
  
  

• Log and monitor all authentication events to create a complete, tamper-proof audit trail required by regulators.
  
  

• Enforce the Principle of Least Privilege (PoLP) and immediately revoke access when a role changes, an employee leaves, or a security incident is detected.
  
  

• Integrate authentication seamlessly into existing infrastructure, including Active Directory, SAML, OpenID Connect, SIEM, and IdPs, without service interruptions.
  
  

• Secure high-risk operations through micro-authorizations that require re-confirmation of identity before performing critical actions.
  
  

Every authentication step handled by Secfense is recorded, time-stamped, and available for auditor review. In practice, this means that an organization can easily demonstrate compliance with DORA requirements for access management, user logging, and ICT risk controls.

DORA emphasizes operational resilience and business continuity, and the Secfense architecture is built to support these goals. It can function as middleware (reverse proxy) or as a standalone Identity Provider (IdP), providing flexibility and security without disrupting production systems.

This enables financial institutions and their ICT providers to meet DORA requirements in a measurable, auditable, and disruption-free way, strengthening security without affecting daily operations.

9. Implementation Examples: Strong Authentication in Practice

Secfense's implementations at European financial institutions demonstrate that adapting systems to DORA requirements doesn't have to involve complex IT projects. A key advantage of Secfense's approach is the ability to implement strong authentication without interfering with application code, without downtime, and without the risk of losing compliance with applicable regulations.

A large European bank

One of Europe's largest banking institutions implemented the Secfense solution to replace traditional passwords with modern passkey-based authentication (FIDO2). The entire process was carried out without disrupting production systems or modifying applications. The reverse proxy architecture secured both internal employee systems and external applications used by corporate clients. This resulted in fully adapting authentication and access management processes to DORA requirements, preparing the environment for a complete transition to passwordless login.

A leading insurer in Central and Eastern Europe

One of the largest insurance companies in the region implemented Secfense to provide strong authentication for employees, agents, and end customers. The project involved thousands of users and dozens of systems running in various environments, on-premises and cloud, and was completed in a matter of weeks. Integration with existing infrastructure, including load balancers, ensured the entire implementation was seamless and code-free. Authentication based on FIDO2 and other MFA methods enabled compliance with DORA requirements for strong authentication, event logging, and identity and access control.

Software Provider for the Financial Sector

A leading software provider for the insurance industry implemented Secfense to quickly secure its application environment against unauthorized access. The solution protected more than twenty systems used by several thousand users. Thanks to the no-code approach and network-layer deployment, the entire project was completed within weeks. The organization gained full visibility and control over access, integrated the solution with existing monitoring tools, and met DORA requirements for incident reporting and login auditability.

Key Takeaways from Implementations
All these examples show that achieving DORA compliance in the area of identity and access management is possible without costly infrastructure changes.

The main success factors included:

• Speed of implementation – projects completed in weeks, not months, with no downtime.
  
  

• No changes to applications – no need to modify code, no risk to production systems.
  
  

• Centralization and auditability – unified access control, full logging, and immediate readiness for regulatory inspections.
  
  

These implementations confirm that DORA compliance is not a one-time project but an ongoing process that can be rolled out in secure, predictable, and scalable phases. Secfense enables financial institutions to move from traditional authentication toward full operational resilience — without rebuilding their entire infrastructure.

10. Summary and Next Steps

DORA is more than just a checklist of regulatory requirements, it defines the future direction of digital security in the financial sector. The regulation obliges organizations to protect their systems, manage access, and respond to incidents quickly and in a fully documented way. In practice, this requires strong authentication, clear access policies, and complete visibility over who accessed what, when, and how.

 How Secfense Addresses Each DORA Requirement

Secfense enables organizations to meet these requirements without redesigning applications or disrupting operations. The platform introduces strong, phishing-resistant authentication across all applications, both modern and legacy, while centralizing access control in one place. This approach strengthens security, simplifies compliance, and ensures readiness for DORA audits.

If your organization is preparing for an audit or planning to enhance its cybersecurity posture, reach out to the Secfense team. Our experts can help you design and deploy a solution that makes DORA compliance straightforward, while improving the everyday security and resilience of your environment.

Contact the Secfense team to learn how to implement strong authentication and achieve full compliance with DORA.