The Certificate Nobody Checked

The Certificate Nobody Checked

Secure Boot's Fifteen-Year Blind Spot

How an Expiring Certificate Exposed an Industry

Section 1 — Introduction: The Clock Nobody Watched

Every X.509 certificate carries two dates. Not Before — the date from which it is valid. Not After — the date after which it is not. These are not metadata. They are not advisory fields. They are cryptographic validity constraints baked into the certificate structure at the moment of issuance, readable by any tool that can parse ASN.1. They do not drift. They do not require interpretation. They are simply there — in plain text, permanently, from day one.

The three Microsoft Secure Boot certificate authorities that anchor the boot trust chain of every Windows system manufactured since 2012 were issued in 2011. They were given fifteen-year lifespans. Their Not After dates have been visible, embedded in the firmware of every affected machine, since the day those machines shipped from the factory.

Nobody checked.

More precisely: the people and organisations best positioned to catch this — Microsoft's own engineering teams, firmware engineers at HPE, Dell, and other OEMs, VMware's virtualisation architects, enterprise IT governance teams — had access to this information for over a decade. The certificates are in the firmware. The firmware ships on every server. The dates are in the certificates.

Microsoft's first public announcement that named the expiry, gave a specific deadline, and provided actionable guidance for enterprise administrators was published on February 13, 2024 — twenty-eight months before the first certificate expires. The alarm bell blog post — titled "Act Now: Secure Boot Certificates Expire in June 2026" — arrived on January 14, 2026. That is five months before the deadline. Broadcom's first VMware-specific advisory appeared in January 2026. HPE's BIOS updates for servers manufactured between 2018 and 2021 landed in December 2025. For hardware manufactured before 2017: no BIOS update. Not late. Not delayed. Simply never.

This paper is not primarily about remediation. The playbooks exist. The registry keys are documented. The PowerShell scripts run. For most supported hardware on current firmware with Windows Update enabled, the update path is clear. The paper is about something the playbooks do not address: why engineers are dealing with this now, at this level of urgency, with this degree of complexity — when the expiry date was known, in the firmware, for fifteen years.

What Happened and Why It Matters

The core technical fact that explains everything is this: UEFI firmware, by design, does not check certificate expiry dates during Secure Boot validation. This is not an oversight. It is an explicit decision written into the UEFI specification, documented by Linux kernel maintainer James Bottomley in his canonical 2012 reference paper "The Meaning of all the UEFI Keys." The reasoning is sound: the hardware clock may not be reliable at boot time, and requiring a valid timestamp would create a trivial denial-of-service vector — set the clock wrong and the machine stops booting.

The consequence of this design decision is profound. The certificates could expire on the calendar without a single machine failing to boot. Existing signed binaries — Windows bootloaders, shims, option ROMs — remain trusted indefinitely on systems that have those certs in their firmware database. The expiry is not a boot failure. It is a signing pipeline freeze. After expiry, Microsoft cannot sign new boot binaries with the 2011 keys. New DBX revocations cannot be authorised without the new KEK. New third-party UEFI components signed only with the 2023 CA will not be trusted on systems that only hold the 2011 CA.

The degradation is silent, cumulative, and invisible until the moment something breaks that cannot be fixed without the new certificates. A system running 2011 certificates looks and operates identically to one running 2023 certificates — until it encounters a boot component signed exclusively with the 2023 CA, or until a new DBX revocation needs to be pushed, or until a new BlackLotus mitigation needs to be applied. At that point, the gap becomes visible. Remediation at that point is significantly more complex than it would have been under a planned transition.

BlackLotus changed the calculus. The bootkit discovered in 2022 and weaponised through 2023 (CVE-2022-21894, CVE-2023-24932) exploited vulnerabilities in the Windows boot manager that could not be fully mitigated without revoking the old signing chain. To revoke the old signing chain — to push the new DBX entries that block all previously vulnerable boot managers — Microsoft needed the new 2023 certificates already trusted in the firmware. BlackLotus turned a planned long-term certificate lifecycle transition into an emergency security remediation. That collision of timelines is why the industry landed in the position it is in now.

The VMware Dimension

For organisations running VMware vSphere — still the majority of enterprise virtualisation estates worldwide — the certificate expiry compounds into a structurally harder problem. Virtual machines do not have physical UEFI chips. Each VM carries a virtual NVRAM file on the datastore, seeded from the ESXi host's internal firmware template at the time the VM was created. VMs created before ESXi 8.0.2 carry 2011 certificates in that virtual NVRAM and have no automated update path.

The problem is further compounded by a Broadcom architectural decision: VMs created before ESXi 9.0 have a NULL Platform Key in their virtual NVRAM by default. The PK is the root of the Secure Boot key hierarchy — without a valid PK, the KEK cannot be updated, which means DB and DBX cannot be updated, which means the Windows certificate update task fails. Broadcom's current official position, as of their March 2026 advisory KB 423893, is explicit: "There is no automated resolution available at this time."

⚠️ BROADCOM ADVISORY STATUS

KB 421593 — the NVRAM rename/bypass procedure Broadcom previously published — has been removed without replacement. KB 423893 (March 2026) is the current official position. It states no automated fix exists for the NULL PK issue on pre-ESXi 9.0 VMs. A community-documented workaround using uefi.allowAuthBypass = "TRUE" exists and functions technically, but is explicitly unsupported by Broadcom. Engineers should verify current Broadcom guidance before proceeding with any ESXi 7.x or pre-9.0 remediation.

The Hardware Abandonment Problem

Hardware support cutoffs create a permanent class of systems that cannot be fully remediated. HPE ProLiant Gen9 servers — released between 2014 and 2019 and still widely deployed in enterprise environments — will receive no BIOS update for this transition. HPE's support policy sets the cutoff at hardware released before 2017/2018. A Gen9 server running ESXi 7.x, itself end-of-life, with VMs created years ago, faces the complete intersection of every problem this paper documents: no firmware support, no hypervisor support, no automated remediation path, and no official guidance from any of the three vendors involved.

Dell is in an equivalent position for 12th and 13th generation PowerEdge servers. The common thread across all OEM cutoffs: hardware that is still within its useful operational life, still running production workloads, still fully functional in every other dimension, has been placed outside the scope of this specific security update — without meaningful advance notice that this would happen.

What This Paper Does

This paper explains the Secure Boot 2026 certificate expiry from the ground up — technically, chronologically, and without vendor-neutral hedging. It covers:

• How Secure Boot actually works — the full PK → KEK → DB → DBX trust chain, in the detail required to understand why anything else in this story matters
• Why UEFI ignores certificate expiry — the deliberate design decision and its consequences
• Three distinct problems — not one — that the industry is conflating into a single event
• The Linux angle — shim, MOK, SBAT, and the 2022 CentOS incident that was not cert expiry but gets confused with it
• BlackLotus — the catalyst that turned a lifecycle event into an emergency
• The disclosure timeline — dated, sourced, named
• Hardware abandonment — what it means when the firmware update never ships
• The VMware compound problem — NULL PK, ESXi 7 EOL, and Broadcom's withdrawn guidance
• What breaks, what doesn't, what is permanently frozen
• What engineers should actually do — technical action plan, not marketing guidance

💡 KEY POINT

This paper is not a tutorial. The Microsoft playbooks, HPE SPP guides, and Broadcom KB articles exist and are linked throughout. This paper explains what those documents assume you already know — and documents the ecosystem failures that made this harder than it needed to be.

Scope and Audience

This paper is written for platform engineers and system engineers responsible for Windows Server infrastructure, VMware vSphere estates, and the intersection of the two. It assumes working familiarity with Windows Server administration, VMware ESXi, and basic PKI concepts. It does not assume prior knowledge of UEFI internals, the Secure Boot key hierarchy, or the Linux shim bootloader chain — those are explained from first principles in Section 2, because without them, the rest of the story does not make sense.

Sections 2 through 5 are technical foundations. Sections 6 through 9 are the investigative and contextual record. Sections 10, 11 and 12 are operational. Section 13 is a conclusion that names the parties involved and states what the evidence shows about how the ecosystem handled — or failed to handle — a known deadline. Engineers can draw their own conclusions about the implications.

Sources — Section 1

Section 2 — How Secure Boot Actually Works

Most engineers have a surface-level understanding of Secure Boot: the firmware checks that the bootloader is signed, and if it is not, the machine refuses to start. That mental model is correct enough for day-to-day operations, and wrong enough to be dangerous when something breaks or needs to change. The 2026 certificate expiry is precisely the kind of situation where the surface model fails. To understand why remediation is complex on VMware, why Gen9 is a dead end, why the Windows update task silently fails without the right firmware prerequisite — you need the full picture. This section provides it.

The canonical reference is James Bottomley's July 2012 blog post "The Meaning of all the UEFI Keys" — still the most precise publicly available explanation of the UEFI key hierarchy fourteen years after it was written. This section draws directly from that reference and from the UEFI specification it documents.

Where the Certificates Actually Live

A Secure Boot certificate is not a file on a disk. This is the first thing to understand, and the most commonly misunderstood. There is no folder on your server. No certificate store in the file system. No network share. The certificates live in a dedicated hardware chip soldered onto the motherboard — the UEFI firmware chip, sometimes called the SPI flash ROM.

That chip contains two logically distinct regions. The first is the UEFI firmware code itself — the modern equivalent of what BIOS was, responsible for initialising hardware, running POST, and handing control to the bootloader. The second is a protected region called NVRAM — Non-Volatile RAM — which stores the Secure Boot variables. These variables persist across power cycles. They survive OS reinstalls. They survive disk replacements. They are bound to the physical motherboard.

The UEFI specification defines four Secure Boot variables stored in NVRAM, each with a specific role in the trust hierarchy. Understanding what each one is, who owns it, and what it authorises is the prerequisite for understanding everything else in this paper. As Bottomley documented in 2012: "the holder of the platform key is essentially the owner of the platform."

The Four Key Stores

PK — The Platform Key

The Platform Key is the root of trust. There is exactly one PK per system, stored in the PK NVRAM variable. The PK is owned by the hardware manufacturer — HPE, Dell, Lenovo, or whichever OEM built the server. On HPE ProLiant servers, HPE's private key signs the PK, and only HPE-signed firmware can change it.

The PK's job is narrow but absolute: it controls who can update the PK variable itself and who can update the KEK variable. Nothing else. The PK cannot be used to sign binaries for execution. It is purely the master lock — the certificate of certificates.

When a platform is in Setup Mode — which occurs when the PK variable is empty — the system operates without Secure Boot enforcement. Secure variables can be written without authentication. When a valid PK is enrolled and the system is in User Mode, every attempt to modify the PK or KEK must be signed with the PK private key. Nobody but HPE holds that key for an HPE server. This is why updating the PK requires a firmware update — a BIOS flash signed by HPE's hardware root of trust — not a software operation.

💡 KEY POINT

On VMware ESXi VMs created before version 9.0, the PK variable in the virtual NVRAM is a NULL signature — a placeholder, not a real key. NULL PK = no owner = no authority to authorise KEK changes = Windows update task fails at the KEK step. This is the root cause of the NULL PK problem documented in Broadcom KB 423893.

KEK — The Key Exchange Key

The Key Exchange Key is stored in the KEK variable. It can contain multiple keys. Microsoft holds the KEK on Windows systems — the Microsoft Corporation KEK CA 2011 is the certificate that has been in this variable on every Windows-compatible system shipped since 2012, and it is one of the three certificates expiring in 2026.

The KEK's role is to authorise updates to DB and DBX. Any entity holding a KEK certificate can push new entries into those databases. Microsoft uses its KEK to deploy new allowed certificates via Windows Update (DB updates) and to push new revocations of compromised or vulnerable boot components (DBX updates). Without a valid KEK that the firmware trusts, neither of those operations can succeed.

The KEK variable can only be updated by an authentication descriptor signed with the Platform Key. This is the chain: HPE's PK authorises KEK changes. Microsoft's KEK authorises DB and DBX changes. If the PK is NULL, the KEK cannot be updated. If the KEK is expired and the new KEK is not present, the DB and DBX cannot be updated. Each level gates the one above it.

DB — The Signature Database

The Signature Database, stored in the db variable, contains the certificates and hashes of what is permitted to execute during the pre-OS boot sequence. This is where the Microsoft UEFI CA certificates live — both the 2011 certificates that are expiring and the 2023 replacements.

The DB validation logic, per the UEFI specification, works as follows during boot: for each EFI binary the firmware is asked to load, it checks whether the binary is signed and whether the signing key is in the DB (and not revoked by the DBX). The image executes if either a hash of the binary matches an entry in the DB, or the image is signed with a key whose certificate is in the DB. The check does not go to the internet. It does not contact a certificate authority. It compares against the local NVRAM contents, entirely offline.

The DB has two distinct states on a physical server: the Default DB — the factory-provisioned contents baked into the firmware image by the OEM — and the Active DB — the running state, which may have been augmented by Windows Update or manual operations. A BIOS reset to factory defaults wipes the Active DB back to the Default DB. If the firmware image itself (the Default DB) only contains 2011 certs, a BIOS reset undoes any 2023 cert updates that were applied at the OS level. This is why firmware updates are not optional for hardware that needs to survive a BIOS reset.

DBX — The Forbidden Signatures Database

The Forbidden Signatures Database, stored in the dbx variable, is the revocation list. It contains certificates, signatures, and hashes of binaries that are explicitly blocked from executing — even if those binaries were previously trusted. A match against the DBX overrides a match in the DB. Revoked wins.

The DBX is the mechanism by which Microsoft responds to discovered vulnerabilities in boot components. When a bootloader is found to have a security flaw, Microsoft adds its hash or signing certificate to the DBX and pushes that update via Windows Update. Every system with a valid KEK receives the update. Systems without a valid KEK — or with an expired KEK that the firmware no longer trusts to authorise DB/DBX writes — are frozen. They cannot receive the revocation.

This is the concrete security consequence of the certificate expiry. It is not that the machine stops booting. It is that the machine becomes permanently frozen at its current revocation state. Any bootloader vulnerability discovered after expiry cannot be blocked. The machine keeps working. The security posture degrades silently, with every new threat that the DBX cannot receive.

The Hierarchy in Sequence

The firmware validates any EFI binary as follows: check if the binary's hash or signing key is in the DBX — if yes, execution is refused. If not in DBX, check if a signing key or hash is in DB — if yes, execution is permitted. If neither, execution is refused. The entire check happens locally, against NVRAM contents, at every boot. The UEFI clock is never consulted. Certificate validity dates are never evaluated.

The Design Decision: UEFI Ignores Certificate Expiry

This is the central technical fact that makes the 2026 story possible. The UEFI specification explicitly states that firmware must not check the validity period of certificates during Secure Boot validation. James Bottomley documented this in 2012: the BIOS clock may not be reliable at boot time, and enforcing timestamp validity would create a trivial denial-of-service vector — adjust the clock, reboot, and the machine refuses to start. The specification therefore requires that firmware treat all enrolled certificates as perpetually valid, regardless of their Not After date.

Rocky Linux confirmed this behaviour independently in their April 2024 Secure Boot key refresh announcement: "Due to nuances in how Secure Boot chain validation is implemented, the expiration of certificates is not taken into account when determining whether or not to trust a particular artifact — as there is no reliable clock available at the time of validation."

