How to Manage Microsoft Secure Boot Certificate Expiration with NinjaOne

What Is Microsoft Secure Boot Certificate Expiration?

Secure Boot is a UEFI security feature that validates the digital signatures of pre-boot software before allowing it to run. It works by checking firmware modules — including boot loaders and UEFI drivers — against a set of trusted certificates stored directly in the device’s firmware. This prevents boot kits and other pre-OS malware from gaining a foothold before Windows even starts.

The certificates that have anchored this trust chain since Windows 8 are now approaching their expiration dates. Microsoft has issued updated 2023 certificates to replace them, and organizations need to act before the original 2011 certificates expire.

Certificates expiring in 2026

• Microsoft Corporation KEK CA 2011 → Expires June 2026
• Microsoft UEFI CA 2011 → Expires June 2026
• Microsoft Windows Production PCA 2011 → Expires October 2026

Devices that miss these updates won’t immediately stop booting — but they will lose the ability to receive new Secure Boot security protections, including revocation list updates, boot manager patches, and mitigations for newly discovered boot-level vulnerabilities. This creates exposure that grows over time.

The NinjaOne solution: SecureBoot Management Script

We’re using a script by SunshineSam from the NinjaOne community.

The script can be found here: https://github.com/SunshineSam/Scripts/tree/main/NinjaRMM/Windows/SecureBoot%20Management

The NinjaOne Secure Boot Management Script

• Audits the actual certificate databases in device firmware (db, KEK, dbDefault, dbx)
• Tracks rotation progress across Microsoft’s multi-stage deployment (Stages 1–4)
• Detects whether firmware is OS-writable, so you know if Windows Update can handle the update automatically
• Maps every device to one of seven clear deployment states with actionable next-step guidance
• Optionally enforces SVN hardening mitigations (with strict safety gates to prevent bricking)
• Outputs formatted WYSIWYG and HTML status cards for fleet-wide visibility in NinjaOne

Step 1: Create custom fields

Let’s start by setting up the custom fields that will surface the script’s output in your NinjaOne device views. Go to Administration → Devices → Custom Fields and create two fields:

• SecureBootCertStatusCard – A WYSIWYG field for the full HTML status card. Set it to Read/Write from automations and read-only for technicians. Under Advanced, check the box to always expand.
• SecureBootCertStatus – A text field (200 character limit) for the one-line plain-text summary. This is ideal for at-a-glance filtering in device tables and alert triggers.

With the fields created, go to the Roles menu, hover over Windows Systems, click the ellipsis, select Edit, then click Manage Tabs in the top-right. Add a new tab called Secure Boot, close the modal, switch to the new tab, and add both custom fields.

Step 2: Import the script from the template library

Navigate to Administration → Library → Automation and click the “Add Automation” button. Copy and paste the script.

Once imported, create the script variables:

Step 3: Run an audit on a live device

Execute the script with securebootAction set to Audit and enforceSvnCompliance set to Passive. This is a fully read-only run — nothing is changed on the device.

After the script completes, open the device record and navigate to the Secure Boot tab. You’ll see the status card populated with a detailed breakdown:

• Certificate inventory – Which of the four new 2023 certificates are present, pending, or absent in the device’s firmware
• Deployment state – One of seven primary states: Compliant, Pending, Action Optional, Action Required,* Disabled, Not Applicable, or Unknown
• Servicing registry – The UEFICA2023Status value and any error codes
• Event log timeline – A color-coded history of Secure Boot events (Event IDs 1799, 1800, 1801, 1808, and others)
• Opt-in status – Whether Windows Update is configured to manage the rotation automatically
• SVN compliance – Which of Microsoft’s four hardening stages have been applied

*If a device shows Action Required, it typically means the firmware is not OS-writable and requires either a BIOS/UEFI firmware update from the OEM, or a manual Secure Boot key reset. The status card will surface OEM-specific guidance links for Dell, HP, Lenovo, ASUS, and Microsoft Surface devices.

Understanding the seven deployment states

