Secure Boot Certificate Expiration: Confirmed KBs and Intune Deployment Steps

Why this matters to SMB admins

Secure Boot is the firmware-level check that stops untrusted boot software from running before Windows even starts. It relies on a set of digital certificates stored in device firmware, and the certificates originally issued in 2011 are now reaching their expiration dates. Microsoft has published a series of support articles describing what’s expiring, why it matters, and how organizations that manage their own updates — including those using Microsoft Intune — should plan for it.

For SMB administrators, the practical questions are simple: which KB articles actually govern this change, which Windows versions are in scope, and what does the Intune deployment process look like in practice? This article pulls together the confirmed details from Microsoft’s own support articles.

The confirmed KB articles

Microsoft has published four related support articles covering this change, each with its own KB ID:

• KB5062710 — Windows Secure Boot certificate expiration and CA updates. This is the foundational article explaining what’s expiring, when, and why. It lists the specific certificates involved and their expiration dates.
• KB5062713 — Secure Boot Certificate updates: Guidance for IT professionals and organizations. This is the deployment playbook for IT-managed environments, covering preparation, firmware considerations, monitoring, and deployment methods.
• KB5073196 — Microsoft Intune method of Secure Boot for Windows devices with IT-managed updates. This article documents the specific Intune configuration profile and settings used to deploy the certificate updates.
• KB5085790 — Known issues and resolutions for Secure Boot certificates updates. This tracks known problems, including an Intune-specific error code, and their resolution status.

Each article is actively maintained with change logs, so details have been refined over time — it’s worth checking the “Change Log” section of each source before acting on older guidance you may have seen elsewhere.

What’s actually expiring

According to KB5062710, the certificates affected were originally issued in 2011 and are being replaced with 2023-dated equivalents. The documented expiration schedule is:

Expiring Certificate	Expiration Date	Replacement Certificate	Purpose
Microsoft Corporation KEK CA 2011	June 24, 2026	Microsoft Corporation KEK 2K CA 2023	Signs updates to the Secure Boot signature databases
Microsoft Windows Production PCA 2011	October 19, 2026	Windows UEFI CA 2023	Signs the Windows boot loader
Microsoft UEFI CA 2011	June 27, 2026	Microsoft UEFI CA 2023	Signs third-party boot loaders and EFI applications
Microsoft UEFI CA 2011	June 27, 2026	Microsoft Option ROM UEFI CA 2023	Signs third-party option ROMs

Microsoft states that devices which don’t receive the newer 2023 certificates will continue to start and run normally, and will keep receiving standard Windows updates. However, they will lose the ability to receive new security protections tied to the early boot process — including updates to Windows Boot Manager, Secure Boot signature databases, revocation lists, and mitigations for newly discovered boot-level vulnerabilities. Microsoft also notes this can gradually affect scenarios that rely on Secure Boot trust, such as BitLocker hardening or third-party bootloader validation.

Which Windows versions are affected

Per KB5073196, the Intune-based deployment guidance became available on November 11, 2025, for versions of Windows 11 and Windows 10 that were still in support at that time. The article’s change log shows this scope has been actively adjusted:

• Windows 11, version 25H2 was added to the “Applies to” list on March 4, 2026.
• Unsupported versions of Windows 10 were removed from the “Applies to” list on March 9, 2026.

Separately, KB5062713’s FAQ notes that Microsoft’s Controlled Feature Rollout deployment assist may not work on “devices [that] are not on supported client versions of Windows 11 and Windows 10 with extended security updates (ESU)” — indicating that ESU-enrolled Windows 10 devices are also within scope for this broader effort, though the CFR assist specifically has limitations there.

The known-issues article (KB5085790) also calls out Windows 11, version 23H2 specifically in relation to an Intune licensing problem, discussed below.

How Intune deploys the Secure Boot certificate update

KB5073196 documents a specific Intune configuration method using a Settings Catalog profile. The documented steps are:

1. In the Intune admin center, go to Devices > Manage devices > Configuration.
2. Select Create, then New Policy.
3. Set Platform to Windows 10 and later.
4. Choose Settings Catalog as the Profile Type.
5. Name the profile (Microsoft’s example uses “Secure Boot”) and select Next.
6. Under Configuration settings, select Add settings, then search for “Secure Boot” in the settings picker. Three settings appear under the Secure Boot category.
7. Configure the opt-in/opt-out settings as needed for your environment, then finish creating the profile.

The three Settings Catalog options

Enable Secureboot Certificate Updates — This setting controls whether Windows begins the certificate deployment process on a device. When enabled, Windows automatically starts deploying updated certificates; the underlying task runs every 12 hours, and some updates may require a restart to complete. The setting’s own reference table lists its documented default as Disabled. Note that Microsoft’s walkthrough for building the profile separately states this setting “is selected by default and enabled” during profile creation — administrators should verify the actual configured value in their own tenant before relying on either description, since the source presents these two statements without reconciling them. Microsoft also notes that once certificates are applied to firmware, they cannot be removed from within Windows; clearing them requires the firmware interface.

Configure Microsoft Update Managed Opt In — This setting lets a device participate in Microsoft’s Controlled Feature Rollout for certificate deployment. Documented default: Disabled (no participation). When enabled, the device requires diagnostic data to be sent to Microsoft, and Microsoft assists with deploying certificates as part of the rollout.

Configure High Confidence Opt-Out — This setting governs whether certificate updates are applied automatically through Windows monthly cumulative updates for devices Microsoft has validated with high confidence. Documented default: Disabled, meaning devices with validated update results will automatically receive certificate updates through monthly updates. Enabling this setting blocks that automatic delivery path.

