DORA Is Here—Is Your Mainframe Access Layer Ready?

The Digital Operational Resilience Act (DORA) became fully enforceable across the European Union on January 17, 2025. From that date forward, financial institutions can no longer simply assert that their systems are resilient. They must demonstrate it. And when that standard of demonstration is applied to production mainframe environments, it surfaces a question that has gone largely unasked for years: was the user access layer ever designed to withstand this level of scrutiny?

The IBM Z platform is, in its native architecture, one of the most robust computing environments ever built. Availability measured in years, pervasive encryption, fault-tolerance engineered into every hardware component. Major banks, insurance companies, and critical payment infrastructures running their core operations on mainframe have sound reasons for doing so. The problem DORA has made visible is not the platform itself – it is everything built around it!

What DORA Actually Demands

The most common mistake organizations make when approaching DORA is reading it as a checklist. That interpretation leads to expensive compliance projects whose only tangible output is more documentation. The regulation does not ask you to prove that controls exist. It asks you to prove those controls actually work when an incident occurs.

Its five pillars — ICT risk management, incident management and reporting, digital operational resilience testing, third-party risk management, and information sharing — all converge on a single underlying principle: if something breaks, how quickly can you understand what happened and restore normal operations? The honest answer to that question depends far more on the complexity of your access architecture than on the robustness of the mainframe platform itself.

 The Fortress With Unguarded Gates

Here is the paradox facing many financial institutions:  The mainframe platform is a fortress, yet thousands of users access it every day through TN3270 emulators installed machine by machine, maintained on inconsistent update cycles, with configurations that vary by user, department or geographic location. Each installed emulator is a dependency and unpatched version is an attack surface. A non-standard configuration is a blind spot in your audit capability.

 The most frequently overlooked attack vector is not a flaw in z/OS. It is an emulator installed on a remote worker’s laptop, running a version that has not been updated in months, transmitting credentials over an unencrypted TN3270 session. Security audits conducted across major European financial institutions consistently surface the same findings: network segregation between mainframe infrastructure and end-user environments is rare, and unencrypted 3270 connections persist in production.

A Lesson Already Learned: From LPM to DORA

For organizations operating in France, this regulatory logic is not new. The “Loi de Programmation Militaire”, which imposed strict security requirements on operators of vital importance (OIVs), raised the same architectural questions years before DORA came into force. The central requirement was identical in spirit: access to critical information systems must be governed, auditable, and centrally managed. A distributed thick-client approach simply cannot satisfy that requirement with any degree of reliability.

Virtel addressed those LPM challenges directly, and the architectural principles developed in that context carry over precisely to DORA. The most important of these is access segregation: the ability to maintain completely separate access paths for business users and system administrators, each governed by its own security controls, each compatible with bastion server architectures, and each operating independently so that a compromise in one channel does not propagate to the other. That separation is not a feature added to Virtel Web Access. It is a consequence of how the solution was designed.

Zero Trust Is Not a Posture. It Is an Implementation.

Zero Trust has become the defining security framework of the current era. Its principles are widely adopted: never trust by default, verify continuously, minimize privilege. The gap that most organizations have not closed is the distance between adopting Zero Trust as a stated posture and actually implementing it across every access layer to critical systems.

The pattern is familiar. Modern web applications are protected by federated SSO, contextual MFA, and cryptographic authentication that never transmits passwords across the network. The CICS applications running the core business sit behind a TN3270 emulator that authenticates with a username and password, sometimes transmitted in cleartext. That inconsistency is no longer defensible.

That authentication gap is only part of the picture. The access architecture itself introduces a layer of third-party risk that DORA now requires organizations to confront directly.

Third-Party Risk: The Compliance Burden Nobody Counted

Among DORA’s five pillars, third-party ICT risk management generates the most anxiety in compliance teams, and for good reason. Organizations must map every critical technology dependency, contractualize resilience obligations with providers, and monitor those providers continuously. In a traditional mainframe access architecture, the user access layer can involve several layers of third-party dependency: the emulator vendor, the session manager provider, VPN solutions used for remote access, and any monitoring or proxy tools layered on top. Each of those is a DORA dependency. Each must be documented, contractualized, and regularly audited.

Simplifying the access architecture reduces that perimeter mechanically. Fewer layers mean fewer vendors, fewer contracts to review, and fewer failure scenarios to model in resilience testing exercises. That reduction in compliance overhead is a direct consequence of an architectural choice, and it is beginning to carry significant weight in infrastructure decisions at major European financial institutions.

What Resilience Testing Will Reveal

DORA requires financial entities to subject their critical systems to regular resilience tests, including for the most significant institutions threat-led penetration tests based on real-world attack scenarios. These tests have a particular value: they surface the gap between what an organization believes its architecture does and what it actually does. In mainframe environments, that gap is often found where nobody was looking.

A realistic crisis exercise raises practical questions that quickly become uncomfortable. How long does it take to isolate a compromised session in your current environment? If the attack vector runs through an emulator on a remote machine, how many people need to be mobilized to understand the scope of the compromise? If you need to fail over to a backup access channel, is that procedure independent of the infrastructure that just failed? A centralized architecture provides structurally simpler answers to every one of those questions.

The Right Question

Organizations that approach DORA as a documentation exercise will spend the next several years producing policies that describe resilience they do not necessarily have. Those that treat it as an opportunity to examine their architectural choices will come out of it with systems that actually hold under pressure.

For mainframe access, the question is worth asking plainly. Was your current architecture designed to withstand the threat model of 2026? Or was it built for a world where perimeter security was a coherent concept and the primary concern was keeping users productive, not keeping attackers out?

DORA does not ask you to answer that question in theory. It requires you to prove the answer through testing, audits, and incident reports that document your real capacity to operate under stress. The distance between those two levels of expectation is what separates an organization that is subject to a regulation from one that has made resilience a genuine design principle.

Is Your Mainframe Access Layer Ready for DORA?

 If you have questions about DORA compliance, Zero Trust architecture for mainframe environments, or how a centralized approach can reduce your exposure surface, our team at Virtel welcomes the conversation. If you’re ready to move from DORA compliance on paper to DORA compliance in practice, reach out today.