Secure Boot PCA 2011 Expires October 19, 2026: Fleet Rollout Guide

Microsoft’s July 15 OEM Secure Boot Office Hours did not move the remaining deadline: Microsoft Windows Production PCA 2011 is scheduled to expire on October 19, 2026. The practical task for administrators is to identify which devices are ready for the 2023 Secure Boot certificate transition, protect recovery access before making changes, and use a staged deployment method rather than treating the work as an ordinary monthly patch.
The session, reported by Windows Latest, brought Microsoft engineers and representatives from major PC and firmware vendors into a Tech Community discussion that remained open for 12 hours. Its most useful outcome was not a universal promise that every device will follow the same path. It was a clearer separation between Windows servicing, management-policy deployment, firmware readiness, and the exceptions that require device-level investigation.
For enterprise teams, the safe approach is straightforward: confirm BitLocker recovery-key escrow, install applicable Windows updates, test representative hardware cohorts, use the local detection material included with updated Windows installations, and deploy through the documented Group Policy or Microsoft Intune method. The Office Hours discussion provides context for those steps; it does not eliminate the need for pilots.

The October Deadline Requires a Fleet Plan​

The Microsoft Corporation KEK CA 2011 and Microsoft UEFI CA 2011 certificates have already expired. The remaining Microsoft Windows Production PCA 2011 certificate is scheduled to expire on October 19, 2026.
That date should be treated as a planning deadline for organizations still working through the Secure Boot certificate transition. It is not a substitute for checking the actual state of individual devices, their firmware versions, and their management configuration. A device inventory that only records Windows edition and patch level is not enough for this work; firmware cohorts and recovery readiness matter as well.
The July Office Hours discussion is particularly relevant because it placed the transition in an operational context. The task is not simply “install an update.” Administrators must establish whether the endpoint is receiving applicable Windows servicing, whether the device can be managed through the organization’s chosen deployment channel, and whether any OEM-specific limitations affect the planned rollout.

Timeline​

After May 12, 2026: Applicable Windows updates include Secure Boot PowerShell example material in %systemroot%\SecureBoot\ExampleRolloutScripts.
July 15, 2026: Microsoft’s OEM Secure Boot Office Hours session is held through a Tech Community discussion.
July 18, 2026: Windows Latest publishes its account of the Office Hours discussion and the responses from Microsoft and participating OEMs.
October 19, 2026: Microsoft Windows Production PCA 2011 is scheduled to expire.

---

Start With Recovery Readiness and Local Detection​

The most defensible first step is not a registry edit or a broad policy assignment. It is verifying that recovery keys are available and that representative devices can be assessed locally.
Windows updates released after May 12 place example Secure Boot rollout scripts in:
%systemroot%\SecureBoot\ExampleRolloutScripts
The supplied local detection script is named:
Detect-SecureBootCertUpdateStatus.ps1
Its presence gives administrators a local, Microsoft-provided starting point for checking a device before and after a planned deployment. The Office Hours discussion also referenced Get-SecureBootRolloutStatus.ps1, but organizations should rely on the documentation accompanying the scripts and the documented deployment guidance for their intended use rather than assuming that either script is interchangeable with a complete fleet-management workflow.

Cautious example: minimum pilot procedure​

The following is a cautious example for a representative pilot device or hardware cohort. It is not a replacement for the organization’s approved change process.

• Confirm recovery-key escrow before making Secure Boot deployment changes.
  Verify that the BitLocker recovery key for the pilot device is present in the organization’s approved escrow location and can be retrieved by the support staff who would handle a recovery event.
• Install applicable Windows updates released after May 12, 2026.
  Confirm that the device has received the applicable Windows servicing needed to provide the Secure Boot example scripts.
• Open an elevated PowerShell session.
  Use an administrator PowerShell window. The procedure should be performed under the organization’s normal endpoint-administration controls.
• Move to the local script directory and run the detection script.
  

  Set-Location "$env:SystemRoot\SecureBoot\ExampleRolloutScripts"
  .\Detect-SecureBootCertUpdateStatus.ps1

• Record the result with device context.
  For each pilot system, record the OEM, model, BIOS or UEFI version, Windows version, the detection-script result, and whether BitLocker recovery-key escrow was confirmed. Treat each meaningful firmware version as a potentially distinct pilot cohort.
• Use the documented Group Policy or Microsoft Intune deployment method.
  After the pilot result is reviewed, deploy using Microsoft’s documented policy-based method for the environment. Do not substitute unverified settings paths, copied registry fragments, or ad hoc scripts for the documented deployment process.
• Validate after deployment according to the documented process.
  Record the post-deployment state and any user-impacting result, including unexpected recovery prompts or management errors. Pause expansion for the affected cohort if the pilot produces results that cannot be explained from the available device evidence.

This sequence is intentionally conservative. It makes recovery readiness, local evidence, and hardware grouping part of the deployment decision rather than cleanup work after a broad assignment has already reached users.

The Scripts Are Useful Evidence, Not a Complete Rollout Strategy​

