How to Decrypt a Virtual Machine in VMware

Encrypting a VMware virtual machine adds a strong layer of security — but there are legitimate situations where you need to remove that encryption. Whether you're migrating to a new host, troubleshooting access issues, or restructuring your virtual infrastructure, understanding how VMware encryption works and how to reverse it is essential knowledge for any VM administrator.

What VMware VM Encryption Actually Does

VMware vSphere and VMware Workstation both support VM encryption, which protects virtual machine files at rest — including the .vmdk (virtual disk), .vmx (configuration), and snapshot files. Encryption is applied using AES-256 and is managed through a Key Management Server (KMS) in enterprise environments, or through simpler built-in mechanisms in VMware Workstation.

When a VM is encrypted, the guest operating system and its data are unreadable without the correct decryption key. This protects sensitive workloads from unauthorized access, even if someone physically extracts the storage files.

Decrypting reverses this process — returning the VM files to an unencrypted state that any authorized host can read without a key.

Two Different VMware Environments, Two Different Processes

The decryption path depends heavily on which VMware product you're using:

These are meaningfully different workflows. Mixing up the approach for your environment is the most common source of confusion.

Decrypting a VM in VMware Workstation or Fusion 🔓

In VMware Workstation Pro or VMware Fusion, encryption is typically applied through the Access Control settings, which password-protect and encrypt the VM package.

To decrypt:

1. Open VMware Workstation and select the encrypted VM
2. You'll be prompted for the encryption password before the VM can be opened or edited
3. Once authenticated, go to VM > Settings > Options > Access Control
4. Select Remove Encryption (or similar, depending on your version)
5. Confirm the action — VMware will decrypt the VM files in place

Key variables here:

• You must have the original encryption password — there is no bypass or recovery path if it's lost
• The decryption process rewrites the virtual disk files, so sufficient free disk space is required (roughly equal to the VM's current size)
• Larger VMs take significantly longer to decrypt — plan for downtime

Decrypting a VM in vSphere (Enterprise/Data Center Environments)

In VMware vSphere, VM encryption is policy-driven. Encryption is assigned through a VM Storage Policy linked to a KMS. To remove encryption, you reassign the policy.

The general process:

1. Confirm the KMS is online and accessible — decryption requires the same key server that encrypted the VM
2. Power off the virtual machine
3. In vCenter, right-click the VM and go to VM Policies > Edit VM Storage Policies
4. Change the storage policy from the encrypted policy to a non-encrypted policy (such as the default datastore policy)
5. Apply the change — vCenter will trigger a storage vMotion-like process that rewrites the VM's files without encryption

Key variables in this environment:

• KMS availability is non-negotiable — if the key server is offline or the key is missing, decryption cannot proceed
• The VM must be powered off during the process in most configurations
• You need appropriate vCenter privileges — typically Cryptographic Operations permissions
• In environments using vSAN encryption, the approach differs again because encryption happens at the datastore level, not the individual VM level

The Role of Encryption Keys and Why They Matter

VMware's encryption architecture separates data encryption keys (DEKs) from key encryption keys (KEKs). The KEK lives on the KMS; the DEK is stored in the VM's configuration file, protected by the KEK.

This means:

• If the KMS is intact, decryption is straightforward through policy changes
• If the KMS is lost or corrupted, the VM's data is effectively unrecoverable — by design
• Key re-keying is also possible (replacing the existing key without fully decrypting), which is a middle-ground option in vSphere

Understanding this hierarchy matters when troubleshooting. An error during decryption often traces back to a KMS connectivity issue or a missing key, not a problem with the VM itself.

Common Obstacles and What Causes Them ⚠️

Snapshots in particular are a common blocker — VMware typically requires snapshot consolidation before encryption state changes can be applied.

What Determines Your Specific Path

The right decryption process for any given situation depends on factors that vary significantly from one setup to the next:

• Which VMware product is hosting the VM
• Whether you have the original password or KMS access
• The VM's current power state and whether snapshots exist
• Your role-based permissions within vCenter, if applicable
• Whether disk space is available for the rewrite operation
• vSAN vs. traditional datastore architecture in enterprise setups 🖥️

Each of these variables can shift the process, the timeline, and even whether decryption is possible at all. A straightforward Workstation password removal is a five-minute task; a vSphere enterprise decryption in a hardened environment can require coordination across infrastructure, security, and storage teams.

The technical steps exist and are well-documented — but which steps apply to your VM depends entirely on how it was encrypted, what tools you have access to, and what your current infrastructure looks like.