Hello.
Apologies for my bad english.
That issue (Standard hardware security not supported), from what I've been researching, is caused by an Update for Windows Security Platform.
It appears that Windows 11 22H2 (build 22621) is not compatible with a previously installed Windows Security Platform update in version 22H1 (build 22000). Although this does not affect all computers because it largely depends on the installed hardware and BIOS settings, as well as the type of installation: in a clean installation there is no such problem.
Specifically, it is the KB5007651 update, May 2022 for Windows 11 22H1, which already had many installation problems at the time. Logically, the computers updated after Windows 11 22H2 maintain that update that is now not compatible and that causes this problem in Windows Security.
The ideal solution has to be implemented by Microsoft through a new update for the Windows Security Platform for Windows 11 22H2.
However, there is a workaround until Microsoft releases the new update: delete the KB5007651 update folder:
- Access the following path: C:\Windows\System32\SecurityHealth
- Delete the folder 1.0.2109.27002-0 with all its content (be careful with deleting other folders)
- Reboot the system.
Hi Enric,
Thank you for this thoughtful post. I have spent hours searching for a workaround to this issue on a new i9-13900KF/Z790 platform that was falsely showing "[standard] hardware security not supported" when everything, including BitLocker was working just fine. I did come up a workaround like yours that expected there to be files in the SecurityHealth directory, but mine was, like many others, empty because of a fresh install of Windows 11.
This is most definitely a bug introduced with a later release of the security platform update. By downgrading to a prior version you posted above, downloading the file, and following the exact procedure you posted, I was able to restore proper functionality, as shown below. Before this all I would see is the "[standard] hardware security not supported" message.
This does beg the question however - since this is well known now, why is it that it has not been fixed yet by Microsoft? (Not a question for you, just a rhetorical question.)
In any case, thank you again. For anyone else reading, this workaround works perfectly when your SecurityHealth folder is empty.
Thanks again!
