Your Windows PCs Could Fail to Boot in June - Secure Boot Certificates Are Expiring

A 15-Year-Old Trust Anchor Is About to Break

Microsoft's Secure Boot, the firmware-level gatekeeper that prevents unauthorized code from executing before Windows even loads, was introduced in 2011. For over fifteen years, the same certificate hierarchy has anchored the trust foundation for billions of PC boots worldwide. That era ends in June 2026, when the first of those original certificates begin to expire.

This isn't a theoretical risk. It's a scheduled, predictable event with real operational consequences. Any Windows PC manufactured before 2024 that hasn't received updated 2023-era certificates may face degraded boot security or, on managed enterprise networks with strict Secure Boot policies, outright boot failures. Microsoft confirmed on April 2, 2026, that the Windows Security app now displays a dedicated certificate status indicator, a quiet acknowledgment that millions of devices remain unpatched with fewer than 90 days until the first expirations.

For CTOs and IT directors managing heterogeneous fleets, this is a compliance and continuity problem that demands immediate inventory and remediation.

---

What Secure Boot Actually Does. And Why Certificates Matter

Secure Boot is a UEFI (Unified Extensible Firmware Interface) feature that validates the cryptographic signature of every piece of software that runs during the boot process, from the firmware itself, through the bootloader, to the OS kernel. It operates below the operating system level, which means it catches rootkits and bootkits that traditional antivirus software can never detect.

The trust model works through a chain of digital certificates stored in the PC's firmware:

1. Root certificates, Issued by Microsoft and embedded in UEFI firmware. These are the trust anchors.
2. Intermediate certificates, Signed by the root, authorizing specific boot components.
3. Leaf certificates, Signed by intermediates, validating individual bootloaders and drivers.

When a certificate in this chain expires, the signature validation fails. On devices with strict Secure Boot policies enforced by Group Policy or MDM, a failed validation means the device refuses to boot. On devices with permissive policies, the device boots but enters a degraded security state: still functional, but unable to receive future boot-level security updates. Either way, your attack surface widens.

The Real Attack Surface

The danger isn't abstract. Bootkits, malware that infects the Master Boot Record or UEFI firmware, have been used in real-world attacks by state-sponsored groups and sophisticated criminal operations. Notable examples include LoJax (attributed to Sednit/APT28), which targeted UEFI firmware directly, and BlackLotus, a UEFI bootkit that exploited a Secure Boot bypass in 2023 to deploy its payload even on systems with Secure Boot enabled.

When Secure Boot certificates expire, the mechanism that blocks these bootkits loses its effectiveness. The signature database (db) and revoked signatures database (dbx) that Secure Boot maintains can no longer be updated, meaning newly discovered vulnerable bootloaders can't be added to the revocation list. It's the firmware equivalent of running an antivirus product with a year-old signature file: technically functional, but increasingly blind to current threats.

For organizations subject to regulatory requirements around endpoint protection (SOC 2, NIST 800-53, ISO 27001), a device with expired Secure Boot certificates represents a control deficiency that must be documented, risk-assessed, and remediated within a defined timeline.

Microsoft's own description is blunt: a device that doesn't receive the new certificates will be "exposed to potential boot-level vulnerabilities that hackers could try to exploit." In a threat landscape where firmware-level attacks are increasing year over year, that's not a gap you want in your security posture.

---

Who's Affected: A Three-Tier Risk Model

Not every Windows device faces the same level of risk. Based on Microsoft's official guidance and OEM communications, here's how the exposure breaks down:

Tier 1. Low Risk (No Action Required)

• Devices shipped in 2025 or later. Almost all devices manufactured in 2025 include the updated 2023 certificates at the factory.
• Devices shipped in mid-to-late 2024. Most OEMs began provisioning updated certificates by mid-2024.
• Windows 11 devices with automatic Windows Update enabled. New certificates are delivered through the regular monthly update process.

Tier 2. Moderate Risk (Check and Update)

• Windows 11 devices manufactured before 2024. These should receive certificates automatically via Windows Update, but a firmware update from the OEM may be required first. Microsoft's new Windows Security indicator will show a yellow badge if action is needed.
• Windows 10 devices enrolled in Extended Security Updates (ESU). These receive the certificates through the ESU update channel, but the same firmware dependency applies.
• Specialized systems: servers, IoT devices, kiosks. These may follow different update processes and require manual intervention.

Tier 3. High Risk (Immediate Action Required)

• Windows 10 devices not enrolled in ESU. Support ended October 2025. These devices do not receive Windows updates and will not receive the new certificates. This is the largest single risk pool.
• Devices with outdated firmware that blocks certificate enrollment. Even on Windows 11, some firmware versions cannot accept the new certificates. A red badge in Windows Security indicates this state.
• Enterprise-managed devices with strict Secure Boot policies. If your Group Policy enforces Secure Boot and a device fails certificate validation, the device will not boot: period.

