Why encrypt virtual machines — and why now?
I’ve run into this scenario more times than I can count as a consultant: a customer running VMware vSphere with datastores on a SAN, feeling secure because there’s a firewall around everything. Then one day a drive fails, gets sent in for warranty replacement — and all the VM data sitting on it is completely unencrypted, totally unprotected. A technician at the vendor’s repair center could read every .vmdk file if they wanted to.
VM Encryption addresses exactly that pain point. Data is encrypted with XTS-AES-256 at the hypervisor layer — before it ever hits storage. Anyone who gets their hands on the physical .vmdk files without the key just sees garbage.
The biggest obstacle used to be the requirement for an external KMS (Key Management Server) — meaning you had to purchase additional products like HyTrust, Thales, or IBM SKLM. Expensive and complex. Starting with vSphere 7.0 Update 2, VMware introduced the Native Key Provider — a key provider built directly into vCenter, no external KMS required. That’s what I want to walk through today.
How Native Key Provider works
The Native Key Provider (NKP) — as the name suggests — integrates directly into vCenter Server, generating and managing encryption keys on its own. No additional servers to deploy, no separate license required.
That said, there are a few things you need to understand before turning it on:
- Keys must be backed up manually — you need to export and store the backup key file externally. If vCenter crashes without a backup, any encrypted VMs will be unbootable.
- NKP only supports VM Encryption and vTPM. Need to encrypt vSAN? You’ll still need a Standard Key Provider (external KMS).
- Minimum requirement: vSphere 7.0 U2 — both vCenter and ESXi hosts.
When I migrated my personal lab to Proxmox, this difference became even clearer. Proxmox doesn’t have an equivalent feature at the hypervisor layer — if you want to encrypt a VM there, you have to handle it yourself at the guest OS level or use LUKS for storage. VMware handles this far more transparently, especially when you’re managing dozens of VMs.
Installing Native Key Provider on vCenter
Everything here is done through the vSphere Client (Web UI). No SSH or PowerCLI needed for this part.
Step 1: Add the Native Key Provider
- Log in to vSphere Client → select vCenter Server in the inventory.
- Go to the Configure tab → Security → Key Providers.
- Click Add → select Add Native Key Provider.
- Enter a name (e.g.,
NKP-Production), then click Add Key Provider.
Right after creation, the status will show “Not backed up” — highlighted in yellow as a warning. Don’t skip the next step.
Step 2: Back Up the Key Provider (REQUIRED)
This is the most important step — and the one most often skipped. If vCenter fails and you don’t have a backup file, every encrypted VM will be unbootable. Complete data loss.
- Select the NKP you just created → click Back Up.
- Set a password to protect the backup file (remember this password — there is no recovery option).
- Download the
.p12file to your local machine (it’s small, just a few KB, but more important than any other backup you have). - Store it in at least 2 separate locations — an offline USB drive, a separate cloud storage account, or a physical safe.
Once the backup is complete, the status changes to “Active” in green.
# Check NKP status using PowerCLI (optional)
Connect-VIServer -Server vcenter.lab.local -User [email protected] -Password 'P@ssw0rd'
# List all key providers
Get-KeyManagementServer
Configuring VM Encryption
The VM Encryption mechanism in vSphere is quite elegant: everything goes through a VM Storage Policy. Create a policy with encryption enabled, apply it to a VM — done. No need to touch individual VM configurations.
Create a VM Encryption Storage Policy
- In vSphere Client, go to Menu → Policies and Profiles → VM Storage Policies.
- Click Create.
- Name the policy:
VM-Encryption-Policy. - Under Policy structure, enable Enable host based rules.
- Go to the Host based services tab → under Encryption → select Use storage policy component.
- Select the VM Encryption Policy component.
- Complete the wizard → Review and Finish.
Encrypt a new virtual machine
When creating a new VM, at the Customize hardware step → select the VM Storage Policy → choose the VM-Encryption-Policy you just created. All disks on the VM will be encrypted automatically.
Encrypt an existing running VM
This operation doesn’t require shutting down the VM — but there will be a brief downtime during the reconfigure, typically under 30 seconds for smaller VMs.
- Right-click the VM → VM Policies → Edit VM Storage Policies.
- Change the policy to
VM-Encryption-Policy→ click Apply to all. - Confirm and wait for the task to complete.
Alternatively, use PowerCLI to batch-encrypt multiple VMs at once — a huge time-saver when you have dozens of VMs to process:
# Connect to vCenter
Connect-VIServer -Server vcenter.lab.local -User [email protected] -Password 'P@ssw0rd'
# Get the encryption storage policy
$encPolicy = Get-SpbmStoragePolicy -Name "VM-Encryption-Policy"
# Apply the policy to all VMs in a folder
$vms = Get-VM -Location (Get-Folder -Name "Production-VMs")
foreach ($vm in $vms) {
Write-Host "Encrypting $($vm.Name)..."
Set-SpbmEntityConfiguration -Configuration (Get-SpbmEntityConfiguration $vm) -StoragePolicy $encPolicy
}
Write-Host "Done. Check Compliance status in vSphere Client."
Encrypt only specific disks (not the entire VM)
If a VM has multiple VMDKs and you only want to encrypt the disk holding sensitive data:
- Go to VM Settings → select the Hard Disk to encrypt.
- Under VM Storage Policy for that disk → choose
VM-Encryption-Policy. - Leave the remaining disks on their existing policy.
Practical note: The .vmx (VM configuration) and .nvram files are also encrypted when you encrypt a VM — not just the .vmdk. Many people miss this when reading the documentation.
Verification & Monitoring
Check the encryption status of a VM
After applying the policy, go to the VM → Summary tab → VM Storage Policies section. Seeing “Compliant” means success.
Quick check via PowerCLI:
# Check compliance for all VMs
Get-VM | Get-SpbmEntityConfiguration | Select-Object Entity, StoragePolicy, ComplianceStatus
# Filter to show only encrypted VMs
Get-VM | Get-SpbmEntityConfiguration | Where-Object { $_.StoragePolicy.Name -eq "VM-Encryption-Policy" }
Verify encryption is working correctly
The most practical test: copy a .vmdk file out and try mounting it directly — you won’t be able to read anything. Or use the following command from an ESXi host to check encryption status:
# SSH into the ESXi host
# Check encryption info for a VM
vim-cmd vmsvc/get.config <vmid> | grep -i encrypt
# Or check directly from the vmx file
cat /vmfs/volumes/<datastore>/<vm-folder>/<vm-name>.vmx | grep encryption
Monitoring and Alerts
Don’t forget to configure alarms in vCenter to catch key-related issues early — by the time a VM refuses to boot, it’s already too late:
- Alarm: “Key Provider not available” — if the NKP fails, encrypted VMs will not start.
- Re-export after each vCenter update: Keys can change after a major update — re-export the NKP backup file after each upgrade.
- vCenter HA: If you’re using vCenter HA, the NKP automatically syncs across nodes — no additional action needed.
A few things to know before going to production
- vMotion works normally with encrypted VMs — keys are securely transmitted between hosts over an encrypted channel.
- Snapshots of encrypted VMs are also encrypted automatically.
- Cold migration to a host outside the same vCenter will require manual key export/import.
- Performance: AES-256 encryption overhead on modern CPUs (with AES-NI) is nearly negligible — under 2% for most workloads.
For environments with compliance requirements like PCI-DSS, HIPAA, or ISO 27001, this is the simplest way to check the “data at rest encryption” box. No additional KMS license to purchase, no extra server to deploy. What I appreciate most: the entire process from setup to encrypting your first VM takes about 30 minutes — compared to the old days of deploying HyTrust or Thales separately, this is a massive step forward.