ℹ️ WHAT THIS MEANS IN PRACTICE

A Windows Server running exclusively on 2011 certificates will continue booting after June 2026 without modification. Existing signed binaries — the Windows bootloader, the shim, option ROMs — remain trusted indefinitely on systems that have those certificates enrolled. The expiry does not disable Secure Boot. It does not brick machines. It freezes the signing pipeline and the update pipeline — Microsoft cannot sign new components with expired keys, and the firmware cannot accept new DB/DBX updates without a valid KEK.

Setup Mode vs User Mode

The UEFI specification defines two operating modes. In Setup Mode, the PK variable is empty, Secure Boot is disabled, and secure variables can be written freely without any authentication descriptor. This is the state of a freshly manufactured server before OEM provisioning, or after a BIOS reset that clears the PK.

In User Mode, a valid PK is enrolled, and every attempt to modify PK or KEK requires an authentication descriptor signed by the PK private key. Updates to DB and DBX require a descriptor signed by a KEK key. The firmware will silently reject any NVRAM write whose authentication descriptor does not validate against the enrolled keys.

The authentication descriptor carries either a time-based or monotonic counter-based replay prevention value. Once a variable has been created with one type, it only accepts updates of the same type with a higher counter or later timestamp — preventing an attacker from replaying a captured valid update.

The Active DB vs Default DB Distinction

Every server has two cert databases that matter for this transition: the Default DB, baked into the firmware image by the OEM and representing factory state, and the Active DB, the running state in NVRAM which may be augmented by Windows Update.

When the firmware is reset to factory defaults — deliberately, or through a failed firmware update — the Active DB is overwritten from the Default DB. If the firmware image only contains 2011 certificates, the 2023 certificates that Windows Update pushed into the Active DB are gone. The system reverts to an unremediated state.

This is why a BIOS update that embeds the 2023 certificates into the firmware image itself is not optional for hardware that needs durable remediation. For Gen9 hardware, no such BIOS update exists. Any OS-level Active DB update on a Gen9 server is fragile — one BIOS reset reverts it.

What Happens at Boot — The Full Sequence

For a Windows Server booting on a physical HPE ProLiant with Secure Boot enabled, the trust chain executes as follows on every power-on:

1. POST — the CPU executes code from the SPI flash ROM. The hardware initialises.
2. UEFI firmware loads — reads NVRAM, finds the PK variable populated, enters User Mode. Secure Boot is active.
3. Boot device scan — firmware locates the EFI System Partition on the configured boot device.
4. Bootloader validation — firmware reads bootmgfw.efi. Checks its signature against the DB. Checks its hash against the DBX. DB match + no DBX match = execute.
5. Boot Manager validates BCD — loads the BCD store, selects the OS loader.
6. OS loader validation — winload.efi is validated by the Boot Manager using Secure Boot policy.
7. Kernel loads — Windows Trusted Boot takes over from this point, outside UEFI's scope.

At no point in this sequence does the firmware check the Not After date of any certificate.

The Signing Pipeline — Where Expiry Actually Matters

The expiry constraint is not on the firmware's verification logic. It is on Microsoft's ability to sign new content with the 2011 private keys. Once the certificate expires, by industry standard and Microsoft policy, the private key is retired. Microsoft will not use an expired certificate to sign new software.

After June 2026, Microsoft can no longer sign new boot manager updates with the Windows Production PCA 2011 private key. Any future Windows Boot Manager security patch — including mitigations for newly discovered bootkits — will be signed exclusively with the Windows UEFI CA 2023 key. A system whose DB contains only the 2011 CA will not trust that new binary. The boot manager cannot be updated. The DBX cannot be extended. The security posture is frozen.

Not a boot failure. A security freeze.

The Certificate Map: What Replaces What

Microsoft did not perform a simple one-for-one renewal. They split the single UEFI CA 2011 into two separate 2023 certificates, allowing finer-grained trust control going forward.

The UEFI CA split matters for organisations with discrete GPUs, hardware NICs, or RAID controllers. A system that updates for Windows boot continuity but does not enrol the Option ROM UEFI CA 2023 will be unable to trust future GPU firmware, NIC PXE ROM, and RAID controller EFI driver updates released after June 2026. Both 2023 CAs are enrolled together by the standard Windows remediation process (AvailableUpdates = 0x5944).

Why the PK Cannot Be Updated by Software

A question that arises when engineers first encounter the NULL PK problem on VMware VMs: why not just write a new PK from inside the guest OS? The PK variable can only be updated by an authentication descriptor signed by the current PK private key. On a physical server, that private key is held exclusively by the OEM. If software running inside an OS could replace the root of trust, Secure Boot would be meaningless.

On a VMware VM, ESXi is the effective OEM. But VMs created before ESXi 9.0 were provisioned with a NULL PK — a placeholder with no associated private key. There is no key to sign an update descriptor with. The variable cannot be updated through normal UEFI channels from inside the VM.

The uefi.allowAuthBypass = "TRUE" workaround bypasses this constraint by temporarily enabling Setup Mode on the virtual machine, allowing NVRAM writes without authentication. That is why it exists. And that is why Broadcom considers it unsupported: bypassing the authentication model of Secure Boot, even temporarily on a VM, is architecturally what Secure Boot was designed to prevent.

⚠️ THE CHAIN IN THREE SENTENCES

The PK is owned by the OEM. The KEK is owned by Microsoft. The DB and DBX are maintained by Microsoft via the KEK. Break any link in that chain and everything above it silently stops working. A NULL PK breaks the chain at the root. An expired KEK breaks it at the second level. Either way: the Windows update task starts, progresses to the step that requires the broken link, and stops.

Sources — Section 2

Section 3 — The Deliberate Design Decision: UEFI Ignores Expiry

Section 2 stated the fact: UEFI firmware does not check certificate expiry dates during Secure Boot validation. This section examines why that decision was made, why it was correct at the time, what it cost in the long run, and why it is the single design choice that allowed a fifteen-year deadline to remain invisible until five months before it arrived.

The Problem UEFI Was Designed to Solve

To understand why UEFI ignores expiry, you have to understand what Secure Boot was actually for when it was designed. The threat model in 2011 was bootkits — malware that embedded itself into the pre-OS boot process, below the operating system, invisible to antivirus software running in userspace. The goal was simple: ensure that the bootloader had not been tampered with. If the bootloader signature validates, boot. If it does not, refuse.

This is a binary verification problem — valid or invalid — and it does not inherently require time. A signature is either cryptographically sound or it is not. The certificate hierarchy exists to establish who signed the binary, not when. For the specific use case Secure Boot was designed for — detecting binary tampering at boot time — the certificate validity period is irrelevant to the core operation.

The hardware clock problem reinforces this. A server that has been powered off for three months, or a system whose CMOS battery has died, or a machine being provisioned before its clock has been synchronised — all of these will have unreliable clock state at the moment the UEFI firmware runs POST. If certificate validity were enforced at that moment, any of those conditions would produce a boot failure. The fix for a dead CMOS battery would become "the server now refuses to boot." That is an unacceptable operational failure mode for infrastructure that may need to boot unattended, remotely, or after extended downtime.

The denial-of-service vector is equally serious. If valid timestamps were required, an attacker with physical access or the ability to manipulate the hardware clock could set the date forward past any certificate's expiry and force a boot refusal. Secure Boot would become a trivial mechanism for bricking machines. The specification authors recognised this and closed it: no check, no attack surface, no operational dependency on clock accuracy.

ℹ️ BOTTOMLEY, 2012

"The UEFI specs require that no check is done of the expiry or start dates for a secure boot certificate. The reason is that the BIOS clock might not be reliable and boot — and it also blocks a potential DoS vector (tamper with the clock and force a reboot)."

— James Bottomley, "The Meaning of all the UEFI Keys," July 2012

Why This Was the Right Call in 2011

It is tempting, in hindsight, to treat the UEFI-ignores-expiry design as a mistake. It was not. It was the correct engineering trade-off for the stated threat model, the operational constraints, and the technology landscape of 2011.

First, certificate lifetime was expected to be managed by the ecosystem, not enforced by firmware. The UEFI design assumes that OEMs, operating system vendors, and certificate authorities will coordinate certificate renewals well in advance of expiry. The firmware does not need to enforce expiry because the ecosystem will never let a certificate expire without a replacement in place. This is a reasonable assumption for a healthy PKI ecosystem. It proved incorrect for this specific case — but that is a failure of the ecosystem, not the design.

Second, UEFI firmware is not a general-purpose PKI validator. It does not perform full X.509 path validation. It does not download CRLs. It does not do OCSP. It has no network access during POST. It has no reliable clock. Asking it to enforce certificate validity periods would require capabilities it does not have and should not have. Firmware that makes outbound network calls during POST is firmware with a new attack surface. The simplicity of the UEFI validation model — compare signature against local NVRAM, allow or deny — is a security feature, not a limitation.

Third, revocation in UEFI is handled by DBX, not by expiry. The correct mechanism for blocking a compromised certificate is not waiting for it to expire. It is adding it to the revocation database immediately. UEFI has a dedicated, actively maintained revocation mechanism in the DBX. Certificates and binary hashes that should no longer be trusted go there. Expiry is not the right tool for revocation. The DBX is.

The Irony: the Same Decision That Made Secure Boot Robust Made the Expiry Invisible

Because UEFI ignores expiry, the approaching expiry of the 2011 certificates produced no observable symptom. No log entry. No warning. No degraded mode. No amber light. Every machine with 2011 certificates in its firmware database continued to function identically on the day before expiry and on the day after. There was nothing to monitor. Nothing to alert on. Nothing to trigger a review.

Compare this with TLS certificates in a web server. An expired TLS certificate immediately produces a browser warning, then a hard failure. Certificate monitoring tools exist specifically to catch this. Operations teams have runbooks for it. The expiry is visible by design — the protocol checks it, browsers surface it, monitoring catches it. The ecosystem has fifteen years of tooling and process built around TLS cert expiry management precisely because it is visible and consequential.

UEFI Secure Boot has no equivalent visibility. The certificates sit in NVRAM silently, doing their job, until the signing pipeline needs to use the private keys. The expiry is meaningful only at the signing end — when Microsoft's HSM refuses to sign a new binary with an expired certificate — not at the verification end where engineers would have seen it. Nobody monitoring server firmware health had any signal that anything was about to change.

💡 KEY POINT

The design decision created a system where certificate expiry was consequential on the signing side but invisible on the verification side. The engineers responsible for the signing side — Microsoft, OEMs, Broadcom — knew the deadline. The engineers responsible for the verification side — the people running the servers — had no mechanism to know.

What SBAT Tells Us About the Limits of This Design

The Secure Boot Advanced Targeting mechanism — SBAT — is a direct acknowledgement that the UEFI revocation model has limitations. SBAT was introduced in 2020 in response to the Boot Hole vulnerability (CVE-2020-10713) in GRUB2, which affected effectively every Linux distribution using the standard shim chain.

The problem was that revoking every vulnerable GRUB2 binary by hash via the DBX was not viable — hundreds of entries across dozens of distributions would overflow the NVRAM. SBAT solved this by embedding compact versioned metadata directly into signed EFI binaries, allowing a single revocation entry to block all versions of a component below a given security level.

The enforcement of SBAT — pushed via a Microsoft DBX update in August 2022 — is what caused the CentOS 8 boot failures many engineers experienced firsthand. SBAT enforcement blocked shims that lacked SBAT metadata. CentOS 8 had gone end-of-life in January 2022 without shipping an SBAT-compliant shim. When the DBX update arrived, CentOS 8 machines stopped booting.

This is critical context for Section 5. The 2022 CentOS boot failures were not caused by certificate expiry. They were caused by a deliberate revocation enforcement push — a security action, not a lifecycle event. The two are frequently confused. Understanding the difference matters for understanding what June 2026 actually is.

The Comparison With TLS — Why Most Engineers' Intuition Is Wrong

When platform engineers hear "certificate expiry" they instinctively reach for their TLS mental model. The UEFI Secure Boot expiry is structurally different in almost every dimension:

The consequence of this structural difference is significant. If UEFI Secure Boot cert expiry behaved like TLS cert expiry — if every server had posted a health warning starting twelve months before June 2026 — the enterprise response would have started years earlier. The problem was not complexity. It was invisibility.

The Notification Gap — April 2026

Starting in April 2026 — six weeks before the first expiry — the Windows Security app began displaying Secure Boot certificate status badges: green for updated, yellow for action required, red for unresolvable. For Windows Server, these badges are disabled by default.

For home users and automatically managed devices, this is useful. For the enterprise server estates this paper is written for — managed environments, WSUS, deliberate patch staging, VMware VMs that do not receive Windows Update automatically, HPE Gen9 hardware that cannot be remediated regardless of any badge — the April 2026 notification arrives after the planning window has closed. Procurement cycles, CapEx approval, hardware refresh decisions, VMware upgrade projects: none of these can be executed in six weeks.

The notification gap is itself evidence of the broader problem. Microsoft built monitoring that surfaces the certificate status after the deadline for meaningful response has passed for the most complex cases. The systems that needed the earliest warning — legacy VMware estates, Gen9 hardware — are the systems least able to act on a six-week notice.

The One Sentence Summary

The UEFI-ignores-expiry design decision was technically correct, well-reasoned, and written into the specification in 2012 by engineers who understood the constraints. It created a world where fifteen years of certificate lifecycle elapsed without producing a single observable warning signal on the systems that would eventually need to act. The vendors who knew the deadline — Microsoft, OEMs, hypervisor vendors — had years to communicate it clearly. None of them did, with meaningful advance notice, to the engineers responsible for the affected infrastructure.

Sources — Section 3

Section 4 — Three Problems, Not One

Most communications about the 2026 Secure Boot certificate expiry treat it as a single event: certs expire, update them, done. That framing is useful for home users with auto-update enabled. It is dangerously incomplete for engineers managing enterprise server estates, virtualised infrastructure, and hardware that predates the 2023 replacement certificates by a decade.

There are not one but three structurally distinct problems that happen to share a root cause and a deadline. They have different consequences, affect different system populations, require different remediation approaches, and impose different risk profiles when left unresolved. Conflating them leads to incomplete remediation plans that miss entire classes of affected systems.

Problem One — The Signing Pipeline Freeze

What it is

After June 2026, Microsoft's private keys for Microsoft Corporation KEK CA 2011 and Microsoft Corporation UEFI CA 2011 expire. After October 2026, the Microsoft Windows Production PCA 2011 expires. Microsoft will not use expired certificates to sign new software. This is not a firmware enforcement event — it is a policy and infrastructure event on Microsoft's side.

What breaks

• New Windows Boot Manager updates released after October 2026 will be signed exclusively with Windows UEFI CA 2023. A system whose DB contains only the 2011 CA cannot install these updates.
• New Linux shim releases (RHEL 9.7+, Ubuntu post-June 2026, others) will be signed exclusively with Microsoft UEFI CA 2023. A system without that cert in its DB cannot boot new installation media.
• Future DBX revocations signed by the new KEK CA 2023 will not be authorisable on systems with only the old KEK. The system cannot receive new boot component blacklistings.
• New hardware option ROM updates — GPU firmware, NIC PXE stacks, RAID controller EFI drivers — signed with Microsoft Option ROM UEFI CA 2023 will not execute at POST on systems without that cert.

