ESXi Has No MFA: A Practical Hardening Checklist

The VCF Security Reality Check series spent five posts arguing that identity, not exploitation, usually decides whether an environment gets compromised. That’s a model, not a checklist. This is the checklist.

The model rests on one fact: ESXi does not support MFA, SAML, OIDC, or FIDO2 for any access path. That’s an architectural boundary, not a missing setting, and no vCenter configuration changes it.

vCenter’s Identity Federation

#

vCenter Server can federate identity to exactly one external provider at a time, on top of the built-in vsphere.local source:

• Okta (since vSphere 8.0 U1)
• Azure/Entra ID natively via OIDC (since vSphere 8.0 U2)
• AD FS

This is real MFA, and if you’re not using it, you should be. Broadcom’s setup guide for AD FS and the Okta equivalent cover a standalone vCenter Server, where federation is limited to one external provider per SSO domain.

If you’re on VCF 9, that ceiling moves up a level. VCF introduces the VCF Identity Broker (vIDB), which sits in front of vCenter, NSX, and VCF Operations/Automation. Each VCF Instance can run its own Embedded vIDB with a different IdP, or several VCF Instances can share one External vIDB, so a fleet isn’t locked to a single IdP even though any one vCenter Server’s own SSO domain still is. Two caveats that hold at either level:

1. Whatever IdP a given SSO domain is federated to, that’s the only external source active for it. AD-over-LDAP and a second IdP don’t run alongside an active federation.
2. AD-joined users authenticated through IWA or LDAP/S don’t get MFA unless they’re routed through the federated IdP.

Because there’s only one IdP per SSO domain, you can’t literally split user and admin access across two separate identity providers at the vCenter layer, and you shouldn’t try to. Standing up a wholly separate directory for admin identities is the old Red Forest / ESAE pattern, and Microsoft has since retired that recommendation in favor of tiering within a single, well-governed identity structure. What that means in practice for vCenter: the admin-tier group inside your one federated IdP needs its own Conditional Access policy, phishing-resistant MFA, and ideally just-in-time elevation, rather than relying on “federation is configured” as proof that admin access is meaningfully separated from general user risk.

Where Federation Stops

#

None of the above touches ESXi directly. DCUI, SSH, and the ESXi Host Client all sit below the federation layer. Whatever you configure in vCenter, a host presented with a valid local or Active Directory credential over SSH accepts it.

Lockdown Mode

#

Since MFA can’t be added to direct ESXi access, the job is to make that access rare and auditable instead.

Lockdown Mode forces host management through vCenter and disables direct login paths. Broadcom’s guidance is that Normal mode is enough for most environments; Strict mode additionally disables the DCUI, worth it if you don’t rely on the console for break-glass recovery.

Two things worth checking today, not “eventually”:

• The Exception Users list is empty by default. Every account you’ve added to it since is a documented bypass of Lockdown Mode. Pull the list on every host and confirm each entry still needs to be there.
• Lockdown Mode has no dedicated Set-VMHost parameter. The native PowerCLI path goes through the host’s access manager view:

  $accessManager = Get-View (Get-VMHost <host> | Get-View).ConfigManager.HostAccessManager
  $accessManager.ChangeLockdownMode("lockdownNormal")

  Scripting that once and looping it over a cluster is worth doing instead of checking hosts one at a time in the UI.

The CISA Baseline

#

CVE-2025-22225, an ESXi arbitrary-write vulnerability, is under active exploitation in ransomware campaigns as of early 2026. Separately, Akira actors encrypted Nutanix AHV virtual machine disks for the first time in mid-2025, via a SonicWall/Veeam-based access chain rather than an ESXi vulnerability. Different campaign, same point: hypervisor-targeting ransomware is diversifying past ESXi and Hyper-V, not slowing down. CISA’s ESXiArgs recovery guidance is a few years old now but the baseline hasn’t changed:

• Don’t assume the SLP service is off. It’s deprecated and slated for removal in a future ESXi release, and Broadcom’s own 8.0 U3 documentation still warns when it’s found enabled, most often on hosts upgraded from older versions rather than clean installs. Verify it on every host and disable it if you’re not using it (most environments aren’t).
• Never expose ESXi management interfaces to any network other than a dedicated management network. That includes the internet, but also user/production VM networks and anything else routable from a workstation.
• Patch. The exploited CVEs are consistently ones that were fixed months before the campaigns that used them.
• Treat backups as the last line of defense, and make sure they’re offline or immutable, not just on a different datastore.

Backup and Admin Credential Isolation

#

Truesec’s incident response team (Anders Olsson and Nicklas Keijser) has handled multiple ESXi ransomware incidents, including Akira, AlphV, and Trigona. Their writeup on preventing ESXi takeovers describes a recurring pattern: a foothold, then Domain Admin credential theft in Active Directory, then a vCenter breach, then a root password change and SSH enablement on the ESXi hosts themselves. Their broader ESXi ransomware guidance is direct about backups specifically: make frequent backups, and make sure they can’t be deleted even if the attacker gets complete control of the rest of the environment. That means backup credentials that aren’t reachable from the same AD forest as the workloads they’re protecting, and backup storage that can’t be deleted by an account the attacker is likely to compromise.

The same logic applies to the accounts used to administer vCenter and ESXi, not just to backup. If the admin credential and the Domain Admin credential an attacker steals are effectively the same identity, isolating the backups doesn’t help; the attacker walks in the front door of vCenter with valid credentials before they ever need the backup target. Admin access to the virtualization layer should not depend on a plain AD-joined account in the same forest as the rest of the estate.

A Non-Native Option: ZeroLock

#

Everything above reduces the blast radius of a stolen credential. None of it puts MFA in front of an SSH session to an ESXi host, because nothing native does that.

Vali Cyber’s ZeroLock is one of the few products built for this layer specifically. It runs in user space on the hypervisor itself (no kernel modules), and one of its listed capabilities is CLI-MFA for SSH access to ESXi. It also does AI-behavioral ransomware detection with automated rollback, and supports Proxmox, Nutanix, XenServer, RHEV, and KVM in addition to ESXi.

I’ve run it in my own lab rather than just reading the product page, and it does what it says on the tin. MFA on direct ESXi access actually works, which is the specific gap this post is about, and it also blocks malicious commands at the shell before they execute, not just flagging them afterward. There’s a demo/presentation from the Norwegian VMUG on YouTube showing it in action.

The Checklist

#

1. Confirm vCenter identity federation is actually configured, using Okta, Entra ID, or AD FS, not just planned. If you’re still on local SSO accounts for admin access, that’s the first gap to close. Deliberately staying on local vsphere.local accounts instead of federating is a legitimate choice too, but only if every admin has their own named account, not everyone sharing administrator@vsphere.local. Local accounts still can’t do MFA, so that trade buys you a clear audit trail and a smaller footprint, not credential-theft resistance.
2. Confirm the admin-tier group inside that IdP has its own Conditional Access policy and phishing-resistant MFA, not just the same baseline policy as general users. Federation being configured isn’t the same as admin access being separated from general user risk.
3. Pull the Lockdown Mode Exception Users list on every host. Anyone on it bypasses everything above. Remove anyone who doesn’t have a current, documented reason to be there.
4. Set Lockdown Mode to Normal at minimum, and move to Strict wherever you don’t depend on DCUI for recovery.
5. Verify the SLP service state on every host, don’t assume it’s off, and disable it unless you have a specific reason to keep it running.
6. Confirm no ESXi or vCenter management interface is reachable from anything other than the management network. Check this directly, including from the internet and from production/user VM networks; don’t assume the firewall rule you remember writing is still in place.
7. Patch on a real cadence, not “when there’s time.” CVE-2025-22225-class vulnerabilities are being exploited months after patches ship.
8. Verify backup credentials, and vCenter/ESXi admin credentials, are isolated from the production AD forest, and that backup storage is immutable or offline, not just logically separate. An attacker with Domain Admin gets both if either is just another AD-joined account.
9. If direct SSH access to ESXi is a real operational need, evaluate a runtime tool built for the hypervisor layer specifically (ZeroLock or equivalent) instead of treating “no MFA on ESXi” as a dead end.