The example scripts matter because they give Windows administrators a local point of reference. They also reduce the temptation to rely on old forum posts, copied commands, or third-party packages whose assumptions may not match the current transition.
Still, a local script result should be treated as one piece of rollout evidence. It does not, by itself, establish that every device in the same product family has identical firmware, Secure Boot configuration, encryption state, or management-policy history.
That distinction is important for organizations with mixed fleets. Two devices sold under the same commercial model name may have different BIOS releases, different disk-encryption histories, or different policy assignment states. For that reason, the most useful inventory groups are usually more specific than “Dell laptops,” “Lenovo desktops,” or “Surface devices.” A workable grouping includes at least:

• OEM and exact model
• BIOS or UEFI version
• Windows release and servicing level
• Secure Boot status and local detection result
• BitLocker state and recovery-key escrow confirmation
• Management channel, such as Group Policy or Intune
• Any observed deployment or recovery outcome

This is also where the Office Hours discussion should be separated from broader editorial interpretation. The verified takeaway is that Microsoft supplied local example scripts and documented deployment methods. The analysis is that organizations will get better results when they use those tools to build an auditable pilot record rather than attempting to infer readiness from a single dashboard field.

---

AvailableUpdates and AvailableUpdatesPolicy Are Not Interchangeable​

One of the most important administrative distinctions discussed around the rollout is the difference between the AvailableUpdates and AvailableUpdatesPolicy registry values.
AvailableUpdates is associated with direct deployment configuration. Microsoft documentation identifies 0x5944 as the value associated with the full 2023 transition. AvailableUpdatesPolicy, by contrast, is documented as a reference value that should not be manually edited through the registry.

Deployment approach	Administrative control point	Direct registry editing?	Practical use
Direct/manual configuration	AvailableUpdates	Documented as a deployment value	Only after a representative pilot and an approved procedure
Group Policy deployment	Secure Boot policy configuration	No manual editing of AvailableUpdatesPolicy	Centrally managed deployment
Microsoft Intune deployment	Documented Intune Secure Boot policy method	No manual editing of AvailableUpdatesPolicy	Cloud-managed deployment
OEM firmware servicing	OEM BIOS or UEFI process	Not applicable	Platform-specific firmware maintenance

The safe conclusion is not that administrators should immediately write 0x5944 into production devices. This article retains the value as a documented-value reference, not as a copy-and-paste registry deployment procedure. A direct registry deployment requires verified command semantics, elevated execution, and a documented reboot and validation process; those details should come from Microsoft’s current documentation and the organization’s approved rollout plan.
Accordingly, do not use direct registry deployment as a shortcut until a representative pilot has succeeded. Do not manually edit AvailableUpdatesPolicy. For managed estates, use the documented Group Policy Objects or Microsoft Intune deployment method rather than attempting to reproduce policy behavior through hand-edited registry state.
The practical difference is simple: one value may be associated with deployment configuration, while the other is policy-related reference state. Confusing the two creates unnecessary risk because it can turn a managed rollout into an unsupported manual change.

Policy Deployment Should Be Deliberate, Not Reverse-Engineered​

A Group Policy or Intune deployment is not merely a way to avoid touching the registry. It is the mechanism for applying an approved configuration consistently, tracking its assignment, and aligning the rollout with normal enterprise change controls.
That does not mean management reporting will always provide a complete diagnosis. The Office Hours discussion included reports of Intune results such as State Error, Error Type 2, and Error Code 0. Those labels identify a management outcome, but they do not by themselves identify the device condition, firmware state, or policy interaction responsible for the result.
When such an error occurs, the appropriate next step is to preserve evidence from the affected endpoint and compare it with the pilot cohort:

• OEM, model, and BIOS or UEFI version
• Local Secure Boot detection-script result
• Windows servicing level
• Policy assignment and deployment timing
• BitLocker status and recovery-key availability
• Any user-visible boot, recovery, or configuration result

This is an evidence-collection recommendation, not a claim that Microsoft attributed those errors to a specific cause. The supplied facts establish that Intune errors and BitLocker recovery were reported during rollout activity. They do not establish a single Microsoft-confirmed root cause or a universal remediation.
For the same reason, organizations should avoid declaring a policy method defective based on one generic status code, just as they should avoid declaring a firmware family ready based on one successful device. The meaningful unit of analysis is the tested hardware and configuration cohort.

---

Firmware Readiness Is an OEM Question​

The Office Hours format was valuable because OEM participation underscored a basic operational reality: Windows deployment and firmware support are related, but they are not the same responsibility.
A Windows device may be current on operating-system servicing while still requiring separate evaluation of its BIOS or UEFI state. That is why an inventory should record firmware version alongside Windows patch level and certificate-detection results.
The safest OEM guidance in the supplied discussion is specific to Surface shipping status:

• Surface devices released since 2024 ship with the 2023 certificates.
• Surface Pro 3, Surface 3, and earlier hardware that shipped with Windows 8 are excluded.

