Secure Boot Certificate Update 2026: Fix Non-Compliant Devices with Intune Proactive Remediations

If you have opened the Intune Secure Boot Status Report recently, you may have seen numbers similar to the example below — 449 devices up to date, 3,052 not up to date, and 1,651 not applicable. Those last two columns represent real security gaps across your fleet — and both have a specific root cause and a specific fix.

📷 Save as blog/images/sb-status-report.png to display this screenshot

What is Secure Boot? (Start here if you are new to this)

Imagine your PC as a secure building. Before anyone gets in, a security guard checks every ID at the door. Secure Boot is that security guard — but for your computer's startup process.

When you press the power button on a Windows device, a sequence of software loads before Windows itself even starts. First the UEFI firmware, then the bootloader, then the operating system kernel, then drivers. Any one of these components can be replaced by malware — a category of attack called a bootkit or rootkit — and if that happens, the malware runs before Windows, before your antivirus, before any of your security tools. It can hide from everything.

Secure Boot solves this by enforcing a chain of trust. Before each piece of startup software is allowed to run, UEFI checks its digital signature against a list of trusted certificates. If the signature is valid — trusted — it runs. If not, UEFI refuses to load it. This means a malicious bootloader simply cannot run on a Secure Boot–enabled device, because it will not have a valid signature from a trusted certificate authority.

According to Microsoft Learn, "modern malware and bootkits specifically are capable of starting before Windows, completely bypassing OS security, and remaining hidden." Secure Boot is the foundational control that prevents this class of attack from working.

The certificate stores: DB, DBX, and KEK

Secure Boot relies on three certificate stores maintained in UEFI firmware:

• DB (Signature Database) — the allow-list. Contains certificates for trusted boot components. The Microsoft UEFI CA 2011 certificate that has historically been in this store allows signed operating systems and bootloaders to run. The 2023 update adds the new Microsoft UEFI CA 2023 certificate.
• DBX (Forbidden Signature Database) — the block-list. Contains certificates and hashes for components that are known to be compromised or malicious. Microsoft uses this to revoke bootloaders that have known vulnerabilities (such as the BlackLotus bootkit).
• KEK (Key Exchange Key) — controls who is authorised to update the DB and DBX. Microsoft's KEK certificate is what allows Windows Update to push new revocations into your DBX. Without a valid KEK, Microsoft cannot send you new security revocations.

The 2011 versions of the DB and KEK certificates are expiring. Once expired, Microsoft can no longer issue new revocations through those certificates — meaning newly discovered compromised boot components cannot be blocked on devices that are still using the old certificate chain. This is why the update matters.

The 2026 timeline

As Microsoft stated in the KB5095093 June 23, 2026 Preview update: "Secure Boot certificates used by most Windows devices are set to expire starting in June 2026." Microsoft is rolling out the new certificates through Windows Update using "additional high confidence device targeting data, increasing coverage of devices eligible to automatically receive new Secure Boot certificates." For managed enterprise devices, that automatic path does not apply — you own the remediation.

Understanding the two failure states in your report

Each failure state has a completely different fix. The sections below cover both, with ready-to-deploy Intune Proactive Remediation scripts for each.

Fix 1 — "Not Up to Date": trigger the certificate update

For devices where Secure Boot is already enabled but the 2023 certificate has not been applied, Windows has a built-in mechanism to perform the update. It is triggered via a registry key and a scheduled task. Intune can set this trigger silently across your fleet.

Step 1: Check the Secure Boot Status Report

Navigate to the Secure Boot Status Report to export the list of affected devices:

📷 Save as blog/images/sb-status-report.png to display this screenshot

Step 2: Enable the certificate update policy in Intune

Before deploying the remediation script, enable the Secure Boot certificate update setting via Settings Catalog. This is the policy-level permission that allows the update to occur:

1. Go to Intune admin centre → Devices → Configuration → Create policy
2. Platform: Windows 10 and later / Profile type: Settings catalog
3. Search for Secure Boot in the settings picker
4. Enable: Enable Secure Boot Certificate Updates
5. Assign to your device group for "Not Up to Date" devices

📷 Save as blog/images/intune-config-create.png