---

The April 2026 Windows Security Update: What It Tells You

On April 2, 2026, Microsoft began rolling out a new Secure Boot status indicator inside the Windows Security app. You'll find it under Device security > Secure Boot. The indicator uses a simple badge system:

Badge	Meaning	Action
Green	Device has received updated certificates	None required
Yellow	Device has not yet received certificates, but can accept them	Install latest Windows Update + check OEM firmware page
Red	Device cannot receive new certificates, firmware blocks enrollment	Apply OEM firmware update immediately; if unavailable, plan device replacement

Microsoft has also announced that beginning in May 2026, additional system-level notifications will appear outside the Windows Security app: system alerts, taskbar warnings, and expanded in-app guidance. This escalation signals that Microsoft expects a significant number of devices to remain unpatched as the June deadline approaches.

For enterprise IT teams, the Windows Security indicator is a useful per-device check, but it doesn't scale. You need fleet-level visibility, which brings us to the remediation playbook.

---

The Remediation Playbook: What to Do Now

Step 1: Inventory Your Fleet (This Week)

You cannot remediate what you haven't inventoried. Start with a complete device audit:

• Export your device list from your MDM or endpoint management platform (Intune, SCCM, Jamf, etc.).
• Identify devices manufactured before 2024. These are your primary risk pool. Most management platforms capture hardware manufacturing dates via WMI or similar interfaces.
• Flag Windows 10 devices not enrolled in ESU. These will not receive certificates under any circumstances.
• Identify specialized systems, servers, kiosks, IoT endpoints, industrial PCs, that may have non-standard update paths.

Step 2: Check Firmware Currency (Within Two Weeks)

For every device in the risk pool:

• Check the OEM support page for firmware updates related to Secure Boot. Microsoft maintains an OEM guidance index linking to Dell, HP, Lenovo, and other manufacturer resources.
• Apply firmware updates before attempting certificate enrollment. The certificate update is delivered via Windows Update, but it requires compatible firmware to accept it.
• Test on a pilot group before fleet-wide deployment. Firmware updates are inherently riskier than OS-level patches.

Step 3: Enforce Certificate Delivery (Ongoing)

Once firmware is current:

• Ensure Windows Update is active on all managed devices. The certificates are delivered through the standard monthly update channel.
• For devices with limited diagnostic data (common in privacy-sensitive environments), Microsoft recommends using the IT administrator playbook and deploying certificates through existing management tools.
• Monitor the Windows Security badge across your fleet. Intune and similar platforms can read the Secure Boot status through device compliance policies.

Step 4: Address the Unrecoverable Devices (Before June)

Some devices cannot be saved:

• Windows 10 devices without ESU need to be upgraded to Windows 11 (if hardware permits) or replaced.
• Devices with red badge status where no firmware update is available represent a permanent security gap. Plan replacement or isolate them from networks requiring strict Secure Boot compliance.
• Legacy servers and embedded systems running older Windows versions may need vendor-specific remediation paths. Engage your vendors now: lead times for embedded system firmware updates can be measured in months.

Deploying at Scale with Intune and SCCM

For organizations using Microsoft Intune or SCCM, you can automate much of the fleet-wide remediation:

• Intune: Create a device compliance policy that reads the Secure Boot status via the DeviceHealthScript resource. Non-compliant devices can be flagged for conditional access restrictions, ensuring they can't access sensitive resources until remediated.
• SCCM: Use the hardware inventory extension to collect Secure Boot certificate status across your fleet. Deploy firmware updates as required applications targeted at device collections filtered by manufacturer and model.
• PowerShell scripting: For environments without Intune or SCCM, the Confirm-SecureBootUEFI cmdlet and WMI queries against ROOT\Security\2 namespace can extract certificate status programmatically. Script results can be aggregated into a CSV for manual tracking.
• Group Policy: If you enforce Secure Boot via GPO, document which OUs have the policy applied and ensure device owners in those OUs have been notified of the firmware update requirement.

The key insight is that certificate delivery is tied to the monthly Windows Update cycle. If your organization defers updates by more than 30 days (common in enterprise change management workflows), you may need to create an expedited deployment ring specifically for the Secure Boot certificate KB.

---

Why This Matters for Business: Beyond the Boot Screen

The immediate risk is clear: devices that can't boot or that boot with degraded security. But the business implications extend further.

Compliance Exposure

If your organization is subject to SOC 2, HIPAA, PCI-DSS, or similar frameworks, Secure Boot is typically part of your baseline security controls. A device running with expired boot certificates represents a documented gap in your security posture: one that auditors will flag. Remediation evidence needs to be in place before your next audit cycle.

