PCA 2011 Revocation: Who Authorizes It, and What Recovery Must Prove

PCA 2011 revocation is the step that removes trust in boot managers signed under PCA 2011, and installing the update does not take it. On October 22, 2026, Kaspersky’s Securelist report on the BlackX bootkit described a UEFI bootkit found on fully patched systems in Central Asian diplomatic agencies, planted by an attacker who already held administrator privileges. The part that matters to an infrastructure owner is narrower than the malware: the revocation that closes the gap is a manual step, and Microsoft’s automatic Enforcement Phase had not been implemented when the report was published. CA distrust propagation covers whether a verifier has consumed a distrust decision. This post starts after that question, at whether the organization is ready to authorize consuming it.

Revocation here means untrusting every boot manager signed under Windows Production PCA 2011 by adding it to the Secure Boot forbidden signature database (DBX). That makes it a recovery event as much as a security one, and recovery is a core layer of data protection architecture, because the boot paths used to recover a device, such as USB media, PXE servers and VM templates, can depend on the same signing chain. The question about PCA 2011 revocation is not whether to close the gap. It is who authorizes the change, on what proof, and what can still boot afterward. The scope is deliberately that narrow: this is not a Secure Boot tutorial, it makes no claim about how many devices remain unrevoked, and it does not discuss how an attacker gets in.

Why PCA 2011 Revocation Is Not Part of Patching

Microsoft’s mitigations for CVE-2023-24932 are in Windows updates from July 9, 2024, and they are not enabled by default, according to KB5025885. A device can carry every update and still trust boot managers signed under PCA 2011. Securelist’s description of the victims is the same point from the attacker’s side: fully patched machines, with the revocation left as a manual step that needs a registry flag and the Secure-Boot-Update scheduled task. Kaspersky’s example of why the design is manual is that automatic revocation could break dual-boot setups, and it assesses that the instructions are hard to find. Both are Kaspersky’s inferences, not Microsoft statements, and neither is measured here.

Two identifiers appear in this story and they belong to two sources. Kaspersky ties BlackX to Baton Drop, CVE-2022-21894, and describes the PCA 2011 revocation as that flaw’s remediation. Microsoft frames KB5025885 under CVE-2023-24932. This post attributes each statement to the source that makes it and does not treat the identifiers as interchangeable.

Expiry is not revocation either. The PCA 2011 certificate expired on October 19, 2026, and Securelist notes that expiry does not stop a boot manager signed under it from loading unless that boot manager is blocklisted. Expiry is a date on a certificate. PCA 2011 revocation is a change to DBX that someone makes on each device.

Microsoft describes the mitigations as preventive, not corrective, and says an attacker needs administrator or physical access to exploit the gap they close. That sharpens the authorization. The benefit of PCA 2011 revocation is protection against a bootkit that has not yet been planted, and the cost is paid in recovery on every device the change reaches. A device that is already compromised is not cleaned by it. Weighing a benefit that is contingent on an attacker against a cost that is certain on the day of enforcement is the kind of judgment that needs a named owner.

Microsoft’s own plan is an Enforcement Phase that applies the revocation automatically, with no option to disable it afterward. The September 30, 2026 revision of KB5025885 gives no date for it and commits to at least six months’ notice. That cuts two ways. Waiting for Microsoft is a decision, not a neutral default. And an organization that starts its recovery testing on the day notice arrives is starting with a clock it did not choose. Nothing here predicts when that notice will come.

Someone Has to Own PCA 2011 Revocation

The mitigations sit outside the normal patch path. Installing an update is a patching task. Revocation writes to firmware variables, depends on the firmware accepting the DB and DBX updates, and has a consequence in recovery that the patching team does not own. The recovery owner knows which media exist but does not run the DBX change. The endpoint team runs the change but may not know a PXE server or a VM template depends on the old chain. Without a named authorizer, each team can reasonably believe the other holds the decision, and PCA 2011 revocation proceeds only when someone happens to run the change or never proceeds at all. Neither outcome is a decision. Both leave the organization with an exposure or a recovery gap that nobody recorded.

