Windows 11 VM on Parallels has broken virtual TPM.

Same for me, Uninstalling KB510650 will bring back up and running TPM. All work security features are back and working (PIN, BL, VPN, etc.).
I guess we need a Hotfix from Parallels for that...

 

Also experiencing this issue both on a personal VM and a work one. Personal I managed to reset my PIN ok on boot when prompted but started getting some authentication issues with some applications. Work enrolled VM was exactly the same as others have reported. Rolling back KB510650 temporarily 'fixed' this, but there are of course a lot of security components to that update that I'd like applied to my machine. Hopeful that Parallels will issue a fix soon. Doesn't appear to affect other VMs on different hardware/platforms or windows running on bare metal.

 

This is what I see pre and post:

With KB installed:
- Get-Tpm: 0x80280095, structure is wrong size
- tpm.msc crashed
- Manufacturer: SLRP
- Specification: Unknown
- Microsoft 365 TPM authentication failed

After KB uninstall:
- Microsoft 365 authentication works
- tpm.msc: TPM ready for use
- Manufacturer: PRLS
- Specification: 2.0
- tpmtool and Win32_Tpm return valid information
- Get-Tpm alone still returns 0x80284005 (Get-Tpm : A specified output buffer is too small. (Exception from HRESULT: 0x80284005))

 

I can also confirm that uninstalling KB5101650 resolves the TPM issue, and I'm able to authenticate, although Get-Tpm keeps reporting the error "A specified output buffer is too small. (0x80284005)"

I've paused the automatic updates as much as possible, so hopefully Parallels will release a fix for this issue.

 

I'm seeing what appears to be the exact same issue on a different environment.

Host

• MacBook Pro (M4 Pro)
• macOS Tahoe 26.5.1
• Parallels Desktop 26.4.0 (57513)

Guest

• Windows 11 ARM
• Parallels Tools 26.4.0.57513

Symptoms

• Get-Tpm returns: TPM 2.0: Structure is wrong size. (0x80280095)
• tpmtool getdeviceinformation returns the same error (0x80280095)
• Win32_Tpm reports:
  • ManufacturerIdTxt : SLRP
  • SpecVersion : Not Supported
• Company Portal reports a TPM failure.
• dsregcmd /status shows:
  • AzureAdJoined : YES
  • AzureAdPrt : YES
  • DeviceAuthStatus : FAILED
• Browser authentication (Edge/Microsoft 365) works normally.
• Native Microsoft apps (OneDrive, Office, etc.) fail to authenticate because device-backed authentication is unavailable.

Already tried

• Rebooting multiple times.
• Reinstalling Parallels Tools (same version as Desktop).
• Confirmed the virtual TPM is enabled.
• Removing Zscaler (not related).

This appears to be a TPM API failure rather than an application-specific issue.

Can someone from Parallels Engineering confirm whether this is being tracked under an internal bug, and whether there is a fix planned for a future build? If so, is there a case number or ETA that affected users can reference?

 

Same situation.
- M2 Max MacBook Pro, macOS 26.5.2 (25F84), Parallels Desktop 26.4.0 (57513)
- Also reproduced by a colleague on M3 Max, same Parallels build

Guest is Windows 11 ARM64, build 26200.8875 after KB5101650. Symptoms match this thread exactly: Get-Tpm → 0x80280095 ("structure is wrong size"), BitLocker auto-suspended, Windows Hello no longer works, and M365 desktop apps fail with 0x80090030. Fortunately, I could still access the system via YubiKey.

Confirmed the root-cause tell noted above: the registry TPM manufacturer decodes to SLRP (0x534C5250), which is PRLS with its bytes reversed -- consistent with the vTPM emulator returning TPM2_PT_MANUFACTURER in little-endian instead of the big-endian the TPM 2.0 spec requires.

Rolling Parallels back to a pre-57507 build restores the TPM; uninstalling KB5101650 also works but isn't viable on MDM-managed machines that re-push the update. A signed hotfix would be hugely appreciated -- is there any ETA?

 

At the moment, my VM is in ring 3... so I won 7 days until the installation is forced again... ;-)

 

Are we sure that this is a Parallels bug? The problem started with a Windows update and ends when that update is uninstalled. It seems more likely to me that Windows is not reading the TPM properly.

With that in mind, I booted my VM to an Ubuntu ISO and took a look at /sys/class/tpm/tpm0/device/modalias and see that that returns the following: acpiRLS0000:MSFT0101:. That suggests to me that the byte order is correct in the firmware. That said, I am no TPM expert, so maybe my approach is flawed...

 

