Don’t Be Afraid of DORA: Future proof against compliance chaos

Don’t Be Afraid of DORA: Future proof against compliance chaos

The EU’s Digital Operational Resilience Act (DORA) aims to fortify financial institutions and their third-party technology service providers against ICT-related incidents and disruptions. It mandates strict requirements for access management, incident response, monitoring, and risk management to protect critical systems and sensitive data.

In this on-demand webinar, expert Jared Henderson from Falx will walk through DORA’s core cybersecurity mandates and provide guidance on how to align your organization with the framework. You’ll learn how DORA maps to well-established controls in NIST 800-53—emphasising secure, role-based access, continuous monitoring, and resilient ICT systems.

Following the overview, Teleport Solutions Engineer, Sami Ali, will give a live technical demo of how to use Teleport’s secure infrastructure access platform to simplify your journey toward DORA compliance.

You’ll see how Teleport supports:

• Least privilege access and context-aware access enforcement
• Just-in-time access provisioning and complete auditability
• Policy driven access to infrastructure, including VMs and applications
• Secure remote access to applications, databases, and workloads
• Exportable access logs and session replays that support incident reporting and collaborative defence scenarios
• Continuous monitoring and real-time incident response

Whether you're in the early stages of compliance planning or refining your controls, this session will provide practical insights and actionable solutions to meet DORA’s requirements.

Who Should Watch:

• Security and compliance teams focused on DORA
• DevOps and infrastructure engineers supporting regulated environments
• Technology leaders responsible for operational resilience and audit readiness

Key topics on Don’t Be Afraid of DORA: Future-Proof Against Compliance Chaos

• DORA is an EU regulation for financial organizations operating in the European Economic Area.
• DORA focuses on five pillars: ICT risk management, incident reporting, digital operational resilience testing, third-party risk management, and information sharing.
• Identity and Access Management (IdAM) plays a critical role in DORA compliance, with most IdAM requirements being mandatory regardless of organization size.
• Complex modern infrastructure creates compliance challenges through identity sprawl and inconsistent controls across multiple environments.
• Teleport addresses these challenges by providing:
  • Identity-first authentication through SSO integration with providers like Okta
  • Role-based access controls with visual access graphs
  • Just-in-time privileged access with approval workflows
  • Short-lived certificates instead of passwords or SSH keys
  • Complete session recording and tamper-proof audit logs
  • Comprehensive visibility of all infrastructure resources
• The above capabilities directly support DORA requirements for secure authentication, privilege elevation controls, incident reporting, and overall ICT risk management, making DORA compliance more achievable despite complex environments.

Expanding your knowledge on Don’t Be Afraid of DORA: Future-Proof Against Compliance Chaos

• Digital Operational Resilience Act (DORA): Navigating Compliance with Teleport
• The 2025 DORA Deadline is Here: Simplify Compliance with Teleport
• Exploring DORA Compliance in Practice: Key Takeaways from Our Recent Webinar

Transcript - Don’t Be Afraid of DORA: Future-Proof Against Compliance Chaos

Sami: Okay. Hi. I am Sami Ali. I’m a Solutions Engineer at Teleport, and I’m here today with Jared Henderson from Falx. Jared, if you want to introduce yourself?

Jared: Yeah. Hey all, I’m Jared Henderson from Falx Cybersecurity, and we focus on security within the financial sector.

What We Really Mean When We Say Compliance

Sami: Great. So let’s dive straight in. When people hear the word DORA, they usually think of one of two things. Usually — well, sometimes a little girl with a purple backpack and her monkey friend Boots and a talking map. And then secondly, a heavy-handed piece of regulation with tight deadlines, lots of acronyms, and real operational consequences. And I think we know which one we’re going to talk about here today. In just a moment, Jared’s going to take us through what DORA is actually asking of organizations like yours and what that regulation expects and why. But before that, I want to show you why Teleport is so central to this conversation. So most of the organizations that I speak to on a day-to-day basis — they have a consistent theme. They want to be compliant. They’re in no way looking to ignore it, ignore DORA. They want visibility, and they absolutely want to reduce risk. But the execution is what’s difficult. So they just don’t have one access system. They have three or four or five or even more. And often, not one person can answer who has access to production right now. So the more we scale across cloud providers, third parties, hybrid deployments, the harder it becomes to maintain control. So tools don’t really talk to each other, and logs live in these silos. So access reviews turn into spreadsheet archaeology. So while compliance is the goal, complexity is the barrier at the moment. And that’s where the conversation has to go next. Not just what DORA has to say, but how can we actually deliver on it.