What does not break

Existing signed binaries remain fully trusted. The Windows Boot Manager installed before expiry, signed with the 2011 CA, continues to boot. Standard Windows Updates continue to install — OS patches, driver updates, and security fixes to userspace and kernelspace components are unaffected. However, any Boot Manager component within a future CU will be signed exclusively with Windows UEFI CA 2023 and will silently fail to deploy on systems with only the 2011 CA. The CU reports success. The Boot Manager does not update. Event ID 1795 or 1796 in the system log is the only indication.

Affected population

Every Windows Server that has not received the 2023 replacement certificates. For Windows Server, there is no automatic rollout — every instance requires a manual registry trigger or Group Policy.

Problem Two — The KEK Management Blockage

What it is

When Microsoft Corporation KEK CA 2011 expires in June 2026, new DB and DBX update packages signed with Microsoft Corporation KEK 2K CA 2023 will be rejected by any system that does not have the new KEK enrolled — the firmware checks the signing authority against the enrolled KEK before applying any DB or DBX change.

What breaks

This is a forward-capability problem, not an immediate operational failure. What stops working is Microsoft's ability to push future updates to that system's DB and DBX. After June 2026, any new Secure Boot allowed-list entries, new revocations, new signing keys that should be blacklisted — none of it can reach the system.

This is the mechanism that creates the permanent security freeze. The system is not broken. It is frozen at the security posture it held the last time it successfully received a DBX update. Every new bootkit discovered after that date, every new vulnerability in a boot component — none of it can reach the system.

Compounding factor: the VMware NULL PK

On VMware VMs created before ESXi 8.0.2, the Platform Key in the virtual NVRAM is a NULL placeholder. The PK must authorise KEK updates. A NULL PK cannot authorise anything. The result: even if the new KEK 2K CA 2023 is available in the update payload, the firmware rejects the write because the authentication descriptor cannot be verified against a NULL PK.

The KEK blockage is doubly enforced on pre-8.0.2 VMware VMs: the old KEK expires and the new one cannot be enrolled because there is no valid PK to authorise the enrollment. Resolving Problem Two on VMware requires first resolving the NULL PK — which itself requires either NVRAM regeneration on ESXi 8.0.2+ hosts or the unsupported uefi.allowAuthBypass workaround on ESXi 7.x.

Problem Three — The Forward Compatibility Break

What it is

New hardware manufactured in 2024 and later ships from the factory with only the 2023 certificates in the firmware Default DB. New Linux distribution shims, post-June 2026, will be signed exclusively with the 2023 CA. New GPU firmware, NIC firmware, and RAID controller EFI drivers released post-June 2026 will be signed exclusively with the 2023 Option ROM CA.

A system running only 2011 certificates will be incompatible with new hardware, new installation media, and new firmware updates from the moment vendors complete their transition to 2023-only signing. This transition is already underway — Mellanox ConnectX-7 firmware published its final 2011-signed release in early 2026 and stated all subsequent releases would be 2023-signed only.

What breaks

• Installing a new OS using post-June 2026 media on a system with only 2011 certs will fail at shim validation if the media contains a 2023-only shim.
• GPU firmware updates post-June 2026 will not execute at POST on systems without the Option ROM UEFI CA 2023 enrolled.
• Bootable recovery media rebuilt after the transition — WinPE USB drives, deployment images, WinRE — will contain 2023-signed components that fail on 2011-only systems.

The WDS/PXE time bomb

If WDS/PXE infrastructure is updated to serve 2023-signed boot files before the clients trust the 2023 CA, every new deployment will fail. If the clients are updated first and WDS/PXE still serves 2011-signed files, BitLocker triggers on every new deployment boot.

The remediation sequence matters: WDS/PXE boot files must be updated with Make2023BootableMedia.ps1 before or simultaneously with the guest certificate remediation wave. This is in the Windows Server Secure Boot Playbook for 2026, published February 23 2026 — less than four months before the deadline.

The Intersection — Where All Three Problems Converge

What Does NOT Break — The Clarification Most Documentation Omits

• Booting — systems with only 2011 certificates will continue to boot after June 2026 and after October 2026.
• Standard Windows Updates — cumulative updates, security patches, and driver updates to OS and kernel components continue to install normally. Exception: Boot Manager update payloads within a CU will silently fail to deploy on systems with only 2011 certificates, because post-expiry Boot Manager binaries are signed exclusively with Windows UEFI CA 2023. The CU reports success. The Boot Manager component is quietly dropped. Event ID 1795 or 1796 is the only indication.
• Running applications — nothing in userspace is affected by Secure Boot certificate state.
• BitLocker at rest — BitLocker continues to protect data. The risk is specifically to boot-chain security posture, not data-at-rest encryption.
• Existing signed binaries — any bootloader, shim, or option ROM signed before expiry continues to execute indefinitely.

💡 KEY POINT

The failure to distinguish between "systems stop booting" (false) and "systems lose the ability to receive future boot-chain security updates" (true) is the single most common source of either panic or complacency. Neither serves engineers well. The correct stance is: the machine works, the security posture degrades silently, and the window to act is closing.

The Remediation Complexity Is Not Equal Across All Three Problems

Problem One — the signing pipeline freeze — is largely solved by the standard Windows remediation process. Set the registry key, run the scheduled task, reboot twice, verify the event log.

Problem Two — the KEK blockage — is trivially solved for physical servers with current firmware, and extremely difficult for VMware VMs created before ESXi 8.0.2, for ESXi 7.x environments, and for any system on hardware that cannot accept a firmware update. The difficulty is structural: it requires firmware-level changes that cannot be performed from inside the guest OS under normal conditions.

Problem Three — forward compatibility — is the problem that will catch organisations after June 2026 if they do not act before it. The consequences are not immediate. They accumulate. The first symptom may be a new server arriving from the factory with a 2023-only DB and refusing to boot an existing WinPE image. Or a GPU firmware update silently failing to load at POST. Or a new Linux distro failing to boot on an old deployment. Each incident, in isolation, looks like a one-off compatibility issue. Together they represent an infrastructure estate left on the wrong side of a security transition.

Sources — Section 4

Section 5 — The Linux Angle: Shim, MOK, and SBAT

Why engineers who have never deployed Linux still need to understand the shim chain — and why the Linux community saw this coming years before anyone else.

5.1 The Chain Windows Engineers Don't See

Most Windows server engineers have never thought about the Linux Secure Boot trust chain. That gap is understandable. Linux is not in their estate, or if it is, it is handled by a separate team. The UEFI trust hierarchy for Linux looks, from the outside, like a simple variation on the Windows path: firmware trusts a signed bootloader, bootloader loads the OS, OS runs. It is not.

The chain for Windows is two hops: firmware verifies bootmgfw.efi (signed directly by Microsoft), bootmgfw.efi loads Windows. One certificate validates the entire path.

The chain for Linux is four hops, and every hop is a distinct component with its own signing authority, its own trust relationship, and its own failure mode:

• Firmware verifies shim.efi — signed by Microsoft via the UEFI CA chain (not the Windows production CA). The firmware trusts it because its signature chains to Microsoft Corporation UEFI CA 2011 in the UEFI DB.
• Shim verifies GRUB (or another second-stage bootloader) — not using a certificate in the UEFI firmware at all, but using a certificate embedded inside shim itself, or a key enrolled in the Machine Owner Key database (MOK).
• GRUB verifies the Linux kernel — against a shim-provided certificate or a MOK-enrolled key, again without touching UEFI firmware variables directly.
• The kernel verifies kernel modules — through its own key ring, populated by MOK-enrolled keys at boot, enforcing module signing independently of the UEFI layer.

Every stage after the initial shim verification happens inside the shim trust boundary, not inside the UEFI firmware trust boundary. This is the architectural reason Linux could support Secure Boot at all: distros cannot get their kernels signed directly by Microsoft, cannot enroll their own CA keys into UEFI DB on arbitrary hardware, and cannot negotiate with every BIOS vendor. Shim is the solution. One Microsoft-signed binary that each distro controls, can update on its own release schedule, and can use to bootstrap its own trust chain.

Why this matters for Windows engineers: Every Linux VM in a VMware or Hyper-V estate has a shim. Every deployment server that installs RHEL or Ubuntu uses a shim. Every HPE Gen10/11/12 server running RHEL bare metal runs a shim at every boot. When Microsoft Corporation UEFI CA 2011 expires in June 2026, every one of those shims is affected — not immediately, but irrevocably.

5.2 MOK: The Escape Hatch

Shim introduced a mechanism that has no Windows equivalent: the Machine Owner Key (MOK) database. MOK is a persistent UEFI variable — stored in NVRAM like DB and DBX — but managed entirely by shim, not by the UEFI firmware itself.

The purpose of MOK is to allow the owner of a machine to enroll additional trusted keys without going through Microsoft, without modifying the UEFI DB directly, and without needing a BIOS update. Any key enrolled into MOK is trusted by shim and can be used to sign GRUB, kernel images, or kernel modules. The enrollment process requires physical presence at boot time — a deliberate security gate that prevents remote enrollment.

The most common enterprise use case for MOK is custom kernel module signing. Enterprises with custom kernel drivers — storage software, security agents, virtualisation components — that are not publicly distributed cannot go through Microsoft's WHCP signing process. MOK gives them a path: generate a signing key pair, enroll the public key via mokutil --import, reboot, confirm enrollment at the MOK management screen, and the kernel will now accept modules signed with that private key.

This mechanism also matters for the 2026 transition in a specific way. Linux distributions that sign their GRUB and kernel through the shim trust chain do not need Microsoft's signature on every kernel update — only on shim itself. When RHEL releases a new kernel, RHEL signs it with a RHEL key. That RHEL key is either embedded in shim or enrolled as MOK. Microsoft signs shim. The chain of trust flows: Microsoft → shim → RHEL key → kernel. In 2026, only the first link in that chain — the Microsoft signing of shim — changes.

5.3 Boot Hole and the Revocation Scaling Crisis

In July 2020, security researchers at Eclypsium disclosed Boot Hole (CVE-2020-10713): a buffer overflow in GRUB2's configuration file parser. The vulnerability affected virtually every GRUB2 version used by every major Linux distribution for years. An attacker with write access to the EFI system partition could place a malicious grub.cfg that triggered the overflow before the OS loaded, bypassing Secure Boot entirely.

The vulnerability was severe. The remediation was, at the time, intractable.

The standard revocation mechanism for Secure Boot is the DBX — the Forbidden Signatures Database. To block a compromised binary, you add its hash (or the hash of its signing certificate) to DBX, and UEFI firmware refuses to load it. For a single exploited binary, this is manageable. For GRUB2 — distributed in hundreds of different builds, signed by dozens of different distro keys, recompiled with every point release across every major distribution for years — DBX revocation was structurally impossible.

There were thousands of distinct GRUB2 binaries that needed revocation. The UEFI DBX variable is constrained in size — measured in kilobytes, not megabytes — and revoking every affected GRUB2 hash would overflow DBX on most hardware platforms before the list was half complete. Revoking the distro signing keys instead would break every binary those keys had ever signed, including current and future releases that were not vulnerable.

Boot Hole exposed something the Linux community had known was coming but had deferred: the Secure Boot revocation model did not scale to the real world. It was designed for occasional, targeted revocations of specific known-bad binaries. It was not designed for a vulnerability that affected the entire ecosystem simultaneously.

The answer was SBAT — Secure Boot Advanced Targeting.

5.4 SBAT: How Linux Solved the Problem Windows Still Has

SBAT is a metadata section embedded directly in shim, GRUB, and other Secure Boot components. Each binary carries a structured record identifying its component name, version, and the vendor that built it. A corresponding revocation list — the SBAT revocation data — is stored as a UEFI variable and maintained by the UEFI firmware after being updated via authenticated DBX-adjacent writes.

Instead of revoking specific binary hashes, SBAT revokes by component version and vendor. A single SBAT revocation entry can block all GRUB2 versions below 2.06 from any vendor, in three bytes of data, without touching DBX at all. The revocation check happens inside shim — after shim loads GRUB but before GRUB executes. If GRUB's embedded SBAT metadata indicates a version below the revocation threshold, shim refuses to run it.

The implications of this design are significant:

• SBAT revocations are compact — a single entry revokes an entire class of vulnerable binaries regardless of how many distinct builds exist.
• SBAT revocations are component-specific — a GRUB revocation does not affect shim, and a shim revocation does not affect GRUB.
• SBAT revocations do not touch DBX — they leave room in the critically space-constrained forbidden signature database for genuinely targeted hash-level blocks.
• SBAT is self-healing — once a distro releases a new GRUB with an updated SBAT generation number, existing systems can receive that update and self-certify as no longer matching the revocation entry.

SBAT was designed and championed by the Linux community — specifically Red Hat, Microsoft's shim review board collaborators, and Canonical — and standardised through the shim review process in 2021. By the time SBAT was publicly deployed, it had been engineered, reviewed, tested, and implemented across major distros. It was operational within RHEL, Ubuntu, SUSE, and Debian before it was enforced by Windows Update.

The gap this exposes: The Windows trust chain has no SBAT equivalent. Windows Boot Manager and its components use only DBX for revocation. The Boot Hole-class problem — a vulnerability in the boot chain that affects everything Microsoft has ever signed — remains structurally unresolved for the Windows side. Every BlackLotus mitigation has required Microsoft to expand DBX with specific hashes of vulnerable Boot Manager versions, consuming a resource that cannot be recovered once spent.

5.5 The 2022 Incident: What Actually Happened

In August 2022, Microsoft shipped KB5012170, an out-of-band security update that implemented SBAT revocation enforcement. On systems that installed this update, Secure Boot began enforcing the SBAT revocation policy — and a subset of Linux installations stopped booting.

The failure reports spread quickly. CentOS 7 machines, older Debian installs, and some RHEL 7.x configurations failed to boot after applying the Windows security update. The narrative that emerged in the general press was, broadly, that a Windows update broke Linux. This framing was inaccurate in a way that matters for understanding what is happening in 2026.

What actually happened: the affected Linux systems were running pre-SBAT shim versions that did not contain SBAT metadata at all. The SBAT revocation policy enforced by KB5012170 included a baseline requirement that any shim loaded must either carry valid SBAT metadata or be explicitly allowlisted. Old shims with no SBAT metadata failed this check. UEFI refused to load them.

This was not a certificate expiry event. The UEFI CA 2011 certificate was not expired, was not revoked, and was not involved in the failure. The shim binaries were validly signed with UEFI CA 2011 and that signature was still trusted. What failed was a policy enforcement check on the content of the binary, not on the validity of its signature.

The 2022 incident was deliberate SBAT enforcement. The 2026 event is certificate expiry. These are structurally different mechanisms with different failure modes, different affected populations, and different remediation paths. The 2022 incident affected systems running old, unupdated shims on systems that had applied a Windows security update. The 2026 event will affect systems running any shim signed with UEFI CA 2011 if and when that certificate is removed from the DB — which, as of April 2026, has not happened and is not scheduled to happen on June 26.

The distinction matters operationally. In 2022, the path to recovery was update shim to a SBAT-compliant version, which all major distros had available. In 2026, the path to recovery involves the host-level UEFI DB update (adding UEFI CA 2023) that the entire Windows remediation wave is also executing. Linux and Windows share the same remediation dependency at Layer 1.

