Secure Boot certificate rollover: what IT teams must do before 27 June 2026

There is a quiet deadline approaching for most Windows devices in business environments: 27 June 2026. On that date, the Microsoft Corporation UEFI CA 2011 certificate — the certificate that has been the foundation of Secure Boot on Windows hardware for fifteen years — expires. Doing nothing will not immediately lock anyone out of their devices, but it will remove protection against future boot-level security updates, and that distinction is critical.

This article explains exactly what is expiring, which devices require manual action, what the risks are around BitLocker and Intune compliance, and how IT teams can handle this in a structured way.

What is Secure Boot and what exactly is expiring?

Secure Boot is a security standard embedded in your device's UEFI firmware. At startup, it verifies that the bootloader and operating system components are signed with a trusted certificate, preventing malicious software — such as bootkits and rootkits that load before the OS — from executing.

The Microsoft Corporation UEFI CA 2011 certificate is the certificate that signs third-party bootloaders, including the Linux Shim used by virtually all major Linux distributions. This certificate expires on 27 June 2026. A second certificate, the Microsoft Windows Production PCA 2011 which signs the Windows bootloader itself, follows later on 19 October 2026. Microsoft is replacing both with 2023 versions of the same certificates.

Devices that receive the new certificates before the expiry date remain fully protected. Devices that miss the update can still start normally — existing signatures remain valid — but cannot receive new boot-level security updates. That means vulnerabilities discovered after the expiry in the boot chain will not be patched on those devices.

What does Windows Update handle automatically?

For most devices, the update happens automatically via Windows Update. Microsoft has included the certificate renewal in the June 2026 Patch Tuesday cycle, with 9 June as the central rollout date. The update adds the new 2023 certificates to the device's UEFI Secure Boot database and Key Exchange Key (KEK).

However, the automatic update only works when certain conditions are met. The device must be reachable via Windows Update or WSUS. The device's UEFI firmware must be able to store the new certificates, which is the case for virtually all hardware from the past seven years. And the device must not have been actively excluded from automatic updates via a managed update policy.

In tightly controlled environments — with WSUS, Configuration Manager, or air-gapped networks without internet access — the update must be explicitly approved and deployed. Anyone who has configured their update policy to 'approved only' needs to release this update this week.

The BitLocker risk that many overlook

For devices on which BitLocker is active, the certificate rollover carries a specific risk. When the UEFI firmware is updated to include the new certificates, this can cause a change in the TPM measurement values. BitLocker uses those values to determine whether the device is in a trusted state. An unexpected firmware change can cause BitLocker to prompt for the recovery key on the next restart.

This is not a hypothetical risk: in the first weeks after the rollout, cases were reported of BitLocker recovery loops on devices that received the certificate update without the recovery key readily available. The mitigation is straightforward but requires preparation. Before the rollout, verify that BitLocker recovery keys for all devices are stored in Entra ID or Active Directory. Intune-managed devices can enforce this via the Endpoint security policy, but verify per device that the key has actually been synced.

Intune compliance and Conditional Access

Secure Boot status is a measurable signal in Microsoft Intune. Devices with Secure Boot disabled, or whose boot database is not up to date, can be marked as non-compliant. If your Conditional Access policy is configured to block non-compliant devices from Microsoft 365, SharePoint, or other company resources, that becomes the practical consequence for devices that do not receive the update.

In the Intune portal, check under Devices which devices are currently non-compliant on the Secure Boot requirement. You can configure a compliance policy specifically for Secure Boot or consult the existing Windows Health Attestation policy. Devices managed by Intune but that have not yet received the certificate update are easy to identify via a filter on update status.

For environments using Registry-based opt-in control: the key MicrosoftUpdateManagedOptIn under HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\ determines whether a device receives the update through the managed rollout. A value of 1 means the device is enrolled for the controlled rollout. Intune Remediations can be used to set this key and report status across the entire device fleet.

Attention for devices with Linux or dual boot

Devices running both Windows and Linux deserve extra attention. The UEFI CA 2011 certificate is precisely the certificate that signs the Linux Shim — the bootloader layer used by virtually all major Linux distributions to boot with Secure Boot enabled. After the expiry date, Linux distributions still using an older Shim version signed only with the 2011 certificate may encounter issues when installing Shim updates.

The major distributions have anticipated this. Red Hat has released new Shim versions for RHEL 8, 9, and 10 signed with both the 2011 and 2023 certificates. Ubuntu and Debian follow a similar path. Nevertheless, organisations with hybrid Windows-Linux environments or Proxmox environments should verify that edk2-ovmf packages on hypervisors are updated, so new virtual machines start with the 2023 certificates.

Five steps for IT teams this week

Most of the required action fits into a compact checklist. First: inventory which devices have not yet received the update. Use Intune reporting on Windows Update status or the Device Health Attestation to generate a list of devices that are lagging. Prioritise devices running critical business functions.

Second: verify that BitLocker recovery keys are synced. Go to Entra ID, open the device overview, and check per device whether a recovery key is stored. Consider deploying an Intune script that forces synchronisation for devices that have not yet synced a key.

Third: approve the certificate update in your update management environment. In WSUS or Configuration Manager, the June 2026 certificate update appears as a separate item. Approve this update this week for all production groups. Account for a restart window, as the update requires a reboot to complete.

Fourth: check firmware versions on older hardware. Devices older than seven years may require a firmware update from the manufacturer before the new certificates can be stored. Dell, HP, and Lenovo have all published specific knowledge articles on which models require a firmware capsule update. Consult the vendor page for your device models.

Fifth: set a temporary exception rule in Conditional Access for devices that have not yet received the update but are critical to business operations. This prevents devices from being unexpectedly blocked while the update is still being rolled out. Remove the exception once the update is confirmed.

After June: what changes structurally?

The certificate rollover is not a one-off action but a signal of a broader structural shift. Microsoft is moving towards periodic replacement of all Secure Boot certificates, similar to how TLS certificates have had shorter lifecycle cycles for years. IT teams that now set up a structured process for firmware and certificate management will be better positioned for future rollovers.

Want support checking your Intune environment, deploying the certificate update, or setting up BitLocker key management? Contact Zarioh — we help organisations keep Windows security structurally in order.