Transcript
Welcome to Ninja101, where today we're looking at how to manage the Secure Boot Certificate expiration that Microsoft has scheduled for June 2026. Before we dive in, a quick bit of background. Secure Boot is a UEFI feature that validates the signatures of pre-boot software before allowing it to run. Microsoft has three certificates underpinning this trust chain that are all expiring this year. The KEK CA-2011 and the UEFI CA-2011 begin expiring in June 2026, and the Windows Production PCA-2011, which signs the Windows bootloader itself, expires in October 2026. Devices that miss these updates won't stop booting, and standard Windows updates will continue to install, but they will lose the ability to receive new Secure Boot security protections for the early boot process. NinjaOne can help you monitor and manage that rotation across your entire fleet. Let's start in NinjaOne by creating the custom fields that will display the script's output. Go to Administration, Devices, Custom Fields, and let's create two custom fields. The first is a WYSIWYG field, or what you see is what you get. We're going to name this field Secure Boot Cert Status Card. Let's go to the Automation Permissions on the left and make sure that it has Read Write from Automations, but is Read Only to Technicians. And then under Advanced on the left-hand side, make sure to check the box to Always Expand. We're going to create a second custom field. This field will be a text field, and this is going to hold the one-line plain text summary. Go ahead and name this field Secure Boot Cert Status. And then under the Automation Permissions, give it the same permissions as above, with Read Write permissions for Automations, and Read Only for Technicians. Now that we've created the fields, we can go to the Roles menu. Hover over Windows Systems and then click the ellipsis on the right, select Edit, and then click Manage Tabs in the top right. We're going to create a new tab called Secure Boot, close this modal, then switch to the newly created tab, and add in the two custom fields we created earlier. Now we're ready to import the script. Navigate to Administration, Library, Automation, and then click the Add Automation button. This script is from the NinjaOne community, and I've linked it in the description below. Go ahead and copy and then paste it into the code box. Once you import the script, there are a few script variables that I am creating here. In the interest of time, that information is located in the GitHub link in the YouTube description. We're going to walk through this on a live device. Execute the script with Secure Boot Action set to Audit, and Enforce SVN Compliance set to Passive. This is a fully read-only run, so nothing is changed on the actual device. After the script completes, open the device and navigate to the Secure Boot custom field tab, and you'll see the status card populated with a detailed breakdown. Now that I know the state of my devices, I 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. Rerun the script with Secure Boot Action set to Enable Opt-in. This configures the machine's opt-in registry keys, sets the required telemetry level, and triggers the Schedule task. If the device is already opted in or already compliant, the script notes that no change was needed. We'll want to automate the script so that it keeps the custom fields current, so I'm going to create a task, name that task, schedule it, and configure the script to run every week in Audit mode. This way, as devices complete their rotation or encounter problems, you'll see it reflected in Ninja 1. Now that our custom field updates every week, we can report on devices that need attention. I'll navigate to Reporting and create a new summary report with a blank template. I can customize this report to add a data table, filter only to Windows devices, and then customize the columns so that the Secure Boot Cert Status custom field is present, along with data on the Make, Model, and Warranty information of the devices. We can also get a similar view by going to Devices and adding in the column for Secure Boot Cert Status, then filtering for Windows devices, and then for the Secure Boot Cert Status custom field where the value does not contain Compliant. And this is a broad catch-all for any device that hasn't completely finished the process. Let's look at some real-world examples. This first device is a laptop where the status card shows all three certificate updates, the UEFI CA-2023, KEK-2023, and Boot Manager, are marked as updated. We're just waiting for Windows Update to finalize the rotation. But on this second device, the status card shows the UEFI CA-2023 certificate is still missing, and a firmware update may be required to update the certificate. Last week I made a video on how NinjaOne can help manage firmware updates on Dell workstations, and this is exactly why that matters. For the 2023 certificates to be written into the UEFI Secure Boot Database, the device firmware first needs to support the injection. This is an older Dell machine that's no longer receiving any firmware updates from the manufacturer, which means that there's no path to get the new certificates onto it. The device will still boot after June 2026, and regular Windows updates will keep installing. But because the firmware can accept the replacement certificates, it will be permanently unable to receive new Secure Boot Security updates moving forward. I've linked the NinjaOne Community Script below. A very, very big thank you to Sam Kay, who is the creator of this script. Really appreciate you sharing all of your knowledge. If you have any questions, please leave a comment. Take care.