Infrastructure complexity

Sami: So this is the reality that most teams are living in. Cloud environments, hybrid networks, legacy systems, CI/CD pipelines, third-party contractors, air-gapped machines, and every one of them has its own way of handling access, logging, and credentials. So this is the reality most teams are living in. The result is identity sprawl, inconsistent controls, and a constant struggle to answer the basics. So answering who has access becomes the most difficult part of the conversation. So this is what makes DORA really difficult, not just the regulation, but the infrastructure that we’re trying to apply it in. So we need a new way to approach it and to approach that access. So identity first, policy driven, and audit ready from the very start. So to understand what that looks like in practice, we can first take a look at what DORA is actually asking for. So, Jared, over to you.

DORA at-a-glance: Pillars of focus

Jared: Amazing. Thank you, Sami. So DORA, and DORA at a glance. So first, what’s DORA? So DORA is the Digital Operational Resilience Act. It’s an EU regulation that came into effect on the 17th of January. Essentially, it means that all financial sector companies operating in the European Economic Area need to follow some strict requirements and also test that they follow them. Ultimately, the purpose of DORA is to provide a large amount of requirements that cover information technology, ICT, cybersecurity, operational resilience, business continuity, supply chain third-party risk, etc. And all these financial sector businesses that are operating in the EEA will need to follow these requirements in order to continue operating or start to operate. And it’s all based on size as well. So the Article 4 of DORA is a proportionality principle. What this means is that even if you’re a smaller company, smaller financial services, you may only have to follow a smaller amount. It doesn’t mean only a little bit, but there may be certain clauses from the articles you don’t have to follow, whereas if you’re a larger organization, like a global multinational bank, you’re more likely to have to follow stricter controls. And essentially, there’s five pillars that DORA focuses on. The first four are what you’re going to hear the most about. These ones contain a lot of the technical requirements and a lot of business and operational risk requirements. And the fifth one focuses on, yeah, information sharing, and information sharing being a community between businesses that have to follow DORA, sharing technical information, business and strategy items, kind of a threat intel, but as a DORA community.

Jared: However, when I mentioned that there’s a proportionality principle and that certain organizations may not need to follow all of the requirements, most requirements related to Identity Access Management are mandatory for the financial entities, regardless of the size of them. And to meet these controls and these standards and these requirements, indirectly or directly, states that — the various IT tools, technologies, but also the people, the processes, and the correct roles are required in order to meet them. And among these would be identity solutions, access management, and they play a critical role. So why Identity Access Management matters in DORA. So DORA refers to a range of obligations that link to Identity Access Management. This can be securing data confidentiality, managing the user identities, the access rights, the use of strong authentication, separating critical duties, but also from the monitoring point of view, such as detecting unusual user behavior. These requirements essentially can be all addressed through appropriate Identity Access Management tools, components, functionalities, roles, and processes.

Why IAM management matters in DORA

Jared: What’s on screen are the five pillars again. So the first one being risk management. So what do we want to do in terms of DORA? We want to map, secure, monitor access to systems supporting critical functions and to manage the digital risk exposure. To pillar two, the incident reporting, can we track and trace who did what? Who did it when? Can we respond to an incident? Are we able to have a full timeline of events and see what user did what with what roles? Pillar three, Digital Operational Resilience Testing. So this one is quite a technical one in nature in terms of what organizations need to follow. For example, there are three yearly — pen test every three years, essentially, a really large one, very complex. And part of this will also be testing access controls, the identity safeguards under stress, and validate the response to cyber system failures. The third-party risk management, which is pillar four here, that’s limiting access to your vendors, to your contractors, your cloud services, and basically reducing external attack surface, as well as the internal threat exposure. And then information sharing, ensuring there’s accountability and shared threat data. Can we consume identity-linked events, improve collaboration, trust, and bring in further information to better feed an Identity Access Management solution? And next slide, please, Sami.

Mapping IAM features to DORA