5.6 The Linux Community as the Canary

The engineers who have most thoroughly understood UEFI Secure Boot — as a mechanism, as a security model, and as an operational reality — are not Windows engineers. They are the Linux kernel developers, distro security teams, and community contributors who have been working inside the UEFI trust chain for a decade while trying to get Linux to boot on hardware that was, by default, configured to refuse it.

This was not academic work. When Secure Boot became mandatory on Windows 8 certified hardware in 2012, Linux had no path to Secure Boot compatibility that did not involve Microsoft signing every kernel. Microsoft's position was that it would sign one shim per distro — a small, auditable binary whose sole job was to verify distro-controlled keys. The shim review board, established to audit submissions before Microsoft signing, became a deep technical forcing function: Linux developers had to understand UEFI's key hierarchy, the DB and DBX mechanics, the authenticated variable protocol, and every edge case in the UEFI spec in order to produce a shim that Microsoft would sign.

By the time Boot Hole was disclosed in 2020, Red Hat's firmware team, Canonical's security team, and the upstream shim maintainers had more operational knowledge of UEFI revocation mechanics than any team in the Windows ecosystem — including, arguably, teams inside Microsoft itself. SBAT was not designed in a vacuum. It was designed by people who had spent years studying why the existing model was insufficient.

James Bottomley's 2012 blog post — cited in Section 3 as the primary technical source for why UEFI ignores certificate expiry — was written while he was working on UEFI Secure Boot support for Linux. The document that established the canonical understanding of UEFI key semantics was written by a Linux developer, for a Linux audience, as an operational reference for people implementing Secure Boot in a context where it was hostile.

That knowledge gap explains why the 2026 certificate expiry caught so many Windows-first organisations unprepared. The Linux community had been tracking UEFI certificate lifetimes for years — not because they were more diligent, but because every shim submission to Microsoft required understanding what certificates would be used to sign it, when those certificates were valid, and what the downstream implications would be. A Linux distro that lets its shim's signing chain expire has a non-booting distribution. That consequence focuses attention.

5.7 What June 2026 Actually Means for Linux

The precise mechanism by which Linux is affected in June 2026 is different from the Windows mechanism — and the failure mode is more deferred.

When Microsoft Corporation UEFI CA 2011 expires on June 26, 2026, it does not immediately stop being trusted by firmware. UEFI firmware does not check certificate expiry. An existing shim signed with UEFI CA 2011 will continue to load on any firmware whose DB contains that certificate. Systems that have not received the DB update removing UEFI CA 2011 will continue to boot Linux normally — on June 27, and for as long as that certificate remains in DB.

The Linux impact accumulates from three separate events, each with a different timeline:

Event 1 — New shim releases require UEFI CA 2023 in DB (June 2026)

After June 2026, new shim binaries submitted to Microsoft for signing will be signed with Microsoft Corporation UEFI CA 2023. A system whose DB contains only UEFI CA 2011 will not be able to boot these new shims. For a system running RHEL 9.6 today, this is not an immediate problem — that shim continues to work. The problem arrives when a new OS installation is attempted using post-June 2026 media (which ships a 2023-signed shim), or a security vulnerability requires the distro to ship a shim update with a higher SBAT generation, and the new shim is signed with 2023 CA only.

Event 2 — SBAT revocation may force shim updates (timing unclear)

If a future boot vulnerability requires SBAT revocation of the current shim generation, distros will need to ship new shim versions. Those new versions, post-June 2026, will be 2023-signed. A system that has not received the DB update will be in a double bind: the old shim is revoked via SBAT, the new shim requires a certificate the DB does not contain. This scenario is not theoretical — SBAT was specifically designed for exactly this type of forced shim turnover, and it will be used again.

Event 3 — The edk2-ovmf problem for virtual Linux environments

This is the most immediately actionable item for any organisation running Linux VMs on VMware or KVM. The edk2-ovmf package provides the virtual UEFI firmware for KVM and QEMU-based virtual machines. Older edk2-ovmf builds contain only UEFI CA 2011 in their virtual DB. New Linux VMs created on a host with an unupdated edk2-ovmf will have a virtual firmware that cannot trust 2023-signed shims.

Updated edk2-ovmf packages — available now, installable without disruption to running VMs — include both UEFI CA 2011 and UEFI CA 2023. The update is safe to apply immediately. The recommended package versions are edk2-ovmf-20241117-2.el10 or later for RHEL 10 and edk2-ovmf-20231122-6.el9 or later for RHEL 9. Existing VMs are not affected by an edk2-ovmf update — only newly created VMs pick up the new DB contents.

The VMware angle: For organisations running Linux VMs on VMware ESXi, the edk2-ovmf issue does not apply directly — ESXi uses its own UEFI implementation seeded from the host ROM, not edk2-ovmf. The relevant action for Linux VMs on ESXi is the same NVRAM regen procedure used for Windows VMs: the host ROM update (SPP) seeds the new certificates into the NVRAM template, and NVRAM regen on existing VMs picks up the 2023 certs. A Linux VM on ESXi 8.0.2+ with an NVRAM-regenerated virtual firmware will trust both 2011 and 2023 shims.

5.8 What Engineers Should Do — Linux Edition

The Linux remediation tasks are fewer than the Windows tasks, but they run in parallel with the Windows remediation wave and share the same Layer 1 dependency: the host-level DB update that adds UEFI CA 2023.

• Update edk2-ovmf immediately on any KVM/QEMU/Proxmox host. This affects only newly created VMs, is non-disruptive to running instances, and takes minutes. There is no reason to defer this.
• Inventory shim versions across the Linux estate. The command rpm -q shim-x64 on RHEL-based systems or dpkg -l shim-signed on Debian-based systems shows the installed shim package version. Check against the distro's security advisories for SBAT-compliant releases.
• Include Linux VMs in the NVRAM regen wave on VMware estates. The NVRAM regen procedure is identical for Linux and Windows VMs — the virtual NVRAM contains the UEFI DB regardless of what OS is installed. A Linux VM with a NULL PK is in the same state as a Windows VM with a NULL PK.
• Do not force standalone DB variable updates on HP or Fujitsu hardware with Linux installed — Red Hat's advisory explicitly documents this. The safe path is the Windows remediation wave (AvailableUpdates=0x5944 on a Windows guest to trigger the update) or the SPP/BIOS key reset path for the host firmware.
• Track RHEL 9.7 and Ubuntu post-June 2026 shim releases as the first deliverables requiring UEFI CA 2023 in DB. These releases are the canary: if they boot on your systems, your DB update is complete. If they do not boot, your DB is still 2011-only.
• VeraCrypt on Linux carries the same risk as VeraCrypt on Windows. DcsBoot.efi is OS-independent — the bootloader is a UEFI application, not a Linux binary. Do not complete DB revocation of UEFI CA 2011 on any VeraCrypt-encrypted system, Linux or Windows, until VeraCrypt ships a 2023-CA-signed bootloader.

The Linux community did not get advance warning of the 2026 transition that Windows engineers did not. The first public Microsoft announcement was February 13, 2024 — available to everyone simultaneously. What the Linux community had was a decade of accumulated operational knowledge about UEFI trust mechanics that made that announcement immediately comprehensible, and that had already produced, years earlier, the revocation infrastructure (SBAT) that the Windows ecosystem still does not have. That is not luck. It is the result of having been forced, by the architecture of Secure Boot itself, to understand the machinery from the inside.

The engineers least likely to be surprised by June 2026 are the ones who have been running Linux on Secure Boot hardware for years. The engineers most likely to be surprised are the ones running large Windows server estates who have never had reason to think about what sits between UEFI and their OS. The goal of this section is to close that gap before the deadline, not after it.

Section 6 — BlackLotus: The Catalyst Nobody Asked For

How a UEFI bootkit transformed a routine certificate lifecycle event into an active security emergency — and what it permanently changed about the cost of staying on 2011 certificates.

6.1 The Bootkit That Changed the Calculus

Before March 2023, the Secure Boot certificate transition was a scheduled infrastructure project. The 2011 certificates were expiring. Microsoft had a timeline. The replacement 2023 certificates existed. The migration path was understood, if not yet widely communicated. For the organisations that had visibility into the expiry dates, it was a lifecycle management problem: plan the remediation wave, test it, roll it out before the deadline.

In March 2023, ESET's threat research team published an analysis of BlackLotus — a UEFI bootkit sold on criminal forums since late 2022 for approximately five thousand US dollars, and the first publicly documented malware capable of bypassing Secure Boot enforcement on fully patched Windows 11 systems.

The certificate transition was never the same again.

BlackLotus did not break Secure Boot. It demonstrated, with working malware, that Secure Boot could be bypassed using a vulnerability Microsoft had known about and patched over a year earlier — by exploiting the fact that Microsoft had not yet revoked the old, vulnerable signed binaries from DBX. The patch existed. The signed vulnerable binaries still existed. The revocation had not been pushed. And because Secure Boot trusts signatures, not intentions, any signed binary that has not been explicitly revoked is loadable — regardless of how long ago a patch for it was released.

The core insight of BlackLotus: A bootkit does not need to defeat Secure Boot cryptography. It only needs to find a legitimately signed binary that is vulnerable — load that binary, exploit its vulnerability before the OS takes control, and Secure Boot has been bypassed without any signature violation. Every signed boot component that has ever had a security vulnerability is a potential attack vector for as long as it remains trusted in DBX.

6.2 The Exploit: CVE-2022-21894 and Baton Drop

The specific vulnerability BlackLotus exploited was CVE-2022-21894, disclosed and patched by Microsoft in January 2022 under the name "Baton Drop". The vulnerability allowed an attacker to load an old, legitimately Microsoft-signed Windows Boot Manager binary that contained a flaw permitting Secure Boot policy bypass — placing it into the EFI system partition and ensuring it loaded at boot rather than the current, patched version.

The mechanism is conceptually simple. Secure Boot validates that the binary being loaded is signed by a trusted certificate. It does not validate that the binary is current. It does not validate that the binary hasn't been patched. It does not consult a version list. If the binary's signature chains to a certificate in the UEFI DB, it loads. The old, vulnerable Boot Manager binary was signed by Microsoft. Its signature was valid. It loaded.

Microsoft's mitigation for Baton Drop — published May 9, 2023 as KB5025885 — required adding the old vulnerable Boot Manager hashes to the DBX. Once added, firmware would refuse to load those binaries regardless of signature validity. The mitigation worked. It also consumed space in DBX that no subsequent vulnerability can reclaim, and it created a direct compatibility problem: any bootable media — WDS images, WinPE ISOs, recovery drives — that contained the old Boot Manager would fail to boot on systems where the revocation had been applied. The WDS/PXE compatibility problem Section 4 describes is a direct inheritance from the BlackLotus mitigation wave.

KB5025885 is not optional. It is the Baton Drop mitigation. Systems that have not applied it remain vulnerable to the exact technique BlackLotus used in active attacks in 2023. As of April 2026, KB5025885 is a prerequisite for the certificate remediation wave — both because the remediation process builds on the DBX state established by the mitigation, and because any system that has not applied it is demonstrably exploitable by a known, documented, commercially distributed bootkit.

6.3 CVE-2023-24932: Round Two

Security research does not stop when a patch ships. In May 2023, Microsoft disclosed CVE-2023-24932 — a bypass of the CVE-2022-21894 mitigation. Researchers had found that KB5025885's initial application was staged and incomplete: the full revocation could be applied by administrators via registry keys, but the default deployment was deliberately conservative to avoid breaking existing boot environments. The staged rollout created a window where systems with the patch applied were still exploitable if the administrator had not manually enabled the more aggressive revocation stages.

The staged deployment was a deliberate tradeoff. Microsoft had learned from the 2022 CentOS/SBAT incident that aggressive revocation can break existing installations. Pushing the full Baton Drop revocation to every patched system simultaneously would have broken millions of WDS/PXE deployments still serving old boot media. So Microsoft made the revocation opt-in at maximum strength, documented the registry keys, and waited for administrators to update their boot media first.

The consequence was that the security/compatibility tension that has characterised every significant Secure Boot mitigation since 2012 resurfaced in direct form. The correct security outcome required breaking existing deployment infrastructure. Most administrators, facing a choice between "apply the full revocation now and break WDS" and "defer the full revocation until WDS is updated", chose the latter — and the window of exploitability remained open.

The three-stage KB5025885 rollout — each stage requiring explicit administrator action to advance — was the direct precursor to the AvailableUpdates registry key mechanism used for the 2026 certificate transition. The lesson Microsoft drew from the Baton Drop mitigation was that pushing Secure Boot changes automatically to server estates is operationally dangerous. The 2026 remediation path is therefore manual, staged, and gated on administrator action. This is correct. It also means that every enterprise that did not pay close attention to the KB5025885 rollout is about to navigate the same complexity at larger scale.

6.4 How BlackLotus Transformed the 2026 Transition

The relationship between BlackLotus and the 2026 certificate transition operates on three levels.

Level 1 — Acceleration of urgency

Before BlackLotus, the certificate transition was a future compliance and lifecycle problem. After BlackLotus, it became a present security problem. The mechanism by which unremediated systems would accumulate risk — inability to receive future DBX revocations — was no longer theoretical. BlackLotus demonstrated exactly what that risk looks like: active, commercially available malware that exploits the window between vulnerability disclosure and DBX revocation.

Every system that has not received the 2023 certificates is, from the moment the 2011 KEK expires, permanently unable to receive future DBX revocations. The next BlackLotus — the next bootkit that exploits a signed but vulnerable boot component — will find those systems as accessible as a 2022 Windows 11 machine was to BlackLotus itself. The question is not whether such a bootkit will appear. Boot-level vulnerabilities in the Windows trust chain have appeared with regularity since CVE-2022-21894. The question is when, and how long the window stays open.

Level 2 — The DBX saturation problem

DBX is a fixed-size UEFI variable, constrained by firmware implementations typically to somewhere between 6 and 32 kilobytes depending on the platform. Every hash added by a BlackLotus-class mitigation consumes that budget permanently. The UEFI specification does not define a mechanism for removing DBX entries — once a hash is in DBX, it cannot be retracted without a complete DB/DBX reset, which would also remove every legitimate revocation applied since the system shipped.

The BlackLotus mitigation wave added dozens of Boot Manager hashes to DBX. The Secure Boot bypass research community is productive and well-funded — both by criminal organisations seeking bootkits and by security researchers seeking CVEs. Each round of Boot Manager vulnerabilities requires more DBX entries. The resource pool is finite. Platforms that run out of DBX space cannot receive further revocations, regardless of certificate state.

This is why SBAT, described in Section 5, matters so much to the Windows side of this transition: it is the architectural answer to DBX saturation that the Linux side has and the Windows side does not. The Windows Boot Manager has no SBAT equivalent. Every future Boot Manager mitigation will consume DBX space. The constrained resource is being depleted, and the depletion rate is set by the discovery rate of boot-level vulnerabilities — not by any timeline administrators control.

Level 3 — The Symantec SEE conflict

The BlackLotus mitigation introduced a collision that has no clean resolution as of April 2026. Symantec Endpoint Encryption (SEE) — Broadcom's enterprise full-disk encryption product — requires the Microsoft UEFI CA 2011 third-party certificate to be present and trusted in the UEFI DB in order for its pre-boot EFI authentication agent to load. Microsoft's own documentation for KB5025885 contains an explicit advisory: Secure Boot mitigations cannot be applied to systems that have installed Symantec Endpoint Encryption.

