Most cloud security tools — Wiz, Lacework, Prisma Cloud — are built entirely around public cloud APIs. Your VMware vSphere estate is invisible to them. Yet for many enterprises, VMware still runs the most sensitive workloads: ERP systems, databases, domain controllers, and legacy applications that cannot easily move to the cloud.
This creates a dangerous blind spot. Security teams audit AWS and Azure continuously, but the VMware vCenter sitting in the data centre gets reviewed quarterly at best — if at all. The risks are real: suspended VMs write decrypted memory to disk, stale snapshots contain old credentials, and ESXi 6.x hosts carry unpatched CVEs including hypervisor-escape vulnerabilities.
CloudVista connects to vCenter via pyVmomi (the VMware vSphere SOAP API) and runs 10 security and resilience checks automatically after every sync — no agents, no manual scripts.
The 10 VMware Security Checks
| Check | Applies To | Severity |
|---|---|---|
| VM Snapshots Stale | vmware_vm | Medium / High |
| VMware Tools Not Installed | vmware_vm, vmware_template | Medium |
| VMware Tools Not Running | vmware_vm | Low |
| VM Suspended | vmware_vm | Medium |
| ESXi Host Disconnected | vmware_host | High / Critical |
| ESXi EOL Version (5.x / 6.x) | vmware_host | High |
| Cluster HA Disabled | vmware_cluster | High |
| Cluster Single Host | vmware_cluster | High |
| Datastore Low Space (<20%) | vmware_datastore | Medium / Critical |
| Datastore Inaccessible | vmware_datastore | Critical |
Check 1: VM Snapshots Stale
VMware snapshots are designed as a short-term safety net for patching or testing — not as a backup mechanism. A snapshot preserves the VM's disk state at a point in time, including its memory contents. Over time, the snapshot delta files grow, degrading I/O performance and consuming datastore space.
From a security perspective, stale snapshots are particularly dangerous because they contain decrypted memory state from when the snapshot was taken — including credentials, session tokens, and encryption keys that may no longer be valid but are still readable on disk. If a threat actor gains datastore access, old snapshot files are a high-value target.
Rule of thumb: Any snapshot older than 72 hours should be reviewed and deleted unless explicitly required. More than 3 active snapshots on a single VM is almost always a problem.
Check 2 & 3: VMware Tools Status
VMware Tools is a suite of drivers and services that runs inside the guest OS. Without it, vCenter cannot report the guest IP address, cannot perform graceful VM shutdowns (the VM is killed, not shut down), and in-guest security scanning is unavailable. When Tools is installed but not running, you lose the same visibility with the false confidence that it's "installed".
- toolsNotInstalled — VM appears healthy in vCenter but guest state is a black box
- toolsNotRunning — Tools installed but stopped; common after OS updates without a VM restart
- toolsOld — Tools installed and running but outdated; may lack support for newer vSphere features
Check 4: VM Suspended
A suspended VM writes its entire RAM contents to a .vmss file on the datastore. This file persists indefinitely and is rarely audited or protected with the same rigor as a running VM's disk files. Suspending a VM with 64 GB of RAM creates a 64 GB file containing a complete snapshot of everything in memory at suspension time: database connection strings, application secrets, OS credentials, encryption keys.
High risk: Suspended VMs are often forgotten. A VM suspended during an incident response or maintenance window months ago may still be sitting on a shared datastore, its memory file readable by any user with datastore browse permissions.
Check 5: ESXi Host Disconnected or Not Responding
A disconnected ESXi host is one vCenter can no longer manage. This means:
- Security policies (firewall rules, host profiles) cannot be pushed to the host
- vSphere HA cannot restart VMs from a failed host
- vSphere DRS cannot balance load away from an overloaded host
- Alarms and performance monitoring are blind to that host's workloads
A notResponding state is escalated to Critical — the host is reachable at the network level but vCenter cannot establish a management connection, often indicating a hardware fault or a hung hostd process.
Check 6: ESXi End-of-Life Version (5.x / 6.x)
VMware ended general support for ESXi 6.x in October 2022. ESXi 5.x reached end of life in 2018. Running either version means:
- No security patches for newly discovered CVEs — including several critical hypervisor-escape vulnerabilities
- No support from VMware (or Broadcom) — incidents are handled on a best-effort basis
- PCI-DSS v4.0 requires all system components to be protected against known vulnerabilities — EOL software fails this requirement automatically
CloudVista reads the esxi_version field from each host and flags any host running a version starting with 5. or 6..
Checks 7 & 8: Cluster HA and Single-Host Clusters
vSphere High Availability (HA) monitors ESXi hosts and automatically restarts VMs on surviving hosts when a host fails. Without HA enabled, a host failure means all VMs on that host go offline until someone manually restarts them — potentially hours of downtime for production workloads.
A single-host cluster is a cluster with only one ESXi host. By definition, HA cannot protect it — there is nowhere to restart VMs if the only host fails. This is a common oversight when clusters are created with the intention of adding more hosts later, but the second host never arrives.
Checks 9 & 10: Datastore Space and Accessibility
When a datastore fills, the consequences are immediate and severe: VMs cannot write to their virtual disk files, swap space cannot be allocated, and snapshot delta files cannot grow. VMs freeze or crash. Recovery requires emergency storage allocation or VM migration under pressure.
CloudVista flags datastores below 20% free space (Medium), below 10% (High), and below 5% on production environments (Critical). An inaccessible datastore — one that vCenter can see but cannot mount — puts all hosted VMs into an invalid state and is always Critical.
How CloudVista Connects to vCenter
CloudVista uses the pyVmomi library to connect to vCenter via the vSphere SOAP API over HTTPS (port 443). It requires a read-only service account with access to the root of the vCenter hierarchy. No agents are installed on ESXi hosts or guest VMs. The connection is established once per sync cycle, all data is collected, and the session is closed.
- Add a VMware credential in CloudVista (vCenter host, username, password, port)
- Click Validate — CloudVista confirms connectivity and authentication
- Trigger a sync or wait for the scheduled sync (runs every hour by default)
- All 10 security checks fire automatically after the inventory sync completes
- Findings appear in the Findings dashboard, mapped to CIS VMware and ISO 27001 controls
Least-privilege setup: Create a dedicated read-only role in vCenter with Read-only privileges on the root vCenter object (propagated to all children). Assign it to a service account named cloudvista-readonly. This account requires no guest OS access and no write permissions to any vSphere object.
Run VMware Security Checks Automatically
Connect CloudVista to your vCenter in under 5 minutes. 10 security and resilience checks run after every sync — free forever, no agents required.
Start Free Today VMware Inventory Guide