Hi there I've noticed a problem with AMD consumer platforms. Confirmed with two different AMD chipsets, SVM (CPU Hyper-V required feature) is disabled by default. But this is required along with Secure Boot to make use of VBS and other subsequent security features, that are to be set in Microsoft Security App (Defender).

After today's AMA, I think I understand that as long as IT managed systems are configured with this reg key / value - 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates' to '0x5944', that should trigger the system to apply the updated Secure Boot certs as long as the firmware supports the update and the machine has the certs via CU. Can you please verify that my understanding is correct? If it's not correct, what additional requirements am I missing? Additionally, with the above configuration, what does timing look like? Should the certs be applied relatively quickly or is there still a wait period before you should expect the updated certs?

Thanks for your participation in today’s AMA! We’ll post a recap of the questions panelists answered during the live AMA, shortly.

what about the 65000 error in Intune.... there are enough people posting this, why isn't it being covered in this discussion thoroughly?

In my environment, we are not currently consuming all the event logs to look for 1808, but I have a MECM (SCCM) baseline looking for the regkey status of "Updated". For those workstations that show "Updated" does that mean they are good? Nothing else to do?

Are you guys aware if there are plans to allow the OS to automatically suspend BitLocker protection when a firmware update comes down via Windows Update on devices where Secure Boot is enabled but the PCR 7 binding is not possible?

Firmware updates coming from WU are currently being prevented from installing when Bitlocker Protection is On and the PCRs are set to 0,2,4,11 (generally devices with Secure Boot turned off). The main concern is a subset of devices that leverage OROMS can not bind PCR7 when Secure Boot is enabled and BitLocker is enabled. This causes an SB enabled device to have 0,2,4,11 PCRs preventing them from receiving important firmware updates with updated Default DB 2023 certs. Depending on the client base to suspend bitlocker protection periodically is not a viable solution and doing it automatically via Remediation script would be a security concern.

If a device receives the new certificate in the active db and is later reimaged, would the device lose the new certificate? I'm unclear how reimaging affects the db/bootmgr since the drive has to be en-encrypted?

Does triggering the update manually via registry key in a corporate environment on sample machines help to develop the confidence buckets?

I see a high number of devices in our environment with the following setting in registry. 1 - “Windows UEFI CA 2023” certificate is in the DB. Will the CFR or LCU trigger it to move to 2 - “Windows UEFI CA 2023” certificate is in the DB and the system is starting from the 2023 signed boot manager ​​​​​?

Is there any potential impact on installed applications following the renewal of Secure Boot certificates? Is there any rollback plan in case of any issues?