Those facts are useful for inventory classification, but they do not remove the need to validate each managed device through the organization’s rollout process. For other OEMs, administrators should use the current vendor documentation for the exact model and firmware release rather than relying on generalized assumptions about a brand, product generation, or BIOS age.
This is especially important for older hardware. A legacy endpoint may remain part of the environment because it supports a specialized application, a peripheral, or a line-of-business workflow. That does not make it suitable for an untested Secure Boot deployment. It makes its exception status more important to document.
A practical legacy-device register should include:

Field	Why it matters
OEM and exact model	Identifies the applicable vendor guidance
BIOS or UEFI version	Separates potentially different firmware cohorts
Secure Boot detection result	Records the local pre-deployment condition
BitLocker recovery-key status	Confirms recoverability before change
Management method	Shows whether the device is targeted through GPO, Intune, or another approved process
Exception owner	Makes responsibility visible
Next review date	Prevents unsupported or deferred systems from disappearing from the project

This approach is less dramatic than declaring every older device a failure or every newer device ready. It is also more useful. The goal is to turn uncertain endpoints into documented decisions: proceed through the standard policy path, hold for OEM review, isolate for further testing, or place on a retirement plan.

BitLocker Recovery and Intune Errors Must Be Treated as Exceptions​

The Office Hours discussion included a report from an administrator managing a large Dell and Lenovo fleet. The report described Intune configuration failures and a smaller number of devices reaching BitLocker recovery during processing.
Those reports matter because a recovery event has operational consequences regardless of the ultimate technical cause. It consumes support time, interrupts users, and can become a serious incident if recovery keys are not available. That is why recovery-key escrow belongs at the beginning of the deployment plan rather than at the end.
The supplied facts do not establish that Microsoft identified BitLocker recovery as normal or abnormal for this transition, nor do they establish a Microsoft-confirmed explanation involving firmware behavior, PCR configuration, or any other specific cause. They also do not provide a Microsoft remediation workflow for affected devices. Administrators should therefore avoid presenting any single explanation as settled.
What can be said safely is that a recovery event should trigger a pause and investigation for the affected cohort. A team should record what changed, what policy was applied, what firmware the device was running, what the local detection script reported, and whether comparable devices exhibit the same behavior.
The same discipline applies to generic Intune failures. A management error may be the first signal that a cohort needs attention, but it is not a complete diagnosis. The correct response is to gather endpoint facts and compare them against successful pilots, not to assume that a broad redeployment will improve the result.

The Office Hours Facts and the Operational Analysis​

The Office Hours session established several concrete facts that administrators can use now:

• The remaining stated deadline is October 19, 2026, for Microsoft Windows Production PCA 2011.
• Applicable Windows updates after May 12 include Secure Boot example scripts in %systemroot%\SecureBoot\ExampleRolloutScripts.
• Detect-SecureBootCertUpdateStatus.ps1 is available locally as part of that example material.
• Microsoft documentation distinguishes AvailableUpdates from AvailableUpdatesPolicy and says not to manually update AvailableUpdatesPolicy.
• The documented value reference for the full 2023 transition is 0x5944 for AvailableUpdates.
• Surface devices released since 2024 ship with the 2023 certificates, while Surface Pro 3, Surface 3, and earlier Windows 8-era Surface hardware are excluded.
• Administrators reported both BitLocker recovery and generic Intune error states during deployment activity.

The broader operational analysis is that these facts support a staged, evidence-based program. That analysis should not be mistaken for a Microsoft statement about every device’s expected outcome. The available evidence does not support sweeping claims about future boot behavior on untransitioned machines, specific future signature or revocation consequences, confidence-rating mechanics, script internals, or a universal cause for recovery events.
That boundary matters. Secure Boot work is sensitive enough that unsupported certainty can be as risky as inaction.

Action box: a source-bounded plan for the remaining window​

• Treat October 19, 2026 as the remaining planning deadline.
• Confirm BitLocker recovery-key escrow and retrieval before changing pilot devices.
• Install applicable post-May 12 Windows updates.
• Run Detect-SecureBootCertUpdateStatus.ps1 from %systemroot%\SecureBoot\ExampleRolloutScripts in elevated PowerShell.
• Record OEM, model, BIOS or UEFI version, Windows servicing level, recovery readiness, and the script result.
• Pilot by meaningful firmware cohort, not by broad product label alone.
• Use Microsoft’s documented Group Policy or Intune deployment method for managed rollout.
• Do not manually edit AvailableUpdatesPolicy; treat AvailableUpdates=0x5944 as a documented reference unless the organization has verified Microsoft instructions for a direct deployment procedure.
• Pause and investigate cohorts that show BitLocker recovery or generic management errors before expanding the rollout.
• Maintain a documented exception list for excluded, legacy, or OEM-dependent systems.

The transition remains a fleet-readiness exercise rather than a single Windows Update event. The organizations most likely to complete it cleanly will be those that keep recovery access current, test representative firmware cohorts, use documented policy deployment, and distinguish verified rollout facts from assumptions about what any individual device will do.

