What Is Actually Happening Here?

Before we dive into the fix, let's clear up the confusion. The BitLocker prompt you're seeing isn't a bug or a virus, it's Windows doing exactly what it was designed to do. But it's doing it because of a chain reaction you didn't expect.

Here's the short version: Windows 10 and Windows 11 include a feature called Device Encryption, which is a simplified, automatic version of BitLocker that Microsoft enables silently on many systems, including virtual machines, when certain conditions are met. This feature is tied to something called the Trusted Platform Module (TPM), a security chip that stores your encryption keys and "remembers" what your hardware looks like.

When Parallels Desktop updates, it often changes how it presents virtual hardware to your Windows VM. It might update the virtual TPM version, change the virtual machine's hardware profile, or alter how the hypervisor layer reports itself to the guest operating system. From Windows' perspective, these changes look like someone swapped out the motherboard or tampered with the system. The TPM detects that the hardware fingerprint has changed, concludes that something suspicious is happening, and triggers BitLocker's lockout mode as a security measure.

The cruel irony is that this security feature is protecting you from a change that you yourself initiated, just indirectly, through a Parallels update you probably trusted and clicked through without a second thought.

Why a Parallels Update Triggers This Specifically

To understand the fix, you need to understand the mechanism. Parallels Desktop runs Windows inside a virtual machine on your Mac. To make Windows run smoothly and securely, Parallels emulates a variety of hardware components, including a virtual TPM 2.0 chip. This virtual TPM is what allows Windows 11 to install in a VM in the first place, Microsoft requires TPM 2.0 for Windows 11.

When Parallels releases an update, especially a major version update (like going from Parallels 18 to Parallels 19, or a significant build update within the same version), it frequently includes changes to:

• The virtual TPM implementation, updated cryptographic libraries, new endorsement key formats, or changes to how the virtual chip presents itself
• The hypervisor's hardware abstraction layer, changes in how the CPU, memory bus, or firmware are reported to the guest OS
• The virtual BIOS/UEFI firmware, updated UEFI firmware strings that Windows reads and stores as part of its security baseline
• The virtual machine's unique identifiers, hardware IDs that Windows uses to fingerprint the machine

BitLocker and Device Encryption use something called Platform Configuration Registers (PCRs), essentially a set of measurements that the TPM takes of the system's firmware, boot loader, and hardware configuration. These measurements are sealed against the encryption key. If the measurements change, which they do after a Parallels update, the TPM refuses to release the key automatically and Windows falls back to demanding the recovery key.

This is also why the issue affects you even if you never consciously chose to enable BitLocker. Windows 11 Home, Windows 11 Pro, and even some Windows 10 builds automatically enable Device Encryption in the background when they detect a TPM and certain other conditions (like being signed into a Microsoft account). You might have clicked through Windows setup months ago, agreed to Microsoft's terms of service, and unknowingly consented to automatic device encryption, all without seeing the word "BitLocker" once.

Before You Start: What You'll Need

Recovery is usually very straightforward, but gathering the right tools and information before you begin will save you a lot of frustration. Here's what to have ready:

• Access to a web browser on your Mac (your host machine) or any other device
• The Microsoft account email address and password that was used when setting up Windows in your VM
• Your Parallels license or subscription details (for advanced steps)
• Approximately 20–45 minutes of uninterrupted time
• Optionally: a USB drive with a Windows Recovery Environment if the standard steps don't work

The most important item is your Microsoft account credentials. If Windows was set up with a local account and no Microsoft account was ever linked, the recovery path is different and we'll cover that in the advanced section. But for the vast majority of users, the Microsoft account route will get you back in quickly.

Step-by-Step: Recovering Your BitLocked VM Right Now

Advanced Troubleshooting: When the Basic Steps Don't Work

For some users, the steps above won't be quite enough, either because the recovery key isn't showing up in the Microsoft account portal, or because there are additional complications. Here are the most common edge cases and how to handle them.

Recovery Key Not Showing in Microsoft Account

If you signed into the Microsoft account portal and found no recovery keys listed, consider these possibilities:

You used a local account. If Windows was set up without ever signing into a Microsoft account, BitLocker would not have automatically backed up the recovery key to the cloud. In this case, think carefully about whether you were ever prompted to save or print a recovery key during Windows setup, check your email, your Documents folder on the Mac host, or any USB drives you might have used.

