-
×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
Good evening again, my friend! And YES -these results definitely get us a little closer. And please don't let the phrase "HP firmware-level problem" worry you just yet. We have not reached that conclusion.
In fact, there is some good news in these results.
First, the Secure Boot variables are present:
You successfully queried all three important UEFI variables:
- PK — present
- KEK — present
- DB — present
So, we are not dealing with a situation where Windows cannot access the Secure Boot databases at all.
And the output:
Bytes : {161, 89, 192, 165...}
Attributes : NON VOLATILE
BOOTSERVICE ACCESS
RUNTIME ACCESS
TIME BASED AUTHENTICATED WRITE ACCESS
is normal for these EFI variables. The fact that PowerShell can retrieve them is reassuring.
But this confirms one thing we already suspected:
You also got:
PS C:\WINDOWS\system32> Confirm-SecureBootUEFI False
So, Windows is unequivocally reporting:
Secure Boot is currently OFF.
That remains an important part of the problem.
However, we still don't know which certificates are actually contained in PK, KEK and DB. The Bytes output doesn't tell us that.
And I want to emphasize something from our previous step:
The four True/False ASCII searches were not sufficient to prove that the 2023 certificates are absent.
We were searching binary EFI Signature List data as though it were ordinary text. That was a useful preliminary check, but it isn't a reliable certificate inventory. I don't want us making a firmware change based on that.
There is another encouraging result:
Remember that we previously found:Secure-Boot-Update State: Ready
and: LastTaskResult: 0
with: AvailableUpdates: 0
So, the Windows Secure Boot servicing task exists, runs, and is not currently reporting a task-execution failure.
That's actually quite useful because it means we shouldn't start repairing or reinstalling Windows simply because the certificate transition hasn't completed.
And there is an important HP clue:
I also want to highlight something that has become increasingly relevant to our investigation:
HP has published a Secure Boot advisory for the EliteBook 840 G5 indicating that the product may experience a Secure Boot error after installing a cumulative Microsoft Security Update.
That does not prove that this particular machine has that problem, but it tells us that an HP/Microsoft Secure Boot interaction on this model is a legitimate possibility -not something we are imagining.
So, we're going to proceed carefully.
One more completely read-only check:
Before we change anything in BIOS or Windows, please run these commands in PowerShell as Administrator:
Get-SecureBootUEFI -Name SecureBoot
Then:
Get-SecureBootUEFI -Name SetupMode
Then:
Get-SecureBootUEFI -Name PKDefault
And finally:
Get-SecureBootUEFI -Name dbDefault
Please copy the complete output from all four commands.
Do not use Set-SecureBootUEFI, and don't change any Secure Boot settings in BIOS.
Also, please don't:
- Clear Secure Boot keys
- Load factory keys
- Delete or replace PK/KEK/DB
- Reset the TPM
- Reinstall Windows
- Attempt another BIOS recovery
We're deliberately avoiding all of those until we know exactly what state the firmware is in.
Why these four checks?
We're trying to distinguish between two very different situations:
Scenario 1 — The Secure Boot configuration is intact, but Secure Boot is simply disabled.
or
Scenario 2 — The enrolled Secure Boot certificates are present, but the firmware's certificate set is not compatible with Microsoft's 2023 transition.
The results we've gathered so far don't let us reliably distinguish those yet.
And there's no need to be alarmed by the second possibility. Even if we ultimately determine that this is an HP firmware compatibility issue, that does not mean the laptop is damaged or that we need to start replacing things. It simply means we need to identify the correct remediation path.
We're actually in a much better position now than when we started because we're no longer guessing. We have established that the PK/KEK/DB variables exist, Windows' Secure Boot servicing task is functioning, and Windows is specifically reporting that Secure Boot is not currently active.
So we're going to keep doing what we've been doing:
Read first. Change nothing until we know exactly what we're changing.
Enjoy the quiet evening, my friend, and post those four results whenever you get a chance.
PEACE!!
Kind Regards,
NonSequitur777
127
9
2
HP Recommended
HP Recommended
Good evening, my friend! And thank YOU for the very kind words. I genuinely appreciate them. We've certainly taken the scenic route with this one, but I think your patience is beginning to pay off.
And yes — I do have a positive response tonight. These results actually tell us quite a bit.
We have just eliminated another major concern:
You reported:
SecureBoot
Bytes : {0}
and:
SetupMode
Bytes : {0}
Those two values are particularly interesting.
SecureBoot = 0 means the firmware is currently reporting that Secure Boot is disabled.
But:
SetupMode = 0 means the system is not in Secure Boot Setup Mode.
That's important.
In practical terms, this tells us that the machine is not simply sitting there with an empty Secure Boot configuration waiting for a Platform Key to be installed.
And that agrees with our earlier discovery that the PK variable exists.
So we now have a much clearer picture:
The system has a Secure Boot key hierarchy, but Secure Boot itself is currently disabled.
That is considerably more reassuring than the possibility that the firmware had lost its Secure Boot configuration altogether.
And look at these two results:
You also got:
PKDefault
Bytes : {161, 89, 192, 165...}
and:
dbDefault
Bytes : {161, 89, 192, 165...}
That tells us that the firmware exposes its default Platform Key and default DB databases as UEFI variables.
Again, that's a good sign.
However — and this is important — PKDefault and dbDefault are not necessarily the same thing as the currently enrolled PK and DB.
We therefore still don't want to conclude that the current DB contains the 2023 Microsoft certificates simply because dbDefault exists.
We're getting very close, though.
I think we should now stop guessing and actually read the certificates.
We've been looking at the UEFI variables themselves, but PowerShell is only showing us:
Bytes : {161, 89, 192, 165...}
That's the raw EFI Signature List data.
What we really need is:
Who issued the certificates currently stored in PK, KEK and DB?
That will give us the definitive answer to the question we've been pursuing.
And fortunately, we can do that without changing anything.
Please run the following in PowerShell as Administrator:
Get-SecureBootUEFI -Name db | Select-Object -ExpandProperty Bytes |
Format-Hex
Please do the same for KEK:
Get-SecureBootUEFI -Name KEK | Select-Object -ExpandProperty Bytes | Format-Hex
And PK:
Get-SecureBootUEFI -Name PK | Select-Object -ExpandProperty Bytes | Format-Hex
However, before you do that, there is an even better approach I would like to try first.
Please run:
Get-SecureBootUEFI -Name db | Export-Certificate -Type CERT -FilePath "$env:USERPROFILE\Desktop\DB.cer"
If that command succeeds, please tell me exactly what it reports.
Then:
Get-SecureBootUEFI -Name KEK | Export-Certificate -Type CERT -FilePath "$env:USERPROFILE\Desktop\KEK.cer"
And finally:
Get-SecureBootUEFI -Name PK | Export-Certificate -Type CERT -FilePath "$env:USERPROFILE\Desktop\PK.cer"
But stop if any of those commands produce an error. Don't try to force the conversion.
The reason I'm being cautious is that these UEFI variables are EFI Signature Lists, which can contain multiple signatures/certificates. We don't want to treat the entire variable as though it were one ordinary Windows certificate.
If PowerShell won't directly export them, that's perfectly fine — I'll give you the proper EFI-signature-list decoding method based on the exact output from this machine.
And please don't change anything tonight!
We're still following our golden rule:
Read first. Change nothing until we understand what we're looking at.
So please do not:
- Clear Secure Boot keys
- Load HP factory keys
- Change PK/KEK/DB
- Reset the TPM
- Reinstall Windows
- Run BIOS recovery
- Manually install Microsoft's 2023 certificates
None of that is necessary at this point.
Where we stand tonight:
I think we can now say with considerably more confidence:
1. PK exists.
2. KEK exists.
3. DB exists.
4. The system is NOT in Secure Boot Setup Mode.
5. Secure Boot itself is disabled.
6. Windows' Secure-Boot-Update task exists and has successfully run.
7. No Secure Boot update is currently queued (AvailableUpdates = 0).
8. Windows previously reported PCA2023NotFoundInDB.
9. Windows still considers the machine incapable of completing the 2023 transition.
That's a surprisingly coherent set of facts.
And importantly, nothing we've seen tonight indicates that the laptop is bricked, that the TPM is defective, or that Windows needs to be reinstalled.
In fact, I'm increasingly interested in one very specific question:
What certificates are actually inside the currently enrolled DB and KEK?
Once we know that, we'll finally be looking at the Secure Boot trust chain itself rather than inferring its contents from Windows' status messages.
And that, my friend, could very well be our breakthrough.
So, get some well-deserved rest tonight. 😊 There is absolutely no reason to make any changes before we have the certificate information.
Tomorrow we'll pick it up from there.
Have a great night, my friend.
Kind Regards,
NonSequitur777
127
9
2
HP Recommended
HP Recommended
Good afternoon, my friend!
And WOW — yes, these results are helpful! You absolutely did the right thing by providing them. And please don't feel bad about looking at all that hexadecimal data and thinking, "What in the world am I supposed to do with this?"
As a retired lab tech, you already have the perfect analogy: you collected the specimen; I'll do the analysis! Your job was simply to obtain the correct data.
And there is some very encouraging information buried in all of that.
The important part:
I was specifically looking to see whether the Platform Key (PK) and Key Exchange Key (KEK) actually exist in the system's UEFI Secure Boot variables.
As a matter of fact, they do!
Your PK contains an HP certificate identifying:
HP Inc. PK 2016 CA
HP UEFI Secure Boot PK 2017
And your KEK contains:
HP Inc. KEK 2016 CA
HP UEFI Secure Boot KEK 2017
It also contains the Microsoft Corporation KEK CA 2011.
That is excellent information because these are legitimate Secure Boot certificates, not empty or obviously corrupted variables.
Why this matters:
Remember that earlier we were dealing with the BIOS reporting something along the lines of:
Platform Key: Not Enrolled
Yet Windows is now able to retrieve a valid PK from the UEFI firmware.
That means we have evidence that the underlying Secure Boot key infrastructure is much healthier than that BIOS status initially suggested.
However, I don't want to jump to the conclusion that everything is fixed just yet.
Having a PK and KEK present does not automatically prove that Secure Boot is fully active and functioning correctly. We still need to verify the other pieces of the Secure Boot trust chain — particularly the db (allowed signatures) and dbx (revoked signatures) databases — and, most importantly, what Windows itself reports.
So, let's keep this controlled and simple.
Please run only these commands (PowerShell) next: Confirm-SecureBootUEFI
Then:
Get-SecureBootUEFI -Name db | Select-Object -ExpandProperty Bytes | Format-Hex -Count 64
And:
Get-SecureBootUEFI -Name dbx | Select-Object -ExpandProperty Bytes | Format-Hex -Count 64
Finally:
Get-ComputerInfo | Select-Object BiosFirmwareType
You do not need to interpret any of the hexadecimal output. Just copy/paste the results here exactly as you did before.
At this point we're essentially checking the Secure Boot chain piece by piece:
PK → KEK → db/dbx → Windows Boot Manager → Secure Boot status
And we've now confirmed that the first two pieces contain legitimate HP/Microsoft Secure Boot certificates.
So, my friend, this is progress! We're no longer blindly troubleshooting Secure Boot. We're actually examining the firmware's Secure Boot configuration and narrowing down exactly where the discrepancy between the BIOS and Windows is occurring.
And don't worry — I promise I won't make you sit there and stare at another thousand lines of hexadecimal trying to figure out whether A1 59 C0 A5 is good news or bad news.
You collect the data; I'll translate the computer gibberish.
Kind Regards,
NonSequitur777
HP Recommended
Deng, I rechecked my previous post to you and there is one quick correction to my previous instructions, my friend!
I included -Count 64 with Format-Hex, but that parameter isn't available in the version of PowerShell we're using. So please disregard that part of my previous instructions. No harm done!
Let's make this easier anyway. Rather than having you produce another enormous hexadecimal dump, please run these commands:
Confirm-SecureBootUEFI
Then:
Get-SecureBootUEFI -Name PK Get-SecureBootUEFI -Name KEK Get-SecureBootUEFI -Name db Get-SecureBootUEFI -Name dbx
And finally:
Get-SecureBootPolicy
Just copy and paste the results here exactly as they appear.
Why these commands?
We've already learned something very important from your previous results:
PK is present and contains a legitimate HP Secure Boot certificate.
KEK is present and contains legitimate HP and Microsoft Secure Boot certificates.
That's a very good sign.
Now we're going to verify the remaining Secure Boot components — db, dbx, the active Secure Boot state, and the currently loaded Secure Boot policy.
This should allow us to determine whether we're dealing with:
- A genuinely incorrect Secure Boot configuration,
- A discrepancy between what the HP BIOS reports and what the UEFI variables actually contain, or
- Something occurring later in the Secure Boot/Windows boot chain.
And please don't worry about understanding the output.
You have already done your part perfectly by collecting the evidence. I'll do the forensic work on the hexadecimal and certificate information.
We're getting considerably closer to the answer!
Kind Regards,
NonSequitur777
127
9
2
HP Recommended
HP Recommended
Good evening, my friend!
First, please tell your grandson that he has excellent timing -although I'm glad you finally managed to get him to take a nap! And thank you for managing to get these results while keeping the peace. They are extremely helpful.
And I have to say, we're finally getting a very clear picture of what is happening.
Here's what your results tell us
The most important result is:
Confirm-SecureBootUEFI False
That tells us that Windows is currently running with Secure Boot NOT active.
But here's the really interesting part:
PK = present
KEK = present
db = present
dbx = present
BIOS Firmware Type = UEFI
In other words, the UEFI firmware contains all four of the major Secure Boot variables we were looking for.
That is very different from having a completely empty or factory-reset Secure Boot configuration.
And your earlier hexadecimal examination went even further: we actually saw legitimate HP Secure Boot PK and KEK certificates, as well as a Microsoft KEK certificate.
So we can now say with considerable confidence:
The Secure Boot keys have not simply disappeared.
And the Get-SecureBootPolicy error makes sense
You received:
Secure Boot policy is not enabled on this machine.
That is consistent with the Confirm-SecureBootUEFI result of False.
It does not mean that the PK, KEK, db and dbx variables are missing.
It means that Secure Boot is not presently being enforced by the firmware.
That distinction is extremely important.
So, where does that leave us?
We now have a very interesting discrepancy:
UEFI Secure Boot key infrastructure: PRESENT
UEFI boot mode: PRESENT
Secure Boot currently active: NO
That is actually good news from a troubleshooting standpoint because we've eliminated several possibilities.
At this point, I do NOT want you clearing Secure Boot keys, restoring security keys, reinstalling Windows, rebuilding the BCD, or making any other major changes.
We've collected enough evidence that I want to compare it against exactly what the HP BIOS is reporting.
One thing I need from you next:
Please restart the computer and enter the HP BIOS/UEFI setup.
Then go to the Secure Boot configuration screen and tell me exactly what it currently says for:
- Secure Boot
- Legacy Support / CSM
- Platform Key (PK)
- Key Management, if shown
- Any option concerning "Restore Factory Keys", "Install Default Keys", or similar
Please don't change anything yet.
Just record exactly what the BIOS says.
If you can take a photograph of that BIOS screen and post it here, even better.
Why am I being so cautious?
Because we now have evidence that the firmware contains valid Secure Boot keys, while Windows reports that Secure Boot is not active. I want to determine whether the HP firmware is simply configured with Secure Boot disabled, or whether we're dealing with the same BIOS "Platform Key: Not Enrolled" discrepancy we've been investigating.
Once we see those BIOS settings, we'll know which direction to go.
And, my friend, this is real progress. We aren't guessing anymore. We have established that the underlying UEFI Secure Boot variables are populated and that the machine is genuinely booting in UEFI mode.
Now we need to find out why the firmware isn't actually putting that Secure Boot configuration into enforcement.
Enjoy that grandson nap whilst it lasts!
Kind Regards,
NonSequitur777
127
9
2
HP Recommended
Hey My Friend. Well, I'm FREE! Grandson is with Mom and I have a photo of my Secure Boot Configuration for you. Tried doing a "screenshot" but, that didn't go too well. So, I captured a pic with my phone. I hope it's okay, if not, I'll attempt another. Here it is:
Feel free to touch base later....I'll be up awhile. Alright, look to hear from you soon!!
HP Recommended
Good evening, my friend!
YES — the photograph is absolutely good enough! And now that you're finally FREE from grandson duty, we can put the detective hat back on.
I can read the important part of the screen, and this is a very interesting development.
What your HP BIOS is telling us:
The highlighted setting appears to be:
Legacy Support Disable and Secure Boot Enable
That is exactly the configuration we want for a normal Windows 11 UEFI/Secure Boot installation.
And this is consistent with what we already know:
BIOS Firmware Type: UEFI
PK: Present
KEK: Present
db: Present
dbx: Present
So the basic Secure Boot infrastructure is there.
But we have one very important contradiction:
HP BIOS: Secure Boot configured for Enable
Windows: Confirm-SecureBootUEFI = False
And that's precisely the discrepancy we need to solve.
I DON'T want you to change anything in the BIOS yet
Please leave everything exactly as it is.
In particular, do not select "Clear Secure Boot Keys," "Restore Factory Keys," or any similar option.
We've already established that the existing PK/KEK databases contain legitimate HP/Microsoft certificates.
There is no reason to erase them while we're still diagnosing the situation.
I want one final, very targeted test
Boot back into Windows and open PowerShell as Administrator.
Please run these two commands:
Get-SecureBootUEFI -Name SecureBoot
and:
Get-SecureBootUEFI -Name SetupMode
Then paste the results here.
These are much more important to us now than another giant hexadecimal dump.
We're specifically asking the firmware two questions:
1. SecureBoot:
Is the firmware's Secure Boot state actually set to enabled?
2. SetupMode:
Is the firmware operating in Secure Boot "Setup Mode", where the platform isn't enforcing the enrolled PK in the normal way?
That is particularly interesting in your case because we have already proven that a PK exists, yet Windows says Secure Boot isn't active.
And here's why I'm excited about this:
We now have enough evidence to narrow the problem considerably.
We know:
UEFI boot: ✅
PK exists: ✅
KEK exists: ✅
db exists: ✅
dbx exists: ✅
HP Secure Boot certificates present: ✅
Secure Boot currently reported by Windows: ❌
So, we're no longer asking: "Are the Secure Boot keys missing?"
We have essentially answered that question: No.
The question now is:
Why does the firmware have a valid Secure Boot key hierarchy, and apparently have the BIOS configured for "Legacy Support Disable and Secure Boot Enable", yet Windows reports that Secure Boot is not actually active?
That's a much narrower -and much more interesting- problem.
And my friend, please don't worry about understanding what any of this means.
You have already demonstrated the most important skill here: you know how to collect the specimen and bring it back to the lab.
I'll continue doing the analysis.
Run those two commands and send me exactly what they return.
We're getting very close now!
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