Microsoft Secure Boot Key Guidance: KEK CA Rollover and OEM Best Practices

Microsoft’s new guidance for Secure Boot key creation and management sharpens the playbook OEMs and ODMs must follow to keep Windows devices secure at scale, and it arrives with concrete, time-sensitive actions: recommended key types and sizes, explicit lifecycle controls, and an urgent rolling plan for a Microsoft KEK CA rollover that affects in-market devices. The guidance — published as a Microsoft Support article and expanded on Microsoft’s Windows hardware documentation — is aimed squarely at manufacturers and firmware teams responsible for provisioning Secure Boot keys during device manufacturing, and it ties Secure Boot key management to hardware security modules (HSMs), PKI best practices, and a predictable update path for certificate rollovers that can otherwise break signature-based update flows.

Background​

UEFI Secure Boot is the pre-OS enforcement mechanism that uses a Public Key Infrastructure (PKI) model to ensure only trusted firmware and boot components execute during platform initialization. Its architecture centers on four logical stores maintained by platform firmware:

• PK (Platform Key) — establishes platform owner control and moves the firmware from setup mode into user mode.
• KEK (Key Exchange Keys) — authorize updates to the signature databases.
• DB (authorized database) — holds allowed signatures and certificates.
• DBX (forbidden database) — holds revoked items, vulnerable firmware hashes, and compromised certificates.

The platform’s root of trust begins with the PK public key embedded in firmware; private keys used to sign firmware and update packages must be protected to prevent massive exposure in the supply chain. Microsoft’s guidance reiterates these fundamentals while providing specific, actionable recommendations for key generation, format, storage, and manufacturing workflows — all intended to reduce the risk of pre-boot compromise and to ensure updates continue to flow to devices in the field.

---

What Microsoft’s Guidance Introduces​

Key practical takeaways​

• Microsoft recommends key objects be created and stored following the UEFI model (PK, KEK, DB, DBX), using signed X.509 certificates formatted for EDK II when appropriate.
• Platform Keys should generally use RSA with a 2048-bit modulus and SHA-256 signatures; Microsoft specifies EFI_CERT_X509_GUID with algorithm RSA-2048 and sha256RSA as the signature algorithm, reserving EFI_CERT_RSA2048_GUID only for constrained storage scenarios.
• Microsoft offers an option for OEMs to use a Microsoft-managed PK, protected within Microsoft-managed HSMs, to relieve OEMs of the operational burden of protecting production PK private keys.
• Microsoft has made available recommended PK/KEK/DB/DBX binaries in a Microsoft open-source repository formatted to EDK II, intended to simplify firmware integration and reduce errors in variable payload formatting.
• There is a time-sensitive CA rollover: the Microsoft KEK CA from 2011 is scheduled to expire, and OEMs must create, sign, and submit updates for a new Microsoft KEK CA (noted as a 2023 CA) so in-market devices can continue to receive DB/DBX updates after the older CA expires.

Why this matters now​

The expiration of embedded certificate authorities and KEK roots is not a theoretical problem — an expired or absent KEK prevents platforms from validating database updates, which in turn stops security patches and revocations from reaching devices. The guidance therefore couples technical key recommendations with a lifecycle and transition plan: create, test, and submit KEK updates ahead of expiration windows so that signed updates will be accepted by devices already shipped.

---

Technical Highlights and Recommendations​

Recommended key types and algorithms​

Microsoft’s guidance is prescriptive about formats and algorithms used in production keys:

• Platform Keys (PK): Prefer EFI_CERT_X509_GUID with RSA-2048 public keys and SHA256 signatures (sha256RSA). If firmware storage is tight, EFI_CERT_RSA2048_GUID is permissible.
• KEK, DB, DBX entries: Use appropriately formatted X.509 certificates and Authenticode signing for Windows components. Signatures must be compatible with UEFI variable authentication formats and the firmware’s supported signature algorithms.

These recommendations align with common industry practices for balancing cryptographic strength and compatibility across devices in the Windows ecosystem.

Key lifecycle rules OEMs must follow​

