Home / Blog / Recast Blog / How to Inventory Secure Boot 2023 Certificate Readiness with SCCM (ConfigMgr)

How to Inventory Secure Boot 2023 Certificate Readiness with SCCM (ConfigMgr)

Published On Jul 20, 2026 by Garth Jones Garth Jones
5 min

Over the last few years, Secure Boot has quietly moved from being a “nice-to-have” firmware feature to a critical pillar of Windows platform security. With Microsoft’s transition from the legacy 2011 Secure Boot certificates to the new Windows UEFI CA 2023 certificate family, that importance has only increased. As enterprises approach the 2026 certificate expiration timeline, understanding which devices are ready and which are not has become essential. 

In this post, I will walk through how SCCM (Microsoft Configuration Manager) can be used to inventory and report on Secure Boot 2023-related registry keys, why collecting this data matters, and how Recast has made this visibility easier by delivering three ready-to-use reports based on data collected with a PowerShell script. 

The key points 

  • Microsoft is moving Secure Boot trust from the 2011 certificates to the Windows UEFI CA 2023 family, and enterprises need device-level readiness visibility ahead of the 2026 timeline. 
  • You can use SCCM (ConfigMgr) to collect Secure Boot 2023-related registry key state at scale by deploying a scheduled PowerShell script. 
  • Store the results in a custom WMI class and surface them through SCCM Hardware Inventory for reporting and dashboards. 
  • Recast provides three ready-to-use reports to quickly identify compliant devices, devices that are capable but not updated, and systems that may need remediation. 

Why Secure Boot 2023 inventory matters 

Secure Boot is a UEFI firmware feature that makes sure only trusted, unmodified code is allowed to run during the boot process. Its job is to stop bootkits, rootkits, and other malware from taking control before the operating system and security tools load. 

At a high level, Secure Boot creates a chain of trust that starts in firmware and continues all the way into Windows. 

Microsoft has provided Secure Boot 2023 registry keys (Microsoft documentation) that allow IT-managed devices to detect, trigger, and monitor the Secure Boot 2023 certificate rollout. These registry values live under the SecureBoot servicing area and expose the state of the update, whether the new certificate is present, and whether the device is already booting with the 2023-signed boot manager.  

From an enterprise perspective, this is not a theoretical risk for the following reasons: 

  • Devices without the 2023 certificates may fail future Secure Boot updates. 
  • Boot-level malware protections rely on an intact and current Secure Boot trust chain. 
  • Some hardware models or firmware versions may silently block updates. 

Without inventory, you are effectively flying blind. 

Secure Boot 2023 registry keys (paths and values) 

Microsoft documents two SecureBoot servicing registry locations that expose your rollout state (for example: whether the 2023 certificate content is present, whether the new boot manager policy has been applied, and whether the device is already booting with the 2023-signed path). To make this data reportable at scale, it helps to standardize exactly what you will inventory. 

Registry path Recommended values to inventory What it helps you determine 
SecureBoot servicing location #1 
See: Microsoft “Secure Boot 2023 registry keys” documentation 
Certificate/policy presence indicators Rollout phase/state indicators Boot manager/boot path indicators Is the 2023 content present on disk/registry? Has the device started/completed the rollout steps? Is the device already booting with the expected 2023-signed components? 
SecureBoot servicing location #2 
See: Microsoft  “Secure Boot 2023 registry keys” documentation 
Additional state/health indicators Capability/prerequisite indicators Does the device meet prerequisites for the transition? Are there signals that the device is blocked or not progressing? 

Event Viewer (optional but useful): Microsoft also references related events that can help explain why a device is stuck (for example: policy not applied, update prerequisites missing, or the transition is pending a reboot/servicing step). If you want that troubleshooting context in your reporting, you can capture a small, recent window of the relevant log entries (event ID, timestamp, message) alongside the registry state. However, the registry values alone are usually enough for readiness/compliance dashboards. 

Why SCCM is a great fit for this job 

Being a ConfigMgr guy, I can think of several ways to collect this data with SCCM. But the question is, what are you going to do with the data, and how useful will those collection options be? 

You can use the Scripts feature, but that only works with online computers. You can create custom inventory to collect the registry keys, but that does not help with the Event Viewer details. 

This is where SCCM and PowerShell come together nicely. 

Using a PowerShell script deployed via SCCM as a program on a recurring schedule, you can reliably read Secure Boot-related registry values that indicate: 

  • Whether the Windows UEFI CA 2023 certificate exists 
  • Whether the system is capable of using it 
  • Whether the device is actively booting with the 2023-signed boot manager 
  • Whether the update has started, is in progress, or has completed 

Once collected, this data can be stored as hardware inventory in a custom WMI class. Then, you can collect this data using SCCM hardware inventory. This allows you to see the data within Resource Explorer and create dashboards from the results. 

Turning raw data into actionable insight 

Collecting Secure Boot data is only half the battle. The real value comes from reporting. 

This is where Recast steps in to reduce friction. 

Recast has included three reports that surface the results collected by the Secure Boot 2023 PowerShell script. These reports are designed to answer the questions administrators actually ask, such as: 

  • Which devices are already compliant with Secure Boot 2023? 
  • Which systems are capable but not yet updated? 
  • Which devices may require firmware attention or manual remediation? 

Instead of building SQL queries from scratch, administrators can immediately visualize the Secure Boot posture of their environment using familiar SCCM reporting. 

From a practical standpoint, this saves time and reduces risk. You can identify gaps early, prioritize remediation, and avoid discovering problems only after a certificate expiration or failed update. 

The bigger picture 

Secure Boot 2023 is not just another checkbox in a compliance report. It is foundational to Windows platform trust. Inventorying these registry keys gives you: 

  • Security assurance – Confidence that systems can validate future boot updates 
  • Operational readiness – Early detection of devices that may break later 
  • Change management clarity – Proof of progress during phased rollouts 
  • Executive visibility – Clear reporting on a risk that lives below the OS 

SCCM remains one of the most powerful tools for this kind of enterprise-scale visibility. By pairing it with a focused PowerShell inventory script and reporting, you can move Secure Boot 2023 from an abstract security concern to a measurable, manageable state. 

If you are already running SCCM, there is no reason to wait. Inventory first, report second, and remediate with confidence. 

Step-by-step: Deploy the PowerShell inventory script via SCCM 

Start by downloading the zip file, which includes everything you need. I created a Word document with step-by-step instructions used in all of my POC examples. For example, you will see that the screenshot examples are from my Browser Extension Inventory POC. If you are a Right Click Tools Insights customer, you can ask your Recast Customer Support rep for this document. The high-level steps are: 

  • Review the documentation and script. 
  • Import the MOF into client settings. 
  • Create the package and program. 
  • Deploy the script on a recurring schedule. 
  • Upload the RDLs to your Reporting Point. 
  • Change the data source for the reports. 

Need help with those last two steps? See my other blog: How to Set Up an RDL for ConfigMgr 

Further reading 

If you want to go deeper on related ConfigMgr inventory and reporting topics, these Recast resources are a good next step: 

Feedback 

We would love to hear your feedback on this script and these dashboards. Do you love them? Should we create others? If so, what else should we build? Post your feedback to our Ideas Portal or catch me in just about any of the ConfigMgr/Intune forums, social platforms, or email. 

Share