The reason is architectural. SEE's pre-boot agent is a UEFI application signed via the UEFI CA 2011 chain. The BlackLotus mitigation ratchets up Secure Boot enforcement in ways that affect how the UEFI CA 2011 trust chain is exercised at boot. On some hardware configurations, applying the full KB5025885 revocation stages breaks SEE's ability to present its authentication screen.

For the 2026 certificate transition, this creates a documented impasse. SEE-encrypted systems cannot safely apply the Secure Boot certificate update that the rest of the remediation wave depends on — because the certificate update builds on the same DBX state that KB5025885 established. As of April 2026, Broadcom has not published a SEE version that resolves the compatibility problem. The affected population — every enterprise running SEE full-disk encryption, which is a significant fraction of the regulated-industry and financial-services sector — faces a choice between deferring Secure Boot remediation entirely, or replacing their disk encryption product before June 2026.

SEE-encrypted systems: Do not apply KB5025885 full revocation stages. Do not apply the 2026 certificate remediation wave. Engage Broadcom support immediately for the remediation roadmap. Document the exception formally with a risk acceptance decision. Compensating controls (network segmentation, EDR coverage, monitoring for boot-level anomalies) are mandatory while this remains unresolved.

6.5 The Permanent Change

Before BlackLotus, an enterprise could have made a reasonable argument that deferring the Secure Boot certificate transition carried manageable risk. The 2011 certificates were expiring, but the failure mode was prospective: inability to receive future security updates, not exposure to present attacks. A security team that prioritised immediate operational continuity over long-term Secure Boot hygiene had a defensible position.

BlackLotus closed that argument.

It established — with working, commercially distributed malware — that the gap between DBX revocation and exploit availability can be measured in months, not years. It demonstrated that boot-level vulnerabilities in signed Microsoft components are a live attack surface, not a theoretical concern. It showed that the signed binary trust model, without active DBX maintenance, is a trust model that erodes over time as vulnerability research accumulates against it.

A system that cannot receive DBX updates after June 2026 is a system frozen at the security posture of mid-2026 — which, given the pace of boot-level vulnerability research since 2022, is a posture that will grow progressively more exploitable with time. The question is not whether a future bootkit will exploit this. The question is how long it will take for one to appear, how long the window between appearance and administrator action will be, and how many servers in an enterprise estate will be in scope when it does.

The answer to all three questions is worse for a system that has not received the 2023 certificates than for one that has. The gap is not abstract. BlackLotus quantified it.

Section 7 covers the disclosure timeline — when Microsoft knew, when it told the industry, and the sequence of communications that brought the 2026 deadline to the attention of the engineers now responsible for remediating it. The BlackLotus incident sits inside that timeline as the event that changed the nature of what was being disclosed.

Section 7 — The Disclosure Timeline

When Microsoft knew, when it told the industry, and why the gap between the two left enterprise engineers with less time than the calendar suggests.

7.1 The Anatomy of a Disclosure Failure

The 2026 Secure Boot certificate expiry will be described, in retrospect, as a failure of advance notice. That description is not entirely accurate, and the inaccuracy matters — because the true failure is more instructive than a simple absence of communication.

Microsoft gave the industry twenty-eight months of advance notice. The first public announcement naming the expiry, the deadline, and the need for action appeared in February 2024. That is not a short notice period. The problem is not that Microsoft didn't say anything. The problem is that what it said, to whom it said it, in what register it said it, and when it graduated from technical documentation to operational alarm — followed a pattern that systematically failed to reach the people responsible for acting on it.

The timeline below is not a sequence of isolated communications. It is a sequence of escalating urgency, in which the gap between the people who understood the problem and the people who needed to act on it narrowed progressively — and closed, for many enterprise administrators, only in January 2026, five months before the first deadline.

7.2 The Full Timeline

2011 — The Certificates Are Issued
Microsoft Corporation UEFI CA 2011, Microsoft Corporation KEK CA 2011, and Microsoft Windows Production PCA 2011 are issued with fifteen-year validity periods. Their Not After dates — June 26, 2026 and October 19, 2026 — are embedded in every server BIOS and every copy of these certificates distributed since issuance. The dates are not secret. They require no special access to read. They are in the certificate, available to any engineer who looks.

January 2022 — CVE-2022-21894 (Baton Drop) disclosed and patched
Microsoft patches the Boot Manager vulnerability that BlackLotus will later weaponise. The fix exists. Revocation of the old signed binaries via DBX has not yet been pushed. The window of exploitability opens.

Late 2022 — BlackLotus appears on criminal forums
A UEFI bootkit exploiting CVE-2022-21894 is offered for sale at approximately $5,000 USD. It is the first publicly known malware to bypass Secure Boot on fully patched Windows 11 systems. Its existence is not yet publicly known.

March 2023 — ESET publishes BlackLotus analysis
ESET's threat research team documents BlackLotus in technical detail. The bootkit's Secure Boot bypass mechanism — loading old signed Boot Manager binaries that haven't been revoked — becomes public knowledge. The security community understands, for the first time from a concrete case, what the gap between patch and revocation looks like as an attack surface.

May 9, 2023 — Microsoft ships KB5025885 — the BlackLotus mitigation
The Baton Drop revocation is published as KB5025885, deploying in three stages that require administrator action to advance. The compatibility problem with WDS/PXE boot media is documented. Symantec Endpoint Encryption is explicitly listed as incompatible. The staged rollout means most enterprise systems remain partially mitigated for months. This is the first large-scale demonstration that Secure Boot changes on enterprise infrastructure require careful sequencing.

May 2023 — CVE-2023-24932 disclosed — KB5025885 bypass
A bypass of the partial mitigation is disclosed. The staged deployment model is confirmed as the correct approach but also as a source of ongoing partial-exposure windows.

2023–2024 — Linux distros begin the certificate transition
Red Hat, Canonical, SUSE, and other major distributions begin the engineering work to produce SBAT-compliant shims signed with Microsoft UEFI CA 2023. The shim review board process begins for the 2023 CA variants. Rocky Linux publishes its Secure Boot Key Refresh 2024 notice — one of the clearest early public communications about what the transition means operationally. The Linux community is working the problem eighteen months before most Windows enterprise teams are aware it exists.

February 13, 2024 — Microsoft — first public enterprise announcement
Microsoft publishes "Updating Microsoft Secure Boot Keys" on the Windows IT Pro blog. The post names the expiry dates, describes the replacement certificates, and explains the update mechanism. It is technical, accurate, and addressed to an engineering audience. It does not use the word "urgent." It does not name a specific enterprise action deadline. It does not appear in Windows Admin Center, WSUS, or any management plane console that would put it in front of the administrators responsible for acting on it. It is a blog post read by security researchers, firmware engineers, and the Linux community. It reaches enterprise Windows server administrators approximately: not at all.

February 13, 2024 was the disclosure. It was also invisible to most of the people who needed to act on it. Visibility into a disclosure requires active monitoring of a blog not surfaced in any enterprise management toolchain. The disclosure existed. The communication did not.

September–December 2025 — HPE BIOS updates land for Gen10/11/12
HPE begins releasing SPP 2026.01.00.00 (Gen11) and later SPP 2026.03.00.00 (Gen10/Gen10 Plus, Gen12) containing the 2023 certificates. The first enterprise-grade firmware fix with embedded 2023 certificates becomes available roughly nine months before the first deadline — enough time to execute a measured rollout, but only for organisations already tracking the issue. HPE's formal advisory document (a00156355) is published in March 2026 — six months after the firmware fixes begin shipping, and three months before the deadline.

December 2025 — Windows Server 2025 ships with 2023 certs by default
New Windows Server 2025 certified platforms ship with the 2023 certificates already present in firmware. For organisations deploying new hardware, this is the correct state by default. The installed base of existing servers receives no equivalent automatic remedy.

January 13, 2026 — Microsoft — "Act Now" alarm bell
Microsoft publishes "Act Now: Secure Boot Certificates Expire in June 2026" on the Windows IT Pro blog. This post, for the first time, uses urgency language explicitly designed to reach Windows administrators rather than firmware engineers. The phrase "Act Now" is in the title. It is five months before the first deadline. For most enterprise Windows server administrators, this is the moment the issue becomes real.

January 13, 2026 — January Patch Tuesday CUs ship for WS2016 and WS2019
KB5073722 (Server 2016, build 14393.8783) and KB5073723 (Server 2019, build 17763.8276) ship as the minimum required patch levels for certificate enrollment tooling. The usable minimum for Server 2022 does not exist until the following month — the January CU (KB5073457) carries a VSM shutdown bug.

January 2026 — Broadcom publishes first VMware-specific advisories
Broadcom/VMware publishes KB 423893 documenting the NULL PK issue and confirming there is no automated fix for pre-ESXi 9.0 VMs. This is the first VMware-specific public advisory. Organisations with large VMware estates receive their first vendor-specific guidance five months before the deadline — and that guidance immediately confirms their remediation path requires unsupported manual procedures.

February 10, 2026 — KB5075906 ships — Server 2022 minimum CU
The minimum required patch level for Windows Server 2022 becomes available, fixing the VSM shutdown bug in the January CU. The Server 2022 remediation path is now unblocked — four months before deadline.

February 23, 2026 — Windows Server Secure Boot Playbook published
Microsoft publishes the Windows Server Secure Boot Playbook for Certificates Expiring in 2026. This is the first document specifically written for enterprise Windows server administrators that contains actionable remediation steps, registry key references, and environment-specific guidance. It arrives four months before the June deadline.

The Server Playbook arrived four months before the deadline. Planning, testing, and executing a remediation wave across thousands of VMs in four months is achievable. It is not comfortable.

February 2026 — Microsoft Tech Community AMA
Microsoft hosts an Ask Microsoft Anything session on Secure Boot. The Hyper-V Gen2 template toggle discovery — the workaround for existing VMs that cannot receive KEK updates without it — is confirmed and documented at this event. Enterprise administrators surface real-world deployment edge cases not covered in the playbooks. This is the first two-way communication between Microsoft engineers and the enterprise administrator community about the specifics of the 2026 transition.

March 2026 — HPE Advisory a00156355 published
HPE publishes its formal advisory covering Gen10/11/12. The advisory explicitly states that a BIOS Secure Boot key reset to factory defaults is mandatory after applying the SPP — not just a reboot, but a specific BIOS menu action. Without this advisory, engineers applying SPP without the reset step would have updated the firmware but not activated the new certificates. Gen9 is not mentioned in this advisory or any other HPE 2026 advisory. The omission is not an oversight. There is nothing to say.

March 2026 — Broadcom KB 423893 updated — no automated fix confirmed
Broadcom updates KB 423893 to confirm: there is no automated resolution available for the NULL PK issue on pre-ESXi 9.0 VMs. KB 421593, the original manual procedure document, has been removed without replacement. The manual NVRAM regen procedure and the unsupported uefi.allowAuthBypass VMX flag are the only options.

April 8, 2026 — Secure Boot Troubleshooting Guide (KB5085046) published
Microsoft publishes a dedicated troubleshooting guide covering Event ID definitions (1795, 1796, 1799, 1800, 1801, 1802, 1803, 1808), diagnostic steps, and resolution paths. This reference document — the one that lets administrators interpret what their event logs are actually saying — arrives seven weeks before the first deadline.

April 14, 2026 — Windows Security App Secure Boot badges ship in CUs
The April 2026 Patch Tuesday CUs include the first visual Secure Boot certificate update status indicators in the Windows Security app (green/yellow/red). This is the first management-plane visibility tool for the certificate update state. It ships six weeks before the first deadline.

June 26, 2026 — KEK CA 2011 and UEFI CA 2011 expire
On systems that have received the 2023 certificates, the operational impact is zero. On systems that have not: the signing pipeline freeze takes effect, the KEK management blockage becomes permanent, and the forward compatibility break begins accumulating. Systems continue to boot. The security posture stops advancing.

October 19, 2026 — Windows Production PCA 2011 expires
Boot Manager update payloads within future CUs will silently fail to deploy on systems with only 2011 certificates. The WDS/PXE time bomb is fully armed for any deployment infrastructure not yet updated with Make2023BootableMedia.ps1.

7.3 The Pattern

The timeline above contains a disclosure structure that appears repeatedly in enterprise security events: early technical publication, long silence in operational channels, late urgency escalation.

The February 2024 post was technically public. It reached the Linux community, firmware engineers, and security researchers — people who actively monitor UEFI specification changes and Microsoft engineering blogs. It did not reach Windows server administrators managing VMware estates. Those administrators do not monitor UEFI firmware blogs. They monitor WSUS, Systems Center, vendor advisories, and the mailing lists of their specific vendors. None of those channels carried the February 2024 announcement.

Broadcom's first VMware-specific guidance arrived in January 2026 — twenty-three months after Microsoft's initial public post. For organisations whose virtualisation layer is managed by a different team from their Windows infrastructure, the person responsible for remediating VMware VMs received their first vendor guidance on the problem five months before deadline — and that guidance immediately informed them that their specific environment had no automated remediation path.

HPE's formal advisory document for Gen10/11/12 arrived in March 2026. The firmware fixes had been shipping since September 2025, but the document explaining that a BIOS key reset was mandatory — not obvious from applying the SPP alone — arrived in March. An engineer who applied the SPP in October 2025 without reading the March 2026 advisory would have done the work incorrectly. There was no documentation saying otherwise for five months.

The Windows Server Secure Boot Playbook — the enterprise-grade remediation guide — arrived in February 2026. The Gen9 dead-end advisory exists nowhere: there is no HPE document that says "Gen9 cannot be remediated." Gen9 is simply absent from the advisory that covers Gen10, Gen11, and Gen12.

The disclosure timeline produced the following operational reality: Engineers in February 2026 received both the alarm bell and the playbook simultaneously, with four months to act. Engineers responsible for VMware received the problem statement and the confirmation that their remediation path was manual and unsupported, simultaneously. Engineers responsible for Gen9 hardware received nothing — because there is nothing to receive.

7.4 What the Timeline Means for Accountability

The disclosure timeline matters for accountability in a specific direction: it matters for how organisations account for the decisions that were made, and the decisions that were not.

Microsoft gave notice. The notice was technically adequate in that it was accurate, publicly available, and appeared before the deadline. The notice was operationally inadequate in that it was published in a channel that enterprise Windows administrators do not monitor, in language that signalled lower urgency than the situation warranted, without accompanying action items in the management tools those administrators actually use.

Broadcom gave notice five months before a deadline affecting every enterprise VMware installation. That is the minimum period in which a large enterprise can execute a remediation programme of any complexity. For organisations with thousands of VMs — the exact population Broadcom's virtualisation platform is designed to serve — five months is not a remediation window. It is a crisis response period.

HPE gave adequate notice for Gen10/11/12 customers willing to apply firmware ahead of formal documentation. It gave no notice to Gen9 customers because it had nothing to offer them. The silence is the message, and the message requires active interpretation by an engineer who knows to look for an absence.