• Generation: Generate private keys in a secure cryptographic module — an HSM that supports FIPS-level protections is strongly recommended. Keys must be generated with high-quality entropy and inside a hardened boundary.
• Storage: Private keys must never be stored in plaintext on general-purpose servers or build machines. Use HSM-backed key usage so signing operations occur within the HSM and private key material never leaves the secure module.
• Access control and dual control: Limit access to key material to a small number of vetted personnel. Implement multi-person approval and dual-control for critical operations such as key export or signing for production images.
• Testing vs. production keys: Use distinct keys for development and test signing, and reserve production keys for signing releases only. Avoid reuse of test keys in production firmware.
• Rotation and expiry: Define cryptoperiods and key rotation plans. Monitor certificate expiry dates and schedule rolling updates months ahead of expiration windows.
• Revocation and emergency response: Have an emergency remediation plan that can roll out DBX entries to block compromised firmware without relying on manual interventions across the install base.

UEFI variable management (setup mode vs. user mode)​

Firmware enforces different rules depending on whether a platform is in setup mode (Secure Boot disabled/configurable) or user mode (Secure Boot active). Key operations have to be signed appropriately:

• If firmware is in setup mode, new PK values may be written without being signed by the existing PKpriv.
• If firmware is in user mode, PK updates must be authenticated by the current PKpriv.
• Clearing the PK variable in user mode requires a signature with the current PKpriv.

Microsoft explicitly warns against using production PKpriv for programmatically resetting platforms because doing so can be misused to place a device into setup mode — a scenario best avoided in production.

---

Manufacturing Best Practices​

Build a hardened, auditable signing pipeline​

• House signing HSMs in a physically secure facility with tamper detection, environmental monitoring, and strict visitor controls.
• Automate signing workflows where possible but require multi-factor and multi-person authorization for sensitive signing operations.
• Keep a comprehensive, immutable audit trail for all signing operations: who requested a signature, who authorized it, which firmware binaries were signed, and the HSM operation logs.

Test both key enrollment and update flows on real firmware​

• Validate the SetVariable() behavior and variable attributes on target firmware versions. Some vendors implement firmware behavior differently; test on the exact SKUs and firmware revisions planned for shipping.
• Test KEK rollover and DB/DBX update acceptance using actual update packages and firmware that reflects final manufacturing BIOS/UEFI builds.
• Perform negative tests: ensure DBX entries block known-bad images and that removing expected KEKs or PKs yields the anticipated remediation behavior.

Use the Microsoft-provided artifacts if appropriate​

Microsoft supplies PK/KEK/DB/DBX reference binaries formatted for EDK II to reduce mistakes in formatting secure-boot payloads. Using these vetted artifacts can lower the risk of incompatibilities during firmware integration.

---

Key Management and HSM Guidance (Best-Practices)​

Adopt proven enterprise cryptographic key management controls when provisioning Secure Boot keys:

• Use certified HSMs: Prefer FIPS 140-2/140-3 validated hardware security modules for generating, storing, and using private keys. HSMs should enforce role separation, dual authorization, and tamper evidence.
• Protect key backups: If a private key must be backed up, store encrypted backups in separate secure vaults with equivalent protections (key-wrapping keys in HSMs).
• Audit and monitoring: Centralize HSM audit logs and integrate them with SIEM for anomaly detection and long-term retention.
• Key rotation policies: Define cryptoperiods and rotate keys before end-of-life, and test the replacement process in a staging environment.
• Separation of duties: Ensure the personnel who have access to manufacturing signing systems are distinct from those who perform firmware development and QA.

These practices are consistent with established key management frameworks and civil/commercial cybersecurity guidance for protecting high-value asymmetric keys.

---

The KEK CA Transition: What OEMs Must Do Now​

Microsoft’s guidance identifies a near-term operational requirement: the existing Microsoft KEK CA (a 2011 CA) is slated to expire, and Microsoft has published an updated CA (denoted by Microsoft as a 2023 CA) that OEMs must adopt to allow in-market devices to continue receiving authoritative DB/DBX updates.
Key actions for OEMs and ODMs:

• Inventory affected SKUs — identify all device models that rely on Microsoft KEK CA 2011 for DB/DBX updates.
• Generate signed KEK update packages — create the update payloads signed under the OEM or Microsoft-recommended signing process that introduce the new KEK CA to firmware.
• Test rollover on real devices — verify that devices accept DB/DBX updates after the KEK change and that no legitimate updates are rejected.
• Submit updates to Microsoft — follow Microsoft’s submission process for KEK updates and use their test collateral to validate behavior.
• Plan rollout timeline — schedule staged rollouts with telemetry and rollback plans to minimize customer impact.

