Compliance
DORA: Security Controls for Financial Compliance and Operational Resilience
What is the European Union’s DORA regulation?
DORA, the Digital Operational Resilience Act, is an EU regulation that sets uniform requirements for the cybersecurity and digital operational resilience of the financial sector. It became applicable on 17 January 2025, so it is in force today, and supervisory expectations continue to tighten as authorities review how entities have implemented it. DORA mandates strict requirements for access management, incident response, monitoring, and risk management to protect critical systems and sensitive data.
DORA applies broadly. In scope are roughly twenty types of financial entities, including banks, payment and e-money institutions, investment firms, insurers and intermediaries, crypto-asset service providers, trading venues, and central securities depositories, as well as the ICT third-party providers that serve them. Critical ICT third-party providers, including major cloud and software vendors, fall under a direct EU oversight framework. If you operate in EU financial services, or you supply technology to firms that do, DORA almost certainly applies to you.
The regulation is built on five pillars: ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information-sharing arrangements. Underneath those pillars, recurring technical themes appear again and again: strong access controls, identity and authentication, privileged access management, continuous monitoring, and auditable evidence of all of it. In this context, DORA aligns closely with NIST 800-53 by emphasizing secure, role-based access, continuous monitoring, and resilient ICT systems.
Why is it important?
If your organization operates in the EU financial sector or provides critical ICT services, compliance with DORA is mandatory. The point of DORA is operational resilience: keeping critical financial services running when something goes wrong, whether the cause is an outage, a supplier failure, or an attack. Regulators concluded that financial stability now depends on ICT resilience as much as on capital, and DORA turns that conclusion into enforceable obligations.
The stakes are concrete. Competent authorities can require remediation, impose administrative penalties, and, for critical ICT third-party providers under the oversight framework, levy periodic penalty payments. Member states set their own sanctions for financial entities, and management bodies are explicitly accountable for ICT risk under DORA, so responsibility sits with named individuals, not an abstract function.
There is an operational upside worth stating plainly. Most of what DORA asks for is good security practice you likely want anyway. Strong access controls, least privilege, an immutable audit trail, and tested incident response reduce real risk regardless of the regulation. DORA gives that work a deadline and a structure.
NIST 800-53 Controls Mapped
DORA states outcomes; it does not hand you a control catalog. NIST 800-53 (the U.S. National Institute of Standards and Technology's catalog of security and privacy controls) does, and most security and platform teams already run against it or something like it. Mapping DORA's access and resilience themes to NIST 800-53 lets you reuse controls you already operate instead of building a parallel program. The sections below map DORA's recurring themes to the relevant NIST 800-53 control families. For a deeper treatment of the mapping itself, see Teleport's NIST 800-53 compliance use case.
| DORA theme | What DORA expects | NIST 800-53 controls |
|---|---|---|
| Access management | Least-privilege access to critical ICT systems, enforced and reviewed | AC-2 (Account Management), AC-3 (Access Enforcement), AC-6 (Least Privilege) |
| Secure remote access | Controlled, authenticated remote access to infrastructure | AC-17 (Remote Access), IA-2 (Identification and Authentication), SC-7 (Boundary Protection) |
| Continuous monitoring | Ongoing monitoring of access and anomalous activity, rapid incident response | SI-4 (System Monitoring), IR-4 (Incident Handling), AU-6 (Audit Review) |
| Auditable access | Just-in-time provisioning and a tamper-evident record of access changes | AC-2 (Account Management), AC-3 (Access Enforcement), AU-2 (Event Logging) |
| ICT risk management | A documented, owned framework with categorization and resilient communications | PM-9 (Risk Management Strategy), RA-2 (Security Categorization), CP-9 (System Backup) |
| Privileged access | Strict control and separation of administrative access | AC-5 (Separation of Duties), AC-6(5) (Privileged Accounts) |
Access Management (Minimized Privilege and Context-Based Controls)
DORA emphasizes controlling access to sensitive data and systems using the principle of least privilege, meaning that access should only be granted based on role, necessity, and specific context. This approach aligns closely with several NIST 800-53 controls:
- AC-6 (Least Privilege): Both DORA and NIST mandate minimizing access rights to the minimum necessary for a role, particularly for high-privilege accounts. DORA requires that permissions be limited so only essential, contextually justified access is granted.
- AC-2 (Account Management): NIST's Account Management control requires organizations to actively manage accounts and permissions, aligning with DORA's emphasis on role-based access control and timely deactivation of unused accounts. Regular access reviews further support least privilege.
- AC-3 (Access Enforcement): This NIST control mandates strict enforcement of access policies based on roles and contextual needs, matching DORA's focus on consistent, role-based access across systems.
The most durable way to satisfy these controls is to stop relying on standing access altogether. Rather than vaulting and rotating privileged credentials the way legacy privileged access management tools do, Teleport eliminates standing credentials with short-lived cryptographic identity. There is no static secret for an attacker to steal, and access is granted against verified identity, not network location.
Secure Remote Access to Applications, Databases, and Workloads
DORA requires secure, controlled remote access to critical ICT resources, particularly when reaching sensitive applications, databases, and workloads. These requirements align with several NIST 800-53 controls:
- AC-17 (Remote Access): This control emphasizes securing remote access, including multi-factor authentication (MFA) and encryption to limit exposure. DORA mandates similar measures to prevent unauthorized remote access.
- IA-2 (Identification and Authentication): DORA's requirement for strong authentication, especially MFA, aligns with this control's demand for strong identity verification before access is granted.
- SC-7 (Boundary Protection): NIST's Boundary Protection control mandates protecting system boundaries and securing connections between internal systems and remote devices, aligning with DORA's mandate for secure inter-system connections.
Because Teleport authenticates every session with phishing-resistant, certificate-based identity and short-lived, ephemeral certificates rather than passwords or long-lived keys, the credential exposure that drives most breaches is removed rather than merely shortened, and remote access is delivered without the standing network footprint of a legacy VPN.
Continuous Monitoring and Rapid Incident Response
DORA highlights the importance of continuous monitoring and the ability to respond quickly to emerging risks. These requirements align with several NIST 800-53 controls focused on system monitoring, threat detection, and incident response:
- SI-4 (System Monitoring): This control emphasizes continuous monitoring of system activity to detect anomalies or abnormal access patterns. DORA mandates similar continuous surveillance to identify real-time threats.
- IR-4 (Incident Handling): Rapid incident response is essential to DORA's mandate for mitigating the impact of security incidents, matching NIST's steps for incident detection, reporting, and remediation.
- AU-6 (Audit Record Review, Analysis, and Reporting): This control mandates regular review of audit logs, which is vital to continuous monitoring. DORA's requirement for proactive threat detection aligns with NIST's approach to analyzing audit records for actionable insight.
Continuous visibility into who can access what, paired with an immutable audit log and replayable session recording, is what lets a DORA-regulated firm reconstruct an incident exactly as it happened. That includes VPN-replacement scenarios where teams need remote access without losing the audit trail.
Auditable Access Management (Just-in-Time Access and Review System)
DORA emphasizes auditable access management, including just-in-time (JIT) access provisioning and regular review mechanisms. This aligns with NIST 800-53 controls that emphasize auditing access and permission changes:
- AC-2 (Account Management) and AC-3 (Access Enforcement): These controls support JIT provisioning by requiring access controls that align with strict, role-based policies. DORA's JIT approach maps to NIST's least-privilege principle: access is granted temporarily and revoked immediately when no longer needed.
- AU-2 (Auditable Events): NIST mandates auditing specific events, particularly access and permission changes, supporting DORA's requirement for a transparent access request system with complete auditability.
Engineers request elevated access just in time, scoped, approved, and time-bound, so the environment runs with zero standing privileges and high-risk access is the exception, granted and recorded, not a permanent entitlement.
ICT Risk Management and Operational Resilience
DORA mandates a comprehensive ICT risk management strategy covering all aspects of operational resilience, meaning the ability to handle and recover from disruption. This aligns closely with NIST 800-53:
- PM-9 (Risk Management Strategy): NIST's Risk Management Strategy control mirrors DORA's ICT risk management requirements, emphasizing a holistic approach to identifying, assessing, and mitigating ICT risk.
- RA-2 (Security Categorization): DORA's emphasis on identifying and protecting critical systems is reflected by NIST's Security Categorization control, which prioritizes protections based on organizational impact.
- CP-9 (System and Communications Protection): NIST mandates robust protections and recoverability for systems and communications, aligning with DORA's requirement to ensure resilient data communications as a cornerstone of operational resilience.
While risk management is broader than access tooling, a unified identity layer materially reduces ICT risk: it shrinks the credential attack surface, gives you one inventory of who and what can reach critical functions, and produces the evidence that risk assessments and audits depend on.
Securing Privileged Access to Critical Systems
DORA requires organizations to protect privileged access to critical systems, minimizing the risk associated with highly privileged users. This aligns with NIST 800-53 controls focused on privileged access management:
- AC-5 (Separation of Duties): This control mandates dividing responsibilities to prevent conflicts of interest or misuse of privilege, supporting DORA's need to ensure no single user holds excessive permissions that could lead to unauthorized changes to critical systems.
- PE-2 (Physical Access Authorizations): Restricting privileged accounts to authorized personnel, with elevated permissions granted narrowly and recorded, aligns with DORA's focus on controlling and auditing privileged access to critical systems.
With approvals, access reviews, and recorded sessions on every privileged action, Teleport produces exactly the privileged-access evidence DORA examiners look for.
How Teleport Solutions Help Meet DORA and NIST 800-53 Requirements
Teleport is the AI Infrastructure Identity Company, and the Teleport Infrastructure Identity Platform establishes a unified identity layer for infrastructure across humans, machines, workloads, and AI agents, secured cryptographically. For DORA, that translates directly into the access, identity, and audit controls the regulation keeps asking for, through one platform rather than several point tools.
Teleport Zero Trust Access
Secure, Granular Access Controls
Teleport Zero Trust Access gives engineers passwordless, least-privileged access to servers, Kubernetes, databases, and applications through one identity-aware access plane. Access is granted against verified identity and role-based access control (RBAC), not network location, which directly supports DORA's access management and secure remote access expectations (NIST AC-3, AC-6, AC-17). Because access uses short-lived cryptographic identity rather than vaulted credentials, there is no static secret for an attacker to steal.
Teleport Machine & Workload Identity
Identity for Non-Human Access
Teleport Machine & Workload Identity extends the same cryptographic identity model to service accounts, CI/CD pipelines, and Kubernetes workloads using SPIFFE-based, short-lived certificates instead of static keys (NIST IA-2). DORA's controls apply to the machine-to-machine access that now dominates financial infrastructure, not just to people, and this is where most static-credential risk lives.
Teleport Identity Governance
Privileged and Just-in-Time Access
Teleport Identity Governance brings privileged access under control with access requests, approvals, and access reviews. Engineers request elevated access just in time, scoped, approved, and time-bound, so the environment runs with zero standing privileges (NIST AC-2, AC-5, AC-6(5)). This is exactly the auditable, least-privilege provisioning DORA's access management pillar requires.
Teleport Identity Security
Continuous Monitoring and Auditing
Teleport Identity Security provides continuous visibility into who can access what and surfaces risky access paths, supporting DORA's continuous monitoring requirement (NIST CA-7, SI-4). Critically, every session is captured in an immutable audit log, and interactive sessions on critical systems are recorded and replayable, so an incident can be reconstructed exactly as it happened (NIST AU-2, AU-6, AU-12). That is the difference between asserting you have a control and producing the evidence on demand.
| DORA requirement | Teleport capability |
|---|---|
| Least-privilege access to critical systems | Identity-based RBAC and short-lived certificates via Teleport Zero Trust Access |
| Strong, phishing-resistant authentication | Certificate-based, passwordless authentication; no long-lived credentials |
| Privileged access control | Access requests, approvals, and reviews via Teleport Identity Governance |
| Just-in-time, time-bound elevation | Scoped, approved, expiring access; zero standing privileges |
| Secure non-human / machine access | SPIFFE-based identity via Teleport Machine & Workload Identity |
| Continuous monitoring of access | Access-path visibility and monitoring via Teleport Identity Security |
| Auditable, reconstructable activity | Immutable audit log and replayable session recording |
Teleport's approach also extends to the newest part of the access surface, autonomous AI agents, which DORA-regulated firms are beginning to deploy in production. See DORA evidence and agentic AI for how immutable audit and cryptographic identity apply when an AI agent, not a person, takes the action.
Related frameworks
DORA rarely sits alone. Most regulated financial entities carry neighboring obligations, and the same access, identity, and audit controls satisfy several of them at once.
- NIST 800-53, the control catalog DORA's themes map to, useful for reusing existing evidence.
- NIS2, the related EU directive on network and information security, with overlapping resilience and incident-reporting duties.
- SOC 2, common for technology suppliers to financial entities, with strong overlap on access and audit controls.
- ISO 27001, the information security management standard many firms certify against.
White paper
Digital Operational Resilience Act (DORA): Navigating Compliance with Teleport
Download this white paper to gain a deeper understanding of DORA’s cybersecurity mandates – and discover how to use Teleport’s secure infrastructure access platform to simplify your journey towards DORA compliance.
Additional Resources
Webinar
Don't be Afraid of DORA: Future proof against compliance chaos
Blog Post
Exploring DORA Compliance in Practice: Key Takeaways from Our Recent Webinar
Blog Post
The 2025 DORA Deadline is Here: Simplify Compliance with Teleport
DORA compliance FAQ
What is DORA?
DORA, the Digital Operational Resilience Act, is an EU regulation that sets uniform requirements for the digital operational resilience of the financial sector. It covers ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing.
When did DORA take effect?
DORA entered into force in January 2023 and has applied to in-scope financial entities since 17 January 2025. Firms are expected to demonstrate compliance now, including evidence of access controls, monitoring, and incident reporting.
Who does DORA apply to?
DORA applies to a broad range of EU financial entities, including banks, insurers, investment firms, payment institutions, and crypto-asset service providers, as well as the critical ICT third-party providers that serve them.
What are DORA's main requirements?
DORA is built around five pillars: ICT risk management, ICT-related incident reporting, digital operational resilience testing, third-party risk management, and information sharing. Strong identity, least-privilege access, and auditable activity sit underneath most of them.
How does DORA relate to NIST 800-53?
DORA states outcomes rather than prescriptive controls, so many firms map its themes to an established control catalog like NIST 800-53 and reuse existing evidence. Access management, authentication, monitoring, and audit controls line up closely between the two.
How does Teleport help with DORA compliance?
Teleport provides identity-based access with short-lived certificates, privileged access governance, continuous monitoring, and an immutable audit log with replayable session recording. Together, these address DORA's access management, ICT risk, and monitoring expectations and produce the evidence an auditor asks for.