The adjacent ownership question is already covered in who controls trust-state updates in virtual firmware, which establishes who holds the platform keys and DB state. The question here comes one step later: who may initiate and execute a trust-state change that cannot be taken back once Secure Boot is in use. It also fits the revocation unit idea in a different form. PCA 2011 is a trust root, and revoking it removes everything signed beneath it at once, the same shape as rotating a credential that many systems share, with a firmware list in place of a credential store.

An authorization has three parts: a named approver, the criteria the approver applies, and the device classes the decision covers. It also has three possible outcomes, and “wait” is only one of them when it is recorded with an owner. The approver can enforce by device class. The approver can defer, with the open exposure documented and an accountable owner. Or the approver can block enforcement until the identified recovery dependencies are remediated.

Revocation Takes Boot Paths Away From Recovery

Before PCA 2011 revocation is enforced on a device class, the compatibility question has to be answered with a boot test, not an assumption. Microsoft states that revoking boot managers could cause issues for some device boot configurations, and that recovery media must be updated because existing media may fail to start or recover the device. Its FAQ names CD/DVD, PXE boot and USB as media that will not start after revocation. Its Windows IT Pro blog post on revoking vulnerable boot managers singles out PXE as especially likely to be affected. Firmware has to be able to apply the DB and DBX updates, which is why Microsoft says to test one device of each type before widening the change. On machines with more than one Windows installation, every installation has to be updated to the July 9, 2024 level or later before revoking.

The table maps each dependency to what Microsoft documents. It is not a prevalence claim: the KB does not say how many devices are affected.

Dependency	What Microsoft documents	What it means for recovery
Recovery media (CD/DVD, USB)	Existing media may fail to start or recover the device after revocation; media must be updated	Rebuild each media type and boot-test it on a device of each class
PXE and network boot servers	Named as media that will not start after revocation; the Windows IT Pro guidance calls PXE especially likely to be affected	Inventory boot servers and test the network boot path before enforcement
x86 VMs with Secure Boot	Known issue: Secure Boot VMs fail to boot; Microsoft says it is coordinating with VMware	Attributed to Microsoft only; Broadcom’s side was not confirmed in the sources read
Symantec Endpoint Encryption	Known issue: the mitigations cannot be applied	Get the vendor’s written position before the device class is enrolled
Server 2012 and 2012 R2 with TPM 2.0	Known issue, addressed April 8, 2026	Confirm the update level before the device class is enrolled
Older external media after SVN 5.0	Listed as a known issue	Test external boot media against the SVN you intend to apply

The KB also lists HP Sure Start, Arm64 devices with Qualcomm chips and Apple Boot Camp among the known issues. BitLocker belongs in the same pass: Microsoft’s guidance is to retain the BitLocker recovery key before making the change.

Recovery dependencies fail in a recognizable way, and it is not the way the failing component announces. The System Recovered. Your Recovery Boundary Didn’t. covers recovery paths that quietly depend on systems outside the recovery design, with certificates already on the list. A boot manager’s signing chain is that class of dependency. It is invisible until the first device that needs the old media does not boot.

PCA 2011 Revocation Is Effectively Irreversible

The KB’s caution is direct: once the mitigation is applied, it cannot be reverted if Secure Boot continues to be used, and reformatting the device does not remove it. The accurate phrase is effectively irreversible while Secure Boot remains enabled, not universally irreversible. Microsoft separates the work into four ordered mitigations, and only the third one is PCA 2011 revocation itself. The first two prepare the device to boot under the 2023 chain, which is why the order is fixed.

Microsoft’s documented read-back for step three checks that the DBX contains the PCA 2011 entry and should return True:

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'

Three terms stay separate in any change record. Deployment rollback is reversing or stopping a deployment that has not completed. Revocation reversal is restoring trust in the revoked boot manager, which Microsoft says cannot be done while Secure Boot stays in use. Recovery is restoring bootability through a documented procedure that may itself disable Secure Boot for a time. A change plan that says “we can roll back” is usually describing the first of the three.