---

Update: Reports flag model-specific HP and Dell rollout failures (July 20, 2026)​

WindowsReport now describes more granular issues reported during the July 15 Office Hours discussion, including repeated BitLocker recovery prompts on some HP EliteBook and ZBook systems after certificate deployment. One administrator said that reverting an HP EliteBook 640 G10 to an earlier BIOS stopped the prompts, despite current firmware and HP guidance having been used initially. Neither Microsoft nor HP had confirmed a root cause or permanent fix during the session.
The report also says some older HP models may be constrained by limited NVRAM space for the new certificate set, while another HP cohort reportedly installed Secure Boot database certificates but repeatedly failed to update the KEK. Separately, some devices reportedly display an “Unknown” Secure Boot status even where the newer certificates appear installed; Microsoft recommended using the more detailed rollout-status script for diagnosis.
Dell fleet results were similarly mixed: most systems reportedly completed the transition, but some OptiPlex 5000 devices did not apply the required rollout registry state. WindowsReport also cites ASUS, MSI, and ASRock-specific firmware behaviors, reinforcing that rollout outcomes can vary by exact model and BIOS release.
For IT teams, these reports strengthen the case for treating failed cohorts as firmware-specific exceptions rather than retrying deployment broadly. They do not establish a Microsoft-confirmed cause, safeguard hold, or remediation for the affected hardware.

https://windowsreport.com/secure-boot-rollout-fails-on-hp-dell-asus-and-msi-pcs

---

References​

1. Primary source: Windows Latest
   Published: 2026-07-18T01:20:31+00:00
   
   

   Windows 11 Secure Boot certificates have expired, and Microsoft says what to do next

   Microsoft and OEMs fixed key Secure Boot certificate issues for IT admins at a live office hours event, covering BIOS updates and KEK errors

   www.windowslatest.com
2. Related coverage: techradar.com
   
   

   Watch out Windows users, a Secure Boot update has been blocked on Windows 11 PCs due to failing on some devices — here's how to check if you're affected | TechRadar

   Microsoft blocked a Secure Boot updates because of an issue on some devices

   www.techradar.com
3. Official source: learn.microsoft.com
   
   

   Update Secure Boot Certificates for Windows Devices - Windows Client | Microsoft Learn

   Update your Windows devices to maintain Secure Boot protection with 2023 certificates before they expire in June 2026.

   learn.microsoft.com
4. Related coverage: dell.com
   

   Secure Boot Transition FAQ | Dell US

   This article provides information about commonly asked questions around the Secure Boot Certificates expiration.

   www.dell.com
5. Official source: support.microsoft.com
   
   

   Windows Secure Boot certificate expiration and CA updates | Microsoft Support

   Windows Secure Boot certificate expiration and CA updates

   support.microsoft.com
6. Official source: blogs.windows.com
   
   

   Refreshing the root of trust: industry collaboration on Secure Boot certificate updates

   Secure Boot is a foundational security feature of the Windows and Windows Server experience, providing protection from the moment a device powers on. Introduced in 2011, Secure Boot runs at startup – before Windows loads – and h

   blogs.windows.com

 

[ChatGPT]

Microsoft is replacing Secure Boot certificates issued in 2011: the Microsoft Corporation KEK CA 2011 and Microsoft UEFI CA 2011 expire on June 24, 2026, while Windows Production PCA 2011 expires on October 19, 2026. Organizations should therefore classify each affected endpoint into one of four outcomes—retain and update, remediate firmware, replace, or isolate—rather than treating “Secure Boot enabled” as proof that the rollover is complete.

Why an enabled Secure Boot checkbox is no longer enough​

Microsoft’s Secure Boot certificate-expiration and CA-update guidance describes a phased transition from the 2011 certificates to newer certificates. June 24 and October 19 are separate expiration dates, so administrators should manage the work as a continuing rollout rather than a one-day cutover.
WindowsForum’s reports on the 2026 rollover repeatedly highlight the practical issue: checking whether Secure Boot is switched on answers only one part of the readiness question. Administrators must also determine whether Windows is being serviced, whether the manufacturer has identified a firmware dependency, and whether the device has completed the certificate-update process supported for that hardware.
This is advance lifecycle work intended to avoid disruption. It should not be presented as evidence that every machine will fail on an expiration date, nor as proof that every enabled machine has already received the replacement certificates.
The four dispositions below are a WindowsForum endpoint-governance model, not a Microsoft-mandated workflow:

1. Retain and update: The device remains supported and accepts the applicable updates.
2. Remediate firmware: Windows servicing alone is insufficient, but the manufacturer provides a supported firmware path.
3. Replace: No supported update path is available for a machine that must remain in a trusted role.
4. Isolate: A necessary but unserviceable machine must remain temporarily under documented restrictions.

Inventory the endpoint before assigning a decision​

Start with representative systems from each hardware model and firmware revision. Do not begin with an unrestricted fleet-wide deployment.

1. Bring the device to its current supported servicing state​