The engineers now executing these remediation waves are not responsible for the disclosure failures. They are responsible for the remediation. The distinction matters both for how they should be resourced and how the programme of work should be communicated to leadership: this is not a routine patch cycle. It is a compressed remediation of a problem that the vendor ecosystem failed to communicate with adequate urgency and adequate lead time.

Section 8 covers the hardware abandonment problem — the specific population of servers and firmware for which the disclosure timeline is irrelevant because no remediation exists regardless of when it was communicated.

Section 8 — The Hardware Abandonment Problem

Why a significant fraction of the servers in production data centres today cannot be remediated — and what the industry's silence about this population reveals about how hardware vendors define their obligations.

8.1 The Population Nobody Is Talking About

Every remediation playbook, every vendor advisory, and every blog post about the 2026 Secure Boot certificate expiry describes a path forward. Apply the SPP. Reset the BIOS keys. Apply the CU. Run Stage 1. Run Stage 2. Verify. Done.

None of those documents describe what to do when the path forward does not exist.

A significant and largely unacknowledged population of production servers cannot receive the 2023 Secure Boot certificates regardless of administrator action. Not because the administrators haven't applied the right patches. Not because the remediation process is complex. Because the firmware update that embeds those certificates was never released for their hardware, and will never be released. The hardware is in production. The servers are running workloads. The certificate expiry is happening on the same schedule. The remediation is structurally impossible.

8.2 HPE Gen9: The Case Study

The clearest example in the HPE estate is ProLiant Gen9, the server generation introduced in 2014 and used extensively through 2018. Gen9 hardware is not exotic. It is not rare. It was HPE's flagship server line during the years when most current enterprise data centres were built out. The DL380 Gen9 is one of the most widely deployed rack servers in the world.

Gen9 reached End of Service Life in approximately July 2025. The last Gen9 SPP release — 2022.08.0_hotfix_3 — shipped in August 2022. It does not contain the Microsoft UEFI CA 2023 certificates. No subsequent SPP was released for Gen9. No out-of-band patch was issued. No individual ROM update was published that addresses the certificate transition. HPE advisory a00156355, published March 2026, covers Gen10, Gen11, and Gen12. Gen9 is not in the document.

The technical consequence is absolute. On a Gen9 host running ESXi:

• The host ROM contains only UEFI CA 2011 and KEK CA 2011 in its factory certificate store.
• NVRAM regen on ESXi 8.0.2+ reseeds the VM's virtual NVRAM from the host ROM template — which contains 2011 certs only. NVRAM regen on Gen9 actively reconfirms the wrong state.
• Stage 1 on any guest VM on a Gen9 host will hard-block at the KEK update step with Event 1803: OEM KEK missing from ROM.
• The uefi.allowAuthBypass workaround can enroll a PK and KEK manually into the virtual NVRAM, but the DB/DBX update still requires a valid KEK to authorise it, and if that KEK is not present in the OEM-signed chain, the Windows update task will still fail at the DB write.

Gen9 is not a partial fix. It is no fix. The remediation path for Gen9 is: replace the hardware, or accept permanently degraded Secure Boot posture. There is no third option. An organisation running Gen9 servers with production Windows workloads after June 2026 will have systems that cannot receive DBX revocations, cannot receive Boot Manager security updates, and cannot be brought into compliance with the 2023 certificate standard by any means short of hardware replacement.

8.3 The Broader Pattern: Gen9 Is Not Alone

HPE Gen9 is the best-documented example because HPE's generation naming makes the boundary visible. But the same structural problem applies across every major server vendor's end-of-life hardware lines.

Dell PowerEdge — pre-2017 generations

Dell's 12th and 13th generation PowerEdge servers (introduced 2012 and 2014 respectively) face equivalent firmware lifecycle constraints. The 14th generation (PowerEdge R740, introduced 2017) received firmware updates relevant to the 2023 certificate transition. Earlier generations did not. No platform firmware update containing UEFI CA 2023 was published for 12G/13G hardware.

Lenovo ThinkSystem — pre-2017 generations

Lenovo's System x line (acquired from IBM in 2014) and earlier ThinkSystem predecessors face the same constraint. The ThinkSystem generation introduced in 2017 received certificate-relevant firmware updates. Earlier hardware did not.

Fujitsu PRIMERGY — pre-2017 generations

Fujitsu hardware carries an additional constraint documented explicitly in the Red Hat advisory: standalone DB updates are blocked at the firmware level on Fujitsu hardware by design, following historical system failures on that platform. For end-of-life Fujitsu hardware with no 2023-certificate firmware update, this means not only that the update is unavailable, but that any attempt to force it through alternative means is blocked at the platform level.

ESXi 7.x — the hypervisor dead end

ESXi 7.x reached end of general support in April 2025. NVRAM regen requires ESXi 8.0.2+. An organisation running ESXi 7.x cannot perform NVRAM regen regardless of the host hardware generation. ESXi 7.x on Gen10 hardware is remediable at the hardware level but blocked at the hypervisor level. The remediation path requires an ESXi upgrade — a separate project with its own risk and maintenance window requirements.

8.4 The Economics of Hardware Abandonment

Hardware abandonment in security contexts is not new. Every end-of-life OS and every end-of-support driver represents the same structural pattern: a vendor stops maintaining software, the installed base continues to run it, and security exposure accumulates. The 2026 Secure Boot situation is different in one important respect: the abandonment is silent.

When Microsoft ends support for Windows Server 2016 in January 2027, the organisation running it receives explicit notice. The vendor names the date, names the consequence, and the administrator can make an informed decision. When HPE released SPP 2022.08.0_hotfix_3 as the final Gen9 update in August 2022, there was no announcement that this SPP would represent the last firmware update for Secure Boot certificate compatibility. There was no communication in 2024 or 2025 to Gen9 customers that their hardware would be unable to complete the 2026 certificate transition.

An administrator managing a Gen9 estate would have had no reason to know their hardware was about to become permanently non-compliant from a Secure Boot perspective. Nothing in the Gen9 firmware release history, nothing in HPE's communications, nothing in the HPE advisory published in March 2026 (which doesn't mention Gen9 at all) communicates this. The administrator discovers it operationally: a BIOS date check and SPP release review reveals no 2026 SPP exists for the platform, and the path forward turns out not to exist.

The silent abandonment problem: Organisations cannot plan for a remediation constraint they do not know exists. An organisation that received Gen9 hardware in 2015, maintained it diligently through its support lifecycle, and applied every available SPP update is now discovering in 2026 that those efforts were insufficient — because the firmware update they needed was simply never published, and no one told them it wasn't coming.

8.5 What to Do With Stranded Hardware

The correct answer for stranded hardware is hardware replacement. That answer is also, for many organisations, not immediately executable. Procurement lead times are measured in weeks to months. Budget approval processes have their own timelines. Migrations involve re-racking, re-cabling, VM migration, and testing. An organisation that learns in April 2026 that its Gen9 fleet cannot be remediated is not replacing that hardware before June 2026.

The operational reality is that a fraction of enterprise infrastructure will cross the June 2026 deadline unremediated. The goal is not to pretend otherwise. The goal is to manage the resulting risk honestly.

• Inventory and classify. Identify every server in the estate that falls into the unremediated category. Check BIOS firmware dates, cross-reference against the vendor SPP release catalogue, and confirm whether a 2026-era SPP exists for the platform. Stranded hardware will have no SPP entry for the 2026 certificate cycle.
• Document formally with risk acceptance. Each stranded server or VM cluster should have a documented exception: the specific hardware, the specific reason remediation is not possible, the risk it carries after June 2026, the compensating controls in place, and the authorising signature. This is the difference between an organisation that knows what it has accepted and one that doesn't.
• Compensating controls are not optional. Stranded hardware operating after June 2026 should be subject to: network segmentation from internet-facing and management networks where possible; EDR coverage with boot-process monitoring; enhanced logging of UEFI variable access attempts; and regular review against new DBX revocations and bootkit disclosures.
• Accelerate the hardware refresh plan. If Gen9 replacement was planned for 2027 or 2028, the case for pulling that timeline forward is now documented. The risk is quantifiable — Section 6 provides the BlackLotus precedent, and the next bootkit will come.
• Do not disable Secure Boot as a workaround. A system with expired 2011 certificates still validates boot binaries against those certificates. A system with Secure Boot disabled validates nothing. The degraded state is better than the disabled state.
• Treat every new Boot Manager CVE as a stranded-fleet incident response trigger. After June 2026, each new Secure Boot bypass vulnerability will widen the gap between the stranded fleet and the remediated fleet. Each such event should trigger a review of whether stranded systems need additional compensating controls or accelerated replacement.

8.6 The Duty That Was Not Owed (and Should Have Been)

Hardware vendors are not legally obligated to provide Secure Boot certificate updates for hardware past its end of service life. The support contracts that govern Gen9, Dell 12G/13G, and equivalent hardware do not promise firmware updates beyond the support period. The vendor has met its contractual obligations.

This is technically correct and operationally inadequate.

The 2011 Secure Boot certificates were issued by Microsoft and embedded in server firmware by hardware vendors who knew — because they embedded the certificate — that those certificates had a fifteen-year lifespan. The certificate expiry was not a surprise to any firmware engineer who implemented the platform. When HPE released a server in 2014 with a certificate expiring in 2026, that server had a twelve-year window before the certificate issue would arise. HPE's hardware support contract covered five years. The gap between support contract end and certificate expiry was seven years.

The enterprise customer who bought that server in 2014 was told: your support contract covers five years, and then you're on your own. They were not told: the security component that validates your server's boot chain has a twelve-year lifespan, and after five years, any remediation that requires a firmware update will be your problem to solve with no vendor assistance.

The industry norm this exposes: Vendors define "support" in terms of their obligations, not in terms of what customers need. A server purchased for a seven-to-ten year data centre lifecycle was sold with a five-year support contract that terminated before the embedded security certificate required a firmware update to remain effective. The customer's asset is still running. The vendor's obligation is over. The security gap is the customer's problem. This is how hardware abandonment works, and the 2026 Secure Boot transition is a large-scale case study in its consequences.

Section 12 — the conclusion — returns to this question from the perspective of what the ecosystem's duty of care should look like, and what the 2026 transition suggests about whether the current model serves the people who depend on it.

Section 9 covers the VMware compound problem — the specific combination of NULL PK, ESXi version constraints, and Broadcom's current inability to provide an automated fix that makes the VMware remediation path the most complex and resource-intensive element of the 2026 transition for most enterprise estates.

Section 9 — The VMware Compound Problem

Why the virtualised estate is not a simplification of the physical one — and why three independent failure conditions must all be resolved in sequence before a single VMware VM can receive its 2023 certificates.

9.1 Not One Problem, Three

Every VM in a VMware estate running Windows with Secure Boot enabled faces the 2026 certificate transition with a structural disadvantage that physical servers do not share. A physical server needs one thing to be correct: its host firmware must contain the 2023 certificates. Apply the SPP, reset the BIOS keys, run Stage 1 and Stage 2 on the OS. Done.

A VMware VM needs four things to be correct — simultaneously, in order, with each layer a prerequisite for the next. The failure modes are independent. Correcting one layer does not advance the others. Getting three of four layers right produces a VM that fails remediation just as completely as a VM where nothing has been done.

The four layers are:

• Layer 1 — Host ROM: The physical host's UEFI firmware must contain the 2023 certificates. Delivered via HPE SPP 2026.01+, followed by a mandatory BIOS Secure Boot key reset to factory defaults. Without this, NVRAM regen in Layer 3 reseeds 2011 certs from the stale host template. All VM work built on a Layer 1 that isn't correct is wasted.
• Layer 2 — ESXi version: The host must be running ESXi 8.0.2 or later. NVRAM regen is not available on ESXi 7.x or ESXi 8.0.0/8.0.1. An ESXi upgrade is a separate project from the certificate transition.
• Layer 3 — VM NVRAM: The VM's virtual NVRAM — stored as a per-VM .nvram file on the datastore — must contain the 2023 certificates and a valid, enrolled Platform Key. This requires NVRAM regen (rename the .nvram file; ESXi regenerates it from the host template on next power-on) followed by PK enrollment. Without a valid PK, the Windows Update task hard-blocks at Event 1803.
• Layer 4 — Guest OS: The Windows guest must be at minimum patch level, the AvailableUpdates registry key must be set, and the Secure-Boot-Update scheduled task must run and complete.

The compound failure: Every layer is a hard gate. Layer 1 wrong → Layer 3 is wasted. Layer 2 wrong → Layer 3 is impossible. Layer 3 wrong (NULL PK) → Layer 4 hard-blocks. There is no partial credit. A VM with Layers 1, 2, and 4 correct but Layer 3 wrong will sit at UEFICA2023Status = InProgress indefinitely, reporting success at every step except the one that matters.

9.2 The NULL PK: Why It Exists and What It Blocks

The Platform Key (PK) is the root of the UEFI Secure Boot hierarchy. It authorises updates to the Key Exchange Key (KEK). The KEK authorises updates to the DB and DBX. Without a valid PK, nothing in the trust chain can be updated — the variable write is rejected by firmware as unauthenticated.

On physical hardware, the PK is enrolled by the OEM at the factory. It is never NULL.

On VMware VMs created before ESXi 8.0.2, the PK in the virtual NVRAM is a NULL placeholder. Not an OEM-signed key. Not a Microsoft-signed key. A NULL value that satisfies the UEFI variable structure but provides no cryptographic authority. The reason is architectural: ESXi's virtual UEFI implementation, in versions prior to 8.0.2, did not enroll a proper PK into the virtual NVRAM at VM creation time.

This means: on any VM created before ESXi 8.0.2, the entire Layers 1–2 remediation produces a VM that has the right certificates in its host ROM but cannot write them to its own virtual NVRAM. Stage 1 runs, sets the registry key, triggers the scheduled task, and the task returns exit code 2: NULL Platform Key detected.

How many VMs are affected: ESXi 8.0.2 was released in September 2023. Any VM created before September 2023 — which is the overwhelming majority of production VMware VMs — has a NULL PK. In a typical enterprise VMware estate, the affected population is not a fraction of the inventory. It is nearly all of it.

9.3 NVRAM Regen: The Fix That Requires Conditions

The NVRAM regen procedure resolves the NULL PK by forcing ESXi to regenerate the VM's virtual NVRAM file from the current host template. The procedure:

1. Snapshot the VM (mandatory — this is the rollback point).
2. Power off the VM.
3. Rename the VM's .nvram file (e.g., vm.nvram → vm.nvram_old) on the ESXi datastore.
4. Power on the VM. ESXi detects the missing .nvram file, generates a new one from the host boot-bank template seeded with 2023 certs.
5. Enroll the proper Windows OEM Devices PK — the placeholder PK written by regen is not sufficient for forward compatibility.
6. Proceed with Stage 1 on the guest OS.

This procedure has four hard prerequisites that must all be true before it produces a correct result:

• Host ROM at SPP 2026.01+. NVRAM regen on a host with pre-2023 ROM reseeds 2011 certs. The procedure completes with no error and produces the wrong state.
• Host rebooted after SPP. ESXi reads its boot-bank template at boot time. Regen against a stale template (SPP applied but no reboot) produces 2011 certs. This failure looks identical to a successful regen until Stage 1 runs.
• ESXi 8.0.2 or later. NVRAM regen does not exist on earlier versions.
• VM hardware version 21 (vmx-21) or later. ESXi 8.0.2 only seeds 2023 certificates into regenerated NVRAM for VMs at hardware version 21 or later. VMs at version 13–20 produce an empty NVRAM after regen — no 2023 certs, no 2011 certs — with no error. The VM boots from empty NVRAM. The failure only surfaces during Stage 1 execution.

