-
×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.
HP Recommended
I am posting your HP EliteBook 840 G5 issue/question you posted in the HP Pavilion 590-p0054 discussion in a brand-new discussion thread -and I quote:
Just thought I'd give you a brief explanation of what is the issue with my Elitebook 840 G5. I tried to manually install the 2023 secure boot certificates, after perusing some methods on the Net. I found one I thought would be pretty easy. Well, the install didn't go well and I tried reverting bios changes I made for the install. When rebooting, got the f30 error with secure boot enabled. So I disabled both legacy and secure boot supports. I can boot into windows. Need to correct the error. Let me know when you're available. PEACE!!
It makes sense to dedicate a separate discussion thread for your EliteBook 840 G5!
And here we go:
Good evening again, my friend!
Well, you've just given me something extremely important -and I'm actually glad you told me the complete story before we start changing anything on the EliteBook.
And after what we just went through with the Pavilion, I'm going to be especially careful with this one. 😊
First: DON'T change anything else in the BIOS for now.
The fact that you can currently boot Windows with:
Legacy Support: Disabled
and
Secure Boot: Disabled
is very good news.
It means the machine is not bricked, and we have a functioning Windows installation from which we can gather information.
The F30 error appearing immediately after your attempt to install the 2023 Secure Boot certificates is also a very significant clue.
Unlike the Pavilion, I don't want to assume this is a Windows boot-file problem.
In fact, based on what you've told me so far, I'm much more suspicious of the UEFI Secure Boot configuration/certificate state in the EliteBook's firmware.
And there's another important distinction:
Please do not try the certificate installation procedure again.
Not yet, anyway.
I want to see exactly what state the firmware is in before we attempt to repair anything.
Here's what I want to do first:
We're going to take the same approach that worked so well with the Pavilion:
diagnose first — modify second.
Since Windows currently boots, that's our opportunity to collect information safely.
I want to establish:
- Exactly what BIOS version the EliteBook is running.
- What HP reports for Secure Boot configuration.
- Whether Windows currently sees Secure Boot as supported and/or enabled.
- Whether the Secure Boot Platform Key (PK) is present.
- Whether the KEK, db, and dbx databases are present.
- Exactly what Windows reports about the F30 condition.
We are not going to clear keys.
We are not going to load/delete keys.
We are not going to reset Secure Boot to factory defaults yet.
We are not going to flash the BIOS yet.
And absolutely do not select anything labeled "Clear Secure Boot Keys".
We've learned enough from our previous HP cases to know that Secure Boot key management deserves a very deliberate approach.
I need some information from the EliteBook first.
When you're ready, boot normally into Windows with Secure Boot disabled.
Then please send me the following.
1. System Information:
Press:
Windows key + R
type: msinfo32
and press Enter.
Please give me the values for:
BIOS Mode
BIOS Version/Date
Secure Boot State
OS Name
OS Version
If it's easier, a photograph/screenshot of the System Summary screen is perfectly fine.
2. PowerShell — Secure Boot status:
Open PowerShell as Administrator and run:
Confirm-SecureBootUEFI
Tell me exactly what it returns.
Then run:
Get-SecureBootUEFI
and post the complete output.
If that produces an error, don't try to fix the error — just give me the exact wording.
3. TPM information:
Still in elevated PowerShell, run: Get-Tpm
and post the complete result.
4. Most importantly — tell me exactly what F30 says.
If you can reproduce the F30 screen without changing anything, I would like the exact wording of the error.
A photograph of the F30 screen would be even better.
Don't intentionally trigger the error yet, though.
If you already have a photograph of it from when this happened, send that instead.
And one more thing...
You mentioned that you found a method online for manually installing the 2023 Secure Boot certificates.
When you have a moment, please give me either:
- the URL of the procedure you followed, or
- the name/title of the article or instructions.
That could be extremely useful.
I don't want to criticize the procedure before seeing it. There are several different Secure Boot certificate-update mechanisms, and the exact method matters enormously -particularly with older HP firmware.
Your EliteBook 840 G5 is also from a generation where the firmware's Secure Boot implementation and the newer Microsoft certificate transition need to be handled carefully.
So, I'd like to reconstruct exactly what was changed rather than guessing.
Most importantly:
You did the right thing by stopping.
You discovered the F30 error, disabled Secure Boot, got Windows booting again, and came to me before attempting another repair.
That's exactly what I wanted you to do.
The Pavilion taught us a valuable lesson:
Don't repair what we haven't diagnosed.
This time we're going to follow that rule from the very beginning.
And don't worry about availability, my friend.
I'm here.
Bring me the EliteBook's information when you're ready, and we'll start from the machine's current known-good state and work forward carefully.
No rush.
No random BIOS changes.
No clearing keys.
No BIOS flashing.
Just information first.
Then we'll determine exactly what F30 is telling us and formulate the safest path back to Secure Boot.
PEACE, MY GOOD FRIEND! 🤝
And congrats again on the Pavilion victory. Now let's see if we can get your EliteBook back into shape without creating another adventure quite as long as the last one!
Kind Regards,
NonSequitur777
116
9
2
HP Recommended
116
9
2
HP Recommended
Good Afternoon My Friend, I'm here again! I hope you are well and prospering! Think I'm ready to begin another "journey" in solving my f30 error. I have gathered the information you asked for and maybe some additional information that may assist you moving forward. BTW, I gave doing screenshots a try, but, it didn't go very well, sorry. So, I'm back to text results. Here goes:
1. System Information:
OS Name Microsoft Windows 11 Pro
Version 10.0.26200 Build 26200
Other OS Description Not Available
OS Manufacturer Microsoft Corporation
System Name JAMES-NEW-ELITE
System Manufacturer HP
System Model HP EliteBook 840 G5
System Type x64-based PC
System SKU 4NH98US#ABA
Processor Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz, 1896 Mhz, 4 Core(s), 8 Logical Processor(s)
BIOS Version/Date HP Q78 Ver. 01.31.00, 3/10/2025
SMBIOS Version 3.1
Embedded Controller Version 4.112
BIOS Mode UEFI
BaseBoard Manufacturer HP
BaseBoard Product 83B2
BaseBoard Version KBC Version 04.70.00
Platform Role Mobile
Secure Boot State Off
PCR7 Configuration Elevation Required to View
Windows Directory C:\WINDOWS
System Directory C:\WINDOWS\system32
Boot Device \Device\HarddiskVolume1
Locale United States
Hardware Abstraction Layer Version = "10.0.26100.1"
User Name JAMES-NEW-ELITE\jeobs
Time Zone Eastern Daylight Time
Installed Physical Memory (RAM) 32.0 GB
Total Physical Memory 31.8 GB
Available Physical Memory 24.4 GB
Total Virtual Memory 33.8 GB
Available Virtual Memory 26.9 GB
Page File Space 2.00 GB
Page File C:\pagefile.sys
Kernel DMA Protection Off
Virtualization-based security Running
Virtualization-based security Required Security Properties
Virtualization-based security Available Security Properties Base Virtualization Support, DMA Protection, UEFI Code Readonly, SMM Security Mitigations 1.0, Mode Based Execution Control
Virtualization-based security Services Configured Hypervisor enforced Code Integrity
Virtualization-based security Services Running Hypervisor enforced Code Integrity
App Control for Business policy Enforced
App Control for Business user mode policy Off
Automatic Device Encryption Support Elevation Required to View
A hypervisor has been detected. Features required for Hyper-V will not be displayed.
2. Confirm Secure Boot UEFI:
PS C:\WINDOWS\system32> Confirm-SecureBootUEFI
False
3. Get-Secure Boot UEFI
PS C:\WINDOWS\system32> Get-SecureBootUEFI
cmdlet Get-SecureBootUEFI at command pipeline position 1
Supply values for the following parameters:
Name:
Get-SecureBootUEFI : Cannot validate argument on parameter 'Name'. The argument "" does not belong to the set
"PK,KEK,db,dbx,SetupMode,SecureBoot,PKDefault,KEKDefault,dbDefault,dbxDefault,dbt,dbtDefault" specified by the
ValidateSet attribute. Supply an argument that is in the set and then try the command again.
At line:1 char:1
+ Get-SecureBootUEFI
+ ~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (:) [Get-SecureBootUEFI], ParameterBindingValidationException
+ FullyQualifiedErrorId : ParameterArgumentValidationError,Microsoft.SecureBoot.Commands.GetSecureBootUefiCommand
4. Get-TPM
PS C:\WINDOWS\system32> Get-Tpm
TpmPresent : True
TpmReady : True
TpmEnabled : True
TpmActivated : True
TpmOwned : True
RestartPending : False
ManufacturerId : 1229346816
PpiVersion : 1.3
ManufacturerIdTxt : IFX
ManufacturerVersion : 7.63.3353.0
ManufacturerVersionFull20 : 7.63.3353.0
ManagedAuthLevel : Full
OwnerAuth :
OwnerClearDisabled : False
AutoProvisioning : Enabled
LockedOut : False
LockoutHealTime : 2 hours
LockoutCount : 20
LockoutMax : 32
SelfTest : {}
Also I found the pics I took when the F30(3F0) error first occurred.
1.
I also thought I'd include the site URL where I got the information to manually install the 2023 certificates. Which is: https://www.elevenforum.com/t/why-installing-2023-secure-boot-certificates-manually-on-hp-elitebook-.... Which I WILL refrain from doing again, unless I get your guidance. Not of great importance right now, just getting this error solved. I hope this isn't TOO much info at one time. I tried to give you as much as I could to get started. I look to hear from you soon. PEACE, MY FRIEND!!!
116
9
2
HP Recommended
HP Recommended
Yea, I don't always get a notification email from HP when OPs post a (new) message -hence the delay.
In any regards, a very Good morning for you, my friend! And please don't apologize for the screenshots. They were actually extremely helpful. In fact, one of them gave us a very important clue that changes how I want to approach this problem.
I have now gone through everything you provided, including the photographs.
First, we have an important clarification:
The error is 3F0, not F30:
Boot Device Not Found
Hard Disk - (3F0)
But even more important is the other message you captured:
Selected boot image did not authenticate.
That is the clue I've been looking for.
Because Windows boots normally when Secure Boot is disabled, while enabling Secure Boot results in the authentication failure/3F0 condition, I am now much more suspicious of the Secure Boot key/certificate state than I am of your Windows installation or SSD.
Your SSD diagnostics also passed, which is reassuring.
So, at this point:
DO NOT reinstall Windows.
DO NOT rebuild the BCD.
DO NOT run BCDBOOT.
DO NOT clear the Secure Boot keys.
DO NOT repeat the 2023 certificate procedure.
DO NOT flash the BIOS.
We're going to diagnose the Secure Boot state first.
Your BIOS information is also very useful
You are running:
HP EliteBook 840 G5
Motherboard: HP 83B2
BIOS: Q78 Ver. 01.31.00 — 03/10/2025
BIOS Mode: UEFI
Secure Boot State: Off
That's exactly the information I wanted.
And your TPM looks completely healthy:
- TPM Present: True
- TPM Ready: True
- TPM Enabled: True
- TPM Activated: True
- TPM Owned: True
- Restart Pending: False
- Manufacturer: Infineon
- Firmware: 7.63.3353.0
So we're going to leave the TPM alone. It isn't where I want to concentrate our attention.
One small correction regarding Get-SecureBootUEFI
The command you entered wasn't actually telling us that Secure Boot was broken.
Get-SecureBootUEFI requires you to specify which UEFI variable you want to examine. PowerShell even gave us the list of valid names.
That's actually perfect, because now we can inspect the individual Secure Boot components.
Please boot normally into Windows with Secure Boot still disabled.
Then open PowerShell as Administrator and run these commands one at a time:
Get-SecureBootUEFI -Name PK
Get-SecureBootUEFI -Name KEK
Get-SecureBootUEFI -Name db
Get-SecureBootUEFI -Name dbx
Get-SecureBootUEFI -Name SetupMode
Get-SecureBootUEFI -Name SecureBoot
Please copy/paste the complete output from all six commands.
If any command produces an error, that's perfectly fine. Do not try to correct the error. Just include the exact error message.
I also want one additional check:
Please run:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot" /s
You can run that from either an elevated Command Prompt or PowerShell.
Again, we are only reading information.
Don't change anything in the registry.
Why I'm asking for these particular results:
We're trying to answer six very specific questions:
- Is the Platform Key (PK) present?
- Is the Key Exchange Key (KEK) present?
- Are the Microsoft/UEFI allowed-signature database (db) and forbidden-signature database (dbx) present?
- Is the firmware in Setup Mode?
- Does the firmware report Secure Boot as enabled internally?
- What does Windows know about the Secure Boot configuration/update state?
That will tell us considerably more than simply knowing that Windows currently reports Secure Boot as Off.
And because your problem began immediately after attempting the 2023 certificate installation, I particularly want to see whether the PK/KEK/db/dbx relationship is intact.
One very important observation:
The sequence you've described now makes sense:
Windows boots normally → 2023 certificate procedure attempted → Secure Boot subsequently rejects the boot image → "Selected boot image did not authenticate" → 3F0 → Secure Boot disabled → Windows boots again.
That strongly suggests that the underlying Windows installation may be perfectly healthy and that the failure occurs specifically when the firmware attempts to authenticate the Windows bootloader.
That's good news, because it gives us a much narrower problem to solve.
And I'm particularly glad you stopped rather than continuing to experiment with the Secure Boot keys.
The EliteBook 840 G5 is old enough that we need to be particularly careful about applying procedures designed for newer HP systems. The 2023 Secure Boot certificate transition is not something I want us to approach by trial and error.
So for now, my friend, nothing gets changed.
Just give me the output from those two diagnostic checks.
Once I see the PK, KEK, db, dbx, SetupMode, SecureBoot, and registry results, we'll know what state the firmware is actually in.
Then -and only then- we'll decide what the safest repair is.
And again, excellent job gathering all of this information. This time we're not guessing. We're narrowing the problem down one piece at a time.
Kind Regards,
NonSequitur777
116
9
2
HP Recommended
116
9
2
HP Recommended
HP Recommended
Good afternoon, my friend! And YES -these results are very favorable indeed. In fact, you just gave me the most important information we've obtained so far.
And please tell your grandson that he has excellent timing. 😄
I've gone through the output carefully, and I think we now understand considerably more about what happened.
First: the Secure Boot keys are still there:
This is excellent news.
Your results show:
PK: Present
KEK: Present
db: Present
dbx: Present
And:
SetupMode = 0
That means the firmware is not in Secure Boot Setup Mode.
So, we have not lost the Platform Key, and I do not see evidence that the Secure Boot key hierarchy has simply been wiped out.
That's a major distinction from the OMEN case we've been working on where the Platform Key was actually missing.
Your EliteBook's situation is different.
Your current Secure Boot state is essentially:
PK present
KEK present
db present
dbx present
Setup Mode = No
Secure Boot = No
That is a perfectly coherent state for a machine that is currently running with Secure Boot disabled.
So far, so good.
But we found something very important
This part of your registry output jumped right out at me:
WindowsUEFICA2023Capable REG_DWORD 0x0
and:
UEFICA2023Status REG_SZ InProgress
Then we have:
DBLastUpdateErrorReason REG_SZ Firmware_KI_7
KEKLastUpdateErrorReason REG_SZ Firmware_KI_7
DB3POROMLastUpdateErrorReason REG_SZ Firmware_KI_7
DB3PUEFILastUpdateErrorReason REG_SZ Firmware_KI_7
And finally:
BootMgrLastUpdateErrorReason REG_SZ PCA2023NotFoundInDB
That is an extremely interesting collection of evidence.
Windows is telling us that it has attempted to process the 2023 Secure Boot certificate transition, but the firmware-side operation has not completed successfully.
And remember what you told me at the beginning:
You manually attempted to install the 2023 Secure Boot certificates, and immediately afterward the machine began producing the 3F0 / "Selected boot image did not authenticate" problem.
The registry information now fits that history remarkably well.
This also explains why I don't want to start changing Secure Boot keys.
We now know that the PK/KEK/db/dbx databases are present.
Therefore:
Do NOT clear the Secure Boot keys.
Do NOT load factory keys.
Do NOT delete the PK.
Do NOT manually import another certificate.
Do NOT repeat the ElevenForum procedure yet.
We have enough evidence now to know that randomly manipulating the key databases could make the situation substantially worse.
There's another important clue:
Your registry contains:
OEMModelBaseBoard REG_SZ 83B2
FirmwareVersion REG_SZ Q78 Ver. 01.31.00
OEMModelNumber REG_SZ HP EliteBook 840 G5
So, Windows is correctly identifying this as the HP EliteBook 840 G5 / 83B2 / Q78 01.31.00 platform.
That's good because we aren't dealing with Windows having some incorrect OEM/platform information.
And the Secure Boot servicing information is clearly being generated specifically for this HP platform.
What I think happened:
At this point, my working theory is:
You attempted the 2023 Secure Boot certificate procedure manually.
Windows subsequently detected that the 2023 Secure Boot servicing process was applicable to the machine.
It entered:
UEFICA2023Status = InProgress
but the firmware did not successfully complete the required update operations.
Windows consequently recorded multiple:
Firmware_KI_7
failures.
At the same time, Windows reports:
PCA2023NotFoundInDB
for the Boot Manager update.
That would fit very nicely with the firmware subsequently refusing to authenticate the Windows boot image when Secure Boot is enabled.
That is a much better explanation of your 3F0 than a damaged Windows installation.
And this is why the 3F0 made sense
Remember the photograph you provided:
Selected boot image did not authenticate.
That is not what I would expect from a dead SSD.
It is exactly the sort of message we would expect when UEFI Secure Boot is active but the bootloader's signature/certificate chain cannot be authenticated against the firmware's current Secure Boot database.
Then the firmware can't successfully launch Windows and eventually gives us:
Boot Device Not Found — Hard Disk (3F0)
Disable Secure Boot, and Windows boots.
That sequence now makes considerably more sense.
So, what do we do next?
We still don't change anything.
We're at the point where I want to be very deliberate.
The next thing I want to establish is whether the Windows 2023 Secure Boot servicing process has left behind a pending state that Windows itself can safely resolve, or whether HP's firmware has a known limitation/compatibility condition for this particular EliteBook.
I do not want to guess at that.
And your registry output gives us a very specific lead to investigate:
Firmware_KI_7
That is the piece I want to understand before we touch the Secure Boot databases.
There is also a very interesting clue in:
StateAttributes ... DBUpdateExternalRollout ... DBUpdate3PUEFICARollout ... DBUpdate3POROMRollout
So, Windows has clearly classified this machine into the newer Secure Boot servicing framework.
For now, I want just one more safe diagnostic
Please open PowerShell as Administrator and run:
Get-WinEvent -LogName "Microsoft-Windows-TPM-WMI/Operational" -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List
If that log doesn't exist or produces an error, that's perfectly okay -just give me the exact response.
Then run:
Get-WinEvent -LogName System -MaxEvents 500 |
Where-Object {
$_.Message -match "Secure Boot|UEFI|PCA2023|2023|Firmware_KI_7"
} |
Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message |
Format-List
Again, we're only reading information.
Don't change anything in the registry or BIOS.
One thing I want you to know right now:
You were worried that the results might not be "pretty."
They are.
The most important thing I wanted to know was whether we had destroyed the Secure Boot key structure.
We haven't.
PK is present.
KEK is present.
db is present.
dbx is present.
Setup Mode is OFF.
That's very good news.
What we have instead is a failed/incomplete 2023 certificate servicing state, which is considerably more specific -and therefore potentially much easier to address correctly.
And I think your original instinct was right: the 2023 certificate procedure is directly relevant to what happened.
But we're going to resist the temptation to simply run that procedure again.
We now have something much better:
evidence.
Let's identify exactly what Windows and the firmware believe happened during the failed certificate transition.
Once we understand that, we can determine the safest way to finish or roll back that process and get Secure Boot functioning again.
So, keep everything exactly as it is for now:
Secure Boot disabled.
Legacy Support disabled.
Windows booting normally.
Do not clear keys.
Do not load factory keys.
Do not flash BIOS.
Do not repeat the certificate procedure.
We're in a very good diagnostic position.
Keep those fingers crossed, my friend. 😎
I think we've finally found the thread that leads back to the original problem.
Kind Regards,
NonSequitur777
116
9
2
HP Recommended
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