Symptoms

• Device prompts for Bitlocker recovery key at every restart

• If the device is a HP Elitebook 840 G9 (my example – but from what im seeing, this is affect other models as well) – and running BIOS version 1.18

• The event log “Applications and services -> Microsoft -> Windows -> Bitlocker API -> Management” shows repeated events along the lines of

  • BitLocker successfully sealed a key to the TPM.
    PCRs measured include [7,11].
    The source for these PCRs was: Secure Boot.

Cause

• If the device has not updated its secure boot certificates and moves to BIOS version 1.18 – and then tries to update the Secure Boot certiticates – this issue will occur.

• If the device has already updated Secure Boot certificates and then updates its BIOS to 1.18 – the issue does not occur

Workaround

• It is expected at some point that HP will fix the 1.18 BIOS release – so this workaround should be considered temporary

• Turn off bitlocker using “manage-bde -off C:” from an elevated cmd prompt

• Play the waiting game (machine is still usable during said waiting game) and check status using “manage-bde -status C:” until percentage encrypted hits 0%

• Download the 1.17 BIOS from https://support.hp.com/sk-en/drivers/hp-elitebook-840-14-inch-g9-notebook-pc/2101000805

• Run the install process – it should specifically list the BIOS as a downgrade. You may also need to enter the BIOS password

• Reboot – considering bitlocker is now disabled – should not prompt for recovery key

• The BIOS screen will promopt the user with a screen similar to this

  • 

    Get the user to enter the code specified to allow the BIOS downgrade to continue

• Once downgraded, check the system event log for event ID 1799, 1801 and 1808…. these are the secure boot update event ID’s. Once we have 1808 – we are all done.

  • After one reboot, you should see an event 1799 or 1801 similar to this

    • Boot Manager signed with Windows UEFI CA 2023 was installed successfully

  • After another reboot, you will see an event ID 1808 with text similar to this

    • This device has updated Secure Boot CA/keys. This device signature information is included here.
      DeviceAttributes: FirmwareManufacturer:HP;FirmwareVersion:U71 Ver. 01.17.00;OEMModelBaseBoard:8ABB;OEMManufacturerName:HP;OSArchitecture:amd64;
      BucketId: 856a1c26ca9b59166ad4ba598387236793398a988321d4a9b6e0964756685b52
      BucketConfidenceLevel: Under Observation – More Data Needed
      UpdateType: Windows UEFI CA 2023 (DB), Option ROM CA 2023 (DB), 3P UEFI CA 2023 (DB), KEK 2023, Boot Manager (2023)

• Once secure boot has updated correctly, we can then re-apply bitlocker – using whichever method you prefer (i use an SCCM task sequence)

I’ve seen a few guides around the about this – but they seem to mainly focused on using Intune – which has the significant downside of not being able to handle systems which aren’t supported by Intune, such as servers and air-gapped systems.

Now – this is just the way ive been doing it – and its not perfect – but its significantly better than nothing…

I’m going to do something different this article and start with the…

References

Secure Boot Certificate updates: Guidance for IT professionals and organizations – Microsoft Support

Act now: Secure Boot certificates expire in June 2026 – Windows IT Pro Blog

Secure Boot Certificate Changes in 2026: Guidance for RHEL

Secure Boot playbook for certificates expiring in 2026

https://support.hp.com/us-en/document/ish_13070353-13070429-16

https://knowledge.broadcom.com/external/article/423893

What is Secure Boot?

• Secure Boot is a UEFI firmware security feature designed to ensure that only trusted, digitally signed boot components are allowed to run during system startup.

• When Secure Boot is enabled:

  • The system firmware verifies the signature of the bootloader

  • The bootloader verifies the next stage (e.g. OS loader / kernel)

  • Anything that is unsigned or signed with an untrusted certificate is blocked

This helps protect against boot-level malware (e.g. rootkits), but it also means systems are dependent on valid signing certificates stored in firmware

Secure Boot certificate expiration