The vmx-21 requirement is frequently missed. A VM at hardware version 17 on ESXi 8.0.2+ will complete NVRAM regen without errors and boot successfully — then fail Stage 1 because the NVRAM contains no certificates. There is no error during the regen step. Upgrade VM hardware version to vmx-21 before regen.

9.4 The PK Problem After Regen

NVRAM regen on ESXi versions prior to 9.0 does not produce a fully remediated VM. It produces a VM with the correct DB and KEK certificates but with a placeholder PK rather than a proper Microsoft-signed Windows OEM Devices Platform Key.

Stage 1 and Stage 2 will complete and UEFICA2023Status will reach Updated. The problem is prospective: the placeholder PK will not authenticate future Windows Update KEK changes using the standard authenticated variable update protocol. A VM remediated with a placeholder PK is correct for June 2026 but may not be able to receive future certificate updates pushed via the normal Windows update channel.

Broadcom KB 423919 documents this and provides the resolution: enroll the proper Windows OEM Devices PK via either the SetupMode method or the uefi.allowAuthBypass VMX flag method.

The uefi.allowAuthBypass = "TRUE" VMX flag is the faster approach for bulk remediation. It works. It is also explicitly unsupported by Broadcom. KB 421593, which documented the original procedure, was removed without replacement. The current Broadcom position is silence: the flag is not referenced in any current KB, and its function is documented only by the community and Broadcom's own withdrawn documentation.

9.5 Broadcom's Position: No Automated Fix

Broadcom KB 423893, updated March 2026: "There is no automated resolution available at this time."

This means: there is no vSphere plugin, no PowerCLI cmdlet, no ESXi host-level script, no VMware Tools integration, no vCenter workflow, and no VMware/Microsoft partnership mechanism that will enumerate an organisation's VMs, identify the ones with NULL PK, perform NVRAM regen, enroll the proper PK, apply the minimum CU, set the registry key, run Stage 1, run Stage 2, and verify the result — automatically, without administrator intervention for each VM.

The automation that exists is community-built — PowerShell toolkits developed and published by practitioners on GitHub automate the per-VM steps within a maintenance window. They do not remove the requirement for human decision-making, the snapshot-before-each-VM discipline, BitLocker recovery key verification, or post-Stage-2 verification. Broadcom has not provided an equivalent official tool.

Broadcom's KB 423893 closes by noting that ESXi 9.0 introduces a proper Microsoft-signed PK — eliminating the placeholder PK problem and enabling an automated fix path. No ESXi 9.0 release date was confirmed as of April 2026. For organisations that cannot wait, the manual path is the only path.

The Broadcom timeline gap: The company that owns the virtualisation platform used by the majority of enterprise data centres was five months late with its first advisory, cannot provide an automated fix, has removed the original manual procedure documentation without replacement, and is pointing to a future product version as the eventual resolution — with no confirmed release date. The operational consequence lands on the engineers responsible for remediating thousands of VMs by June 26.

9.6 The Scale Problem

The manual nature of the VMware remediation path has a scale dimension that enterprise playbooks understate. In an estate of hundreds or thousands of VMs, the per-VM procedure is not a remediation. It is a programme of work.

What must be true before Stage 1 runs — per VM:

The specific scale challenges:

• Maintenance windows. NVRAM regen requires a VM power-off. In an estate of thousands of production VMs, scheduling maintenance windows across all of them before June 2026 is a project management exercise in its own right.
• BitLocker/vTPM VMs are higher-risk. NVRAM regen changes the Secure Boot variable state and may trigger BitLocker recovery. A missing or incorrect recovery key on a production VM after a failed regen is a data-loss event.
• Sequencing errors propagate silently. NVRAM regen on a host that hasn't had its SPP applied produces no error — it produces wrong-cert state that appears correct until Stage 1 runs, potentially weeks later.
• ESXi upgrade adds another variable. Organisations running ESXi 7.x on Gen10/11/12 hardware need to complete an ESXi upgrade to 8.0.2+ before NVRAM regen is possible. That upgrade must be done via ISO — not via ESXCLI, which breaks VIB signatures and leaves the ESXi host with a broken Secure Boot chain.

9.7 ESXi 9.0 and the Path Out

ESXi 9.0 resolves the structural issue. It introduces a proper Microsoft-signed Windows OEM Devices PK at VM creation time — eliminating the placeholder PK problem entirely. For the existing installed base, ESXi 9.0 is expected to provide an automated migration path. Broadcom describes this as "in active development" as of April 2026. No release date is confirmed.

ESXi 9.0 is not a June 2026 solution. For the June 2026 deadline, the manual path on ESXi 8.0.2+ is the only path, and it must be executed now.

Section 10 covers the Hyper-V path — its fundamentally different architecture, the OS-shipped template model, the KEK write-protect bug, and the Template Toggle workaround that was not in the initial playbook. Section 11 covers what breaks, what doesn't break, and what is frozen across both the remediated and unremediated populations.

Section 10 — The Hyper-V Path: OS Templates, Write-Protect Bugs, and the Toggle

Why Hyper-V is not ESXi with different names — and why applying SPP to the physical host does nothing for the VMs running above it.

10.1 The Architecture That Changes Everything

The most dangerous assumption an engineer can bring to a Hyper-V remediation is knowledge of the VMware path. The layer structure looks similar. The end goal — UEFICA2023Status = Updated on every Gen2 VM guest — is identical. The mechanism is different in every respect that matters operationally.

ESXi reads its virtual machine firmware certificates from the physical host ROM. Apply the SPP, reboot the host, regen the VM NVRAM, and the VM has 2023 certs. The path runs: ROM → ESXi boot-bank template → VM .nvram file.

Hyper-V does not read the physical host ROM to supply certificates to VMs. Not at all. Not as a fallback. Not for initialisation. The Hyper-V virtualisation layer ignores the host UEFI firmware entirely when determining what Secure Boot certificates its Gen2 VMs receive. Instead, it uses Secure Boot template files that ship embedded in the Windows Server operating system itself. The template is named MicrosoftWindows, and it contains the certificates that every newly created Gen2 VM inherits. The path runs: Windows Server OS template → Hyper-V virtual firmware → Gen2 VM vFirmware.

The operational consequence: Applying SPP 2026.01+ to the physical host running Hyper-V updates the host's own physical UEFI ROM — necessary for the host's own Secure Boot integrity. It does nothing for the certificates served to Gen2 VMs. An organisation that applies SPP to every Hyper-V host and considers the VM layer addressed has done zero VM remediation. The VM layer requires a Cumulative Update applied to the Hyper-V host OS.

10.2 Two Problems Running Simultaneously

Hyper-V environments face two compounding issues that must both be resolved before remediation can complete.

Problem 1 — Stale OS templates

Every Windows Server OS ships with a MicrosoftWindows Secure Boot template containing the certificates in effect at release time. For Windows Server 2022 hosts deployed before 2026, that template contains the 2011 certificates. Every Gen2 VM created on that host inherits 2011 certs.

The March 2026 Cumulative Update for each supported Windows Server version updates this template to include the 2023 certificates alongside the 2011 certificates. Until that CU is applied to the Hyper-V host and the host is rebooted, every Gen2 VM on that host will receive 2011 certs. Stage 1 run on a guest on an unpatched Hyper-V host will fail — the update task runs, writes nothing new to the DB, and UEFICA2023Status stays at NotStarted.

Problem 2 — KEK write-protection bug (Event 1795)

Before the March 2026 CU, there was a bug in how Hyper-V presented the virtual KEK variable to Gen2 VM guests. The KEK variable was write-protected at the virtual firmware level. When Stage 1 attempted to write the new KEK 2K CA 2023 certificate, the write was rejected with Event ID 1795 — "The media is write protected" / error code 0x80070013. The guest reported a hard failure at the first write operation.

This bug affected existing Gen2 VMs on unpatched hosts. The fix required the March 2026 CU applied to both the Hyper-V host (to update the template and the virtual firmware presentation layer) and the Gen2 VM guest (to provide the client-side enrollment tooling capable of working with the updated virtual firmware).

Event 1795 means different things in different environments. On VMware, Event 1795 typically indicates a host ROM mismatch — the SPP hasn't been applied, or the BIOS key reset wasn't performed. On Hyper-V, Event 1795 on an existing Gen2 VM typically indicates the KEK write-protect bug — the March 2026 CU hasn't been applied to the guest. The same event ID, two completely different root causes, two completely different fixes. An engineer who diagnoses Event 1795 on a Hyper-V guest using VMware troubleshooting instincts will spend time looking at hardware that isn't the problem.

10.3 The Template Toggle

Even after the March 2026 CU is applied to both the Hyper-V host and the Gen2 VM guest, a subset of existing VMs may still fail Stage 1 with Event 1795. These VMs have a virtual KEK variable that remains in the write-protected state from their original NVRAM initialisation, despite the CU.

The resolution is the Hyper-V Secure Boot Template Toggle — documented primarily through community investigation and confirmed by Microsoft at the February 2026 Tech Community AMA. It is not in the initial version of the Windows Server Secure Boot Playbook.

The toggle forces Hyper-V to refresh the VM's virtual firmware with the host's current certificate template, clearing the write-protection state of the KEK variable:

1. Shut down the VM gracefully.
2. Open Hyper-V Manager → select the VM → Settings → Security.
3. Change "Secure Boot Template" from "Microsoft Windows" to "Microsoft UEFI Certificate Authority".
4. Click Apply.
5. Change "Secure Boot Template" back to "Microsoft Windows".
6. Click Apply / OK.
7. Start the VM.

Two prerequisites before the toggle does anything useful: (1) The March 2026 CU must be applied to the Hyper-V host — otherwise the host's template still contains 2011 certs and the toggle refreshes the VM with the wrong state. (2) The toggle must be performed on a powered-off VM. The toggle does not complete the remediation — the guest CU must still be applied and Stage 1 must still run.

The toggle adds a mandatory VM shutdown before Stage 1. Combined with Stage 1's own two-reboot requirement, the minimum reboot count per affected VM is three. In environments where VM reboots require maintenance windows, this operational overhead must be factored into scheduling.

10.4 New VMs vs Existing VMs: A Critical Distinction

VMs created after the March 2026 CU has been applied to the Hyper-V host automatically receive the 2023 certificates from the updated template. They do not need the Template Toggle. They do not exhibit Event 1795. They require only the CU on the guest OS and Stage 1/2.

VMs created before the CU was applied carry their original NVRAM state initialised from the pre-CU template containing only 2011 certs. These VMs need the Template Toggle if Event 1795 is present.

The practical implication: provisioning teams should be informed that new Gen2 VMs created after the host CU is applied should go directly to Stage 1 without the toggle step. Applying the toggle to VMs that don't need it adds unnecessary reboots.

10.5 The Remediation Sequence in Full

Wave 1 — Physical Host