The documented recovery shows how narrow the third one is. Microsoft’s procedure is to turn Secure Boot off, reset the keys to factory defaults (Reset, not Clear), restore the boot files with bcdboot, reinstall from recovery media if needed, and re-enable Secure Boot. The KB describes the result as a pre-revocation state. While Secure Boot is off, the device is exposed to the bootkits the revocation was meant to stop. The only documented way back from a failed enforcement temporarily removes the control.

The Recovery-Proof Gate: Eight Checks to Authorize and Verify Enforcement

Authorizing PCA 2011 revocation needs two recovery proofs, made at different points. The first is made before authorization: for each device class, a device that fails to boot can be recovered, tested on one device of that type. The second is made after revocation, on a pilot device in each class, with no boot manager signed under PCA 2011 left in the path: media rebuilt, boot servers updated, and recovery still works. The first passing says nothing about the second, because the old media still boots until the moment it does not. The second is a condition for widening, not for starting. It closes on the pilot before enforcement extends to the rest of the class.

Microsoft’s guidance supports testing one device of each type. The staged sequence of authorize, pilot, prove and widen is this post’s recommendation, not a Microsoft procedure. The second proof is a controlled recovery test conducted after revocation, with the legacy boot dependency unavailable. That is the point of adversarial restore testing: demonstrate that recovery still works when a dependency the old design relied on is gone. Evidence of that kind belongs in the same record as the approval, in the way recovery-evidence assurance treats recovery as something a team demonstrates rather than asserts.

Gate	When	Question	Proof	Owner
1. Prerequisite state	Before	Does the device hold the 2023 certificate and run a PCA2023-signed boot manager, and can its firmware apply DB and DBX updates?	Events 1036 and 1799; UEFICA2023Status; a controlled reboot test; firmware vendor confirmation for devices that failed	Endpoint or platform team
2. Compatibility inventory	Before	Which recovery media, USB media, PXE or network boot servers, VM templates and disk-encryption products depend on a PCA 2011 boot manager?	Inventory plus a boot test per media type; KB known-issues check	Recovery owner
3. Encryption readiness	Before	Are BitLocker recovery keys escrowed before the change, and has each third-party encryption vendor confirmed compatibility?	Escrow check; vendor statement	Security or endpoint team
4. Pre-enforcement recovery proof	Before	Can a device that fails to boot be recovered, and was it tested on one device of each type?	Documented test per device class	Recovery owner
5. Authorization	Before	Who may approve an effectively irreversible transition, and on what criteria?	Named approver; recorded criteria	To be named by the organization
6. Enforcement decision	Before	Enforce on a pilot by device class, defer with documented exposure and an accountable owner, or block until identified recovery dependencies are remediated?	Recorded decision with the open exposure stated	The authorizer from gate 5
7. Enforcement evidence	After	Did revocation take effect on each pilot device?	Event 1037; DBX read-back	Whoever ran the change
8. Post-revocation recovery proof	After	Can recovery proceed without any boot manager signed under PCA 2011, including rebuilt media and updated PXE servers? Passing is the condition for widening.	Boot test of rebuilt media on the pilot after revocation	Recovery owner

Gates 5 and 6 are the two that no tooling closes. Gate 5 names who decides. Gate 6 records what they decided, in terms of organizational readiness and documented risk and not an assumed Microsoft timetable. A deferral with an owner and a stated exposure is a legitimate result. A deferral that exists only because nobody ran the change is not. Gate 8 is the closure: until it passes on the pilot, enforcement does not widen.

Additional Resources

View 2 more resources ↓

>_ External Reference

Windows IT Pro Blog: Revoking vulnerable Windows boot managers

Microsoft’s April 2024 explanation of why PXE boot is especially likely to be affected

>_ External Reference

Securelist: the BlackX UEFI bootkit report

Kaspersky’s October 22, 2026 analysis of the incident that dated this post