Correction to the above, the site converted two characters into an emoji after I hit 'Post Reply'. What cat /sys/class/tpm/tpm0/device/modalias returned was acpi: PRLS0000:MSFT0101:, except without the space between 'acpi:' and 'PRLS000'.

 

someone reverted the Parallels version and the issue also went away and no one seems to be reporting the issue in native windows 11 with the update applied that i have seen.

 

I need to correct my earlier conclusion that rolling Parallels back to a pre-57507 build restores the TPM - do not want to send anyone down the Parallels downgrade path.

I reproduced the failure on the same VM across these versions:

Parallels Desktop version TPM2/SSDT comparison
26.0.0 / 57238 Byte-identical
26.3.2 / 57398 Byte-identical
26.4.0 / 57513 Byte-identical
The captured TPM2 and SSDT data remained unchanged across all three tested versions. Windows failed identically on each version while KB5101650 was installed.

Environment and symptoms

• Windows 11 25H2 ARM64
• KB5101650
• OS build 26200.8875
• Parallels ARM VM

Observed symptoms:

• Get-Tpm and tpmtool fail with: 0x80280095 - TPM 2.0: Structure is wrong size
• tpm.msc crashes or unloads
• Windows Hello and BitLocker functionality is disrupted
• Windows logs TPM command and initialization failures, including events 17 and 27

Linux validation
I booted the affected VM into an Ubuntu live environment on every tested Parallels version. Linux successfully queried the same vTPM each time:

• Manufacturer correctly reported as PRLS
• The TPM was operational
• The responses observed under Linux were correctly framed
• There was no indication under Linux that the stored vTPM state was corrupted

I also installed KB5101650 on a physical Windows ARM64 device. Its TPM remained queryable through Get-Tpm after installation. This suggests the problem is not a universal failure of TPM support on Windows ARM64, although that comparison does not exercise the Parallels virtual TPM path.

Results

• Parallels 26.0.0 / 57238 with KB installed: fails
• Parallels 26.3.2 / 57398 with KB installed: fails
• Parallels 26.4.0 / 57513 with KB installed: fails
• Uninstalling KB5101650: restores TPM functionality
• Installing KB5101650 again: returns the failure

Across all three tested Parallels versions, the failure occurred only while KB5101650 was installed, and uninstalling the KB restored TPM functionality.
Seems to establish KB5101650 as the trigger for an incompatibility between Windows and the Parallels vTPM path. It does not yet establish whether Microsoft or Parallels must provide the compatibility fix.

For now, the practical workaround is to uninstall KB5101650 and pause quality updates. Downgrading to the tested Parallels versions did not help, so I have returned to Parallels 26.4.0 / 57513.

 

Awesome, thanks for this thorough testing. Now we just need a fix...

 

The KB5101650 update contains a bug that also occurs on standalone (DELL) computers, among other things. This is not a Parallels problem, but a bug in KB5101650 that causes hardware and software to be suddenly accessed differently, resulting in a TPM error. On DELL computers is strickly advice don't install this update, it result in TPM problems,

 

KB5101650 - breaks my Install too on Parallels - PIN does not work after reboot.
After reverting the update - I am able to use the PIN feature - and do not get the error code "0x80280101".

I suspect this is a problem for Parallels and some DELL hardware.

 

if it's true that the Dell issue is the same issue, MS released an OOB update that is targeting the Dell systems. they may need to do the same for ||s?
https://support.microsoft.com/en-us/servicing/os/windows-11/2026/07/kb5121767-out-of-band

 

We had the same problem with the KB5101650 update. Once we'd uninstalled it, the virtual TPM 2.0 chip started working again. However, as the update is intended to fix many security issues, we hope that Microsoft will resolve the Parallels compatibility issue as soon as possible. Analysing the issue and finding a temporary solution really took up a lot of our time, which we were unable to use productively. How will we be informed once the problem has been resolved?

 

Any updates on this?
Time is running (until forced installation of Update) and I need my VM

 

I've tried the KB5121767 (Dell-Update), but the TPM-error occurs again. Can anyone else confirm this?

 

Would appreciated if someone from Parallels can chime in and give us an update. Is the problem being worked on? When can we expect an update/fix? Once the company forces KB5101650 my main workflow will be dead in the water. I of course can use O365 in a browser on the Mac to get some of the work done. But will be missing loads of work that needs to be done via local DB and/or spreadsheet data relating.

 

The company I work for forces the update as soon as it is uninstalled, rendering my Parallels VM for work effectively useless right now, so I very much feel your pain. I agree that it would be appreciated if someone from Parallels would chime in, but since this is a Windows bug, not a Parallels bug, I am not sure what Parallels can do other than acknowledge the issue and work with Microsoft to pursue a fix. Still, an official response would go a long way...