1. Open Settings > Windows Update.
2. Select Check for updates.
3. Install the Windows updates offered to the device.
4. Install firmware or manufacturer updates only through a channel supported for that exact model.
5. Restart whenever Windows or the manufacturer’s installer requests it.
6. Repeat the update check until no applicable updates remain.
7. Record the date, update result, model, and firmware version.

Do not require an update identified only by an assumed release date. Use Microsoft’s current deployment guidance, Windows Update, your managed servicing tools, and the device manufacturer’s applicable advisories.

2. Confirm whether Secure Boot is active​

Open Windows PowerShell as administrator, then run:
Confirm-SecureBootUEFI
Interpret the result narrowly:

• True means Windows reports Secure Boot as enabled.
• False means Windows reports Secure Boot as disabled on a system where the cmdlet can query it.
• An unsupported-platform error means the cmdlet could not provide the requested result on that configuration.

This command does not prove that the certificate rollover is complete. It should be retained as one inventory field, not used as the sole compliance test.

3. Collect firmware certificate information for diagnosis​

In an elevated PowerShell window, administrators can collect decoded output with:

Get-SecureBootUEFI -Name KEK -Decoded
Get-SecureBootUEFI -Name db -Decoded

Treat this output as diagnostic evidence only. Do not declare a device compliant merely because a certificate subject appears to be newer or contains a particular year. Microsoft’s deployment documentation and management reporting should supply the applicable completion criteria for the rollout stage being implemented.
Preserve the output when escalating a problem to Microsoft or the manufacturer. It can help support teams compare machines, but it is not a substitute for an authoritative success state.
At minimum, inventory:

• Manufacturer and exact model
• Firmware or BIOS version
• Windows edition, version, and servicing status
• Confirm-SecureBootUEFI result
• KEK and DB diagnostic output
• Windows Update success or failure
• Manufacturer update status
• Any Microsoft or OEM compatibility hold
• Reboot and startup-test results
• Assigned owner and proposed disposition

Do not use Set-SecureBootUEFI to improvise a repair. Directly changing firmware trust variables can alter the platform’s boot policy and should not replace Microsoft’s supported rollout or an OEM-prescribed procedure.

Which decision should each PC receive?​

Can the PC install the applicable updates normally?​

Assign retain and update when the device is supported, current Windows updates install successfully, no unresolved firmware limitation is reported, and verification through the organization’s approved Microsoft management signals shows that the applicable rollout stage completed.
Use this ordered procedure:

1. Confirm the exact model and firmware revision.
2. Install currently applicable Windows updates.
3. Restart as required.
4. Install manufacturer updates offered for that model.
5. Restart again if required.
6. Run Confirm-SecureBootUEFI.
7. Collect KEK and DB output for the pilot record.
8. Review Windows Update and management-platform results for failures or holds.
9. Perform repeated startup tests.
10. Record the final disposition and evidence.

WindowsForum’s readiness reports emphasize planning before the June expiration rather than waiting for an incident. Keep completed devices in normal servicing rings and continue watching Microsoft’s current rollout notices, because a completed pilot does not eliminate the need to monitor later deployment stages.
For an individually managed PC, the safe practical approach is simpler: keep Windows current, install firmware only from the PC manufacturer or its supported update utility, restart when requested, and recheck Windows Update. Do not rely on an unofficial certificate-name checklist.

Does the device require manufacturer action?​

Assign remediate firmware when Microsoft’s or the manufacturer’s guidance identifies a firmware dependency, when an applicable firmware update is offered, or when a fully serviced test device cannot complete the supported process.

1. Identify the exact manufacturer, model, and firmware version.
2. Check the manufacturer’s supported update channel for that model.
3. Read the release notes and prerequisites.
4. Preserve required recovery information before changing firmware.
5. Follow the manufacturer’s requirements for AC power, battery level, docks, and attached devices.
6. Install the firmware update.
7. Do not interrupt the firmware installation.
8. Restart and verify that the system starts normally.
9. Apply remaining Windows updates.
10. Restart as required.
11. Repeat the PowerShell inventory and review managed deployment status.
12. Escalate persistent failures with update logs and collected diagnostic output.

Microsoft’s published Azure Local approach supports phased rollout, monitoring, validation, and coordination with OEM or hardware updates. That is a useful operational pattern for endpoint teams, but it does not establish a universal rule that firmware and Secure Boot work must always occur in separate reboot sequences.
A firmware-dependent device is not automatically a replacement candidate. Move it to replacement only after confirming that no supported remediation path is available or that the approved remediation repeatedly fails.

Is the hardware no longer serviceable?​

Assign replace when authoritative guidance for the exact model establishes that it cannot receive the required update path and the organization cannot accept the resulting security or support limitation.
Prioritize systems according to organizational risk, including machines used for privileged access, sensitive workloads, security administration, or long remaining deployment periods.
Use a controlled decision:

1. Obtain written confirmation of the unsupported state from the manufacturer, Microsoft support, or applicable product documentation.
2. Record the device, owner, workload, and evidence.
3. Set a replacement date.
4. Plan application and data migration.
5. Maintain available Windows and application servicing until retirement.
6. Remove the old asset through the organization’s normal sanitization and disposal process.

“Still starts” is not a complete support determination. Conversely, administrators should not infer a detailed list of protections that a particular machine will or will not receive without Microsoft documentation for that configuration.

Must an unserviceable PC remain temporarily?​

Assign isolate only when a required workload cannot move immediately and replacement is not yet possible. Isolation is a temporary risk treatment, not completion of the certificate rollover.
Define the exception explicitly:

• Place the machine on the minimum necessary network segment.
• Remove unnecessary internet and internal access.
• Do not use it for privileged administration.
• Restrict interactive users and local administrators.
• Keep available operating-system and application updates current.
• Monitor configuration changes, update failures, and unexpected restarts.
• Document the business owner, risk owner, controls, and retirement date.
• Review the exception on a fixed schedule.

Do not disable Secure Boot merely to bypass the rollover. Keep existing protection enabled unless authoritative recovery or manufacturer guidance for a specific incident requires a different action.

Treat unusual boot configurations as separate test cases​

WindowsForum’s rollover reports also stress that one successful mainstream-PC test cannot represent every hardware and boot configuration. Systems with alternative bootloaders, customized Secure Boot keys, or hardware that participates before Windows starts require their own approved test plans.
These are WindowsForum operational recommendations, not claims that Microsoft guarantees a particular third-party configuration:

1. Record the complete boot configuration before the pilot.
2. Identify who owns the firmware trust policy.
3. Update each operating system and boot component through its supported channel.
4. Preserve approved recovery media and necessary recovery information.
5. Test a representative device before broad deployment.
6. Verify every required startup path after changes.
7. Stop the ring if a boot path fails.
8. Escalate to the responsible operating-system, hardware, or firmware vendor.

Do not restore factory keys or replace customized platform variables without understanding who authorized the existing configuration and how required boot components are trusted.

Build rollout rings around hardware​

Organize pilot rings around meaningful hardware differences rather than departments. Include each major manufacturer and model family, important firmware revisions, remote devices, and any configuration that departs from the organization’s standard boot design.
Advance a ring only after confirming:

1. Applicable Windows and manufacturer updates completed.
2. Secure Boot remains enabled where required.
3. The device starts successfully after repeated restarts and cold starts.
4. Management tools show no unresolved deployment failure.
5. Required organizational startup paths still work.
6. Diagnostic output and update records have been retained.
7. The endpoint has a documented disposition.

Pause deployment when Microsoft or the manufacturer publishes a compatibility hold. A paused rollout is not automatically proof that hardware must be replaced; keep the device otherwise serviced and reassess it when updated guidance becomes available.

Frequently Asked Questions​

Will a PC stop booting as soon as a 2011 certificate expires?​

The supplied Microsoft guidance calls for advance action to avoid disruption, but it does not justify predicting an identical outcome for every configuration. Determine readiness through supported servicing, manufacturer guidance, and Microsoft’s rollout status rather than assuming either immediate failure or guaranteed continued operation.

Is Confirm-SecureBootUEFI enough for compliance?​

No. It reports whether Secure Boot is enabled; it does not independently verify completion of the certificate rollover.

Can decoded KEK and DB output prove completion?​

Not by itself. Use it as diagnostic collection unless Microsoft documentation for the deployment explicitly provides the expected certificate identities and success criteria.

Should I disable Secure Boot if the update is blocked?​

No. Disabling Secure Boot is not a general remedy. Investigate Windows servicing, compatibility holds, and manufacturer firmware support first.

Is October 19, 2026, another date that must be tracked?​

Yes. Microsoft lists October 19, 2026, as the expiration date for Windows Production PCA 2011, after the June 24 expirations of Microsoft Corporation KEK CA 2011 and Microsoft UEFI CA 2011.
The durable outcome is an asset register in which every relevant endpoint has evidence, an owner, and one documented disposition: retained and updated, awaiting supported firmware remediation, scheduled for replacement, or temporarily isolated under explicit risk acceptance.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Secure boot | Microsoft Learn

   Provides guidance on what an OEM should do to enable Securely booting a device

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Secure Boot Certificate Rollover 2026: Plan Now to Safeguard UEFI Boot | Windows Forum

   Microsoft has warned that the cryptographic roots underpinning UEFI Secure Boot on Windows devices will begin to expire in June 2026, forcing a global...

   windowsforum.com

 

[ChatGPT]

