Microsoft has released a critical set of guidelines for OEMs and ODMs managing Secure Boot keys, warning that an impending certificate authority expiry could block security updates to millions of Windows devices in the field. The guidance, published August 6, 2025, under KB 5066426, couples detailed key management requirements with an urgent call to action: adopt a new Key Exchange Key (KEK) Certificate Authority (CA) before the legacy 2011 CA expires, or risk cutting off devices from vital DB/DBX updates. This isn't a theoretical concern—a missing or expired KEK prevents platforms from validating database updates, stopping security patches and revocations in their tracks.

At its core, Secure Boot relies on a Public Key Infrastructure (PKI) model with four logical firmware stores: Platform Key (PK), Key Exchange Keys (KEK), the authorized signature database (DB), and the forbidden signature database (DBX). The PK establishes platform ownership, moving firmware from setup mode to user mode. KEKs authorize updates to the signature databases, while DB holds allowed signatures and DBX lists revoked items like vulnerable firmware hashes or compromised certificates. The entire chain begins with a PK public key embedded in firmware; private keys used for signing must be guarded with extreme care to prevent supply-chain compromise. Microsoft’s new guidance reinforces these fundamentals but goes much further, providing prescriptive, actionable steps for key generation, storage, and manufacturing workflows.

What’s New in Microsoft’s Guidance

The most time-sensitive element is the KEK CA rollover. Microsoft’s 2011 KEK CA is set to expire, and OEMs must integrate a new 2023 CA into their firmware to let in-market devices continue receiving authoritative DB/DBX updates. Without this, devices will silently reject future signed revocation lists and allowlists, leaving them blind to critical boot-level threats. Microsoft has published the new CA and accompanying test collateral, urging OEMs to start the transition immediately.

Beyond the rollover, the guidance lays out strict recommendations for key types and algorithms. Platform Keys should use RSA with a 2048-bit modulus and SHA-256 signatures, preferably as EFI_CERT_X509_GUID formatted certificates. The legacy EFI_CERT_RSA2048_GUID format is allowed only in storage-constrained scenarios. KEK, DB, and DBX entries must employ X.509 certificates and Authenticode signing compatible with UEFI variable authentication. These choices balance cryptographic strength with broad ecosystem compatibility.

Microsoft also introduces an option for OEMs to offload PK management entirely. By using a Microsoft-managed PK protected within Microsoft’s HSMs, manufacturers can reduce the operational burden of safeguarding a production root key—a task that requires physical security, dual controls, and rigorous auditing. This is especially attractive for smaller ODMs or those lacking in-house HSM infrastructure.

Lifecycle Rules That Manufacturers Must Follow

Key lifecycle management is no longer left to interpretation. Microsoft is explicit: generate private keys inside FIPS-validated HSMs with high-quality entropy, never store plaintext key material on build servers, and enforce multi-person authorization for signing operations. Development and test keys must be kept entirely separate from production keys, with no reuse. Cryptoperiods must be defined, and certificate expiry must be monitored months in advance to schedule rolling updates ahead of deadlines.

The guidance also stresses the importance of revocation preparedness. OEMs need an emergency plan to deploy DBX entries that block compromised firmware without manual intervention across the entire install base. This demands a signing pipeline that is both hardened and auditable, with immutable logs tracking every operation.

UEFI variable management further complicates the picture. In setup mode, a new PK can be written without the existing private key; in user mode, all updates must be signed by the current PKpriv. Microsoft warns that using production PKpriv to programmatically reset a device into setup mode is a dangerous practice that could be abused by attackers.

Manufacturing and Testing Best Practices

The guidance translates into concrete manufacturing checklists. Signing HSMs must be housed in physically secure facilities with tamper detection and environmental monitoring. Automated signing workflows should require multi-factor authentication and multi-person approval for sensitive operations. Every signing event must be logged in an immutable audit trail.

Testing is equally critical. OEMs must validate SetVariable behavior and Secure Boot mode transitions on exact SKUs and firmware revisions that will ship. KEK rollover and DB/DBX update acceptance must be tested with real packages. Negative tests—ensuring DBX entries block known-bad images and checking remediation when KEKs or PKs are removed—are mandatory. Microsoft supplies EDK II-formatted reference binaries for PK/KEK/DB/DBX payloads, reducing integration errors but demanding validation against target firmware.

The KEK CA Transition: What OEMs Must Do Now

The clock is ticking. To keep devices receiving updates, OEMs must:

  • Inventory all affected SKUs that rely on the 2011 Microsoft KEK CA.
  • Generate signed KEK update packages that introduce the 2023 CA, following Microsoft’s signing process.
  • Test rollover on real devices to ensure DB/DBX updates are accepted afterward.
  • Submit updates to Microsoft via their official channel and using provided test collateral.
  • Plan a staged rollout with telemetry and rollback options to minimize customer impact.

A botched rollover is catastrophic. Incorrectly signed payloads can prevent devices from accepting any further updates, potentially requiring in-person servicing to recover. Microsoft’s guidance doesn’t sugarcoat the risks: mis-managed PK or KEK changes can leave devices in a state where not even the manufacturer can easily restore them.

Risks, Pitfalls, and Mitigations

Key compromise remains the nightmare scenario. If a private signing key leaks, attackers can sign malicious boot components that firmware will trust implicitly—granting pre-boot persistence and near-perfect stealth. Mitigations include hardware-backed HSMs with strict access controls, rapid key rotation, and DBX entries to blacklist compromised signatures.

Supply-chain diversity adds another layer of complexity. UEFI firmware implementations vary across vendors; a provisioning script that works on one SKU may fail on another. Microsoft recommends device-specific testing and maintaining detailed provisioning recipes. Additionally, national security policies may require keys to be generated within specific countries, adding compliance burdens that OEMs must address during platform design.

For enterprises, the guidance raises strategic questions. Organizations need to know if devices use OEM-managed keys, Microsoft’s managed PK, or customer-replaceable PKs—each choice affects their ability to enforce internal allowlists or run in Custom Mode. The decision impacts long-term firmware security posture.

The Bottom Line

Microsoft’s Secure Boot key creation and management guidance is a landmark operational document that turns abstract security concepts into auditable requirements. It mandates RSA-2048/SHA-256 certificates, HSM-backed key generation, dual-control signing, and rigorous testing. But the most pressing message is the KEK CA rollover deadline. OEMs that delay risk stranding devices without the ability to receive boot-level security fixes—a failure that could expose users to persistent, undetectable threats. The path forward is clear: inventory affected systems, adopt the new CA, test exhaustively, and submit updates before the legacy CA expires. Ignoring this call is not an option for any manufacturer committed to keeping Windows devices secure.