📷 Save as blog/images/create-profile-settings-catalog.png

📷 Save as blog/images/settings-picker-search.png

📷 Save as blog/images/secure-boot-3-settings.png

This policy writes to HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdatePolicy (value 5944). Both the Intune policy and Group Policy write to the same registry location — you only need one.

Step 3: Deploy the detection script

This script reads the UEFICA2023Status registry value and exits 0 (compliant) or 1 (non-compliant). Deploy it as the Detection script in an Intune Proactive Remediation.

# Detection: Check Secure Boot CA 2023 certificate update status
# Author: Imran Awan | endpointweekly.com
# Run as: System

$AvailableUpdatesValue = 0x5944

try {
    # Confirm Secure Boot is enabled
    try { $sbEnabled = Confirm-SecureBootUEFI -ErrorAction SilentlyContinue } catch { $sbEnabled = $false }
    if (-not $sbEnabled) {
        Write-Output "Non-Compliant: Secure Boot is disabled."
        Exit 1
    }

    # Read registry status values
    $servicingPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing"
    $sbPath        = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot"
    $status    = (Get-ItemProperty -Path $servicingPath -Name "UEFICA2023Status"  -ErrorAction SilentlyContinue).UEFICA2023Status
    $capable   = (Get-ItemProperty -Path $servicingPath -Name "WindowsUEFICA2023Capable" -ErrorAction SilentlyContinue).WindowsUEFICA2023Capable
    $available = (Get-ItemProperty -Path $sbPath        -Name "AvailableUpdates"        -ErrorAction SilentlyContinue).AvailableUpdates

    switch ($status) {
        "Updated"    { if ($capable -eq 2) { Write-Output "Compliant: Updated"; Exit 0 } else { Write-Output "Non-Compliant: Updated but Capable=$capable"; Exit 1 } }
        "InProgress" { Write-Output "Compliant: In progress"; Exit 0 }
        "NotStarted" { if (($available -band $AvailableUpdatesValue) -eq $AvailableUpdatesValue) { Write-Output "Compliant: Trigger set"; Exit 0 } else { Write-Output "Non-Compliant: Not started"; Exit 1 } }
        default      { Write-Output "Non-Compliant: Unknown status=$status"; Exit 1 }
    }
} catch {
    Write-Output "Non-Compliant: Error - $_"
    Exit 1
}

Step 4: Deploy the remediation script

When the detection script exits 1, Intune runs this remediation. It sets the AvailableUpdates registry trigger to 0x5944 and starts the \Microsoft\Windows\PI\Secure-Boot-Update scheduled task. A reboot is required to complete the update.

# Remediation: Trigger Secure Boot CA 2023 certificate update
# Author: Imran Awan | endpointweekly.com
# Run as: System

$AvailableUpdatesValue = 0x5944
$ScheduledTaskName     = "\Microsoft\Windows\PI\Secure-Boot-Update"

try {
    try { $sbEnabled = Confirm-SecureBootUEFI -ErrorAction SilentlyContinue } catch { $sbEnabled = $false }
    if (-not $sbEnabled) { Write-Output "Failed: Secure Boot is disabled."; Exit 1 }

    $servicingPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing"
    $sbPath        = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot"
    $status    = (Get-ItemProperty -Path $servicingPath -Name "UEFICA2023Status" -ErrorAction SilentlyContinue).UEFICA2023Status
    $available = (Get-ItemProperty -Path $sbPath        -Name "AvailableUpdates" -ErrorAction SilentlyContinue).AvailableUpdates

    if ($status -eq "NotStarted") {
        if (($available -band $AvailableUpdatesValue) -ne $AvailableUpdatesValue) {
            Set-ItemProperty -Path $sbPath -Name "AvailableUpdates" -Value $AvailableUpdatesValue -Type DWord
        }
        Start-ScheduledTask -TaskName $ScheduledTaskName
        Write-Output "Remediated: Trigger set and task started. Reboot required."
        Exit 0
    } elseif ($status -in "Updated", "InProgress") {
        Write-Output "Remediated: No action needed (status=$status)"; Exit 0
    } else {
        Write-Output "Failed: Unknown status=$status"; Exit 1
    }
} catch {
    Write-Output "Failed: $_"; Exit 1
}

