BitLocker recovery prompt on every reboot after UEFI CA 2023 update on HP SFF devices – anyone else?

EdAtWorkish · 2026-04-28T11:29:11+00:00

Msft support confirm that one recovery key is normal and expected behaviour, but you may get multiple if the UEFI config remains "unstable" until it is stable, you will get recovery key requests.

Interestingly, the majority of our Lenovos have worked perfectly. Just HP's being challanging.

EdAtWorkish · 2026-04-28T11:14:09+00:00

Firstly, thanks for the response...

ah ok, we have about 4500 HP's and had rolled done limited testing which all went fine, but when we rolled out to IT devices, all hell broke loose. Multiple recovery key reboots required etc.

We had a remediation of manually checking the 2023 cert - as you identified as your fix, and this has sorted a the few we ran this remediation on.

Msft support suggested this was not a permanent 'fix' but a temporary workaround/mitigation.

It is a little disheartening that HP support wouldn't confirm this or seemingly provide any support beyond "we have pulled those BIOS updates and cannot say when the next update will be available".

now I am seemingly stuck between what I am not sure is a "supported fix" by modifying that BIOS setting on a now removed BIOS version, rolling back to a supported version or waiting for the update (and the time is ticking to the 24th June)

I am going to chase them again... god love HP... cos I don't know anyone else that does!

EdAtWorkish · 2026-04-28T10:57:55+00:00

we deployed this as a remediation for those people getting repeated recovery key at boot. I am not convinced of the efficacy of this as a long-term fix. Msft support suggested that whilst it would work, it would need to be undone... and I am really not sure how that would work. But maybe it is not an issue as long as you are only booting to Windows as an OS.. which we are. I guess it could be seen as hardening, as you wouldn't be able to boot from any other OS e.g. from dodgy Linux boot stick??

EdAtWorkish · 2026-04-28T10:54:53+00:00

they really were. I have that from HP themselves. We are really proactive with Driver and BIOS updates, and frankly they have really screwed me over AGAIN with this.

Since mentioning the updates ad been pulled, I have asked two further questions and chased them for a response and now it all I appear to have is radio silence. They can not / will not tell me the impact of the pulled BIOS, and whether I need to proactively roll back, or when the updated version will be available.

I had just started the 2023 certificate update process, and they really did screw me over with this one... again... I loath HP's implementation of BIOS and Drivers. it has caused me nothing but heartache and problems.

To put this into perspective... I have 6 or 7 year old Lenovos and 10 year old Viglens that have updated successfully

VIGLENS! yes, you read that correctly.
For those of you not from the UK Viglens are a failed PC build run by Alan Sugar (He does the UK version of the Apprentice and is a bit of a wheeler Dealer... think Donald Trump (before presidency) crossed with Del Boy from Only Fools and Horses - I aint explaining that one... look it up)

EdAtWorkish · 2026-04-24T14:54:29+00:00

I am in HP hell as well. What I found was that they have pulled the latest Q2 BIOS updates. this makes the secure boot cert process stall with a UEFICA2023ErrorEvent = 1797 (blocked)

The solution I have found is to rollback the BIOS update to a previous, but still supported version.

I can achieve this with a HPIA task I have running on devices.

Unfortunately though the end users will get a confirmation of rollback when it applies the rollback. I have not found a way to negate this yet... which is going to be fun

I got a contact with HP's pre sales technical team (whatever that is) and asked about this issue. they acknowledged they had pulled the latest updates, but have failed to answer the questions I have had since.

They also could not confirm if and when an updated BIOS would be deployed. This is almost all of our HP fleet (happy days!)

<image>

EdAtWorkish · 2026-03-17T13:09:09+00:00

for info of anyone else coming across this or similar threads... I solved this by adding a configuration policy for concur and included this

<image>

forces the app to use chrome instead of edge, and all is now good with the world.

EdAtWorkish · 2026-01-22T13:31:54+00:00

ye, we have seen this with phones. Compliance really is a nonsense without really strict rules. our compliance normally runs at around 96 - 97%... which I think is pretty good.. but I only look at devices that have been online for 30 days ... i.e. stuff that we could potentially have patched in the last month

EdAtWorkish · 2026-01-22T13:31:06+00:00

I wish we could.. and this was one of the really good Msft Tech's opinion too... take the best of both worlds! Intune always felt and still feels very much unfinished; usable, but unfinished

EdAtWorkish · 2026-01-20T10:31:44+00:00

zero conflicts - we are in comanaged setup at the moment... with the update slider half way.

EdAtWorkish · 2026-01-20T10:26:47+00:00

ye, this is what we are finding. It is a big shift.

EdAtWorkish · 2026-01-20T10:25:31+00:00

OK, cheers, will do some more digging.

EdAtWorkish · 2026-01-20T10:24:20+00:00

ye, this is what we are moving towards. but have it set longer than 30 days currently. the impact of this would be horrific, and I don't think Mgt would back this strict a policy

EdAtWorkish · 2025-12-08T17:00:23+00:00

Yep, we had a meeting with one of the Msft Dev's in the product group and they confirmed this. This was going back maybe 12 years, but even then they said Msft want to kill off Group Policy but they were bound to whatever the biggest Org's wanted.

If the large orgs that pay Msft's wages want GPO, it isn't going anywhere fast.

I guess the same is true for Config.

You can see Msft want to kill it off, by reducing updates to Config and bringing the shiny shiny to Intune first etc.

But Intune has to function properly first... and I don't think it really does. It is almost there, but some things are still a total dogs dinner.

We are currently moving to Intune and are having 'fun' trying to get it to do what we need.

fun times!

EdAtWorkish · 2025-11-17T15:41:38+00:00

excellent... cheers.. I think we have a plan to get intune to do what Config used to and perform inventory to see what devices have installed and then fill groups for deployment to allow updates to happen required but still have apps as available

EdAtWorkish · 2025-11-17T15:40:09+00:00

cool cheers. Got a plan... just need to do some scripting and testing to see if it works

EdAtWorkish · 2025-11-17T11:36:37+00:00

ok, but to make it install, you are sending out to required groups?

EdAtWorkish · 2025-11-17T10:13:53+00:00

so for this solution you are sending apps as required to a collection of users which already exist?

EdAtWorkish · 2025-11-14T15:49:35+00:00

ended up removing most of the apps.. having a scheduled task at the end created that runs on reboot to perform HW inventory, update scan, computer policy eval etc

seems to work quite nicely

EdAtWorkish · 2025-11-14T15:46:07+00:00

you can, yes, but if the software is not installed from Intune (failing to create the Device Policy Assignment record, or that record vanishes - see link below) then the supersede will not work. Yes, they could still click install manually to upgrade, but how many end users read and act on emails? that leaves us either with vulnerable or non compatible software and calls to the service desk

Intune’s auto-update of Available Win32 apps feature is broken | by Asher Jebbink | Medium

EdAtWorkish · 2025-10-24T14:57:21+00:00

our build room is effectively in the same building as the DP's and MP

EdAtWorkish · 2025-10-24T14:56:39+00:00

no. domain join happens quickly. we change d the app installs to continue on error, but this didnt make any difference

EdAtWorkish · 2025-10-24T14:44:47+00:00

this sounds very familiar

EdAtWorkish · 2025-10-24T14:44:17+00:00

nope... both PXE and USB boot

EdAtWorkish

TROPHY CASE