Secure Boot Certificates 2026 Deadline: How to Check Device Compliance

Secure Boot is about to undergo its biggest change in over a decade. For years, the same digital certificates have safeguarded the Windows boot process. But beginning this June, that stability ends. Microsoft is rolling out new 2023 certificates to replace the ageing keys that have been in place since Windows Server 2012.

For IT teams, this isn’t a warning about failing hardware—it’s a critical maintenance deadline. Missing these updates won’t cause systems to crash, but it will create a long-term security blind spot. Any device without the new keys can no longer receive boot-level security fixes, instantly falling out of compliance.

Here’s what you need to know to ensure your transition is seamless.

What is UEFI?

UEFI is the modern firmware that replaced the “legacy BIOS.” It starts the machine, then hands off to the operating system.

What is Secure Boot?

Secure Boot is a UEFI feature that only allows trusted, signed boot components to run early in startup. It works using a chain of trust:

• PK (Platform Key) – top of the trust chain, usually controlled by the OEM
• KEK (Key Exchange Key) – controls updates to the signature databases
• DB (Allowed signatures) – what is allowed to boot
• DBX (Revoked signatures) – what is blocked, even if otherwise valid

Where is that trust stored?

In the firmware itself, inside UEFI Secure Boot variables (PK/KEK/DB/DBX). Microsoft’s certificates live primarily in DB and KEK, depending on the certificate

Only Microsoft-trusted (or OEM-trusted) code is allowed

What’s expiring, and what replaces it?

Here’s the core mapping (the one you’ll keep coming back to):

Expiring certificate	Expiration date	New certificate	Storage location	Purpose
Microsoft Corporation KEK CA 2011	June 25, 2026	Microsoft Corporation KEK 2K CA 2023	Stored in KEK, KEKDefault	Signs updates to db and dbx.
Microsoft Windows Production PCA 2011	October 20, 2026	Windows UEFI CA 2023	Stored in db, dbDefault	Used for signing the Windows boot loader.
Microsoft UEFI CA 2011	June 28, 2026	Microsoft UEFI CA 2023	Stored in db, dbDefault	Signs third-party boot loaders and EFI applications.
Microsoft UEFI CA 2011	June 28, 2026	Microsoft Option ROM UEFI CA 2023	Stored in db, dbDefault	Signs third-party option ROMs (for example, networking or graphics cards).

The Microsoft Corporation KEK 2K CA 2023 and Windows UEFI CA 2023 certificates are enabled by default and are automatically updated on all applicable systems.

The Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 certificates are not enabled by default on PCs that comply with recent versions of the Microsoft Secured-core PC requirements. If you do not intend to use third-party UEFI code, HP recommends leaving these certificates disabled.

The Enable MS UEFI CA Key setting controls third-party UEFI certificates. To locate this option, open the F10 BIOS Setup menu.

---

How Microsoft delivers the updates (so you don’t over-engineer it)

Microsoft’s guidance is basically:

1. Many devices (especially manufactured since 2024) already have 2023 certs.
2. For the rest, Microsoft can deploy via monthly Windows updates for “high-confidence” device types, unless you opt out.
3. OEM firmware updates can be important because they enable the firmware to accept and store new certificates. Apply OEM firmware updates first if recommended.
4. If you want to deploy yourself proactively, you can trigger the process using registry keys (and there are Intune+ GPO options too)

Tip: Don’t mix deployment methods on the same device (registry vs GPO vs Intune), especially during pilots.

---

PowerShell: One script to check everything (“Am I safe for June 2026?”)

I created a detection and remediation script to help you assess compliance across your tenant device fleet. You can find both scripts on GitHub.

If you want to learn how to deploy them using Microsoft Intune, see my post: How to Deploy PowerShell Script via Intune: A Complete Guide for IT Admins.

What the detection script checks

• Secure Boot is enabled
  • If SecureBootOn is false, nothing else matters.
• Registry status and errors
  • UEFICA2023Status should be updated
  • UEFICA2023Error should be null/0 (key shouldn’t be present unless an error is pending)
• Event log proof (the fastest truth source), Microsoft’s playbook says:
  • Event ID 1808 indicates that the required new certificates have been applied to the firmware
  • Event ID 1801 indicates updated certificates have not been applied yet
• Firmware rejection signals
  • If you see 1795 events, Microsoft explains this is firmware returning an error while updating Secure Boot variables, and Windows will retry on the next restart. The action is to check with the OEM for firmware updates.

How to read the detection output quickly

• SafeForJune2026
  • true = compliant (exit 0)
  • false = not compliant (exit 1)
• If false, read only:
  • ComplianceReasons
  • ComplianceDetails
