Secure Boot Implementation

Question

Are there any issues implementing "Secure Boot" in group policy to all workstations/servers?

Answer 1

Yes, there are known considerations and potential issues when deploying Secure Boot–related settings broadly via Group Policy to all workstations and servers.

Key points from the documented guidance:

1. Firmware and device compatibility risks
   Secure Boot updates depend on device firmware, and some devices can experience compatibility issues. Before broad rollout via GPO:
   • Validate the Secure Boot update policy on at least one representative device for each device type.
   • Confirm that Secure Boot certificates are successfully applied to the UEFI DB and KEK stores. Guidance is provided in Secure Boot certificate deployment documentation.
   • After validation, group devices by bucket hash and roll out in controlled phases rather than enabling for all devices at once.
2. GPO is configuration-only; monitoring is separate
   Group Policy provides a straightforward way to configure Secure Boot certificate deployment on domain-joined clients and servers (Computer Configuration → Administrative Templates → Windows Components → Secure Boot). However, GPO does not provide built‑in monitoring of deployment status. Monitoring must be done via:
   • Registry keys associated with Secure Boot deployment.
   • Event logs (for example, TPM-WMI events indicating Secure Boot update failures).
3. Avoid mixing deployment methods on the same device
   When using GPO to manage Secure Boot updates, do not mix it with other deployment methods (such as direct registry control, WinCS CLI, or Intune/ConfigMgr scripts) on the same device. Mixing methods can cause inconsistent state and troubleshooting complexity.
4. Interaction with BitLocker policies and Secure Boot DBX updates
   Some Secure Boot DBX security updates (for example KB4535680 and KB5012170) have documented interactions with BitLocker and TPM platform validation policies:
   • Conflicting BitLocker Group Policy settings (PCR bindings, “Allow Secure Boot for integrity validation”, or “Require additional authentication at startup”) can trigger BitLocker recovery after Secure Boot DBX updates.
   • If the BitLocker policy Configure TPM platform validation profile for native UEFI firmware configurations is enabled and PCR7 is selected, Secure Boot DBX updates can fail to install. Recommended mitigations include:
   • Suspending BitLocker before applying Secure Boot DBX updates (with different reboot counts depending on whether Credential Guard is enabled) and then resuming protection.
   • Aligning BitLocker GPO settings with the existing BitLocker configuration (for example, suspending/resuming BitLocker or reconfiguring protectors if PCRs or startup authentication requirements are changed).
5. Error events during Secure Boot updates
   If Secure Boot updates fail to update UEFI variables, TPM-WMI events (such as Event ID 1796) will log errors. These indicate that the Secure Boot update could not write to a Secure Boot variable and require investigation before continuing broad rollout.

In practice, implementing Secure Boot and its certificate/DBX updates via GPO is supported but should be done in a staged, validated manner with attention to firmware compatibility, BitLocker policy alignment, and separate monitoring via registry and event logs.

---

References:

• Group Policy Objects (GPO) method of Secure Boot for Windows devices with IT-managed updates
• Secure Boot Certificate updates: Guidance for IT professionals and organizations
• KB4535680: Security update for Secure Boot DBX: January 12, 2021
• KB5012170: Security update for Secure Boot DBX