You used a different Microsoft account. If you have multiple Microsoft accounts (personal, work, school), try each one. The key is always stored on the account that was active when Device Encryption was first activated.

You used a work or school Microsoft 365 account. If your email ends in a company or university domain, your encryption keys are stored in Azure Active Directory, not in personal account settings. You'll need to contact your IT department or, if you're the admin, log into the Azure portal at portal.azure.com and navigate to Azure Active Directory → Devices → BitLocker Keys.

BitLocker Screen Shows "No Recovery Options"

In rare cases, especially if the virtual TPM has become corrupted beyond what a recovery key can fix, Windows may show a message indicating that the recovery key isn't working or that no recovery options are available. At this point, you have a couple of options:

Option A: Use the Windows Recovery Environment (WinRE). Download a Windows 11 ISO on your Mac and mount it as a virtual DVD in Parallels. Boot from the ISO (you'll need to press a key quickly during startup to get the boot menu, or configure Parallels to boot from CD first). Choose "Repair your computer" rather than Install. In the recovery environment, go to Troubleshoot → Advanced options → Command Prompt. From there, you can use the manage-bde command to attempt to unlock the drive: manage-bde -unlock C: -RecoveryPassword YOUR-48-DIGIT-KEY. If this succeeds, you can then suspend BitLocker with manage-bde -protectors -disable C:.

Option B: Export the VM and restore from a pre-update snapshot. If you had Parallels snapshots taken before the update, you can revert to a prior snapshot from the Parallels Snapshot Manager. This will undo the Parallels update's hardware changes from the VM's perspective and may restore normal boot behavior. Note that this will also undo any Windows changes you made since that snapshot.

Virtual TPM Is Corrupted or Missing

In some edge cases, particularly after major Parallels version upgrades, the virtual TPM state can become corrupted or the TPM chip may no longer be visible to Windows. You can check this by booting into Windows (after unlocking with the recovery key) and pressing Win+R, typing tpm.msc, and pressing Enter. If you see an error saying "Compatible TPM cannot be found" or the TPM status shows an error, the virtual TPM configuration in Parallels has been disrupted.

To resolve this, shut down your VM completely. In Parallels, right-click your VM and choose Configure. Navigate to Hardware → TPM Chip. If it shows as disabled or missing, re-enable it. If it's already showing as enabled but TPM isn't working inside Windows, try removing the TPM chip from the VM configuration, saving, then adding it back again. This forces Parallels to reinitialize the virtual TPM. Note that doing this after BitLocker is active will make things worse, only attempt this after you've successfully unlocked and disabled BitLocker.

The Recovery Key Entry Screen Keeps Rejecting a Valid Key

If you're certain you have the right key but Windows keeps saying it's incorrect, check the following: Make sure you're typing in the right text field, there's sometimes a small cursor that's easy to miss on the blue BitLocker screen. Try clicking directly in the input field before typing. Also ensure your keyboard language layout is set correctly; if your Mac is set to a non-US keyboard layout, certain characters might not be typing the correct characters. If you're pasting the key (which requires a USB keyboard workaround on the lockout screen), make sure no extra spaces or characters were copied.

Prevention: Making Sure This Never Happens Again

Now that you've recovered access to your VM, let's talk about how to prevent this situation from recurring. There are several strategies, and the right one for you depends on how much you rely on Windows encryption.

Strategy 1: Keep BitLocker / Device Encryption Off in Your VM

This is the simplest and most reliable prevention. A virtual machine living inside an encrypted Mac disk image already has hardware-level protection from Parallels and macOS. You don't need Windows-level disk encryption on top of that in most use cases. By disabling Device Encryption in Windows, you eliminate the dependency on the virtual TPM for boot, which means Parallels updates will never cause a lockout again.

To do this, go to Settings → Privacy & Security → Device Encryption (Windows 11) or Settings → Update & Security → Device Encryption (Windows 10) and toggle Device Encryption off. If you're on Windows 11 Pro or Enterprise and using full BitLocker (not just Device Encryption), go to Control Panel → System and Security → BitLocker Drive Encryption and click "Turn off BitLocker."

Strategy 2: Take a VM Snapshot Before Every Parallels Update

Before you ever click "Update" in Parallels, take a snapshot of your VM. In Parallels, this is done from the Actions menu → Take Snapshot. Give it a descriptive name like "Before Parallels 20 Update – April 2026." If the update causes a BitLocker lockout or any other issue, you can revert to this snapshot instantly and you're back to a fully working state within minutes.

This is a best practice that goes beyond BitLocker prevention, it protects you from any VM instability that might be introduced by a Parallels update, a Windows update, or any other change.

Strategy 3: Back Up Your Recovery Key Before Updates

If you do want to keep BitLocker enabled for legitimate security reasons, make sure your recovery key is always backed up before you update Parallels. You can back it up in three ways from within Windows (Start → Search "Manage BitLocker" → Back up your recovery key):

• Save to Microsoft Account, stores it in the cloud, accessible from any browser
• Save to a file, saves a text file you can put on your Mac's desktop or a USB drive
• Print the recovery key, or save it as a PDF

Keep at least two copies in two different locations. A recovery key you can't find when you need it is no recovery key at all.

Strategy 4: Configure TPM-Independent BitLocker

Advanced users who need BitLocker but want to avoid TPM-related lockouts can configure BitLocker to use a startup PIN or startup USB key instead of relying on TPM measurements alone. This means Windows will ask you for a PIN at startup rather than using the TPM's hardware fingerprint to unlock automatically. This is more secure and immune to TPM state changes from Parallels updates.

This requires Windows 11 Pro or Enterprise and a Group Policy change. Open the Local Group Policy Editor (Win+R → gpedit.msc), navigate to Computer Configuration → Administrative Templates → Windows Components → BitLocker Drive Encryption → Operating System Drives, and enable the policy "Require additional authentication at startup." Set it to require a PIN or startup key. Then use Manage BitLocker to change the unlock method on your drive.

Strategy 5: Keep Parallels Updated but Reboot Consciously

Parallels sometimes staggers the hardware changes across restarts. You can reduce the chance of a lockout by updating Parallels when you have access to your recovery key and some free time to troubleshoot if needed, not right before an important deadline. Also check the Parallels release notes before updating; major version updates are more likely to change virtual hardware profiles than minor maintenance releases.

A Note About Windows Device Encryption and Why You Might Have It Without Knowing

Many users are genuinely surprised to learn that BitLocker or Device Encryption was running on their VM. Microsoft has made Device Encryption automatic and background in ways that aren't always obvious. Here's when it gets turned on without a deliberate choice from you:

During Windows setup, if you sign in with a Microsoft account, Windows 11 automatically enables Device Encryption and silently uploads your recovery key to your Microsoft account. This happens even on Windows 11 Home, which previously didn't support BitLocker at all, Microsoft brought Device Encryption to Home in Windows 11.

If your system meets the "Modern Standby" and "HSTI" requirements (which Parallels-hosted Windows VMs often do, since Parallels emulates modern hardware), Device Encryption is eligible for automatic enablement.

After a Windows upgrade or feature update, Windows can re-evaluate these conditions and enable Device Encryption if they're now met and it wasn't previously enabled.

The bottom line: if you've been running Windows 11 in a Parallels VM and you signed in with a Microsoft account at any point, there's a reasonable chance Device Encryption was active on your drive without you ever explicitly choosing to enable it. This isn't Microsoft being deceptive, it's a security feature genuinely intended to protect user data, but the interaction with VM hypervisor updates creates this painful edge case.

Frequently Asked Questions

You're Back in Control

A BitLocker lockout triggered by a Parallels update is startling, but it's one of those problems that looks much worse than it actually is. In the vast majority of cases, your data is completely safe and accessible, you just needed the right key and the right steps to get to it. Now that you've recovered access and disabled Device Encryption (or configured it properly), you've removed the fragile dependency between Parallels' hardware emulation and Windows' boot security.

The most important takeaway: before any future Parallels update, take a snapshot and verify your recovery key is backed up somewhere you can access it. Two minutes of preparation before an update can save you hours of stress afterward.

If you've followed all the steps in this guide and you're still locked out, your best next steps are to reach out to Parallels Support directly (they have specific tooling for recovering VM states) or post in the Parallels community forums with the specific error messages you're seeing. The community there is experienced with this exact issue and often has version-specific workarounds.