The configuration of certificate authorities (CAs), also referred to as certificates, provided by Microsoft as part of the Secure Boot infrastructure, has remained the same since Windows 8 and Windows Server 2012. These certificates are stored in the Signature Database (DB) and Key Exchange Key (KEK) variables in the firmware. Microsoft has provided the same three certificates across the original equipment manufacturer (OEM) ecosystem to include in the device’s firmware. These certificates support Secure Boot in Windows and are also used by third-party operating systems (OS). The following certificates are provided by Microsoft:

• Microsoft Corporation KEK CA 2011

• Microsoft Windows Production PCA 2011

• Microsoft Corporation UEFI CA 2011

What’s changing?

Current Microsoft Secure Boot certificates (Microsoft Corporation KEK CA 2011, Microsoft Windows Production PCA 2011, Microsoft Corporation UEFI CA 2011) will begin expiring starting in June 2026 and would expire by October 2026.

New 2023 certificates are being rolled out to maintain Secure Boot security and continuity. Devices must update to the 2023 certificates before the 2011 certificates expire or they will be out of security compliance and at risk.

Windows devices manufactured since 2012 may have expiring versions of certificates, which must be updated.

Using SCCM to detect and remediate

• Preparing
  • There is no need to run this against systems which are using “Legacy” BIOS mode and not UEFI (Microsoft has unfortunately destroyed the word “legacy” by using it inaccurately for sales purposes – but its is the correct term here)
  • Create a new collection folder called something along the lines of “SecureBoot2026”
  • Create 2x collections
  • Secure.Boot.UEFI.Detected
    • select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_FIRMWARE on SMS_G_System_FIRMWARE.ResourceID = SMS_R_System.ResourceId where SMS_G_System_FIRMWARE.UEFI = “1”
  • Secure.Boot.BIOS.Detected
    • select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_FIRMWARE on SMS_G_System_FIRMWARE.ResourceId = SMS_R_System.ResourceId where SMS_G_System_FIRMWARE.UEFI = “0”
• Configuration baseline 1 – Detect secure boot
  • Create a new configuration item
  • Name : Secure Boot – Check Enabled
  • Target OS : All
  • New setting
    • Name : Secure Boot – Check Enabled Script
    • Setting type : Script
    • Data type : String
    • Discovery script : Please see https://github.com/hayesjupe/SecureBootUpdate2026 – script SecureBootEnabledCheck.ps1

• • Remediation script : None
  • Compliance rule :
    • Name : Secure Boot – Check Enabled Result
    • The value returned by the specified script = True
  • Create a baseline
    • Name : Secure Boot Enabled Baseline
    • Add the configuration item we just created
    • Tick “Always apply this baseline even for co-managed clients”
  • Deploy the baseline to the “Secure.Boot.UEFI.Detected” collection

This will run against devices that we know are running in UEFI mode and detect if they have secure boot enabled. (Note that the “Confirm-SecureBootUEFI” powershell command only exists if a machine has a recent CU level…..  patching machines is a large rabbit hole to go down – but… if you havent patched your machines in the last 3 months – you have larger issues than Secure Boot – address that first)

• From the deployment of the “Secure Boot Enabled Baseline”
  • right click and go to “create new collection”
  • Create one for “Compliant” called “CB-SecureBootEnabled”
  • Create another for “Non-compliant” called “CB-SecureBootNotDetected”
    • Note : i go with “NotDetected” because there may be a patching issue on some machines – you can check this very easily by adding and looking at the OS build version column in SCCM
  • Move these collections from the root (where SCCM puts them) into your “SecureBoot” folder

• Configuration baseline 2 – Detect if the update process has completed
  • Create a new configuration item
  • Name : Secure Boot Update Completed
  • Target OS : All
  • New setting
    • Name : Secure Boot Update Completed Script
    • Setting type : Script
    • Data type : String
    • Discovery script : Please see https://github.com/hayesjupe/SecureBootUpdate2026 – script SecureBootUpdateComplete.ps1