Step 5: Create the Intune Proactive Remediation

1. Go to Intune admin centre → Devices → Scripts and remediations → Create
2. Name: Secure Boot CA 2023 Certificate Update
3. Upload the detection script to Detection script
4. Upload the remediation script to Remediation script
5. Run as: System (64-bit PowerShell)
6. Schedule: daily until compliant
7. Assign to: device group containing your "Not Up to Date" devices

📷 Save as blog/images/remediation-main-page.png

📷 Save as blog/images/remediation-create-basics.png

📷 Save as blog/images/remediation-settings-tab.png

Alternative: Group Policy

If you use GPO instead of or alongside Intune, the same update can be enabled via ADMX:

1. Download the latest ADMX templates for Windows 11 25H2 from Microsoft and update your Central Store
2. Open Group Policy Management → Computer Configuration → Administrative Templates → Windows Components → Secure Boot
3. Enable: Enable Secure Boot Certificate Deployment

Both methods write to the same registry path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot with AvailableUpdatePolicy set to 5944.

Fix 2 — "Not Applicable": enable Secure Boot on Lenovo devices

"Not Applicable" means Secure Boot is off in UEFI firmware. Certificate updates are impossible until Secure Boot is enabled. These devices are completely unprotected at boot time — no chain of trust, no signature verification, and no ability to receive any Secure Boot protections from Microsoft.

On Lenovo hardware, the BIOS can be configured remotely via WMI without requiring a technician to physically access each device. Lenovo exposes a WMI namespace (root\WMI) with classes including Lenovo_BiosSetting, Lenovo_SetBiosSetting, and Lenovo_SaveBiosSettings. This is the mechanism the remediation script uses.

Detection script — Lenovo Secure Boot status

# Detection: Secure Boot enabled check (Lenovo WMI)
# Exit 0 = Compliant (Secure Boot enabled)
# Exit 1 = Non-Compliant (Secure Boot disabled or not found)

try {
    $SecureBoot = Get-WmiObject -Class Lenovo_BiosSetting -Namespace root\WMI -ErrorAction Stop |
                  Where-Object { $_.CurrentSetting -match "SecureBoot" } |
                  Select-Object -ExpandProperty CurrentSetting

    if ($SecureBoot -eq "SecureBoot,Enable") {
        Write-Host "Compliant: SecureBoot is enabled."; exit 0
    } else {
        Write-Host "Not Compliant: SecureBoot is disabled or unknown: $SecureBoot"; exit 1
    }
} catch {
    Write-Host "Error querying Lenovo BIOS WMI: $_"; exit 1
}

Remediation script — enable Secure Boot via Lenovo WMI

# Remediation: Enable Secure Boot via Lenovo WMI BIOS interface
# Author: Imran Awan | endpointweekly.com
# ⚠ Replace Password_1 and Password_2 with your BIOS supervisor passwords

$LogDir = "C:\Windows\Logs\Temp\scripts"
if (-not (Test-Path $LogDir)) { New-Item -ItemType Directory -Path $LogDir -Force | Out-Null }
Start-Transcript -Path "$LogDir\SecureBootRemediation.log" -Append -Force