Windows organizations should move from passive reliance on Microsoft’s phased Secure Boot certificate delivery to an IT-owned deployment and exception process before October 19, 2026, when the Microsoft Windows Production PCA 2011 certificate expires. The right approach is not a rushed estate-wide push this week: use August through October to prove certificate coverage across representative hardware, fix firmware blockers, and obtain formal acceptance for every device that cannot be remediated in time.
Microsoft’s July 14 Windows updates expanded the high-confidence targeting data used for automatic certificate delivery, and the company says supported PCs and non-managed business devices will continue receiving the update through Windows Update in the coming months. That is useful progress, but it is not the same thing as evidence that a managed fleet has completed the transition. For IT, the operational question is now whether an automatic rollout is sufficient for the organization’s risk tolerance—or whether the certificate rotation needs to become a tracked security deployment with named owners and documented exceptions.
Microsoft’s own Secure Boot guidance makes the consequence clear: an unremediated Windows device can still boot and keep receiving ordinary Windows updates, while losing the ability to receive future protections for boot components, Secure Boot databases, revocation lists, and boot-level vulnerability mitigations. That distinction is why this cannot be treated as a routine patch-compliance exercise.

The 2011 Trust Chain Is Already Partly Expired​

Two key pieces of the legacy 2011 certificate set have already reached their end dates. The Microsoft Corporation KEK CA 2011 expired on June 24, 2026, and Microsoft UEFI CA 2011 certificates expired on June 27, 2026. The remaining milestone with the broadest operational significance is October 19, 2026, when the Microsoft Windows Production PCA 2011 certificate expires.
The immediate danger is not that every device with old certificates suddenly stops starting on October 19. Microsoft says affected systems may continue booting and accepting standard Windows servicing. The longer-term problem is more subtle and more serious: those machines become stranded from future changes that depend on current Secure Boot trust material.
That creates an awkward visibility gap. A conventional update dashboard can show a system as current because its normal Windows updates are installed, even while its pre-OS trust state is stale. For security teams, this means the Secure Boot rotation must be measured separately from monthly patching and feature-update compliance.
WindowsForum readers following the broader rollout can review the mechanics in Secure Boot Certificate Rotation in Windows Update: A Practical IT Guide. The critical shift for administrators is to stop considering certificate delivery a background Microsoft process and start treating it as an enterprise control with a completion criterion.

---

August Is for Proving Coverage, Not Waiting for Certainty​

The strongest argument against forcing deployment is that Microsoft is still automatically delivering the 2023 certificates to supported systems. The strongest argument for taking control is that automatic targeting is deliberately phased, while October 19 is fixed.
A phased rollout makes sense for a boot-sensitive change. It allows Microsoft to raise confidence gradually across a diverse hardware population. But enterprises do not manage a generic population; they manage particular OEM models, particular firmware releases, particular BitLocker configurations, and particular remote-support constraints. A device that remains outside automatic targeting may be a harmless timing issue—or it may be exposing a firmware compatibility problem that will not solve itself before the deadline.
That is why August should be the point at which IT changes the workstream from observation to verification. The objective is not merely to ask whether Microsoft has started delivering the certificates. It is to establish whether every in-scope device is either updated, in an actively managed remediation path, or recorded as an accepted exception.
A practical August-to-October plan should proceed in this order:

1. Identify the Windows devices still relying on the 2011 Secure Boot certificates and separate them from devices that have completed the 2023 certificate update.
2. Build a pilot that deliberately spans multiple OEMs, different firmware versions, and BitLocker-enabled devices, following Microsoft’s recommended test coverage.
3. Confirm that pilot devices complete the certificate update without boot failures, startup hangs, Secure Boot validation errors, or unexpected BitLocker recovery prompts.
4. Check each affected hardware family for available OEM firmware updates and deploy those updates before broad certificate remediation where appropriate.
5. Choose a managed deployment method—Intune, registry settings, Windows Configuration System/CSP, or Group Policy—and make the rollout observable through existing endpoint-management and incident processes.
6. Place every device that cannot be updated into a formal exception queue with an owner, a reason, a support plan, and a decision on whether it remains suitable for its current workload.

The important point is sequencing. Firmware readiness comes before a wide certificate push, and pilot evidence comes before declaring the estate covered. A deployment that succeeds on a modern reference laptop but fails on an older model with a different UEFI implementation has not validated the policy; it has only validated the reference laptop.

Firmware Is the Real Gate for the Hard Cases​

Secure Boot certificate rotation crosses an uncomfortable boundary between Windows servicing and platform firmware. Microsoft supports delivery and management through Windows controls, but the actual trust databases and behavior at boot are rooted in UEFI firmware. That is why the same policy can behave differently on systems that look identical from a software inventory perspective.
Microsoft specifically recommends checking for OEM firmware updates, particularly on older device models. That is not generic vendor-maintenance advice. Updated firmware can improve compatibility and reduce the likelihood that the certificate update fails or leaves the device in an unstable state.
The failure modes deserve planning attention because they are operationally expensive. Microsoft warns that outdated firmware or certificate updates that do not apply correctly can lead to Secure Boot validation errors, BitLocker recovery prompts—including repeated recovery loops—startup hangs, and devices that fail to boot.
For a centrally managed office fleet, those risks argue for controlled rings and recovery preparation. For laptops used remotely, they argue for a more demanding standard: do not move a hardware cohort beyond pilot until the service desk, endpoint engineering, and field-support teams know how they will authenticate users, handle BitLocker recovery, and recover a machine that cannot complete startup.
This is also where a simple “force it everywhere” policy becomes less attractive. Forcing deployment is sensible when it means forcing process ownership: inventory, ring assignment, deployment control, and exception tracking. It is reckless if it means bypassing the pilot evidence needed to identify firmware-sensitive groups.
For earlier planning context, Secure Boot Certificates Expire June 2026—Plan for Windows 11 Certificate Rotation explains why the certificate lifecycle deserved attention before the June expirations. The situation now is more concrete: the remaining runway is about demonstrating successful deployment, not debating whether the rotation matters.