Jared: And this slide here — so this one is some features of Identity Access Management that you’ll find when reading through the overarching regulation of DORA. Put together here are six different features and five features and the why, and then mapping those to DORA and RTS. Now RTS has not been mentioned here yet. So I’ll break those two down. So, first, you have DORA, which you mentioned earlier, Digital Operational Resilience Act. That’s the overarching regulation. It’s high-level obligations that basically surround those five pillars we’ve went through. There’s IT risk management, incident reporting, third-party oversight, and so forth. Then you’ve got RTS, and what I’m referring to here is the Regulatory Technical Standards. These are detailed rules which are developed by the European Supervisory Authorities, and they’re designed to give you a bit more practical guidance. So essentially turning the what into the how. It’s not deep-dive implementation steps to do exactly this, do exactly that. It’s more building on the back of the overarching regulation, giving you a bit more technical information on how we could best meet certain clauses and articles. You’ll see that in the DORA and RTS column, DORA 9, DORA 10 come up quite a few times. So DORA being the overarching regulation, DORA 9 is the protection and prevention article that contains various different clauses, as you can expect, but Identity Access Management is a piece of that, as is DORA 10, which is the detection article. And you’ll see in RTS — I’ve mentioned RTS 20, RTS 21. And this isn’t linked to any clause specific to a number or a letter or any paragraphs. It’s because those two sections are articles of the RTS, primarily all related to Identity Access Management.

Jared: So you’ve got 20, which is Identity Management, and you’ve got 21, which is Access Control. So how can an Identity Access Management System help a financial sector organization comply with DORA requirements? Well, a solution will help provide a single central location to store these user identities. You can automate the key identity processes: your joiner, your movers, your leavers, whether that’s within the organization or to external. You can do central access to systems and manage that, improving efficiency, consistency. You can do access right management, your role-based access. You could do least privilege, zero trust, you-need-to-know principles. But also, especially from the audit point of view and the reporting, you can have a complete view of the organization’s access landscape and highlight potential security risks. And the features here on the slide: your role-based access, your secure remote access, that can be through VDIs. It could be remoting into a server, or it could be virtual desktops that all employees work off, session recording, having a replayable tamper-proof session history tied to a specific identity, being able to see what accounts did what and when, privileged or not. Your just-in-time access, that’s your time-bound. You approve privilege elevation so that you can do critical tasks and have forward logging, requesting it, making sure everything is governed, and it’s tracked, again, with session recording, along with the secure access. And then audit logging, which summarizes all of it, is reviewable, exportable access history, and that’s something that can also be proved to the regulators, and you can prove in audits, be able to pull out this information, whether it’s from an incident, whether it’s just to verify security controls.

Jared: And from what I’ve seen, in general, across financial services within the EU and clients we’ve worked with before, is identity tends to be one that there’s a bit more of a tool sprawl or a bit more of, let’s say, account sprawl, whether that’s within on-premises, whether that’s up in the cloud or the hybrid estate. And really, DORA is so big and so large, and it covers a vast amount of things. And you may think Identity Access Management is a smaller piece of a pie, but when you dig into it and you start expanding the regulation, you start expanding the technical standards, you see how common identity and access management comes across. And also, sometimes it’s the first line of the defense. It’s the first thing protecting your way in. So DORA does rely heavily on it. And these sort of features and how it can map to DORA and RTS are just a small piece of that. There’s only five here on display. If we had 24 hours of webinar, we could talk through the whole lot. We’d be here for a very long time. But yeah, essentially, having an Identity Access Management system can help financial service organizations comply with DORA requirements, providing that all these in the center, with all these various features, and then abiding by the articles that are required to operate in the sector.

Demo

Sami: Okay. Well, thanks, Jared. That was really interesting. So we’ve just seen how DORA helps measure how fast and safe and reliable our delivery processes are. So now I guess the question becomes, how do you actually build that kind of infrastructure that supports those outcomes day to day? So I guess that’s where Teleport comes in and the most awaited part, which is the demo. I’m going to walk you through the UI and show you how access control and auditability, the foundations of DORA, are built in by default. Okay. Let’s start with how users actually log into the Access Infrastructure. So as we already know, Teleport supports SSO through identity providers like Okta, Entra ID. So instead of using those shared passwords or SSH keys, users would authenticate using with their existing identity. So in this case, I’m using Okta. Let’s log in. Let that log in. And then the first thing that we should see is the cluster overview. So this is what you see. You see all of your connected infrastructure. It’s all visible as in your Azure VMs, your Linux servers, your Windows desktops, Kubernetes clusters, applications. And you would then — I mean, this supports DORA’s ICT risk management pillar, so by ensuring that there’s complete visibility and classification of critical assets.