• Two common real-world interpretations
  • UEFICA2023Status = NotStarted/InProgress → The device hasn’t finished; remember the 12-hour task cadence and reboot dependency.
  • Event 1795 → firmware rejected the handoff; prioritise OEM BIOS/UEFI update
• FirmwareState = Applied When the Event ID 1808 is the newest
• FirmwareState = Pending When the Event ID 1801 is the newest

Tip: Run the script as administrator for best results—event log access and some firmware-related signals are more reliable with elevated permissions

This script is designed for Intune Detection. If you want to test it on a machine, make sure to comment out the last lines

($safe) {
exit 0
} else {
exit 1
}

The output would be compress json, which you can do by simply commenting out the compression option

$summary | ConvertTo-Json -Depth 10 #-Compress

What the remediation script does

Step 0 — Pre-flight checks (and early exit)

It captures PreState (Secure Boot, registry status, and relevant TPM-WMI events), then:

• If Secure Boot isn’t on → exits 1 with clear NextSteps
• If the firmware is already Applied and there’s no servicing error → exits 0 immediately

That makes it safe to run repeatedly across a fleet.

Step 1 — Set the enterprise trigger: AvailableUpdates = 0x5944

The script writes:

• HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates = 0x5944

This matches Microsoft’s enterprise guidance for deploying all needed components.

Step 2 — Run the scheduled task now (don’t wait 12 hours)

It then runs the task at:

• \Microsoft\Windows\PI\Secure-Boot-Update

The script also waits briefly and captures LastTaskResult to help with troubleshooting.

Step 3 — Suspend BitLocker for two reboots (practical protection)

Firmware/boot-chain changes can trigger BitLocker recovery prompts in some environments. Your script attempts:

• Suspend-BitLocker -RebootCount 2 (with a manage-bde fallback)

It reports whether suspension was attempted and whether it succeeded, so the service desk isn’t blindsided.

Step 4 — Post-check and a human answer

It gathers PostState and decides:

• Completed (exit 0) if firmware is Applied and UEFICA2023Error is clear
• NotCompleted (exit 1) with tailored NextSteps if:
  • Firmware is Pending (often means “reboot required”)
  • Firmware state is Unknown (logs missing/inconclusive)
  • Registry/task execution failed
  • Firmware errors exist (1795–1798 family)

How to read the remediation output quickly

Start with:

• Status (Completed / NotCompleted)
• Reason (single paragraph you can paste into a ticket)
• NextSteps (what the user/IT must do next)

Then, only if needed:

• Actions (what it tried: reg set, task start, BitLocker suspend)
• PreState and PostState (before/after evidence)

The most common “NotCompleted” case you’ll see

FirmwareState = Pending → your script correctly advises reboot(s), then re-run detection to confirm Event 1808 appears. Microsoft notes the boot manager update may not occur until after a restar

The rollout plan that won’t ruin your week

1) Baseline report (before changing anything)

Use detection output to segment:

• Secure Boot off (fix BIOS policy/device configuration)
• NotStarted/InProgress (time + reboot + patience)
• Pending (1801 newest → needs reboot/follow-up)
• Firmware rejection (1795+ → OEM firmware update queue)

2) Patch and firmware first on problem models

Microsoft explicitly recommends applying OEM firmware updates first if you’ve identified Secure Boot update issues or OEM recommends it.

3) Pilot the remediation script via Intune Proactive Remediations

Typical flow:

• Detection runs → if exit 1, remediation runs
• Remediation triggers update and returns next steps
• After reboot cycle → detection should return SAFE

4) Monitor using the same signals Microsoft tells you to use

• UEFICA2023Status = Updated
• No UEFICA2023Error
• Event ID 1808 presents as success proof

---

Troubleshooting cheat sheet (copy into your runbook)

UEFICA2023Status = NotStarted / InProgress

• Normal during rollout; task runs every 12 hours; reboot may be needed.
  ✅ Action: wait, reboot, re-run detection

UEFICA2023Error is non-zero

• Indicates a fault; Microsoft advises checking Secure Boot events for root cause.
  ✅ Action: review TPM-WMI events 1795–1799; prioritise OEM firmware if firmware errors appear

Event 1801 (newest)

• Updated certificates not applied yet.
  ✅ Action: reboot and re-check until 1808 appears

Event 1795

• Firmware returned an error when updating Secure Boot variables; Windows retries on next restart; OEM firmware update recommended.
  ✅ Action: update BIOS/UEFI firmware, reboot, retry remediation

FAQ

Will devices stop booting in June 2026?

Microsoft’s risk statement focuses on loss of boot-component security updating after certificate expiry and devices becoming out of security compliance if not updated before expiration.

How do I prove a device is updated?

Microsoft’s playbook calls out:

• Event 1808 (success proof)
• UEFICA2023Status = Updated
• no UEFICA2023Error