Windows 10: Security Processor not showing in Windows Security, Attestation is not supported

I've been having some issues with my Security Processor in Windows Security, it is not visible and so it says the standard security is not supported.- If I go to it through the Start Menu I can see that Attestation is not supported or sometimes even the whole TPM is not visible.- But going into TPM.msc I can see that it is ready.- I have tried clearing the TPM but the issue persists.- I've used the solution for LSA protection not getting activated under Core Isolation which seems to be working now from: Windows 11 Pro Local Security Authority TPM 2.0 cannot be turned - Microsoft Community- Bef

:)

 

"Device health attestation isn't supported on this device"

Hi there.

When going to windows security, device security and then security processor details, Attestation shows "Not supported" under status.





And when I click on Security processor troubleshooting, it tells me "Device health attestation isn't supported on this device.".





What could be the cause of this? Is it possible to fix it and get attestation to work?

My device specs are as follows:

Intel core i5-7500 processor

16 GB RAM

GTX 1060 3 GB graphics card

B250-HD3P-CF motherboard.

 

TPM Attestation Not Supported after CPU Upgrade

I recently upgraded my CPU from a Ryzen 5600X to a Ryzen 5800X3D. Since upgrading in Windows Security it states Attestation Not supported. It states Storage is Ready. I have tried nearly everything to get it fixed to no avail;

• Cleared TPM in Windows
  
• Cleared TPM in BIOS
  
• Reset Secure Boot
  
• Ran the Attestation script from Rudy from Call4Cloud, which states the EKCert is missing - The Last TPM Attestation Script
  
• Updated to the latest beta channel build (22623.1245) as Rudy had said on Twitter that an AMD TPM Attestation bug was fixed in 22621.1192 but this didn't fix it for me either - Rudy's Tweet
  

 

Windows 8 Secure Boot Feature: Not So Secure?

• Linux
• Linux
• Linux
• Linux
• Oh and OSX

Here is a statement from a Kernal Developer at Red Hat:

I'm not sure this exploits the legacy BIOS but rather it exploits the legacy boot method on MBR drives, injecting a signed key before the OS boots, which you are correct in that it has nothing to do with Windows 8. And the simplest fix would just be to require boot drives use GPT when Secure Boot is enabled in UEFI.