Sami: So, of course, seeing the resources is only part of the story, right? You want to know how to actually control that risk. And so we also need to be able to see who can access what and when and under what conditions. So let’s have a look at our roles. So as I mentioned, Teleport uses role-based access controls to scope exactly who can access what and under what conditions. So here you can see some of the roles which define login permissions, allowed resources, and session policies. So say if I open — let’s go with the — oops, the auditor role. And so now you can see two key areas. So on the left, we have the detailed YAML configuration. And this is where the permissions are defined, what resources this role can access, which logins it grants, and what session policies to apply, so. And on the right-hand side, you can see an Access Graph, which is kind of, I think, one of my favorite features. And the reason for that is it’s just giving you that visual of how roles and users are connected, and who is connected to what. And just in one swoop, be able to see who is connected to this auditor role. You can see all of these users.

Sami: So it’s really a dynamic view of your identity access layer, making it much easier to validate least privilege across the whole environment. So thinking of DORA, again, this ties directly to the ICT risk management and access governance requirements, so yeah. So we’ve looked at the role. Let’s now see what this role can actually allow a user to do. So we define roles. Now, let’s see how that plays out in action. So let me go to one of the servers. We’ll connect to a server. And whether you do this through SSH or RDP into Windows, it will be the same thing where you have no passwords, no long-lived keys. And Teleport has issued that short-lived certificate tied to my identity and my assigned roles. So this supports secure authentication methods, which is required by DORA’s RTS 6 and RTS 21, and again, eliminating that traditional credentials risk. So I’ll just do a few random — just so that we can see that it’s recorded, right? So I just want to show that. Okay, yeah. I did ls, but I know there’s nothing in there.

Sami: Okay. So let’s have a look at — we’ve seen how to access a server. Let’s now think about — let me close this. Don’t worry. We’ll come back to that when we look at the session recording. But let’s think about, now, privileged tasks. So users don’t automatically have that standing access. So I have requested elevated access just in time with my alias account, but I’ll show you where that lives. So if you go into — ah, it’s in Governance, there it is. Access Requests. There we go. So we can see two here. So one was three hours ago. Sorry, one was nine hours ago, and one was seven minutes ago. And we have one approved already. So this just creates that approval workflow with time-bound access that auto-expires. There’s no lingering admin relating to having to decommission these accounts. And this model directly satisfies DORA’s rules around privilege elevation and short-lived access permissions. So let’s go ahead and — I don’t know. Let’s see what comes into that. So it tells you cluster name, node, requested resource name. You can reject it. You can approve it. You can approve access. You can “approve long-term access via Access List with the requested resources” — which is a separate feature — is grayed out here. And the user who is requesting the access can put in a note as well to say why they need that access. So here I would reject it. So let’s just say rejected, and that’s it. I mean — you can link this with your Slack, with your Teams, with your emails to just simplify this even further.

Sami: Let’s have a look at — so say this user has now got the access to that server temporarily. We still want to know what they’re doing, which is what the session recordings and the audit logs help us see, really. So let’s go to the audit log. And again, you see a sign here, external audit storage, connect your AWS account. So you can link it with your AWS storage. You can link it with your Azure Blob Storage or — there’s several options for that too. So now you can see that user task updated. Let’s have a look at that. What time was that? So that will give us some information on what’s just happened. EC2, Solutions Engineer. Okay. Let’s have a look at the session recorded. So there’s a couple here. So duration’s 47, 32 seconds, and 3 minutes. So you want the most recent one, which will be the one at the top.

Sami: And just bear in mind that Teleport records every single session at the network level. So whether that’s SSH, RDP, Kubernetes, every single action taken is logged. It’s tamper-proof, and it’s tied to that verified identity. So these session recordings meet DORA’s incident reporting obligations under RTS 10, I believe. And that’s providing evidence that access controls were enforced and actions can be audited after the fact. So let’s play. So hopefully, you should see the next tab, and it should show the small commands that I played earlier. Any minute now. I was, too, talking while I was showing you this, wasn’t I? Let’s see. Hey. There we go. Alice. And then whoami? Yeah. Disconnected.

Join the Teleport community

Sami: Okay. At least we know it was me. And that’s the session recorded. So I guess to put — finally, Teleport generates this complete audit log of every event. And it’s searchable. It’s exportable. It can be streamed to SIMs for continuous monitoring. Auditability underpins both DORA’s incident response pillars and its information sharing pillars. So yes, let me see what else. I guess those are the main things I wanted to show you in relation to DORA. So I guess what you’ve seen today is a live example of what DORA is really asking for. And so that’s not just controlled on paper, but evidence that you’re enforcing access governance and identity-first authentication. So thank you for your time, and I hope you enjoyed this. And please reach out to us. If you have any questions, we’d be happy to answer. We have a community Slack also, so join us, ask questions, test things out, and hope to see you soon.