Is there a report in intune/Entra that show the state of devices in the fleet for the updated certs?

For Surface devices - the bios update is not a required step - so for surface devices we just need to wait for the udpated certificate to show up?
Also for surface devices, we see 2 options for secureboot - 1. Microsoft only 2. Microsoft & thirdparty CA

Is there any guideline MS gives to select one to get the certificate updated?

1 - What's the best way to automate certificate verification across 500+ machines?

2 - How to deal with legacy devices that don't support automatic updates?

3 - What are the best practices for dual-boot environments or VMs?

If using Option 1 in the Playbook to Deploy certificates using Microsoft Intune does this only apply Mitigation 1 and 2? Is Mitigation 3 and 4 applied automatically via enabling the CFR option? If I want to control Mitigation 3 and 4 rollout, I'm guessing I need to deploy the regkeys manually/separately from enabling CFR?

Why do HP state "If your HP Commercial PC is listed as a supported platform, update the BIOS to the minimum version to ensure that the SMBIOS Type1 version field contains the SBKPFV3 substring on Secure Boot-enabled PCs. This substring allows cumulative updates from Microsoft to append the KEK and DB with new certificates throughout 2026." - Is this a string that the Windows OS process is looking for, or something that the BIOS needs in order to accept the update? thanks

For devices currently sitting in vendor storage awaiting deployment, do we need to update all of them before June?

For example, if a device remains in storage until the end of the year and is then shipped to a user, would we still be able to update the Secure Boot Certificate by scoping that device into the remediations? Or would the certificate be too far expired at that point to be remediated if the BIOS is up to date?

If I roll out the Intune configuration profile to enable the download of the Secure Boot, would that be sufficient if test cases across our laptop models show promising results?

On test cases across existing computer models in our environment, allowing it to download the latest cert and restart the machines after the task runs shows that most of them are showing the following outputs:

[System.Text.Encoding] : :ASCII.GetSTring( (Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

True

[System.Text.Encoding] : :ASCII. GetString( (Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'

False

Am I missing anything?

When will Microsoft release an Windows 11 ISO with the updated Certs in them by default? Is this something we should be concerned about? Is this something Org's should open up the ISO and add in the certs manually? 

Also, when should we start to see the boot manager using the new Certs?

Post-expiration behavior for 3rd Party / Option ROM CAs

When the Microsoft Windows Production PCA 2011 expires in June 2026, the migration path to "Windows UEFI CA 2023" is well documented for the boot manager. However, the situation is much less clear for the "Microsoft Corporation UEFI CA 2011" (3rd Party UEFI CA) and its Option ROM counterpart.

On many Secured-Core systems, the "Allow Microsoft 3rd Party UEFI CA" BIOS setting is disabled by default, so the 2011 3rd Party CA is absent from the Default db store and Windows Update never injects its 2023 equivalent ("Microsoft UEFI CA 2023").

What is the supported remediation for customers who reach June 2026 with the 3rd Party CA never migrated — for example fleets running Linux dual-boot, third-party Option ROM hardware (RAID, GPU, NICs), or pre-OS tools signed by the 3rd Party CA? Is there an official guidance document specific to the 3rd Party / Option ROM CA migration, equivalent to what exists for the Windows boot manager?

Can you explain what Not Applicable , Unknown mean. I see these  on secure boot status report...