Ditching External KMS: The AngrySysOps Guide to vSphere Native Key Provider

Let’s be honest: managing external Key Management Servers (KMS) for vSphere VM encryption has always been a massive pain. You have to stand up extra infrastructure, pay extortionate licensing fees, and pray the connection between vCenter and your KMS doesn’t randomly drop.

VMware finally threw us a bone in vSphere 7.0 Update 2 by introducing the Native Key Provider (NKP). No external KMS required. It’s built right into vCenter, it’s free, and it actually works.

But because we don’t trust marketing brochures, we need to know how this thing actually operates, how to migrate to it, and—most importantly—what happens when vCenter inevitably decides to corrupt itself.

Here is your no-nonsense guide to setting up and migrating to NKP.

How This Witchcraft Actually Works

VMware NKP uses a three-tier key hierarchy to lock down your VMs. Since your storage team is handling the actual disks, your job is managing the locks.

1. Key Derivation Key (KDK): The master key. This is generated and stored securely inside vCenter when you initialize the NKP. This is what you are backing up when you download the .p12 file.
2. Key Encryption Key (KEK): A secondary key derived from the KDK. vCenter passes the KEK down to the ESXi host.
3. Data Encryption Key (DEK): The actual key that encrypts the VM’s storage (VMDKs) and memory. The ESXi host generates this.

The Workflow: The ESXi host uses the DEK to encrypt the VM. It then uses the KEK (provided by vCenter) to “wrap” (encrypt) the DEK. The wrapped DEK is stored safely with the VM’s files on the datastore. vCenter never sees the raw DEK, and the storage admins never see the unencrypted keys. Beautiful.

The Doomsday Scenario: vCenter is Dead

This is the question that keeps sysadmins awake at night: If vCenter holds the master key, and vCenter crashes, burns, or corrupts its database… do I lose all my encrypted VMs?

Short answer: No, assuming you actually backed up your NKP and have physical TPMs on your hosts.

Because your ESXi hosts have the master KDK sealed inside their physical TPM 2.0 chips, the keys can be reconstructed and synced back into a brand new vCenter database. How it happens depends on the VM’s power state when disaster struck:

Scenario A: VMs were Powered ON

If your VMs are up and running while you rebuild vCenter, the ESXi hosts already have the decrypted KEKs active in their volatile memory (RAM).

1. We deploy the fresh vCenter and restore the Native Key Provider using our .p12 backup file.
2. We add the existing ESXi hosts back into the new vCenter inventory.
3. The Magic: Once the hosts reconnect, a management sync occurs. The ESXi host takes the active KEK from its RAM, wraps it using the restored KDK, and pushes it up to the new vCenter Server.
4. Result: The new vCenter database is automatically repopulated. You’re saved.

Scenario B: VMs were Powered OFF

If a VM is powered off when vCenter dies, its KEK is wiped from the host’s RAM.

1. When an encrypted VM is created, a copy of the wrapped KEK is saved directly inside the VM’s metadata files (like the .vmx or vSAN object metadata) on your shared storage.
2. When you register that existing VM to your newly rebuilt vCenter (which has the NKP restored), vCenter reads the VM’s files on the disk.
3. It extracts the wrapped KEK from the storage metadata and writes it into the new vCenter inventory.
4. Result: The database repopulates from the storage backup copy.

The Pre-Flight Checklist (Prerequisites)

Do not attempt this unless you meet these requirements.

• vSphere Version: 7.0 Update 2 or higher. (Note: VM Encryption existed in 6.5, but Native Key Provider did NOT. Don’t go looking for this in 6.7).
• TPM 2.0: Highly recommended on all ESXi hosts. Without a physical TPM, keys won’t survive a host reboot if vCenter is offline.
• Permissions: Your account needs “Cryptographic Operations” and “Change Encryption” privileges.

Step 1: Setting Up the Native Key Provider

1. Log in to vCenter → Navigate to Configure → Key Providers.
2. Click Add → Select Native Key Provider.
3. Give it a name (e.g., NKP-Primary).
4. UNCHECK the box that says “Use key provider only with TPM protected ESXi hosts” ONLY IF your cluster has hosts without TPM 2.0. (Though seriously, get TPMs).
5. Click Add.

Step 2: Initialize, Backup, and Secure

An NKP is useless until it’s backed up.

1. Select your new NKP → Click Initialize.
2. Enter a brutally strong backup password. WARNING: If you lose this password, your backup .p12 file is worthless, and you will lose your VMs if vCenter dies. Store it in your enterprise password vault (CyberArk, Thycotic, 1Password, etc.).
3. Wait for the status to change to Ready.
4. Click Backup → Download the .p12 file (e.g., NKP-Primary-backup.p12).

The OpenSSL Extraction Trick

If your enterprise vault strips formatting or you just want to store the raw KDK safely offline in a text format, you can extract the contents using OpenSSL on any Linux box:

# Extract contents from .p12 file
openssl pkcs12 -in NKP-Primary-backup.p12 -nodes -out NKP-Primary-backup.txt

# Enter the backup password when prompted.
# The .txt file now contains the Key Derivation Key (KDK) in readable format.

Store this output securely. If you ever need to rebuild the .p12 file to restore vCenter:

openssl pkcs12 -export -in NKP-Primary-backup.txt -out NKP-Primary-restore.p12

Step 3: Make it the Boss

1. Select your NKP → Click Set as Default.
2. Verify the status shows as both Ready and Default.

Migrating from your Old KMS to NKP

If you are moving away from an external KMS, you need to re-encrypt your VMs to use the new Native Key Provider.

First, understand the difference between Shallow and Deep re-encryption:

Aspect	Shallow Re-encryption	Deep Re-encryption
Speed	Fast (seconds to minutes)	Slow (hours for large VMs)
VM Power State	Can stay powered ON	Must be powered OFF
What’s Changed	KEK / KDK only	KEK + DEK (full cryptographic wipe)
Data Rewrite	No	Yes (rewrites all encrypted disk data)
Use Case	Key rotation, Provider migration	Security mandates a full data refresh

For a standard migration to a new provider, Shallow Re-encryption is exactly what you want. It changes the KEK boundary to the new NKP without having to rewrite terabytes of disk data.

The PowerCLI Migration Method (Do it the right way)

The vSphere UI is notoriously clunky when trying to force a key provider change without messing with storage policies. Just use PowerCLI and save yourself the clicking.

# Connect to your vCenter
Connect-VIServer -Server vcenter.yourdomain.local

# Define your Target VM and the new Native Key Provider
$vm = Get-VM -Name "DB-Server-01"
$nkp = Get-KeyProvider -Name "NKP-Primary"

# Execute a shallow rekey to the new provider
Set-VM -VM $vm -KeyProvider $nkp -RunAsync

Validate the task completes in vCenter, and you’re done. You can now start decommissioning that expensive, legacy KMS and sleep a little easier. Just don’t lose that backup password.