For PCI-DSS specifically, Requirement 5 mandates protection against malware, and expired Secure Boot certificates directly undermine that control on Windows endpoints. For HIPAA, the Security Rule requires technical safeguards to protect electronic protected health information (ePHI), and boot-level compromise represents a clear vector for data exfiltration that bypasses OS-level encryption if the attacker gains access before the OS loads.

Insurance and Liability

Cyber insurance providers increasingly require evidence of basic security hygiene, including firmware-level protections. A known, unaddressed certificate expiration could affect coverage in the event of a breach. Several major cyber insurers have begun including firmware security attestation in their underwriting questionnaires for 2026 policy renewals. A fleet with known certificate expiration issues may face higher premiums, coverage exclusions, or outright denial of claims related to boot-level compromises.

Supply Chain Risk

Your vendors and partners may enforce Secure Boot as a condition of network access. If your devices can't validate their boot chain, you may lose access to partner systems, VPNs, or zero-trust network segments that require device health attestation. In environments where Conditional Access policies evaluate device compliance before granting access to cloud resources (Azure AD, Google Workspace, Okta), an expired Secure Boot certificate could trigger access denials across your entire collaboration ecosystem.

Operational Cost of Inaction

Beyond security and compliance, there's a pure operational cost. If even 5% of a 10,000-device fleet fails to boot on a Monday morning in late June, that's 500 help desk tickets, 500 disrupted employees, and potentially days of productivity loss while devices are manually remediated. The cost of proactive remediation, inventory, firmware updates, and certificate verification, is a fraction of the cost of reactive incident response at scale.

---

The OEM Perspective: Dell, HP, and Lenovo Weigh In

Microsoft's Secure Boot certificate refresh is one of the largest coordinated security maintenance efforts in Windows ecosystem history. The major OEMs have been working with Microsoft on this transition for over a year:

• Dell. Dell says it planned for everything from tightly managed fleets in regulated industries to resilient systems at the edge, ensuring customers across use cases have a clear migration path.
• HP, Vali Ali, HP Fellow and Chief Technologist for Security and Privacy, confirmed that firmware updates are available for all supported HP PCs running Windows 11, with active outreach to business customers.
• Lenovo, Tom Butler, VP of Worldwide Commercial Portfolio, described a coordinated effort across planning, testing, and rollout phases to ensure customers stay protected "without interruption to their business."

The consistent message from all three OEMs: firmware updates are available, but customers must apply them. The update won't happen automatically on most enterprise-managed devices without IT action.

---

A Generational Refresh: What This Means Long-Term

Microsoft describes this as a "generational refresh of the trust foundation that modern PCs rely on at startup." That's not marketing language: it's architecturally accurate. The 2011 certificate hierarchy has been the root of trust for over a decade. The new 2023 certificates will serve the same role for the next decade or more.

This transition also reflects a broader industry shift toward proactive cryptographic lifecycle management. As quantum computing advances threaten to undermine older encryption standards, certificate rotation at the firmware level is becoming a standard practice rather than an exception.

For IT leaders, the Secure Boot certificate expiration is a dress rehearsal for the kind of coordinated, ecosystem-wide security maintenance that will become more frequent. Building the inventory, assessment, and remediation workflows now will pay dividends when the next cryptographic lifecycle event arrives.

---

The 60-Day Countdown: Your Action Checklist

Here's the prioritized timeline for IT leaders with fewer than 90 days until the first certificate expirations:

Week 1 (April 3-9):

• Export full device inventory from MDM/endpoint management
• Identify all devices manufactured before 2024
• Flag all Windows 10 devices not enrolled in ESU

Week 2-3 (April 10-23):

• Check OEM firmware update availability for every device in the risk pool
• Apply firmware updates to a pilot group (50-100 representative devices)
• Validate certificate enrollment on pilot devices via Windows Security indicator

Week 4-5 (April 24 - May 7):

• Roll out firmware updates fleet-wide
• Monitor Windows Security badge status across the fleet
• Begin planning for unrecoverable device replacement or isolation

Week 6-8 (May 8-28):

• Complete fleet-wide certificate enrollment verification
• Document remediation status for compliance records
• Isolate or replace devices that cannot be remediated
• Prepare for Microsoft's May system-level notification rollout

June 2026:

• First certificates expire, verify no devices in degraded state
• Conduct final compliance sweep
• Update security documentation and audit evidence

---

Bottom Line

The Secure Boot certificate expiration is not a zero-day surprise, it's a scheduled event that Microsoft and OEMs have been preparing for over a year. But preparation on their end doesn't equal remediation on yours. If you manage a Windows fleet, the clock is ticking. Inventory your devices, update your firmware, and verify your certificate status before June arrives.

The alternative, a fleet of devices running with degraded boot security, or worse, devices that refuse to boot on a Monday morning, is not a conversation you want to have with your board.