Thank you so much for this AMA

• Q1A) What happens to VMware UEFI VMs, as well as Hyper-V, Azure Local and Azure generation 2 VMs that are isolated from the Internet?
  Q1B) What is the step-by-step procedere to change their Secure Boot root certificate at scale? Especially the Platform Key (PK)?
  
  
• Q2: Is there any dependency on the root hardware for VMware ESXi hosts or Hyper-V hosts and the certificate change?
  
  
• Q3A) What happens to end user devices at home or work or physical servers which will not or never receive any UEFI firmware updates after the old root cert, especially PK expires?
  
  Answer for Q3A: 

  The device will continue to boot and function normally. However, it will no longer receive future security fixes for Windows boot manager updates or Secure Boot, compromising the security of the device. Source: General Questions, Q4

• Q3B) Will devices with the old expired (insecure) Root Certificate still be functional and booting Windows or other OSes using Secure Boot?
  If yes, how is it ensured and secure that they boot with an expired (or even tampered) certificate?
  If no, do you have a step by step guide how to remediate a relevant amount of these outdated systems at scale?
  
  Answer for Q3B:
  The device will continue to boot and function normally. However, it will no longer receive future security fixes for Windows boot manager updates or Secure Boot, compromising the security of the device. Source: General Questions, Q4.
  
  You might need to update the devices manually when the OS is still supported. How-To: Michael Niehaus (PS Module) / Gunnar Haslinger (Guide), please use Edge for in-line translation.
  
  
• Q3C) When the (Windows or Linux) OS deployed the new keys into the Firmware, and the PK remains outdated (CA2011), then the customer / user updates the Firmware, will Windows boot?
  Asking because often Firmware (UEFI / BIOS Updates) reset the keys or entering setup phase. When I understand this correctly the PK key is outdated and revert the updates made by the OS.
  What is your guidance here?
  
  Answer to Q3C:
  Resetting the DB / KEK after it has been updated with a BIOS reset / Secure Boot Reset or BIOS Update that does not contain the CA2023 PK might tamper Secure Boot - as designed - 
  Windows will stop booting due to the Secure Boot Violation. This might trigger Bitlocker, Windows Hello (PIN) and other features.
  Source: Customer / IT Managed Systems Q1 & Q7, ref to Bitlocker / Windows Hello (PIN) - based on own tests.
  
  
• Q4) Could you please describe, if any, the dependency between the OS level update process in the Windows, Windows Server or Azure Local OS and the UEFI firmware?
  
  Answer to Q4:
  For Windows Server, Hyper-V things should go well as Microsoft will try to update both DB and KEK in the VM. Before that a workaround was required.
  Source: Customer / IT Managed Systems Q5 / General Question Q7
  
  
  
• Q5) What happens to older OS that are receiving ESU, or do not receive ESU? Theoretically all devices since Windows Server 2012 R2, 8.1 could be configured with UEFI OS  Secure Boot.
  
  Answer to Q5:
  Windows OS with ESU are considered supported / eligible systems. Unsupported OSes will not receive any updates. They remain bootable but Secure Boot becomes insecure. See Q3.
  
  
• Q6A) Is there any obligation for OEMs and ISV - especially including retail mainboard manufacturers, such as MSI, Asus, Asrock, Gigabyte, Medion, Huawei, Intel etc.- to update their UEFI firmwares?
  
  Answer to Q6A:
  Appears there is no eligibity for OEMs or ISV / Retail to provide updates. Source: Please consult OEM pages. Retail is missing out. I am asking for further clarification, esp. for non OEM systems, or OEM systems that are unlisted.
  
  Q6B) what is their timeline?
  
  Q6C) will this include all mainboard models and chipsets, which still could run CPUs, certified for Windows 11? 
  Context: Thinking about some million of custom build (workstation) computers or gaming computers out there that are not "OEM" and eventually not managed by organizations.
  
  
• Q7) How can we ensure that default Windows RE partitions across the board, or custom Windows PE images are updated and compliant with the new Secure Boot root cert?
  
  
• Q8) Are Linux distros adopting this change?
  Context:
  When Microsoft adapted Secure Boot there was a large fallout with Linux distros which didn't support UEFI at all in grub /Kernel. Thankfully this has changed so no one has to turn off Secure Boot for using Windows and Linux on the same hardware.
  
  Preliminary note:
  My own tests are not running good! When Windows 11 has updated Secure Boot, Distros with older CA2011 certs cause a boot violation (as per design).
  
  
• Q9) Are other vendors adopting the change? 
  Context:
  Other vendors in business and non business bootable devices, including backup vendors, partition tools, driver and firmware updater - ISOs or USB creation tools by HPE, Dell, Seagate, Samsung etc.
  My concern is that they will keep using the expired UEFI root certs, which could deny booting.
  
  Macrium Reflect X is the first product I see that has implemented a choice for the new or old root certificate for Windows RE /PE rescue media.
   
  

  
  added Q3C, having a better understanding.
  added answers and sources, as per current availability pre this AMA event.