Every device the script runs on resolves to exactly one primary state. Here’s what each one means and what action (if any) is required:

Step 4: Enable opt-in and schedule regular audits

Now that we know the state of our devices, we can start taking action. For most devices in managed environments, the quickest path is to enable the Windows Update opt-in so Microsoft’s update process can push the new certificates automatically.

Re-run the script with $securebootAction set to Enable opt-in for SecureBoot management. This configures the machine’s opt-in registry keys, sets the required telemetry level, and triggers the scheduled task. If the device is already opted in or already compliant, the script notes that no change was needed.

To keep your custom fields current, schedule the script as a weekly automation. Navigate to your workstation policy and add a scheduled automation to run the script in Audit mode on a recurring weekly schedule. This way, as devices complete their rotation — or encounter problems — you’ll see it reflected in NinjaOne without any manual effort.

Step 5: Create device groups for targeted remediation

With the custom fields updating regularly, you can build device groups that surface devices needing attention. Navigate to Devices and create a new device group using the following conditions:

• Windows Workstations where SecureBootCertStatus contains Action Required — these devices need a firmware update or manual key reset and won’t self-resolve through Windows Update
• Windows Workstations where SecureBootCertStatus contains Action Optional — these are progressing automatically, but you can accelerate them or confirm opt-in is enabled
• Windows Workstations where SecureBootCertStatus does not contain Compliant — a broad catch-all for anything not yet finished

Save these as “Secure Boot – Action Required” and “Secure Boot – In Progress.” You can now tie automated tasks, alert conditions, or technician workflows directly to these groups, making fleet-wide remediation manageable even at scale.

Understanding Secure Boot SVN enforcement risks

The script also supports enforcing Microsoft’s Secure Version Number (SVN) hardening mitigations, which correspond to the four stages of Microsoft’s rollout plan. SVN is the rollback protection piece — once applied, firmware will refuse to load anything older than the recorded version, which prevents attackers from reverting to a vulnerable boot manager.

Stages 3 and 4 are irreversible. Once the 2011 CAs are revoked (Stage 3) or SVN is written to firmware (Stage 4), there is no going back without a physical BIOS factory reset. The script enforces strict prerequisite gates to prevent out-of-order application. If devices use BitLocker, ensure BitLocker recovery keys are backed up before running in Enforce mode.

The recommended approach until Microsoft begins enforcement in June 2026 is to leave $enforceSvnCompliance set to Passive. In Passive mode, the script audits and reports your SVN status without making any changes — and also runs a safety check to clean up any prematurely staged bits before a reboot can process them.

Microsoft’s rollout timeline

Here’s the four-stage rollout Microsoft has planned for the Secure Boot certificate update process:

Wrapping up

The June 2026 deadline is around the corner, but now you have everything you need to get ahead of it. To recap what we covered:

1. Create two custom fields — a WYSIWYG card field and a text summary field
2. Add a Secure Boot tab to your Windows Systems role and attach both fields
3. Import the SecureBoot Management script from https://github.com/SunshineSam/Scripts/tree/main/NinjaRMM/Windows/SecureBoot%20Management
4. Run an initial audit across your fleet in Passive/Audit mode to baseline your current state
5. Enable Windows Update opt-in on devices that are ready for automatic rotation
6. Schedule a weekly audit automation to keep your device records current
7. Build device groups for Action Required and Action Optional devices to target remediation
8. For devices showing Action Required, apply OEM firmware updates first, then re-audit

Acknowledgements

Many thanks and complete credit to Sam K., the creator of the script used in this post! Connect with Sam on LinkedIn here: www.linkedin.com/in/samauroh

Resources

• Microsoft Secure Boot Certificate Overview: KB5062710
• Microsoft IT Pro Blog – Secure Boot Playbook: techcommunity.microsoft.com
• All Secure Boot resources: https://aka.ms/GetSecureBoot
• NinjaOne Template Library documentation and SecureBoot Management script: GitHub – SecureBoot-Management-CA2023.ps1