• • Remediation script : None
  • Compliance rule :
    • Name : Secure Boot Update Completed Result
    • The value returned by the specified script = Updated
  • Create a baseline
    • Name : Secure Boot Update Completed Baseline
    • Add the configuration item we just created
    • Tick “Always apply this baseline even for co-managed clients”
  • Deploy the baseline to the “CB-SecureBootEnabled” collection

This will run against devices that we know have secure boot enabled.

• From the deployment of the “Secure Boot Completed Baseline”
  • right click and go to “create new collection”
  • Create one for “Compliant” called “CB-SecureBootUpdateComplete”
  • Create another for “Non-compliant” called “CB-SecureBootUpdateIncomplete”
  • Move these collections from the root (where SCCM puts them) into your “SecureBoot” folder

You now have the structure that will provide you up-to-date information on where you are at.

Deployment of the secure boot update

• There are a number of methods you can use here – i prefer an SCCM task sequence – as it allows me to perform other steps, which i will explain below
• Create a new blank task sequence with a name such as “SecureBootUpdate2026”
  • First task – Disable bitlocker for x reboots
    • When first deploying this for our EUC devices, there was an approx 5% hit rate of devices that prompted for a bitlocker recovery key. Disabling bitlocker first will address that. I went for 4 reboots – but do whats best for you and your enviornment.
  • Second task – set the secure boot regkey
    •  Command line : reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
  • Third task – force the secure boot scheduled task to run
    • Powershell : Start-ScheduledTask -TaskName “\Microsoft\Windows\PI\Secure-Boot-Update”

Now – if, for whatever reason, you have not started this process at all yet (yikes!) – create a new collection and place a small number of machines in there first in order to test this process…. do not immedaitely deploy it to everything that is secure boot enabled. Once you become more confident with the process, place more machines into that collection.

You could also choose to do your firmware updates as part of this task sequence… but i already have a process in place for this – and to me, it makes sense to keep them seperate…. as i want to continue to do firmware updates… but the secure boot update wont be required again in my working lifetime.

Event ID’s you will become familiar with

These are all in the system event log

• Event ID 1801 – you will see this event every time the secure boot update scheduled task runs – giving you a status. Some of the status’s you may see will be (they will be different based on the OS and hardware)

  • ✅ 0x5944 → 0x5904 – Windows UEFI CA 2023 applied

  • ⏳ 0x5904 → 0x5104 – Microsoft Option ROM UEFI CA 2023 (if needed)

  • ⏳ 0x5104 → 0x4104 – Microsoft UEFI CA 2023 (if needed)

  • ⏳ 0x4104 → 0x4100 – KEK applied

  • ⏳ 0x4100 → 0x4000 – Boot manager updated

• Event ID 1799 – you will often see this on VM’s where the process has all-but completed. Windows has updated, but it cannot update the hyper-V or VMWare firmware file.
• Event ID 1808 – All done. This is the one we want to see.

The (many) wrinkles in this process

To say that this has been poorly managed by MS is an understatement.

Wrinkle 1 – Windows updates

In order to update, the device must be running a supported OS version and have Windows updates from a relatviely recent timeframe. Its different for each OS – because the process is not complex enough already i assume. In order to make life easy, i just say “March 2026 CU”. If the “Confirm-SecureBootUEFI” commandlet is not present, then you need to update.

Wrinkle 2 – UEFI updates (which most of us still call BIOS updates)

The UEFI firmware on the device must support this process. The org im with now is all HP – so i used
https://support.hp.com/us-en/document/ish_13070353-13070429-16 to determine which models could not be updated – and which ones could (and what version was needed)

Now – for reasons i dont know, it looks like that page has gone offline – not sure if its temporary or what… but the short answer is that your UEFI version must support this process. I used HPIA to update the versions fleet wide – which seemed to work well.

Wrinkle 3 – Hyper-V

Hyper-V will commonly get to eventID 1799 but not 1808 because it cannot update the firmware file. A helpful commenter in the secure boot playbook (referenced at the start of this post) found that if you toggle the firmware setting – it then updates. Script to do this en-masse at the end