try {
    # Suspend BitLocker for 1 reboot before touching BIOS
    $BLStatus = Get-BitLockerVolume -MountPoint "C:" -ErrorAction Stop
    if ($BLStatus.ProtectionStatus -eq "On") { Suspend-BitLocker -MountPoint "C:" -RebootCount 1 }

    # BIOS password configuration
    # Replace Password_1 (old/current) and Password_2 (new/rotated) with real values
    $Encoding = ",ascii,us"
    $OldPass1 = "," + "Password_1" + $Encoding
    $OldPass2 = "Password_1" + $Encoding
    $NewPass1 = "," + "Password_2" + $Encoding
    $NewPass2 = "Password_2" + $Encoding

    # Test which password is accepted
    $OldTest = (Get-WmiObject -Class Lenovo_SaveBiosSettings -Namespace root\wmi).SaveBiosSettings($OldPass2).return
    if ($OldTest -eq "Success") { $Pass1 = $OldPass1; $Pass2 = $OldPass2 }
    else {
        $NewTest = (Get-WmiObject -Class Lenovo_SaveBiosSettings -Namespace root\wmi).SaveBiosSettings($NewPass2).return
        if ($NewTest -eq "Success") { $Pass1 = $NewPass1; $Pass2 = $NewPass2 }
        else { Write-Host "ERROR: Neither BIOS password accepted."; Stop-Transcript; exit 1 }
    }

    # Enable Secure Boot and save
    (Get-WmiObject -Class Lenovo_SetBiosSetting  -Namespace root\wmi).SetBiosSetting("SecureBoot,Enable$Pass1") | Out-Null
    $SaveResult = (Get-WmiObject -Class Lenovo_SaveBiosSettings -Namespace root\wmi).SaveBiosSettings($Pass2).return
    if ($SaveResult -ne "Success") { Write-Host "FAILED: $SaveResult"; Stop-Transcript; exit 1 }

    Write-Host "SUCCESS: Secure Boot enabled. Reboot required."
    Stop-Transcript; exit 0
} catch {
    Write-Host "Error: $_"; Stop-Transcript; exit 1
}

Intune deployment for Lenovo remediation

1. Go to Intune admin centre → Devices → Scripts and remediations → Create
2. Name: Lenovo — Enable Secure Boot
3. Upload detection script and remediation script
4. Run as: System (64-bit)
5. Assign to: a device group filtered by Device manufacturer = Lenovo (use a filter in the assignment to avoid running this on Dell/HP)

Monitoring — registry and Event Viewer

After deployment, verify progress by checking these registry values on target devices:

📷 Save as blog/images/registry-secureboot-trigger.png

📷 Save as blog/images/registry-servicing-inprogress.png

📷 Save as blog/images/registry-servicing-updated.png

For Event Viewer monitoring, navigate to Windows Logs → System and filter by source TPM or TPM-WMI. These sources report firmware-level issues that may block the certificate update even after the registry trigger is set. If your device manufacturer's firmware is outdated, the certificate update may fail at this layer — a BIOS/UEFI firmware update from the manufacturer is required first.

📷 Save as blog/images/eventviewer-tpm-error-1802.png

📷 Save as blog/images/eventviewer-tpm-success-1799.png

What about non-Lenovo devices with Secure Boot disabled?

For Dell and HP devices with Secure Boot disabled, the manufacturer-specific WMI interfaces differ. Dell uses the Dell Command | PowerShell Provider and HP uses the HP BIOS Configuration Utility (BCU). The approach is the same — query the BIOS setting via WMI or the vendor tool, change it, and save with the BIOS password — but the class names and syntax differ. Contact your Dell or HP account team for the specific WMI classes or BCU command syntax for your device models.

What the community is saying

Key things to remember

• Devices remain bootable — not updating the certificate does not cause devices to stop booting. The impact is security degradation, not outage.
• Multiple reboots may be required — a device may show compliant in the detection script after the first reboot, but Event Viewer may still show firmware errors. Give it 2–3 reboots.
• Vendor device lists may be incomplete — some devices are affected even if not listed in your manufacturer's advisory. Verify independently with the Secure Boot Status Report.
• Lenovo BIOS passwords are mandatory — the WMI BIOS interface will not accept changes without a supervisor password. If your estate has no BIOS password set, the remediation script still works but you should set a BIOS password as part of your hardening baseline.
• Non-Lenovo "Not Applicable" devices require manual BIOS access or a manufacturer-specific tool — there is no generic WMI interface for Dell and HP BIOS configuration.

Official Microsoft references

• Secure the Windows boot process — Microsoft Learn
• KB5095093 June 23, 2026 Preview — Microsoft Support
• Alerts and Remediations in Windows Autopatch — Microsoft Learn
• Proactive Remediations in Intune — Microsoft Learn
• How to Update Secure Boot Certificate Using Intune — System Center Dudes

All four scripts — detection and remediation for both failure states — are available on GitHub alongside a full README covering registry paths, deployment steps, and the BIOS password configuration required for the Lenovo remediation.

🔗 View on GitHub — Imran76Awan/Daily-Tasks/Secure-Boot-Certificate-Update-2026