---

Automatic Delivery Should Be a Baseline, Not the Control Plane​

Microsoft’s automated delivery remains valuable, especially for supported personal PCs and non-managed business devices. Organizations should not interfere with it merely to replace one delivery channel with another. But automated targeting should be treated as a baseline signal, not as the authoritative record of security readiness.
The reason is simple: a managed organization needs to answer questions that a consumer-oriented rollout does not. Which OEM and firmware cohorts are complete? Which BitLocker-enabled devices have passed? Which systems are waiting for firmware? Which devices are unmanaged, off-network, retired, or no longer supportable? Which exceptions have a business owner?
A Windows Update status alone cannot answer all of those questions. The certificate rotation needs a device-level evidence trail, even if Microsoft’s automatic process performs much of the actual delivery.
This is where the supported management options matter. Intune, registry settings, Windows Configuration System/CSP, and Group Policy give IT a way to establish deployment intent and consistent policy rather than hoping individual devices are selected at the same pace. Organizations should select the method that fits their endpoint-management model rather than introducing a new tool solely for this event.
The choice should also be reversible in operational terms. Use staged groups, protect the pilot population from unrelated configuration changes while testing, and preserve a record of which policy was applied to which device cohort. If an issue appears, the team needs to distinguish a certificate problem from an OEM firmware issue, a BitLocker interaction, or a coincidental Windows servicing change.

Exceptions Must Be Security Decisions, Not Inventory Debris​

Every large Windows estate has machines that do not fit the preferred deployment path: aging hardware, irregularly connected endpoints, specialized systems, devices awaiting replacement, and systems with firmware that cannot be updated on the desired schedule. The mistake is allowing those machines to become invisible because they continue to boot.
An exception should state the specific condition preventing remediation, the hardware and firmware population affected, the business owner, and the planned disposition. “Waiting for automatic Windows Update delivery” may be a valid temporary status during August, but it is not a durable exception as October approaches.
The useful dividing line is whether the organization has evidence. A device that is still in Microsoft’s phased delivery path but is actively inventoried, monitored, and scheduled for a decision is managed risk. A device that simply has not been checked is unknown risk.
Security teams should be careful not to overstate the immediate impact. The October 19 expiration is not a universal outage date. The more accurate description is that it marks the end of trust for the legacy Windows Production PCA 2011 certificate and narrows the organization’s ability to receive future boot-level protections. That makes unmanaged delay a compounding security debt, not necessarily a same-day catastrophe.

Frequently Asked Questions​

Should IT deploy the certificate update immediately to every Windows device?​

No. IT should begin an owned deployment process immediately, but broad enforcement should follow a pilot that covers OEM variation, firmware variation, and BitLocker-enabled systems.

Will a Windows PC stop booting on October 19, 2026?​

Microsoft says devices missing the new certificates can continue to boot and receive regular Windows updates. The concern is that they may no longer receive future Secure Boot protections and boot-level mitigations.

Is Microsoft’s automatic Windows Update delivery enough for managed fleets?​

It may be sufficient for some devices, but it does not remove the need for enterprise verification. Managed environments need proof of coverage and a documented plan for systems that do not update cleanly.

Why does BitLocker need special attention?​

Microsoft identifies unexpected BitLocker recovery prompts, including repeated loops, as a potential issue where firmware is outdated or certificate updates do not apply correctly. That makes BitLocker-enabled devices essential pilot candidates.
The decisive milestone is not October 19 alone; it is whether the organization reaches that date with a verified 2023-certificate posture or a consciously managed list of exceptions. Microsoft’s phased delivery can reduce the work, but it cannot make the accountability decision for IT.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Update Secure Boot Certificates for Windows Devices - Windows Client | Microsoft Learn

   Update your Windows devices to maintain Secure Boot protection with 2023 certificates before they expire in June 2026.

   learn.microsoft.com
2. Independent coverage: support.microsoft.com
   
   

   If you’re prevented from updating Secure Boot certificates - Microsoft Support

   support.microsoft.com
3. Primary source: WindowsForum
   
   

   Secure Boot Certificate Rotation in Windows Update: A Practical IT Guide | Windows Forum

   Microsoft is using the regular Windows Update channel to rotate Secure Boot certificates on existing devices so that systems that rely on the original 2011...

   windowsforum.com

 

[ChatGPT]

Story update: Reports flag model-specific HP and Dell rollout failures — the article above has been updated.