KB4535680: Security update for Secure Boot DBX: January 12, 2021

Issue

Workaround

Some original equipment manufacturer (OEM) firmware might not allow for the installation of this update.

To resolve this issue, contact your firmware OEM.

If BitLocker Group Policy Configure TPM platform validation profile for native UEFI firmware configurations is enabled and PCR7 is selected by policy, it may result in the BitLocker recovery key being required on some devices where PCR7 binding is not possible.

To view the PCR7 binding status, run the Microsoft System Information (Msinfo32.exe) tool with administrative permissions.

To workaround this issue, do one of the following based on credential guard configuration before you deploy this update:

• On a device that does not have Credential Gard enabled, run following command from an Administrator command prompt to suspend BitLocker for 1 reboot cycle:

  Manage-bde –Protectors –Disable C: -RebootCount 1

  
  Then, restart the device to resume the BitLocker protection.
  
  Note Do not enable BitLocker protection without additionally restarting the device as it would result in BitLocker recovery.

• On a device that has Credential Guard enabled, there may be multiple restarts during the update that require BitLocker to be suspended. Run the following command from an Administrator command prompt to suspend BitLocker for 3 restart cycles. Manage-bde –Protectors –Disable C: -RebootCount 3

  This update is expected to restart the system two times. Restart the device once again to resume the BitLocker protection.

  Note Do not enable BitLocker protection without additionally restarting as it would result in BitLocker recovery.

You might enter Bitlocker recovery if conflicting BitLocker group policy settings are configured after BitLocker has been enabled in environment. Bitlocker recovery can be triggered due to any of the below Group Policy settings:

• Forcing Explicit configuration of PCR bindings that is different from what is already chosen by BitLocker.

• Configuring GP “Allow Secure Boot for integrity validation” to dis-allow Secure boot for integrity validation but BitLocker is already using secure boot (PCR7).

• Configuring Group Policy to Require additional Authentication during startup but BitLocker has been configured before deploying this group policy.

If this update has already been applied and the device hasn’t restarted, suspend BitLocker and restart after following the below steps:

• If an explicit PCR configuration has been set through group policy or a policy is configured to disallow using secure boot for integrity validation, Suspend and resume BitLocker to clear the GP conflicts.

• If the Require additional Authentication during startup policy is configured to require TPM and PIN, run the following command from an Administrative command prompt and enter the desired PIN: manage-bde -protectors -add c: -TPMAndPin

• If the Require additional Authentication during startup policy is configured to require a startup key, execute the following command to create startup key: manage-bde -protectors -add c: -tpmandstartupkey  <path to external key directory>

• If the Require additional Authentication during startup policy is configured to require startup key and pin, execute the following command from Admin command prompt to create Pin and startup key. When prompted, enter the desired PIN: manage-bde -protectors -add c: -tpmandpinandstartupkey  <path to external key directory> 

This update might not install on devices with an unsigned, non-Microsoft bootx64.efi boot manager file.  This update might be offered and reoffered through Windows Update but might not install.  When you try to install this update manually, you might receive an error, “Some updates were not installed” listing KB4565680.  You can also check the CBS Log file in %systemroot%\logs\cbs for the following error: 

onecore\base\secureboot\servicing\advancedinstaller\securebootai.cpp(277): Error TRUST_E_NOSIGNATURE originated in function Windows::WCP::SecureBoot::BasicInstaller::Install expression: ApplySecureBootUpdate( dwAvailableUpdates)

We are working on a resolution and estimate a solution will be available for Windows 10, version 1909, Windows 10, version 2004 and Windows 10, version 20H2 in late March.  The remaining supported versions of Windows are estimated to have a solution available in mid-April.

For additional guidance before the release of the resolution, please contact your device manufacturer (OEM).