Intune · PowerShell · Secure Boot · Remediations · Windows Security

Updating Secure Boot certificates with Intune

Stage the Secure Boot 2023 certificate update, follow the reboot-dependent result, and check the error paths before assigning these scripts widely.

Drafted
Published
Updated
Reading time
4 min
Author
Roberto Gramellini

Source: Intune Secure Boot Certificate Update · revision 58a70964

  • Intune
  • PowerShell
  • Secure Boot
  • Remediations
  • Windows Security
A Secure Boot shield sits above a gated certificate update with separate stage and verify steps.

Updating Secure Boot certificates with Intune

An Intune remediation reports success, and the registry value is correct. Has the Secure Boot certificate update finished? Not necessarily. The detection/remediation pair in Intune-SecureBoot-CertUpdate stages the Microsoft 2023 certificate rollout on eligible devices through AvailableUpdates. Reboot and status monitoring still have to happen.

Keep detection separate from remediation

Detection checks Secure Boot state, manufacturer, model support, BIOS requirements, certificate presence and the current update value. Compliant means no action is needed; non-compliant asks Intune to run remediation. The remediation repeats the safety checks before changing anything. That repetition is worth keeping.

Here is the explicit target and the already-staged check:

$RegistryPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot'
$RegistryName = 'AvailableUpdates'
$DesiredValue = 0x5944

if ($currentValue -eq $DesiredValue) {
    Write-Output 'Update already staged; a reboot may still be pending.'
    exit 0
}

Set-ItemProperty -Path $RegistryPath -Name $RegistryName -Type DWord -Value $DesiredValue -Force -Force
$verifyValue = Get-ItemPropertyValue -Path $RegistryPath -Name $RegistryName

After a new write, the script reads the value back. However, exit code zero can also mean the value was already pending, or the update was in progress or complete. It does not establish that firmware processing has finished. The certificate transition still needs a reboot. Follow UEFICA2023Status and UEFICA2023Error rather than stopping at the successful script result.

Scope to supported hardware

The Dell and Lenovo model allowlists and BIOS checks are there for a reason. Keep that scope during rollout. Extend an allowlist only after checking the hardware and firmware requirements, then start with representative devices. An unsupported model should not receive a generic registry write because it looks nearly the same as a supported one.

Review detection and remediation together. Non-compliance triggers the action; remediation success reports that the request was staged and verified. The reboot-dependent part still has its own outcome. It is easy to lose that distinction when the dashboard is already green.

Review error handling before broad assignment

I would not broadly assign this revision without reviewing its fail-open paths. Detection's outer exception handler returns 0, which Intune reads as compliant. A failed Secure Boot read becomes false and then "no action required." A certificate read failure also becomes false, but that can lead to a remediation request instead. Neither result tells the operator what actually failed.

The Dell path has another case to check: if it cannot parse the BIOS version, it continues. It blocks only when a parsed version is below the minimum. For an action involving firmware, an unknown version is not enough evidence to proceed. Review and test that behaviour deliberately.

Before production use, give detection at least three distinguishable outcomes: compliant, remediation required, and detection error. Keep the error visible in device reporting. Unknown hardware or BIOS state should skip remediation, not quietly pass as healthy or carry on with the write.

Rollout and monitoring checklist

  • Confirm Secure Boot is enabled and validate the device model and BIOS family.
  • Test detection exit-code behavior for both normal results and failed WMI/UEFI reads.
  • Make unknown BIOS or certificate state a deliberate, observable outcome.
  • Start with a small device assignment and confirm the remediation stages the expected value.
  • Schedule the required reboot through the organization's normal change process.
  • Monitor UEFICA2023Status and UEFICA2023Error after restart.
  • Expand assignment only after detection, remediation, reboot, and post-update monitoring are verified.

The overall staging pattern is useful. The handling of unknown and error states still needs hardening before this becomes a broad production baseline. A green result should not mean "we did not manage to check"; that interpretation is better left to committee minutes.