-
×InformationNeed Windows 11 help?Check documents on compatibility, FAQs, upgrade information and available fixes.
Windows 11 Support Center. -
-
×InformationNeed Windows 11 help?Check documents on compatibility, FAQs, upgrade information and available fixes.
Windows 11 Support Center. -
Create an account on the HP Community to personalize your profile and ask a question
Your account also allows you to connect with HP support faster, access a personal dashboard to manage all of your devices in one place, view warranty information, case status and more.
Check out our WINDOWS 11 Support Center info about: OPTIMIZATION, KNOWN ISSUES, FAQs, VIDEOS AND MORE.
146
9
2
HP Recommended
HP Recommended
Good afternoon again, my friend! And first — LOL!
It sounds like that 18-month-old little guy finally won the battle of wills. At least you got to enjoy a little NFL Network afterward! And I'm glad you caught my mistake, because you are absolutely right.
I went back and looked at your photograph again, and the entry does indeed read:
Legacy Support Disabled, Secure Boot Support Disabled
—not "Secure Boot Support Enabled."
That changes our interpretation considerably, and I owe you a correction.
So, here's where we actually stand:
Your current BIOS configuration is:
Legacy Support: Disabled
Secure Boot Support: Disabled
That means the computer is configured to boot in UEFI mode, but Secure Boot itself is currently turned OFF.
And that completely explains why Windows previously reported:
Confirm-SecureBootUEFI = False
Microsoft's documentation confirms that this command returns $False when the system supports Secure Boot but Secure Boot is disabled.
So there is no contradiction between BIOS and Windows at this moment.
The important discovery is actually something else:
We have already established that the firmware contains:
✅Platform Key (PK)
✅Key Exchange Keys (KEK)
✅Signature Database (db)
✅Forbidden Signature Database (dbx)
✅HP/Microsoft Secure Boot certificates
Microsoft's Get-SecureBootUEFI documentation confirms that those are the UEFI variables associated with Secure Boot, along with SecureBoot and SetupMode.
And this is actually GOOD news.
It means we do not have a missing-key problem.
The firmware appears to have a populated Secure Boot key hierarchy; Secure Boot is simply not being enforced right now.
And your observation that this is probably the configuration that currently allows Windows to start is entirely reasonable.
So, let's NOT collect those two PowerShell commands yet.
I'm changing my previous instruction.
I don't want to collect more data simply for the sake of collecting data. We now have a much more logical diagnostic path.
For now, please leave the BIOS exactly as it is.
Do NOT:
❌Clear Secure Boot Keys
❌Restore factory keys
❌Reset security settings
❌Change Legacy Support
We've already done enough investigation to know that the keys are present.
What I want to determine next:
I want to establish exactly what happens when we change only:
Secure Boot Support: Disabled → Enabled
while leaving:
Legacy Support: Disabled
exactly as it is.
That is the configuration we ultimately want:
UEFI + Legacy Support Disabled + Secure Boot Enabled
But before I have you make that change, I want to make sure we have our baseline completely documented.
So, my friend, you did exactly the right thing by stopping and asking before changing anything.
Please don't run any additional commands yet.
I'm going to reassess everything we've collected with this corrected BIOS information and determine the safest next controlled test.
And this actually makes me feel better about the situation, not worse.
We aren't looking at a mysterious system where Windows says Secure Boot is OFF while the BIOS says it's ON.
We now know:
BIOS: Secure Boot OFF
Windows: Secure Boot OFF
Those two agree.
The real question has become:
What happens when we turn Secure Boot Support ON, given that the necessary HP/Microsoft Secure Boot keys are already present?
That's a much cleaner diagnostic question.
And you were absolutely right to catch that wording in the photograph. Excellent specimen handling, my friend!
I'll give you the next step after we've accounted for this corrected information. For now, hands off the BIOS.
So, enable Secure Boot Support
After you have done that, report these two things after enabling Secure Boot Support:
- What happens when you save/exit BIOS:
- Does Windows boot normally?
- Do you get any Secure Boot error/message?
- Does the system return to BIOS?
Once in Windows, run PowerShell as Administrator: Confirm-SecureBootUEFI
and report whether it returns:
True or False.
That's enough for the next diagnostic step.
Kind Regards,
NonSequitur777
146
9
2
HP Recommended
Okay, my friend, back again with some results. As to the question, "What happens when Secure Boot is enabled and Legacy Disabled...I took these photos:
1.
Message screens after enabling Secure Boot:
2.
3.
Confirm- Secure BootUEFI command came back: "False".
Of course I had to restart and enter BIOS to disable both Legacy and Secure Boot in order to login to Windows.
So, this is the dilemma I've created trying to install the 2023 certificates. I was just trying to be proactive, not reactive. Didn't want to run into any issues about the "future" security of my laptop. Guess, I could've or should've not bothered anything. Hindsight, of course. I guess the old saying is true, "If it ain't broke, don't fix it".
Okay, my friend, enough of my "ranting". Hope these results can paint a clearer picture on the situation. As always, I look to hear from you soon! PEACE
HP Recommended
Good evening again, my friend! And YES -these photographs absolutely do paint a much clearer picture.
And I want you to take one thing off your mind immediately:
You have NOT broken your laptop.
In fact, the controlled test you just performed gave us an extremely valuable result.
When we changed only:
Legacy Support: Disabled
Secure Boot: Enabled
the machine produced the Secure Boot error you photographed. Then, after that failed, it went to the HP Sure Recover screen.
That tells us that the firmware is actually enforcing Secure Boot and rejecting the boot chain.
So your Confirm-SecureBootUEFI = False result is completely expected now, because you had to disable Secure Boot again in order to get Windows to start.
Here's the important part
I don't want us to jump immediately to installing or replacing certificates.
I have just checked HP's current documentation for the EliteBook 840 G5, and HP is presently warning that this product may experience an HP Secure Boot error after installation of a cumulative Microsoft Security Update.
That's a very interesting correlation with what we're seeing.
And HP's current guidance regarding the 2023 certificates says that the certificate transition involves both the HP BIOS preparation and the Microsoft certificate/boot-manager changes.
Therefore, before we touch the Secure Boot keys or certificates, I want to establish exactly what is currently installed on your Windows system.
NEXT STEP — Windows-side inspection
Please leave the BIOS exactly as it is now:
Legacy Support: Disabled
Secure Boot: Disabled
That's our safe working configuration.
Then, in Windows, open PowerShell as Administrator and run these commands one at a time:
1. Check the Windows boot manager:
Get-Item "$env:windir\Boot\EFI\bootmgfw.efi" | Select-Object FullName,Length,LastWriteTime
2. Check its Microsoft digital signature:
Get-AuthenticodeSignature "$env:windir\Boot\EFI\bootmgfw.efi" | Format-List Status,SignerCertificate
3. Check the actual UEFI boot entry:
bcdedit /enum firmware
4. And one more very important check:
Please run: Get-SecureBootUEFI -Name db
Don't worry if that produces a lot of information. I mainly want to see the output -don't modify anything.
Kind Regards,
NonSequitur777
146
9
2
HP Recommended
HP Recommended
We have found a very important clue.
My friend, thank you for collecting all of this information so carefully. These results are considerably more revealing than the earlier tests.
Let's go through them.
1. The Windows Boot Manager file is present:
You have:
C:\WINDOWS\Boot\EFI\bootmgfw.efi
Size: 3,086,848 bytes
Date: July 15, 2026
So we are NOT dealing with a missing Windows Boot Manager.
That's good.
2. And the Boot Manager is properly Microsoft-signed:
This is even more important.
Your result says:
Status: Valid
and the signer is:
Microsoft Windows
Issuer: Microsoft Windows Production PCA 2011
with a certificate valid through:
October 17, 2026
That tells us the Boot Manager itself has a valid Microsoft digital signature.
So we can now rule out another possibility:
The bootmgfw.efi file isn't simply corrupt or unsigned.
3. Your UEFI boot configuration also looks correct:
This section is very reassuring:
Windows Boot Manager
device partition=\Device\HarddiskVolume1
path \EFI\Microsoft\Boot\bootmgfw.efi
That is exactly the sort of UEFI boot entry we expect to see.
So again, we have no reason at this point to rebuild the BCD, recreate the EFI partition, or run bcdboot.
Please do NOT do any of those things.
4. And the Secure Boot DB is definitely populated:
Your:
Get-SecureBootUEFI -Name db
successfully returned the db variable.
That confirms the firmware's Secure Boot signature database is present and readable.
So we now have three important pieces agreeing:
Windows Boot Manager exists.
Windows Boot Manager is digitally signed.
UEFI has a valid Windows Boot Manager entry.
Yet:
Secure Boot ON → Windows will not boot.
That is the puzzle we need to solve.
And I think I see where we need to look next
There is one thing we have not yet established:
Does the firmware's db actually contain the 2023 Windows UEFI certificate?
The output you gave:
db {161, 89, 192, 165...}
only tells us that the database exists.
It does not tell us which certificates are inside it.
And that distinction is extremely important.
Microsoft explains that the 2023 transition involves new Secure Boot trust anchors, including the Windows UEFI CA 2023, while older 2011 certificates are approaching/undergoing expiration.
Meanwhile, your Windows Boot Manager is currently signed through the Microsoft Windows Production PCA 2011 chain.
That doesn't automatically mean the machine is broken — existing 2011-signed boot components can remain usable while the transition occurs — but it gives us something very specific to investigate.
So, here is our NEXT controlled test:
Leave the computer exactly as it is now:
Legacy Support: Disabled
Secure Boot: Disabled
Do NOT enable Secure Boot again yet.
Open PowerShell as Administrator and run this command:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes) -match 'Windows UEFI CA 2023')
Then run:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes) -match 'Microsoft UEFI CA 2023')
And finally:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes) -match 'Microsoft Corporation UEFI CA 2011')
Please give me the three results exactly as PowerShell reports them: True or False
I am particularly interested in: Windows UEFI CA 2023 = ?
That is the key result right now.
One other thing I want you to check:
Because your EliteBook 840 G5 is now specifically listed by HP with a warning concerning a Secure Boot error following a cumulative Microsoft Security Update, I don't want to overlook that possibility. HP's current support page for the 840 G5 carries that warning, and Microsoft's current guidance likewise notes that outdated firmware or certificate-update problems can produce Secure Boot validation failures and even boot failures.
So please also run:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='TPM-WMI'; Id=1795,1801,1802} -MaxEvents 20 |
Select-Object TimeCreated,Id,Message | Format-List
If it returns anything, give me the output.
Those event IDs may tell us whether Windows has already attempted the Secure Boot certificate transition and encountered a firmware problem.
And this is where I want to reassure you
We're actually in a much better position now than we were several days ago.
We have established:
Component Result
| UEFI boot mode | ✅ |
| Legacy Support | Disabled |
| Windows Boot Manager | ✅Present |
| Boot Manager signature | ✅Valid |
| UEFI Windows Boot Manager entry | ✅Present |
| Secure Boot db | ✅Present |
| Secure Boot enabled | ❌Boot failure |
| Windows with Secure Boot disabled | ✅Boots normally |
That's a very narrow problem.
We do NOT need to reinstall Windows.
We do NOT need to rebuild the boot configuration.
We do NOT need to clear the Secure Boot keys.
We do NOT need to start manually importing certificates.
Not yet.
We are now trying to determine whether this is a 2023 certificate-transition problem, a firmware/Secure Boot validation problem, or the specific HP Secure Boot issue that HP is currently flagging for this model.
And, my friend, I think we're finally close.
So, enjoy your Sunday, play that bass, and let the 18-month-old know that his grandfather's laptop is still under professional investigation.
When you get home, just send me the three True/False certificate results and the TPM-WMI event output.
That's our next step. Nothing else needs to be changed.
Kind Regards,
NonSequitur777
146
9
2
HP Recommended
HP Recommended
Good afternoon again, my friend! And YES — these results are helpful. In fact, we're getting closer to a final solution, so let's take this one step at a time.
First, your Secure Boot certificate results
These three results are significant:
- Windows UEFI CA 2023 = False
- Microsoft UEFI CA 2023 = False
- Microsoft UEFI CA 2011 = True
So, at present, your Secure Boot db contains the older Microsoft UEFI CA 2011, but we are not seeing the 2023 certificates in the active DB.
That is important because the 2023 Secure Boot certificate transition is precisely what we're investigating.
And there is an additional wrinkle here: HP's current documentation says that HP commercial PCs released in 2018 and earlier reached end of service life and did not receive the later BIOS changes for the 2023 Secure Boot certificate transition. The EliteBook 840 G5 is a 2018-era platform.
However, I do NOT want us jumping to the conclusion that this alone explains your F30/Secure Boot problem. Remember, your present problem began after the attempted certificate procedure, so we still need to establish exactly what the firmware is doing.
Second, the TPM-WMI command:
Don't worry about those errors. You did not do anything wrong.
The problem is simply that Windows doesn't recognize TPM-WMI as the provider name in the way we specified it.
The actual Windows event provider is normally: Microsoft-Windows-TPM-WMI
So, let's query it correctly.
Please open PowerShell as Administrator and run this exact command:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-TPM-WMI'; Id=1795,1800,1801,1802,1803,1808} -MaxEvents 30 |
Select-Object TimeCreated,Id,Message | Format-List
I have deliberately added 1800, 1803, and 1808 to our search.
We're particularly interested in:
- 1795 — firmware error while applying the Secure Boot update
- 1801 — updated certificates are available but have not been applied to firmware
- 1803 — required Secure Boot certificate/KEK is missing
- 1808 — Secure Boot certificates were successfully applied
Microsoft documents these events as part of the Secure Boot certificate-update process.
Most important: DON'T change anything yet.
For now, please do not:
- clear Secure Boot keys
- reset Secure Boot keys
- reinstall Windows
- rebuild the BCD
- reset the TPM
- flash the BIOS
- repeat the certificate-installation procedure
We're still in the diagnostic phase. I don't want us changing another variable until we know exactly what the firmware is reporting.
Please paste the complete output from that corrected PowerShell command here — even if it says that no matching events were found.
And my friend, don't be anxious. The fact that Windows is successfully showing us the Secure Boot database contents is good news. We're narrowing this down rather than blindly trying fixes.
Once I see those TPM-WMI events, we'll know whether the firmware is actually rejecting a Secure Boot certificate update, whether Windows has merely staged an update, or whether we're dealing with the older HP firmware/key configuration left behind by the earlier certificate attempt.
We're going to let the evidence tell us what to do next.
Thank you for your patience! Obviously -and this is nothing new to me as I indicated a little while ago- troubleshooting can sometimes be quite time consuming -it is what it is, I'm afraid.
Kind Regards,
NonSequitur777
146
9
2
HP Recommended
HP Recommended
Good afternoon, my friend! And please don't apologize for being anxious — you have absolutely nothing to feel guilty about. You followed every instruction carefully, supplied exactly the information I asked for, and that is precisely how we solve a difficult problem like this.
And now I have some very good news for you.
I believe we have finally found the important piece of the puzzle.
Please look very carefully at this event:
8/13/2026 3:37:03 PM — Event ID 1808
"This device has updated Secure Boot CA/keys."
And, even more importantly, Windows identifies the update as:
- Windows UEFI CA 2023 (DB)
- Option ROM CA 2023 (DB)
- 3P UEFI CA 2023 (DB)
- KEK 2023
- Boot Manager (2023)
That is extremely significant.
Microsoft's documentation identifies Event 1808 as the successful completion of the Secure Boot certificate/key update. In other words, Windows is telling us that the firmware accepted the required Secure Boot update and that the 2023 Secure Boot configuration was successfully applied.
And now the earlier 1802 events make sense
Notice the chronology:
2:36 PM
- 1801 — certificates available but not yet applied
- 1802 — several components blocked by the known firmware issue
Then:
3:37 PM
- 1808 — Secure Boot CA/keys updated successfully
That is a very important transition.
So, I would not interpret the older 1802 events as meaning that the update ultimately failed. They document the earlier unsuccessful attempts. The later 1808 is the success event.
Microsoft specifically describes 1802 as a condition where Secure Boot certificate deployment is temporarily blocked because of a known firmware issue, whereas 1808 indicates successful deployment.
There is one apparent contradiction we need to resolve:
Earlier we tested the db contents and received:
Windows UEFI CA 2023 = False
Microsoft UEFI CA 2023 = False
Microsoft Corporation UEFI CA 2011 = True
At first glance, that seems inconsistent with Event 1808.
And this is where I want to correct something from my previous analysis: I do not want us to conclude that the certificate update failed merely because those ASCII-string searches returned False.
The Event 1808 result is much more authoritative for determining whether Microsoft's Secure Boot update process completed. Microsoft also recommends checking the Windows Secure Boot servicing status in the registry, rather than relying solely on an ASCII search through the raw EFI signature database.
So we're going to make one final verification, and I think this may be the last diagnostic step we need.
Please run this exact PowerShell command as Administrator:
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' | Select-Object UEFICA2023Status, WindowsUEFICA2023Capable, AvailableUpdates
Then run:
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' | Select-Object UEFICA2023Status, UEFICA2023Error, UEFICA2023ErrorEvent
Please paste all of the output, including any blank fields or error messages.
What we're hoping to see:
The most important value is: UEFICA2023Status : Updated
If that is what we find, then I am prepared to say:
The Secure Boot certificate update is complete.
Microsoft's current troubleshooting guidance specifically identifies UEFICA2023Status = Updated as the successful state, with Event 1808 providing additional confirmation.
And if there are no persistent UEFICA2023Error or UEFICA2023ErrorEvent values, that's even better.
One other important point:
Your system reports: HP firmware: Q78 Ver. 01.31.00
and the successful 1808 event specifically records that firmware version.
So we now have a very strong chain of evidence:
HP firmware 01.31.00 → attempted 2023 certificate deployment → temporary 1802 blocks → successful Event 1808.
That is a very different picture from where we started.
And please do not:
- clear the Secure Boot keys
- restore factory Secure Boot keys
- reset the TPM
- reinstall Windows
- rebuild the boot configuration
- flash the BIOS again
Not at this point.
We're not going to disturb a machine that has just given us evidence of a successful firmware-level Secure Boot update.
Give me those two registry-command results, my friend. I genuinely think we're at the final verification now.
And regardless of what those two commands say, you've done an excellent job working through this. You didn't "create" this problem -the logs themselves show that the firmware/certificate update process encountered a known firmware compatibility issue. You simply had the patience to help us expose exactly what happened.
Kind Regards,
NonSequitur777
Be alert for scammers posting fake support phone numbers and/or email addresses on the community.
If you think you have received a fake HP Support message, please report it to us by clicking on "Flag Post".
Didn't find what you were looking for?
Ask the community