Most financial institutions have deployed multifactor authentication (MFA) where auditors have traditionally looked for it: VPNs, email, cloud applications. That coverage checks the expected boxes—and for years, it was enough.
But one critical layer is still routinely excluded. Not because teams ignored it, but because practical solutions didn’t exist.
That layer is the hypervisor—the software (like VMware ESX) that runs every virtual machine in your environment. And under the EU’s Digital Operational Resilience Act (DORA), leaving it unprotected is no longer acceptable.
As of January 17, 2025, DORA Article 9 makes securing privileged access to core infrastructure a legal requirement — and for most institutions, the hypervisor remains the one access path that MFA hasn’t reached.
What DORA Article 9 Requires for Strong Authentication
DORA is the EU’s framework for ensuring that financial institutions (banks, insurers, investment firms, payment providers) can withstand and recover from Information and Communication Technology (ICT) disruptions, including cyberattacks. It applies to roughly 22,000 financial entities across Europe, and DORA Article 9 is where authentication comes into focus.
DORA Article 9 Protection and Prevention: The Authentication Mandate
Titled “Protection and Prevention,” Article 9 is where authentication becomes mandatory.
The DORA MFA requirements include “strong authentication mechanisms” for access that could materially impact systems. In practice, regulators interpret this consistently: at least two independent factors, especially for privileged access to infrastructure.
Hypervisor administrators fall squarely into that category.
DORA Article 9 and ICT-Related Incident Management
Article 9 is closely tied to Article 17, which governs ICT-related incident reporting. Weak authentication is one of the most common initial access points behind the incidents regulators now require you to detect, document, and report. Closing these critical gaps supports compliance, and it also directly reduces incident exposure.
The Gap No One Talks About
Hypervisors sit beneath everything: core banking systems, trading platforms, customer data, backups. Whoever controls the hypervisor controls all of it, including the sensitive customer and financial data those systems process and store, and the DORA data protection obligations that come with it.
Historically, the hypervisor layer has been treated as out of scope for MFA. VPNs and SaaS adopted strong authentication first, while ESX and similar platforms were deferred—not by choice, but by lack of viable tooling. That left a well-documented, unguarded entry point into the most consequential layer of enterprise infrastructure.
The threat data reflects it:
- 700% increase in hypervisor ransomware attacks in 2025
- Ransomware families targeting ESX have quintupled since 2022
- 60% of organizations faced virtualization-related incidents in 2024; 30% involved unauthorized VM access.
Credential compromise is now a routine part of breach chains, with 16B logins compromised in 2025. And when compromised credentials lead to hypervisor access, the result is an ICT-related incident that must be reported to competent authorities — with all the regulatory, legal, and reputational weight that entails.
Why VPN MFA Doesn’t Satisfy DORA Article 9 for Hypervisor Access
VPN MFA and hypervisor MFA protect different doors. Think of your VPN as the front gate of a building — MFA there means only authenticated people get onto the grounds. But once someone is on the grounds with a stolen keycard to a specific room, the gate doesn’t help you. Hypervisor MFA is the lock on that room itself.
Once inside the VPN, an attacker with compromised ESX credentials can authenticate directly to your hypervisor without any additional challenge. The two systems don’t share an authentication boundary. This is why DORA Article 9’s framework looks at privileged access paths individually, and why your Article 9 compliance should include controls specifically at the hypervisor layer, not just at the perimeter.
Closing the Gap with ZeroLock CLI MFA for ESX
ZeroLock® is the only preemptive security solution built specifically for hypervisors that leverages CLI MFA.
Unlike traditional MFA tools that stop at the network or application layer, ZeroLock’s CLI MFA embeds strong authentication directly into the command line, enforcing control precisely where credential-based attacks occur.
For DORA compliance, ZeroLock enables you to demonstrate:
- Article 9 protection and prevention controls at the hypervisor layer
- Credential-compromise resilience, a stolen password alone cannot unlock your virtual infrastructure, whether accessed via console or SSH
- Reduced ICT-related incident exposure at a primary attack surface
- Audit-ready enforcement at a layer regulators increasingly scrutinize
- Continuity-safe deployment within existing VMware environments
If you think of your current MFA coverage as a chain, ZeroLock can close the link that’s been missing. The chain is only as strong as its weakest point, and for most financial institutions right now, that point is the hypervisor. It’s a conclusion that security teams at financial institutions are already arriving at firsthand, like one of our customers quoted below.
“One of the biggest selling points for us was that we could get MFA on the SSH. Everywhere else in our system we have MFA, so it was nice to be able to add that in as well.”—Current ZeroLock User
The Financial and Regulatory Cost of Missing Hypervisor MFA
The average data breach cost for financial institutions is $5.56 million. Hypervisor-targeted ransomware incidents often exceed that—a single 2025 ESX incident resulted in $402 million in losses.
Against those numbers, deploying MFA at the hypervisor is one of the highest-return security investments available — and under DORA, it’s also the law.
“Serious DORA violations can result in fines of up to 2% of global turnover, plus additional costs for remediation, business disruption, and reputational damage.”
The institutions best positioned for DORA enforcement are the ones that can show they’ve identified their gaps and addressed them deliberately. The absence of hypervisor MFA represents a remediable security gap that is challenging to rationalize, and it is drawing growing attention from regulatory authorities.
Assess Your Hypervisor MFA Coverage Before DORA Auditors Do
If you’re unsure whether your current authentication coverage extends to the hypervisor layer, that’s exactly the conversation we’re here to have. We help financial institutions identify how ZeroLock integrates with their existing systems to support compliance and preemptive security.