Each of these settings corresponds to an underlying registry key (AvailableUpdates, MicrosoftUpdateManagedOptIn, and HighConfidenceOptOut respectively), which can also be used for monitoring outside of Intune.

Deployment methods documented alongside Intune

KB5062713 describes multiple deployment paths beyond the Settings Catalog profile, including registry keys, Group Policy (planned for a future update at the time of writing), and the Windows Configuration System (WinCS) command-line tool for domain-joined clients. That same article states that a dedicated Configuration Service Provider (CSP) for Intune/Configuration Manager deployment was planned for “a future update,” with PowerShell script deployment mentioned as the interim Intune/Configuration Manager approach. Given that KB5073196’s Settings Catalog method was documented from November 2025 onward, administrators should treat the Settings Catalog profile in KB5073196 as the current primary Intune-native method, while being aware that Microsoft’s guidance has evolved across these two articles.

Known Intune-specific issues and resolutions

Error Code 65000 on Pro editions

KB5085790 and KB5073196 both document a resolved issue affecting Secure Boot deployment through Intune MDM:

• Symptom: Secure Boot configuration policies deployed via Intune were blocked on Pro editions of Windows 10 and Windows 11, returning Intune Error Code 65000. Event logs recorded POLICYMANAGER_E_AREAPOLICY_NOTAPPLICABLEINEDITION, indicating the feature wasn’t recognized as applicable to the edition.
• Resolution: Microsoft updated the Intune licensing service on January 27, 2026 to allow Secure Boot configuration deployment on Pro editions of Windows 10 and Windows 11.
• Windows 11, version 23H2 specifically: This error was resolved for that version through Windows updates released on and after April 14, 2026 (KB5082052).
• License renewal: Devices that obtained their Intune license before the fix needed their license renewed to pick up the change. Licenses renew automatically on a monthly cycle, so Microsoft expected affected devices to be resolved by February 27, 2026 (with Windows 11 23H2 devices needing the later KB5082052 update as well). Admins could also manually renew a device’s license by running ClipDLS.exe removesubscription followed by ClipRenew.exe under the affected user’s context.

Event ID 1795 issues in virtualized environments

The known-issues article also documents two separate problems affecting Secure Boot certificate deployment on virtual machines, which are relevant if you manage Hyper-V hosts or Azure-based VMs alongside Intune-managed physical endpoints:

• Hyper-V virtual machines: Key Exchange Key (KEK) updates could fail with Event ID 1795 and a “media is write protected” error. This was resolved in Windows updates released on and after March 10, 2026 (Windows Server 2025 required updates from April 14, 2026). Microsoft states the fix must be applied on both the host and the guest.
• Azure Trusted Launch virtual machines: A separate, still-open issue can prevent the KEK update from completing on certain Azure Trusted Launch (Gen2) VMs, Windows 365 Cloud PCs, and Azure Virtual Desktop environments. As of the source’s latest update, Microsoft states there is no required customer action and a fix is planned for a future update.

Documented deployment guidance from Microsoft

KB5062713 lays out a staged deployment playbook that applies regardless of which deployment method (Intune, GPO, registry keys, or WinCS) an organization uses:

• Inventory and test first. Microsoft recommends building a representative sample of devices based on manufacturer, model, BIOS version, and baseboard details, and testing updates on that sample — with a suggested minimum of four or more devices per unique hardware category — before broad rollout.
• Monitor before you deploy. Set up monitoring ahead of time so you have a baseline view of your fleet. Event ID 1801 indicates a device still needs updating; Event ID 1808 indicates the required certificates have been successfully applied.
• Deploy in stages. Microsoft recommends starting with a small subset of devices, validating results, and expanding gradually rather than deploying to the entire fleet at once.
• Expect a multi-day process. Once a device is targeted for the update, Microsoft estimates roughly 48 hours and one or more restarts before the certificate deployment completes, since the underlying scheduled task runs every 12 hours and some steps depend on a natural reboot.

Practical recommendations for SMB administrators

The following points are practical guidance based on the documented behaviour above, not additional Microsoft requirements:

• Confirm your current Intune settings before assuming a default. Given the inconsistency noted in KB5073196 around the default state of “Enable Secureboot Certificate Updates,” check the actual configured value in your Settings Catalog profile rather than relying on either documented default.
• If you hit Error Code 65000, check the date and Windows version first. Since the licensing fix and the Windows 11 23H2-specific fix (KB5082052) landed on different dates, confirm your affected devices have received the relevant update before troubleshooting further, or use the manual license renewal commands if you need an immediate fix.
• Treat Hyper-V and Azure VM environments as a separate check. If your organization runs Windows workloads on Hyper-V or Azure VMs alongside Intune-managed physical devices, verify both host and guest have the relevant Windows updates installed, since the Hyper-V fix specifically requires updates on both sides.
• Don’t mix deployment methods on the same device. Microsoft’s guidance explicitly recommends choosing one deployment path (Intune, GPO, registry keys, or WinCS) per device rather than combining them.

Conclusion

The Secure Boot certificate expiration is a firmware-trust maintenance issue rather than an urgent outage, but it has real long-term security implications and a genuinely documented Intune deployment path. For SMB administrators, the practical takeaway is to know the four governing KB articles (KB5062710, KB5062713, KB5073196, and KB5085790), confirm which Windows versions in your fleet are in scope, and use the Settings Catalog profile described in KB5073196 as the current Intune-native deployment method — while watching the known-issues article for updates on the Error Code 65000 fix and virtualization-related event log issues. As with any Microsoft servicing article that’s still receiving change-log updates, it’s worth rechecking these sources periodically before finalizing a rollout plan.

This article is a draft based on currently available Microsoft support documentation and is subject to human review before publication.