Wrinkle 4 – VMWare

Similar to hyper-V, the nvram file cannot be updated. Once the status gets to “Microsoft UEFI CA 2023”, you can rename the NVRam file (allowing a new one to be created), boot and then reboot again, and you will get 1808.

Update 01/05/2026 – VMWare have made large updates to their guidance, and it looks like things will be improved in coming patches – https://knowledge.broadcom.com/external/article/423893

Wrinkle 5 – Inconsistency

Even if you have your Windows updates and UEFI firmware up to date and sorted – the process doesnt seem to be completely consistent.

Set the reg key, run the scheduled task, notice that the machine is in the state “KEK applied”, reboot, run the scheduled task again, get to 1808 – completed

Move onto the next machine and it will require an extra reboot for some reason.

The next machine will get stuck on “KEK applied” for 2-3 reboots for some reason

A small % of our Hyper-V servers seemed to move to 1808 without the need to toggle the boot file – even though they appear to be identical to all the other Hyper-V servers.

Its just… inconsistent…. its gets there – and im sure there are reasons for it… but when your trying to get this deployed to thousands of machines – it creates stress….. and the fact that there’s no reporting / management tool from MS for this process is just exceedingly shit (in line with the “fuck you – what are you going to do about it?” approach they appear to be taking with customers at the moment)

Some scripts to help – see https://github.com/hayesjupe/SecureBootUpdate2026

ToggleVMFirmwareHyperV.ps1 – toggles the hyper-V boot file to allow the completion event 1808 to show up

SecureBootCheck.ps1 – allows you to check and optionally run the scheduled task against a list of computers

Get-SecureBootAudit-SCCM.ps1 – runs against SCCM collections to produce a report of machines current status – can be run against different collections (i i use to get a EUC, Server and Operations status – as these devices are managed by different groups)

Note : the two bottom scripts will sometimes report a “custom state”…. this generally means the UEFI firmware requires an update before the device an write to the firmware.

A while back, one of the main vendors for the organisation im now working for had a bit of an indignant chuckle when i asked for their supposed enterprise-grade software to have a silent install…. “Just use the click-once version – its fine for everyone else”

Well – needless to say, i saw red, what an incredibly fucking stupid thing to say… and im finally getting around to writing blog article as to why thats the case.

So, with that said – lets have a look at a few of the challenges, and positives, of user-based installs – be it click-once or other.

Administrator rights

Any per-user install can generally be installed without requiring administrator rights or elevation.

Now, in some instances, this can be a good thing…. think about at the start of Covid when many people moved to working form home – and some (not all) IT departments did not have the capbility of deploying software to remote machines. The ability to get users to download and install teams (for example) would have reduced the load of those IT departments at the time.

The other side of this is, it also creates an opportunity for users to install software which is not on the companies approved list. Which creates potential for support hassle, security vulnerabilities and inconsistent business processes. Application whitelisting controls will address this – but again, not all enterprise IT departments are at that maturity level (and yes, i agree, they should be – but thats just not the reality sometimes)

Click Once installation performance and size

Click once has various optimisations to decrease the initial install time…. but the reality is, if an application is 600MB, its not going to perform well over a slow network connection…. and even with a LAN connection, it lacks the options you get when deploying an application with something designed for mass-deployment, including slow network links, like SCCM (.e.g peer caching, pre-staging etc)

For organisations that have a large number of users cycling through a group of machines (im thinking healthcare – but you may have your own example) – 100 people all installing a 600MB application into their user profile starts to become an issue.

Management

Enterprise management and deployment apps (im thinking SCCM and group policy, but insert your fave here) have plenty of built-in capabilities to install, inventory and report on applications. Want to find all the versions of Acrobat Reader that aren’t the current version? – sure, give me a few minutes – and then a couple more to get them all updated to the current version.

