Microsoft’s sample PowerShell inventory script for Secure Boot is a compact, practical starting point for IT teams that must assess firmware readiness ahead of the platform-wide Secure Boot certificate rotation and associated mitigation work. The script is intentionally procedural—capturing hostname and collection time, reading Secure Boot state and servicing registry keys, pulling device attributes from the SecureBoot registry area, parsing System event log entries (notably Event IDs 1801 and 1808), and querying basic WMI/CIM facts such as OS version and baseboard details. It’s useful for building a firmware-aware inventory that maps OEM/model/firmware to the Secure Boot servicing state before any updates are triggered.
Background / Overview
Secure Boot depends on a small set of firmware trust anchors: the Platform Key (PK), Key Exchange Key (KEK), the Allowed Signature Database (DB), and the Revoked Signature Database (DBX). Microsoft’s published guidance and supporting tooling are part of a coordinated operational effort to rotate the old 2011 Microsoft trust anchors to new 2023 certificates and to deliver mitigations (for example, BlackLotus-related protections) in a carefully ordered manner. If devices still rely exclusively on the 2011 certificates when those certificates begin to expire, updateability of pre‑boot components will be impaired, creating measurable security and operational risk. Microsoft’s OS‑side flow uses a scheduled servicing task that examines a per‑machine bitmask (the registry value
AvailableUpdates) and executes a sequence of updates. For IT‑managed rollouts, that bitmask is typically set to
0x5944 to request the complete set of operations: add the 2023 CA entries, update KEK, and replace the boot manager with one signed by the Windows UEFI CA 2023. The OS flow is order‑sensitive—each step is designed to succeed before the next runs to avoid leaving systems in a state that cannot accept future updates.
What the script collects (at a glance)
The sample collects a concise, operationally useful set of attributes that map directly to rollout readiness and post‑deployment telemetry:
- HostName and CollectionTime (basic provenance).
- Secure Boot state (Confirm‑SecureBootUEFI or registry fallback).
- Servicing registry values: AvailableUpdates, HighConfidenceOptOut, UEFICA2023Status, UEFICA2023Error, and UEFICA2023Capable.
- DeviceAttributes in firmware registry: OEM manufacturer, model/family, firmware version, firmware date, OS architecture, and the CanAttemptUpdateAfter FILETIME.
- System Event Log summary focused on TPM‑WMI IDs (notably Event IDs 1801 and 1808) and parsed fields such as BucketId and BucketConfidenceLevel.
- WMI/CIM facts: OS version, last boot time, baseboard manufacturer and product.
Each of these items is chosen to answer a concrete operational question: is Secure Boot enabled, can firmware accept OS‑initiated updates, has the device already been processed by Microsoft’s servicing task, and does the device’s firmware/boot configuration make it high or low risk for an automated update?
Section-by-section analysis of the script
1) Host and timestamp
The script begins defensively: it attempts to resolve the hostname and time and falls back to benign values on error. This improves data hygiene for later aggregation and troubleshooting. Simple but important: always include provenance metadata in inventory outputs.
2) Secure Boot status (Confirm‑SecureBootUEFI + registry fallback)
The script primarily uses the PowerShell cmdlet
Confirm‑SecureBootUEFI to return a Boolean indicating whether Secure Boot is enabled. This cmdlet can return platform‑not‑supported on legacy BIOS machines and may require appropriate privileges when run under constrained contexts. The script falls back to reading the registry key UEFISecureBootEnabled under HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\State if the cmdlet fails. That fallback is sensible because not every environment exposes the cmdlet or runs a version of PowerShell with required privileges. However, the cmdlet and some registry reads can require elevated privileges and will fail silently unless errors are handled carefully.
3) Servicing registry keys (AvailableUpdates, UEFICA2023Status/UEFICA2023Error, HighConfidenceOptOut)
- AvailableUpdates (REG_DWORD) is the operational trigger for the OS servicing task. Setting it to 0x5944 requests the full deployment on that device. Microsoft documents this value as the “high confidence” flag sequence for IT‑managed rollouts. The sample script reads this key and, when present, emits a hex display of the value for easier correlation with Microsoft’s rollout documentation.
- UEFICA2023Status (string) and UEFICA2023Error (DWORD) are per‑device progress and error instrumentation. Microsoft updates UEFICA2023Status from NotStarted → InProgress → Updated as the servicing task runs; non‑zero UEFICA2023Error values should be triaged with event log data and vendor firmware guidance. The script captures both and prints them for immediate triage.
- HighConfidenceOptOut and MicrosoftUpdateManagedOptIn control whether Microsoft’s managed rollout will automatically attempt updates on devices categorized as “high confidence” (devices Microsoft’s telemetry deems safe to update automatically). The script’s attempt to read these values helps teams understand whether a device is opted in or out of the Microsoft‑managed assistance path.
4) DeviceAttributes (firmware metadata)
The script reads OEMManufacturerName, OEMModelSystemFamily, OEMModelNumber, FirmwareVersion, FirmwareReleaseDate, OSArchitecture, and CanAttemptUpdateAfter (a FILETIME) from HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\DeviceAttributes. These fields are critical for triaging devices that log 1801 errors or report UEFICA2023Error values—OEM/model/firmware date are the first things OEM support will ask for. The script attempts string validation and FILETIME→DateTime conversion for CanAttemptUpdateAfter, which indicates when the servicing logic should next attempt a write.
5) Event log parsing: focus on Event IDs 1801 and 1808
The script pulls up to the latest 20 TPM‑WMI events filtered to Event IDs 1801 and 1808 and computes:
- LatestEventId,
- BucketId and BucketConfidenceLevel (parsed from the event message),
- Count of each event type.
Event ID mapping is important operational telemetry:
- Event ID 1801 is an error indicating the updated certificates have not been applied and includes device attributes and a bucket ID for correlation.
- Event ID 1808 is informational and indicates the device has successfully applied the new Secure Boot certificates.
Capturing the bucket ID and confidence values enables automated grouping for OEM escalation and large‑scale triage pipelines.
6) WMI/CIM queries: OSVersion, LastBootTime, BaseboardManufacturer/Product
These fields are low overhead but high value: OS build level and last boot time help determine whether the system already has required servicing updates installed and whether a recent reboot may have blocked the boot manager switch. Baseboard manufacturer and product fields speed OEM triage and firmware‑specific correlation. The script uses Get‑CimInstance and gracefully handles missing values.
How this script fits into the operational playbook
The sample script is not an action script—it’s an
inventory script. Use it to build the dataset you need before changing any Secure Boot variables. That dataset should feed these operational decisions:
- Group devices by OEM/model/firmware/KEK acceptance behavior for pilot selection.
- Verify BitLocker recovery key escrow and test recovery procedures before any firmware‑affecting action.
- Validate that images and recovery media include the new Windows UEFI CA 2023 boot manager or are otherwise compatible.
- Use the script as an Intune/ConfigMgr/CMDB data‑gathering agent to build a baseline for OEM escalation and rollback planning.
Microsoft’s recommended rollout cadence includes an early representative pilot, OEM firmware coordination, and phased expansion; the script supplies many of the per‑device signals needed to implement that cadence. The OS‑side servicing task runs roughly every 12 hours and processes bits in AvailableUpdates in sequence; plan at least 48 hours for a device to progress through the sequence and reboot windows.
Practical modifications and hardening suggestions
The sample script is intentionally readable and defensive; however, real‑world deployments benefit from a few pragmatic improvements:
- Output to structured files (CSV/JSON) instead of or in addition to console output so results can be ingested into a SIEM or CMDB.
- Add a consistent machine identifier (GUID) and include UTC timestamps for collection time to simplify multi‑region correlation.
- Add Get‑TPM and a check for TPM version to the default collection set—TPM presence and state are often required for triage.
- Expand event log capture to include related TPM‑WMI event IDs (1795–1799) and persist raw event messages for later forensic review.
- Where available, include a Get‑SecureBootUEFI db inspection (extract ASCII from the db bytes and search for strings like "Windows UEFI CA 2023") to confirm certificate presence in the DB without requiring firmware tooling.
- Add clear, audited error codes and a non‑privileged mode so helpdesk or remote agents can gather partial data without escalation.
A minimal example of the kind of structural change to add would be: serialize the collected fields into a JSON object, sign/validate the file at rest, and transmit results over an authenticated channel (endpoint management or secure API) to a central aggregator.
Permissions, environment constraints, and common failure modes
- Many of the script’s registry reads and Get‑WinEvent queries may require administrative privileges. Running the script as a non‑privileged user may produce partial data or false negatives. The script tries to be defensive, but collection pipelines should plan for elevated execution.
- Confirm‑SecureBootUEFI returns a platform‑supported boolean only on UEFI systems; legacy BIOS or VM platforms may be unsupported and will report differently. Recognize the difference between a true disabled Secure Boot state and platform not supported.
- Firmware can block OS‑initiated KEK/DB/DBX writes. Event ID 1795 is commonly logged when firmware refuses a variable write; persistent KEK update failures (AvailableUpdates bit 0x0004 not clearing) are often an OEM dependency requiring firmware updates or OEM‑signed KEK objects. The sample script’s collection of OEM/model/firmware date is vital for those escalations.
- BitLocker triggers are the #1 operational failure mode: swapping a boot manager or changing Secure Boot variables can prompt BitLocker recovery if protectors are not suspended. Inventory collection must be paired with a BitLocker recovery plan and tested helpdesk procedures.
Monitoring, verification and triage guidance
- Monitor the System log for TPM‑WMI Event IDs: 1795–1799, with special focus on 1801 (error: updated certificates not applied) and 1808 (info: device updated). Aggregating these events into SIEM dashboards and correlating them with UEFICA2023Status and UEFICA2023Error is the fastest path to identify problematic models and firmware versions.
- Use the registry keys under HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing as your canonical telemetry: AvailableUpdates, UEFICA2023Status, UEFICA2023Error, MicrosoftUpdateManagedOptIn, and HighConfidenceOptOut. They provide an authoritative per‑device lifecycle view that the scheduled task updates as it runs.
- For devices that report UEFICA2023Error or do not clear the KEK update bit, capture the full System event log and the exact firmware version string—these are the most commonly required artifacts when contacting OEM firmware support.
Strengths of the sample script and Microsoft’s approach
- The script is concise and maps directly to the keys and events Microsoft documents for the certificate rollout, making it straightforward to integrate into existing management tooling. It intentionally balances low privilege collection (where possible) with admin‑level checks when available.
- Microsoft’s staged, order‑sensitive model (DB addition → KEK update → boot manager swap → optional DBX revocation) reduces the chance of leaving devices in an unrecoverable state when firmware behaves correctly. The script’s event and registry collection feed that staged model with actionable signals.
- The data captured by the script is precisely the set OEMs and Microsoft will ask for when triaging device‑specific failures—OEM/model, firmwares strings, event bucket IDs, and the UEFICA2023Error codes accelerate vendor support.
Residual risks and limitations
- OEM firmware variability remains the gating risk. Some vendors will not release firmware updates for older models, and some firmware has quirks that block OS‑initiated enrollment or misreport DB/DBX state. These outcomes cannot be fixed from the OS side alone and require OEM coordination or device replacement. Treat vendor claims about model support as unverifiable until confirmed with the manufacturer per model.
- DBX/Revocation decisions can be effectively permanent on many devices. Avoid applying DBX revocations at scale until you have broad confidence across all device families that they accept the 2023 certs and that all third‑party bootables or recovery media are re‑signed and tested.
- BitLocker recovery and helpdesk capacity are big operational hazards. Without well‑practiced recovery workflows and reliable recovery key escrow, even a small pilot can generate significant support load. Plan the human processes as carefully as the technical sequence.
- Virtual and non‑UEFI environments will not behave the same way; inventory scripts should explicitly mark these devices so you don’t attempt firmware‑oriented actions on incompatible hosts.
Recommended rollout checklist (practical, prioritized)
- Inventory: run the sample script across a representative pilot and ingest results into your CMDB; prioritize high‑value and older models.
- Escrow BitLocker keys and test recovery procedures for pilot devices—suspend BitLocker in pilots where feasible.
- Build a pilot group of 5–10 representative devices per OEM/model family; do full end‑to‑end tests including recovery media boots and imaging.
- Trigger the OS servicing flow in pilot devices by setting AvailableUpdates = 0x5944 and monitor UEFICA2023Status, UEFICA2023Error, and Event IDs 1801/1808 for 48+ hours.
- Escalate KEK/DB failures (bit 0x0004 not clearing or UEFICA2023Error non‑zero) to OEMs with the collected event logs and firmware strings.
- Expand in staged waves (10% → 50% → full), allowing 48 hours between waves and maintaining rollback and recovery readiness.
Closing assessment
The Sample Secure Boot Inventory Data Collection script is an effective, low‑friction building block for any Secure Boot certificate rotation program. It collects the right telemetry to make informed decisions, to escalate problems to OEMs, and to automate triage across large fleets. However, the script is only one piece of a broader operational puzzle: inventory accuracy, BitLocker recovery hygiene, OEM firmware coordination, and conservative DBX/revocation planning are the elements that determine whether a rollout will be smooth or painful.
Administrators should treat the script as inventory instrumentation rather than a remediation tool. Pair it with central aggregation, conservative pilot discipline, and documented recovery procedures. Confirm the script’s collection behavior in your environment (non‑privileged vs elevated runs, virtualized hosts, and regional OEM support variability) and iterate: add structured output, TPM checks, extended event captures, and automated reporting to make the dataset production‑grade.
For the critical numbers and behavior that govern rollout—AvailableUpdates = 0x5944, UEFICA2023Status transitions, Event IDs 1801/1808 mapping, and the June–October 2026 certificate expiry windows—validate your local plans against Microsoft’s published guidance and your OEM’s per‑model firmware advisories before mass action. Microsoft’s documentation and OEM advisories remain the canonical references for timing and per‑model readiness; use the script to gather the data you need to query those references effectively.
Source: Microsoft Support
Sample Secure Boot Inventory Data Collection script - Microsoft Support