• Apply HPE SPP 2026.01+ to the physical host (required for host's own Secure Boot integrity and for Option ROM CA 2023 hardware compatibility).
• Reboot the physical host after SPP.
• Apply the March 2026 CU to the Hyper-V host OS. This is the step that updates the MicrosoftWindows Secure Boot template. Without it, no VM on this host can receive 2023 certs regardless of what is done at the guest level.
• Reboot the Hyper-V host after the CU (required for the template update to activate).

Wave 2 — Existing Gen2 VMs (each VM)

• Apply the March 2026 CU to the Gen2 VM guest OS. This fixes the KEK write-protect bug inside the guest.
• Reboot the guest.
• If Stage 1 fails with Event 1795: apply the Template Toggle (shut down VM, toggle Security template setting, restart VM).
• Run Stage 1 on the guest (set AvailableUpdates=0x5944, run Secure-Boot-Update scheduled task).
• Stage 2 runs automatically on startup — requires two reboots.
• Verify: UEFICA2023Status = Updated and 'Windows UEFI CA 2023' present in DB bytes.

Skip entirely

• Gen1 VMs — no UEFI, no Secure Boot, permanently excluded.
• NVRAM regen steps — not applicable to Hyper-V. There is no .nvram file to rename.
• Legacy/BIOS mode Hyper-V hosts — Secure Boot requires UEFI mode. Conversion is a separate project.

10.6 Azure: The Contrast That Explains Why On-Premises Is Hard

Azure's Trusted Launch VMs face the same certificate transition — the guest OS still needs Stage 1 — but the virtual firmware layer is owned and managed by Microsoft's Azure platform. There is no NVRAM file on a datastore. There is no NULL PK. There is no Template Toggle. There is no vendor advisory saying "no automated resolution available."

For Trusted Launch VMs, Microsoft applied the platform-level certificate update automatically and transparently. High-confidence VMs received it without any customer action. The guest still needs the CU and Stage 1 to complete the DB and Boot Manager update, but the hardest layer was handled by the platform provider.

The contrast is instructive. The reason the on-premises paths are complex is that the customer owns the virtual firmware layer. On VMware, that means owning the .nvram file, the ESXi version, the host ROM, and the NULL PK remediation. On Hyper-V, it means owning the OS template version, the CU sequencing, and the KEK write-protect bug workaround. On Azure, it means owning nothing below the guest OS.

The 2026 transition didn't create that structural difference. It made it visible.

Section 11 covers what breaks, what doesn't, and what is frozen — the reference guide that states precisely what a system can and cannot do after June 26, 2026 depending on whether it has been remediated.

Section 11 — What Breaks, What Doesn't, What's Frozen

The complete reference guide: what a system can and cannot do after June 26 and October 19, 2026 — across fully remediated, unremediated, and stranded hardware populations.

11.1 How to Use This Section

This section does not repeat the remediation procedures covered in Sections 9 and 10. It is a reference for a specific question: given a system in a specific state after the certificate expiry dates have passed, what specifically happens and what specifically does not?

Three populations are covered throughout:

• Remediated — systems that have received the 2023 certificates via the correct remediation path. UEFICA2023Status = Updated.
• Unremediated — systems technically capable of receiving the 2023 certificates but that have not yet done so.
• Stranded — systems on hardware or hypervisor versions that cannot receive the 2023 certificates by any supported means: Gen9, Dell 12G/13G, ESXi 7.x with no upgrade path, Hyper-V Gen1 VMs.

Two distinct deadlines with different consequences: June 26, 2026 (KEK CA 2011 and UEFI CA 2011 expire) and October 19, 2026 (Windows Production PCA 2011 expires).

11.2 The Master Reference Table

Booting & Runtime Operation

Windows Updates & Patching

Hardware Compatibility & Firmware

Linux & Cross-Platform

Deployment, Recovery & Media

Security Posture & Future Mitigations

11.3 The WDS/PXE Inversion Problem

The deployment and recovery rows above contain a counterintuitive pattern. After October 2026:

• Remediated systems break on old media. A fully remediated system trusts only 2023-signed Boot Manager. WDS boot images, WinPE ISOs, and recovery drives built before October 2026 contain 2011-signed Boot Manager binaries. Remediated systems will refuse to boot them.
• Unremediated systems work fine with old media. A system that hasn't received the 2023 certificates still trusts the 2011-signed Boot Manager and boots old WDS/WinPE media without issue.

This creates a precise sequencing dependency: WDS/PXE infrastructure must be updated with Make2023BootableMedia.ps1 before or simultaneously with the guest certificate remediation wave. The window between "some guests remediated, WDS not yet updated" is the window where those remediated guests cannot be redeployed or recovered via WDS.

The recovery media risk is the most dangerous consequence. The first time most organisations discover that their recovery media no longer boots their remediated servers is during a crisis — a failed boot, a corrupted OS volume, a disaster recovery exercise. Test recovery media against remediated systems before the guest remediation wave begins. Not after.

11.4 The Frozen Posture: What It Means in Practice

The frozen posture is not a failure state. The system runs. The OS patches. The applications execute. The certificates already in DBX continue blocking the currently-known-bad boot binaries.

What stops advancing is the boundary between the known-bad list and reality. Every boot-level vulnerability discovered after June 2026 will have a DBX revocation that Microsoft publishes. On a remediated system, that revocation reaches the DB. On an unremediated or stranded system, the revocation is signed by a KEK that the system cannot authorise — the write is rejected, and the system's DBX stays where it was on June 25, 2026.

The gap between the frozen DBX and the current DBX grows with every new Boot Manager CVE. The growth rate is determined by the vulnerability discovery rate — which has been high and consistent since 2022. The practical question is not "is it safe right now?" It is "how long until a bootkit appears that exploits a DBX gap this system cannot close?" BlackLotus demonstrated that gap can be measured in months.

The frozen posture summary: The machine runs. All OS-level security patches install. Data-at-rest encryption remains intact. DBX revocations applied before June 2026 remain in effect. What stops: new DBX revocations, new DB cert additions, new Boot Manager security updates. The security posture is fixed at June 25, 2026. Every day after, the gap between that posture and the current threat landscape widens.

11.5 The Silent Failure Inventory

Several consequences of the unremediated state are silent — they produce no error, no event log entry, and no visible operational failure at the time they occur.

Section 12 covers what engineers should do — the consolidated action list across all populations and all deadlines, ordered by priority and deadline pressure.

Section 12 — What Engineers Should Do

The consolidated action list, ordered by priority and deadline pressure, covering all populations from fully remediable to stranded hardware.

12.1 The Priority Stack

This section is addressed to the engineer holding the remediation programme. Five priority levels. Work from P0 downward. Do not start P2 until P0 and P1 are complete for the relevant hosts. The priority order is not preference — it is sequencing dependency.

12.2 The Three Things Most Likely to Go Wrong

1. SPP applied, BIOS key reset skipped

The SPP updates the physical ROM with 2023 certificates. The certificates are physically in the firmware — in the default certificate store, activated when you perform a Secure Boot key reset to platform defaults. If that reset step is not performed, the active Secure Boot variables still reflect the previous certificate set. Any VM cert regeneration procedure run on a host where SPP was applied but the BIOS reset was skipped will reseed 2011 certs from the pre-reset active variables.

Detection: check whether the BIOS Secure Boot key reset has been performed by verifying the active KEK and DB contain 2023 certificates (via Get-SecureBootUEFI db on the host OS, or via BIOS setup review). Fix: BIOS → System Utilities → BIOS/Platform Configuration → Server Security → Secure Boot Settings → Reset Secure Boot Keys to Factory Defaults. Reboot and re-verify.

2. KB 423919 cert enrollment on a vmx-<21 VM

ESXi 8.0.2 only seeds 2023 certs into the NVRAM for VMs at hardware version 21 or later. Running KB 423919 procedures (auth bypass or SetupMode) on a VM at v17 may produce empty or 2011-only NVRAM state. Stage 1 then reports no certificates present and the procedure must be repeated after upgrading the hardware version.

Prevention: upgrade VM hardware version to vmx-21 before running KB 423919. Get-VM "VMName" | Set-VM -HardwareVersion vmx-21 -Confirm:$false. Run on powered-off VM only.

3. Hyper-V host CU not applied before Stage 1

If Stage 1 is run on a guest before the host CU has been applied and the host rebooted, the guest's virtual firmware still presents 2011 certs. Stage 1 runs and technically completes — but what it wrote was already present. UEFICA2023Status reaches Updated incorrectly. The 2023 certs are not in the DB.

Detection: verify the DB bytes directly: [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'. A status of Updated without this string means the update wrote 2011 certs redundantly.

12.3 The Special Cases

VeraCrypt

Do not complete Stage 1 Step 3 (DB revocation of UEFI CA 2011) on any system running VeraCrypt full-disk encryption. DcsBoot.efi is signed with UEFI CA 2011. Once UEFI CA 2011 is revoked from DB, the encrypted volume is inaccessible.

Correct path: run Stage 1 Steps 1–2 only (KEK and DB cert additions). Defer Step 3 (revocation). Monitor VeraCrypt GitHub issue #1655 for v1.27 with 2023-CA-signed DcsBoot.efi. Complete Step 3 only after that release is applied.

Symantec Endpoint Encryption

Do not apply KB5025885 full revocation stages to SEE systems. Do not run Stage 1 on SEE systems. Microsoft-documented incompatibility in KB5025885. Contact Broadcom for roadmap. Maintain formal exception documentation.

ESXi 7.x estates that cannot be upgraded before June 2026

Options: (1) accept unremediated VM state on these hosts with risk acceptance and compensating controls; (2) follow KB 423919 Auth Bypass method (uefi.allowAuthBypass = "TRUE" + FAT32 disk with cert files + UEFI setup screen PK enrollment) — KB 423919 applies to all ESXi versions including 7.x; proceed with snapshots and test on pilot VMs first; (3) treat ESXi upgrade as an emergency project with the same urgency as the certificate remediation.

Bare metal Windows Server (no hypervisor)

The simplest path. SPP + BIOS key reset on the host, then Stage 1/2 directly on the OS. No hypervisor VM layer, no PK enrollment, no Template Toggle.

Windows Server 2016

Technically remediable (KB5073722 minimum, build 14393.8783). But WS2016 reaches EOL January 2027 — seven months after June 2026. Before investing significant effort in WS2016 Secure Boot remediation, confirm the server's decommission timeline. If decommission is planned before January 2027, a formal risk acceptance deferring Secure Boot remediation may be more appropriate than executing a full remediation wave on hardware scheduled for replacement.

12.4 After June 26

The June 26 deadline does not end the programme. It ends the window for clean, proactive remediation.

• Unremediated systems are now in a degrading posture. Continue remediation on remaining systems. Each additional remediated system is a system that can receive the next DBX revocation.
• Monitor for the WDS/PXE inversion. Know your WDS update state before remediating any client. Remediated clients will fail to PXE boot from old media.
• Watch every Boot Manager CVE. Each new CVE represents a DBX revocation that remediated systems will receive and stranded systems will not. Treat each as a prompt to re-evaluate compensating controls for stranded hardware.
• October 19 is the second deadline. WDS/PXE boot images and all recovery media must be updated with Make2023BootableMedia.ps1 before that date. Test every recovery path before October.
• Monitor VeraCrypt and SEE. Track VeraCrypt v1.27 and Broadcom SEE roadmap. These are the two open blocking issues. Each month without resolution is a month those systems remain in an exception state.

Section 13 — the conclusion — addresses the question this paper has been building toward: not what engineers should do about the 2026 transition specifically, but what the 2026 transition reveals about the ecosystem's obligations to the people who depend on it.

Section 13 — Conclusion: The Ecosystem's Duty of Care

13.1 What This Paper Was Actually About

The remediation steps for the 2026 Secure Boot certificate transition are documented. Microsoft has published them. The procedures exist, the registry keys are specified, the CU requirements are named. Engineers who follow Section 12 of this paper, apply the vendor playbooks, and execute the wave order will have remediated systems on the other side of June 26.

That was not what this paper was about.

This paper was about why those engineers are in this position at all — managing a compressed, partially undocumented remediation wave across infrastructure they did not choose to make vulnerable, against a deadline they were not adequately warned about, for a problem that the industry had fifteen years to communicate and mostly chose not to. The remediation steps are the answer to the engineering question. The question this paper was written to address is different: what does the 2026 Secure Boot transition reveal about how the vendor ecosystem treats the people who depend on it?

The answer is not flattering.

13.2 Three Failures, Named Directly

The 2026 transition is the product of three distinct failures, each owned by a different part of the ecosystem. They are not equally severe. They are all real.

Microsoft's communication failure. The first public announcement naming the certificate expiry, the deadline, and the need for action appeared in February 2024. The enterprise-grade Windows Server Secure Boot Playbook — the document containing actionable remediation steps for the environments most affected — appeared in February 2026. The alarm bell blog post appeared in January 2026. That is five months of practical notice for a problem Microsoft had documented, in public, for two years. The notification path — a blog post on a technical channel not surfaced in any enterprise management toolchain — systematically failed to reach the administrators responsible for acting on it. The disclosure was technically adequate. The communication was not.

Broadcom's negligence. The company that owns the virtualisation platform running the majority of enterprise data centres published its first VMware-specific advisory in January 2026 — five months before the deadline. That advisory confirmed there was no automated remediation path for the NULL PK problem affecting the overwhelming majority of production VMs. The original manual procedure document (KB 421593) had already been removed without replacement. The current documented approach (KB 423919) addresses PK enrollment but not the root cause. The roadmap points to ESXi 9.0 with no confirmed release date. Broadcom's handling of this transition gave its customers the shortest notice of any major vendor involved, for the most complex remediation path, with the least automation support. That is not a sequence of unfortunate coincidences. It is a pattern of inadequate stewardship of infrastructure that millions of organisations depend on.

The hardware abandonment problem. HPE Gen9 reached End of Service Life in July 2025. Its last SPP shipped in August 2022. That SPP does not contain the 2023 certificates. No subsequent update was published. No advisory communicated this to Gen9 customers. No document from HPE says "Gen9 cannot be remediated" — that conclusion must be inferred by an engineer who notices Gen9's absence from the advisory that covers Gen10, Gen11, and Gen12.

The 2011 Secure Boot certificates were embedded in Gen9 hardware by HPE in 2014 with a twelve-year lifespan. HPE's support contract for that hardware covered five years. The gap between support contract end and certificate expiry is seven years — and in that gap, the security component embedded at shipment became unrepairable, with no vendor communication to the customer about when or why.

This is not a Gen9 problem. Dell 12G and 13G, Lenovo System x, Fujitsu PRIMERGY pre-2017 — the same arithmetic applies to every hardware generation from every vendor that shipped with 2011 certificates and subsequently passed its support end date without a 2023-certificate firmware update. The specific manufacturers and model numbers differ. The structure is identical.

The common thread across all three failures: each vendor defined its obligation in terms of what it was contractually required to do, not in terms of what the customer needed. Microsoft published the disclosure — technically adequate. Broadcom published an advisory — five months before deadline. HPE shipped firmware updates for supported hardware — omitting the hardware it no longer supported, without saying so. Every obligation was technically met. The customers were left to discover the gaps operationally.

13.3 What a Duty of Care Actually Looks Like

The phrase "duty of care" is not a legal concept in this context. It is a description of what the relationship between infrastructure vendors and the engineers who depend on them should involve — and what the 2026 transition demonstrates it currently does not.

A vendor that ships hardware with an embedded security component carrying a fixed expiry date has a duty to communicate, well in advance of that expiry, whether the hardware will receive a firmware update that addresses the transition — and if not, when that determination was made and why. This communication should not require the customer to notice the hardware's absence from a new advisory. It should be proactive, specific, and delivered through the same channels as the original product support communications.

A vendor that owns the virtualisation layer running the majority of enterprise production infrastructure has a duty to give that infrastructure's operators adequate notice and adequate tooling when a platform-level change requires per-VM manual remediation at scale. Five months is not adequate notice for an estate of thousands of VMs. "No automated resolution available" without a committed timeline for one is not adequate tooling.

A software vendor that has known about a fifteen-year certificate expiry since the certificates were issued has a duty to communicate the operational implications to its enterprise customers with enough lead time to execute a real remediation programme. Not a blog post in a channel that engineers don't read. A service health notification. An update in the management console. An item on the Windows Admin Center dashboard. Something that reaches the person responsible, not just the person who monitors firmware engineering blogs.

None of this is technically difficult. All of it was technically possible at any point in the last fifteen years. The barrier was not capability. It was prioritisation — or more precisely, the absence of it.

13.4 The Linux Community's Lesson

Section 5 of this paper observed that the engineers who most thoroughly understood UEFI Secure Boot were Linux developers — not because they are more diligent, but because the architecture of Secure Boot was hostile to Linux, and survival required deep understanding. The shim review board, the SBAT mechanism, James Bottomley's 2012 canonical reference document — these are products of an ecosystem that was forced to engage with the machinery of UEFI trust because the alternative was non-booting distributions.

The Linux community also demonstrated, through SBAT, that it is possible to design a revocation mechanism that scales — that does not consume a finite, irrecoverable resource with every mitigation. The Windows boot chain has no equivalent. Every BlackLotus mitigation, every future Boot Manager CVE, continues to consume DBX space that cannot be recovered.

The 2026 transition is partly a story about what happens when you do not have to engage deeply with the infrastructure you depend on. The Linux community had no choice. Windows-first organisations did — and the choice, for most of them, was not to engage until the deadline made it unavoidable.

13.5 The Question This Leaves Open

The 2026 Secure Boot transition will end. The June 26 deadline will pass. The October 19 deadline will pass. Organisations that executed will have remediated systems. Organisations that deferred will have stranded ones. The programme of work described in Section 12 will eventually be complete, or formally excepted, or simply carried as background risk.

The question the 2026 transition leaves open is whether the industry learns from it.

The structural conditions that produced this situation are not specific to Secure Boot certificates. Every piece of hardware ships with embedded security components that have finite lifetimes. Every platform dependency has a maintenance window that ends before the customers stop using the platform. Every communication gap between vendor engineering teams and enterprise operations teams is a gap through which the next equivalent problem will pass undetected until it is too late for a clean, planned response.

The 2026 transition is a large-scale case study in what happens when those conditions interact: a fifteen-year clock, a five-year support contract, communication channels that reach researchers but not operators, and a virtualisation platform whose remediation path requires manual per-VM work with no supported automation. The specific combination is unusual. The underlying structure is not.

The engineers who executed this remediation — who read the advisories when they appeared, understood the layered architecture well enough to know what sequence the work had to follow, managed the maintenance windows and the BitLocker recovery keys and the KB 423919 procedures, and got their estates to UEFICA2023Status = Updated before June 26 — did so despite the disclosure failures, not because of adequate vendor support. They deserved better preparation from the ecosystem they depend on.

The conclusion of this paper is not that the 2026 transition was uniquely badly handled. It is that the industry has a repeating pattern of treating security component lifecycle management as the customer's problem once the support contract expires, communicating through channels that reach engineers but not operators, and providing remediation tooling only after the urgency is undeniable. That pattern will produce the next equivalent event. The 2026 transition is not the cautionary tale. It is the most recent one.

The certificate nobody checked was in the firmware the whole time. The dates were visible. The consequence was known. The remediation was technically achievable years before it became urgent. What failed was not the technology. What failed was the ecosystem's willingness to treat the engineers who depend on it as people who deserve to be told, in time, what they need to know.