Per-user installs break this management model by storing the program files in the user profile… now obviously we can start inventoring those paths as well…. but we have gone from looking at WMI, C:\Program files and Program files (x86), to now looking at all the user profiles on a machine…. and as anyone will tell you that does that stuff for a living, per-user installs seem to have a fanatical hatred of using a standard directory structure and prefer putting in random GUID’s here and there along the way – making it more difficult (but generally not impossible) to optimise that process.

In addition, when click-once does break (and it does) – you are dealing with a different type of support – and potentially much more of it (due to the multiple installs per machine).

We now are potentially managing multiple copies per machine, in locations that generally dont match a pattern, rather than 1 per-machine in a standard location. This then has flow on effects for application whitelisting, support – and the big one, security.

Security

For the purposes of this section, we are going to assume that application whitelisting is in place and that the application in question is a part of your companies approved software list – as it becomes more of a process and governance dicussion if this isnt the case. (which iun turn becomes a security issue if these aren’t in place)

Lets say you have an application called “LostSouls” (named after the band i cannot stop listening to at the moment).

LostSouls deploys via ClickOnce….. and 1800 people have installed it across the org.

LostSouls v1.1 turns out to have a major security vulnerability in one of its supporting dll’s…. fair enough, that happens… and LostSouls v1.2 comes out, which addresses that vulnerability….

“Dont worry – we have fixed it” the vendor says… “it will update the next time they open the app” the vendor (correctly) says…. the technically clueless management and project manager nod in agreement – because… why should they care about reality now? Ignorance is bliss after all.

So out of those 1800 installs of 1.1…. for various reasons (staff leaving, people using different machines etc), only 1200 people start it up again on the same machine – so those 1200 installs get updated… but we now have 600 installs sitting in user profiles that are vulnerable. 600 installs that i (as a deployment admin) need to find and address – which is achievable – but ofcourse uses time and effort that would better be spent elsewhere… and more to the point, just making life much harder than it needs to be.

To sum up

There is nothing wrong with applications that present the option to be installed as a per-machine or a per-user install…. and while i might not be a fan of per-user installs – there clearly are specific use cases where that model fits.

User-based installs become an issue where:

• User-based install is the only option
• The install size is large (lets say anything over 500MB) and
  • Is intended to be used across all sites – even those with slow network links – this can lead to significant delays before the user can use the app after an update
  • You have user-base that roams between machines commonly – and the mutliple installs across multiple machines ends up using significant disk space
• Support. There’s no nice way of putting it – its a extremely poor deployment model which is far more difficult to manage when compared to your traditional per-machine install.
• When there is a security issue in a release, where that issue can be exploited simply by the existance of the vulnerable dll (for example – using dll preloading/hijacking) – the difficulty of finding and removing or updating all of these for a per-user application is significant
• Dealing with smug fuckwit salespeople that have absolutely no idea why click once is a bad idea and say idiotic shit like “our other clients use it and dont have a problem”… yes, your other clients with 100 PCs in their entire org across 1 site who have no dedicated IT function and dont know any better.

In short, if you turn up to any reasonable size client and say “we deploy our 700Mb memory leak simulator (yes, im thinking of partrcular piece of software here) via click once:” – any comptent IT people should laugh you out the door.

While i realise there is zero chance of salespeople caring about their product’s actual capabilities and likewise, zero chance of managers starting to care about buying products that are complete fucking shit and expecting internal techs to somehow make them work – i was disappointed when i couldn’t find any existing articles on the shittiness of per-user applications…. so… now there is one.

Other articles that touch on the issues of ClickOnce

https://www.stevestreeting.com/2013/05/12/friends-dont-let-friends-use-clickonce/#:~:text=ClickOnce%20forces%20you%20to%20put,your%20customer’s%20time%20on.

https://www.codemag.com/article/0902031/Eight-Evil-Things-Microsoft-Never-Showed-You-in-the-ClickOnce-Demos-and-What-You-Can-Do-About-Some-of-Them

All You Need Is One – A ClickOnce Love Story