Replacing an Standard key management server (KMS) with the VMware native key provider (NKP) in VMware vCenter server

Products

VMware vCenter Server

Issue/Introduction

This article provides guidance on transitioning from a standard Key Management Server (KMS) to the VMware Native Key Provider (NKP).
It outlines how to safely migrate vTPM-enabled and encrypted virtual machines to the NKP, ensuring continuous operation and security compliance once the external KMS is decommissioned.

When replacing a standard KMS with the VMware Native Key Provider, administrators may encounter uncertainty regarding how existing vTPM-enabled or encrypted VMs will behave after the external KMS is retired.

In particular, concerns may include:

Whether vTPM certificates need to be regenerated.
If encrypted workloads will continue to operate normally after the KMS is removed.
What steps are necessary to transition key management safely to the NKP without disruption.

This guidance applies when:

The Native Key Provider is already deployed and set as the default Key Provider.
The external KMS is being prepared for decommissioning.
The environment includes encrypted VMs and vTPM-enabled workloads initially tied to the external KMS.

Environment

VMware vCenter Server 8.x

Cause

This situation arises when an environment transitions from a standard KMS to the Native Key Provider (NKP) as the new default key manager.
While the NKP is fully capable of managing existing encryption keys and vTPM components, a controlled rekey (re-encryption) process is required to ensure:

All vTPM and encryption keys are re-associated with the NKP.
Key management continuity is maintained without requiring certificate regeneration.
Encrypted VMs remain accessible after the external KMS is retired.

Resolution

To safely transition vTPM-enabled and encrypted virtual machines from the external KMS to the Native Key Provider, perform a rekey (recrypt) operation.
This process re-encrypts the virtual machine with a new Key Encryption Key (KEK) issued by the NKP.
Once the rekey is completed, the virtual machine’s cryptographic operations are managed exclusively by the NKP, and the external KMS can be safely removed.

Rekey Process Overview

You can use the vSphere Client to perform a shallow rekey (recrypt) or a deep rekey, depending on your operational requirements.

Rekey Type	Description	Power State Requirement
Shallow Rekey (Recrypt)	Replaces only the Key Encryption Key (KEK) used to protect the Disk Encryption Key (DEK). Recommended for transitioning to a new key provider.	Can be performed while the VM is powered on, except for VMs with IDE controllers, which must be powered off.
Deep Rekey	Replaces both the KEK and DEK for full cryptographic renewal.	Requires the VM to be powered off.

Required Privilege:
Cryptographic operations > Recrypt

Steps to Perform a Rekey (Recrypt) Using the vSphere Client

Log in to the vCenter Server using the vSphere Client.
In the inventory, select the encrypted virtual machine.
Right-click the VM and select:
VM Policies > Re-encrypt
When prompted, click Yes to proceed.
The virtual machine will be rekeyed with the new KEK from the Native Key Provider.

If the rekey process fails, the following event is generated:

com.vmware.vc.vm.crypto.RekeyFail

Note:

The rekey process does not modify or regenerate the vTPM certificate.

Once rekeyed, the VM is fully managed by the NKP, and the external KMS can be safely removed.

Verification

After completing the rekey process, confirm the following:

The VM’s encryption policy now references the Native Key Provider.
The VM remains powered on and accessible (for shallow rekey).
The vTPM and encrypted disks function as expected without key retrieval errors.
The external KMS no longer appears as the active provider for any VM encryption keys.

Additional Information

Best Practices and Recommendations

Perform rekey operations during a maintenance window to minimize operational impact.
Ensure recent backups exist before performing any cryptographic changes.
Validate NKP health and configuration before decommissioning the external KMS.
Regularly export and back up the NKP keys in accordance with VMware’s security guidance.
Refer to VMware documentation for Configuring and Managing vSphere Native Key Provider.
Refer to VMware documentation for vSphere Native Key Provider (NKP) Questions & Answers.