Failure to perform these steps can leave devices unable to accept signed revocation lists and allowlists, blocking security fixes from being deployed via the expected channel.
Cautionary note: KEK/PK rollovers are a high-risk operation. Mis-signed or incorrect payloads can prevent devices from accepting subsequent updates, lead to loss of update capability, or even require in-person servicing to recover.

---

Practical Checklist for OEMs and Firmware Teams​

• Inventory all systems that will use custom PK/KEK/DB/DBX provisioning.
• Choose whether to:
• Manage PK and KEK in-house with your own HSMs and key management program; or
• Use the Microsoft-managed PK to reduce operational burden.
• If managing keys in-house:
• Generate keys inside FIPS-certified HSMs.
• Implement dual-control signing workflows and multi-person approval for exports.
• Maintain immutable signing logs and regular audits.
• Build separate test and production keysets. Never use test keys in production images.
• Integrate Microsoft-supplied EDK II-formatted binaries as a canonical reference for DB/DBX/KEK packages to reduce formatting errors.
• Validate SetVariable() behavior and Secure Boot mode transitions on target firmware.
• Prepare and test KEK CA rollover packages well before CA expiry dates.
• Schedule staged rollout and telemetry collection to monitor acceptance of DB/DBX updates.
• Maintain an emergency response playbook for compromised keys that includes DBX revocation procedures and comms plans.
• Review and conform to Windows Hardware Certification Requirements where applicable.

---

Risks, Pitfalls, and Mitigations​

Key compromise is catastrophic​

If a private key used to sign images or update packages is compromised, attackers can sign malicious boot components that firmware will accept. The consequence is pre-boot persistence and potentially perfect stealth for malware.
Mitigations:

• Use HSMs with strict physical and logical controls.
• Rotate and revoke keys quickly and provision DBX entries to blacklist compromised signatures.
• Limit the scope of any given key (don’t reuse keys for multiple purposes).

Replacing PK/KEK can brick or fragment device fleets​

Replacing or removing Microsoft or vendor keys without a carefully managed plan can result in devices that no longer accept legitimate firmware or driver updates — or worse, become difficult to recover without manufacturer support.
Mitigations:

• Test replacement flows on representative hardware.
• Provide a clear recovery path (e.g., hardware-based factory reset that re-enters setup mode) and document it.
• Avoid removing Microsoft-managed keys unless absolutely necessary.

CA expiration and in-market updates​

If CA rollover is not completed before expiry, DB/DBX updates can be denied by firmware, blocking critical revocations and fixes.
Mitigations:

• Treat certificate expiry as a project milestone requiring months of lead time.
• Use Microsoft’s provided KEK update packages and test collateral when applicable.
• Coordinate with Microsoft early in the lifecycle when submitting KEK update packages.

Supply chain and firmware vendor differences​

Some OEMs and firmware vendors have device-specific behaviors and limitations. UEFI variable APIs may behave differently across vendors, so a one-size-fits-all provisioning script may fail on some SKUs.
Mitigations:

• Test on all target SKUs and firmware versions.
• Maintain device-specific provisioning recipes and document exceptions.

---

Policy and Compliance Considerations​

Secure Boot key provisioning intersects with national and enterprise requirements for shipping devices to government customers, export compliance, and national security policies. Some agencies require that keys be generated in-country or under specific controls. OEMs should map these requirements during platform design and manufacturing planning.
Enterprises buying devices should also understand whether devices use OEM-managed keys, Microsoft-managed PK, or customer-replaceable PKs — and the implications this has for their ability to enforce internal allowlists or run in Custom Mode.

---

Conclusion​

Microsoft’s Secure Boot key creation and management guidance is a practical, operationally focused resource that turns abstract Secure Boot concepts into concrete, auditable requirements for manufacturers. It balances cryptographic best practice — RSA-2048 / SHA-256 certificates, HSM-based key generation, and strict lifecycle controls — with pragmatic steps for ensuring in-market devices continue to receive critical database updates during CA rollovers.
For any organization responsible for provisioning Secure Boot keys, the guidance underscores three immutable priorities: protect private keys with hardware-backed controls, test firmware behavior across real device SKUs, and plan certificate transitions well ahead of expiry windows. The cost of neglect — from blocked updates to pre-boot compromise — is too high to accept slippage. OEMs and firmware teams that follow the checklist and operational rigor described in Microsoft’s guidance will significantly reduce systemic risk and keep devices able to receive the revocations and allowlist updates that Secure Boot depends on.

---

Source: Microsoft Support Windows Secure Boot Key Creation and Management Guidance - Microsoft Support