BIOS Update Requested - Failing Attestations

[kcraven7]

Hi,

I'm requesting a BIOS update for the HP OMEN Obelisk Desktop 875 baseboard 84FD, current BIOS version F.35, December 2023, AMI firmware.

The issue is that the current BIOS does not write standard TCG PC Client Specification event types into Platform Configuration Register 7 (PCR 7) of the TPM 2.0 measured boot log. Specifically, the firmware produces zero EV_EFI_VARIABLE_DRIVER_CONFIG (type 0x80000001) events and zero EV_EFI_VARIABLE_AUTHORITY (type 0x8000000A) events in the TCG log. Instead, the BIOS records a single vendor-specific event (type 0x800000E0) on PCR 7 containing certificate data.

Secure Boot itself is functioning correctly — signatures are verified, the 2023 Secure Boot certificates are fully applied, and Windows confirms Secure Boot is enabled. However, because the TCG log uses a non-standard event format, third-party software that performs attestation by parsing the measured boot log (per the TCG spec) cannot verify that Secure Boot was active during boot. This is currently preventing me from accessing features in Call of Duty that require attestation via the RICOCHET Anti-Cheat Secure Attestation Wizard.

I've confirmed this by extracting and analyzing the TCG boot log from the TPM. A compliant UEFI firmware should measure the SecureBoot, PK, KEK, db, and dbx variables into PCR 7 using EV_EFI_VARIABLE_DRIVER_CONFIG events before the separator, per the TCG PC Client Platform Firmware Profile Specification. The HP OMEN 875 firmware does not do this.

I'm asking HP to release a BIOS update for board 84FD that implements standard TCG 2.0 Secure Boot event logging in PCR 7. This is a spec compliance issue, not a feature request.

System details:
- Product: OMEN by HP Obelisk Desktop 875
- Baseboard: 84FD
- BIOS: F.35 (AMI), December 2023
- CPU: Intel Core i7-8700
- TPM: Intel PTT, firmware version 403.1.0.0
- OS: Windows 11, build 26200
- Secure Boot: Enabled, Windows UEFI CA 2023 applied

Please escalate this to the firmware engineering team. I'm happy to provide the raw TCG boot log binary for analysis.

Thank you.

[NonSequitur777]

@kcraven7,

Interesting -I have not found additional reports that specifically identify the OMEN Obelisk 875 (84FD) and explicitly mention the absence of EV_EFI_VARIABLE_DRIVER_CONFIG and EV_EFI_VARIABLE_AUTHORITY events in the TCG log, there are a growing number of reports from HP gaming-system owners describing what appear to be related attestation and Secure Boot interoperability problems. These reports often arise when games or anti-cheat systems attempt to validate TPM/Secure Boot state.

Examples include:

• An OMEN 30L owner requesting a BIOS update due to a TPM attestation failure preventing access to Call of Duty ranked play despite TPM and Secure Boot being enabled.
• An OMEN 25L owner reporting a similar TPM attestation error and requesting a BIOS update for the motherboard.
• An OMEN Max 16 owner reporting that Secure Boot appeared enabled, yet attestation tools reported a PCR mismatch (PcrsMatchTcgLog = false) and Call of Duty attestation failed.
• Another OMEN Obelisk 875 owner reporting that Secure Boot was enabled and keys were enrolled, but software relying on Secure Boot verification still failed.

What's particularly interesting is the OMEN Max 16 report mentioning "PcrsMatchTcgLog = false". That is not proof of the same firmware behavior you described, but it does suggest at least some HP gaming systems have encountered measured-boot or TCG-log-related interoperability issues with attestation systems.

There is also evidence that HP has published advisories for TPM attestation failures on certain OMEN and Victus gaming systems, although those advisories concern a known AMD fTPM firmware issue rather than TCG event-log formatting.

From a firmware-engineering perspective, your complaint is actually more specific than most of these reports.

For example, most users are saying:

"TPM attestation fails even though TPM and Secure Boot are enabled."

You are instead proposing a concrete root cause:

The firmware extends PCR 7 using a vendor-specific event type rather than logging the standard TCG Secure Boot variable measurements expected by attestation software.

I have not found a public HP thread where another user independently documented that exact PCR 7 event-format issue on the 84FD platform. However, I would characterize your report as fitting into a broader pattern of HP gaming users reporting TPM attestation, Secure Boot verification, PCR mismatch, and anti-cheat attestation failures despite apparently correct firmware configuration.

If your TCG-log analysis is correct, it could potentially explain at least some cases where users see:

• Secure Boot = enabled
• TPM = healthy
• Windows = compliant
• Anti-cheat attestation = failed

even though the underlying cause may not be obvious from the operating system's perspective. That would make your report considerably more actionable for firmware engineers than the typical, quote: "Secure Boot is on but the game says it isn't" complaint...

Anyway, based on your description, this does not appear to be a Secure Boot failure. Rather, you are reporting that the firmware's measured boot log does not record the standard TCG-defined Secure Boot variable events that some attestation software expects to find when validating the boot chain.

From what you've described:

• Secure Boot is enabled and functioning.
• The TPM is extending PCR 7.
• The firmware appears to be using a vendor-specific event type instead of the standard EV_EFI_VARIABLE_DRIVER_CONFIG and EV_EFI_VARIABLE_AUTHORITY event types that many attestation tools expect.
• The issue affects third-party attestation validation rather than Windows Secure Boot operation itself.

Unfortunately, HP Community members such as myself and moderators do not have a mechanism to directly escalate firmware change requests to the BIOS engineering team, nor can anyone here commit to a future BIOS release for a platform of this age.

A few suggestions:

1. Open a formal HP support case* and include:
   • The raw TCG boot log.
   • Your PCR 7 analysis.
   • The exact BIOS version (F.35).
   • Evidence showing the discrepancy between the measured boot log and the TCG PC Client specification requirements.
2. If the attestation failure is specific to a game or anti-cheat platform, consider opening a support ticket with the game vendor as well. They may already be aware of firmware implementations that use vendor-specific PCR 7 event formats and may be able to determine whether their attestation logic can accommodate them.
3. If possible, compare the TCG log against a system from another OEM that successfully passes the same attestation workflow. A side-by-side comparison of the EV_EFI_VARIABLE_* measurements may help demonstrate the interoperability issue.

One question that may help narrow the scope of the issue: does the attestation failure occur only with the RICOCHET Secure Attestation Wizard, or have you observed the same behavior with other measured-boot attestation tools that validate PCR 7 against the TCG event log?

Given the level of analysis you've already performed, providing the raw TCG log and a decoded event listing alongside the applicable TCG specification references would likely give HP engineering the best chance of evaluating whether this is a firmware compliance issue or an intentional implementation choice by the BIOS vendor.

* As to how to open a formal HP support case, I'll follow up in a separate post.

Kind Regards,

NonSequitur777

[NonSequitur777]

@kcraven7,

OK, for a firmware-related issue like the one you described, the user (you) would typically need to go through HP's official support channels rather than the HP Community forum. HP's support portal allows users to identify their product, create a support case (where available), and track case status.

I would suggest something along these lines:

1. Go to HP Support: HP Support Contact Page

2. Sign in with an HP account (or create one if necessary).
3. Identify the system using the serial number and product number.
4. Select the support/contact options available for the product. Depending on region, warranty status, and product type, HP may offer chat, phone, or case-creation options.
5. When opening the case, provide:
   • Product: OMEN by HP Obelisk Desktop 875
   • Baseboard: 84FD
   • BIOS: F.35
   • TPM version and firmware version
   • A concise description of the PCR 7 / TCG event-log issue
   • The raw TCG log file
   • Screenshots or decoded-event analysis showing the absence of EV_EFI_VARIABLE_DRIVER_CONFIG and EV_EFI_VARIABLE_AUTHORITY events
6. Emphasize that:
   • Secure Boot is functioning.
   • TPM is functioning.
   • The concern is a potential interoperability/specification-compliance issue affecting measured-boot attestation.
   • The request is for engineering review, not standard troubleshooting.

One thing I would caution you about: because the OMEN Obelisk 875 is an older platform, first-line support personnel may initially treat this as a software or gaming issue. The most effective approach is usually to provide a concise technical summary and supporting evidence rather than leading with the Call of Duty symptom. The firmware-behavior description is much more likely to reach the appropriate engineering review path based on my observations.

I would also encourage you to attach both:

• The raw measured-boot log (binary format).
• A decoded version highlighting the PCR 7 entries and the vendor-specific 0x800000E0 event.

That should give HP's firmware team something concrete to analyze if your case is escalated beyond front-line support.

Good luck and Smooth Sailing!

NonSequitur777

[AP-retro]

This BIOS update needs to happen. I'm now out of 100s of dollars and unable to play my favorite game....All because of some sloppy BIOS code. I love my PC and it has outlived its life by leaps and bounds, but if this is what causes me to get a new one than it definitely won't be another HP Omen. Which is f'ing sad because I love this thing. It still has so much life left 10+ years in. Will probably end up a media center and my new PC will be anything that isn't HP. You have 1 month from today. Clock starts now. Thanks for starting my kids summer off so crappy. Drop the update.

[Donlullo73]

100% Agree. This is my 2nd Omen and this is pretty annoying, so probably my last.

[Donlullo73]

Found out more with help of Claude:

This is a firmware spec-compliance issue, not a game/software support request — please route to firmware engineering.

BIOS firmware bug — PCR0 not logged per TCG spec, breaks Remote Attestation (OMEN MAX 16-ah0xxx, baseboard 8D41, BIOS F.22)

Summary
On the OMEN MAX Gaming Laptop 16-ah0xxx, the Insyde BIOS (F.22, 29-04-2026) does not produce a TCG measured-boot event log that matches the actual PCR0 value in the TPM. As a result, Microsoft Azure Attestation (and any application relying on Remote Attestation, e.g. RICOCHET Anti-Cheat) cannot fully attest the platform.

Evidence (Windows 11, Build 26200 — TPM-WMI Event ID 1041, Attestation Readiness Verifier):
- HealthStatus: "Possibly attestable"
- PcrsMatchTcgLog: false
- BitMaskOfPcrMismatches: 1 → PCR0 mismatch
- SoftwarePcrReplayHresult: 0, HardwarePcrReplayHresult: 0 (replay succeeds mechanically; this is a content mismatch, i.e. missing/incorrect PCR0 event logging by firmware)
- EkCertIsAvailable: true, TcgLogFound: true, SecureBootEnabled: true (verifiable from TCG log)
- Bitlocker PCR7 Binding State: Binding Possible

This rules out user configuration: TPM 2.0 (Intel PTT), Secure Boot, UEFI, GPT and PCR7 are all correct. The defect is that the firmware does not measure/log all PCR0 (platform firmware) events into the TCG event log per the TCG PC Client Platform Firmware Profile Specification, so the log replay does not reproduce PCR0.

System details
- Product: OMEN MAX Gaming Laptop 16-ah0xxx
- SKU: B9EY6EA#ABH
- Baseboard: 8D41
- BIOS: Insyde F.22 (29-04-2026), Embedded Controller 38.46
- CPU: Intel Core Ultra 9 275HX
- TPM: Intel PTT (INTC), fw 700.19.1005.2175, PC Client 1.04, Spec 1.59
- OS: Windows 11 Home, Build 26200

Request
Please release a BIOS/firmware update for the OMEN MAX 16-ah0xxx (baseboard 8D41) that correctly measures and logs all PCR0 platform-firmware events into the TCG event log per the TCG PC Client Platform Firmware Profile Specification, so that measured-boot replay matches PCR0 and Remote Attestation (MAA) succeeds. Other OEMs have already shipped equivalent fixes for this exact issue.

[Hiabst]

On the OMEN by HP Obelisk Desktop 875-0xxx, the BIOS (F.35 Rev.A, 2023-12, latest available) does not produce a TCG measured-boot event log that reproduces the platform-firmware PCR values in the TPM. As a result, Windows measured-boot log replay fails and any application relying on Remote Attestation (e.g. Microsoft Azure Attestation, and RICOCHET Anti-Cheat in Call of Duty) cannot fully attest the platform. This is the same class of defect  on newer models (e.g. OMEN MAX 16-ah0xxx, baseboard 8D41).

Evidence (Windows 11 Home, Build 26200)

1. - TPM Endorsement Key certificate IS present and valid: Get-TpmEndorsementKeyInfo returns IsPresent=True, Issuer CN=www.intel.com, "TPM EK intermediate for CNL_EPID_POST_B1LP_PROD_2", O=Intel. So this is NOT a missing-provisioning problem.
2. - tpmtool getdeviceinformation reports: TPM 2.0 present/ready/attestable=True, Secure Boot enabled, but "BitLocker PCR7 Binding State: Binding not possible".
3. - PCR7 "Binding not possible" indicates the Secure Boot / platform-firmware measurements are not logged into the TCG event log per the TCG PC Client Platform Firmware Profile Specification, so measured-boot replay does not reproduce the firmware PCRs.
4. - This rules out user configuration: TPM 2.0 (Intel PTT), Secure Boot, UEFI, GPT are all correct and verified.
5. - Intel CSME firmware is fully up to date (12.0.97.3000, Consumer H) – confirming the issue is in the HP BIOS platform-firmware logging, not the ME.

System details

1. - Product: OMEN by HP Obelisk Desktop 875-0xxx
2. - Baseboard: 84FD
3. - BIOS: F.35 Rev.A (2023-12-19/29) – latest available for this board
4. - CPU: Intel Core i7-8700
5. - TPM: Intel PTT (INTC), spec 2.0 (1.38), PC Client 1.03, ManufacturerVersion 403.1.0.0
6. - CSME: 12.0.97.3000 Consumer H
7. - OS: Windows 11 Home, Build 26200

Request

1. Please release a BIOS/firmware update for the OMEN Obelisk 875-0xxx (baseboard <84DA>) that correctly measures and logs all platform-firmware events into the TCG event log per the TCG PC Client Platform Firmware Profile Specification, so that measured-boot replay reproduces the firmware PCRs and Remote Attestation (and BitLocker PCR7 binding) succeeds. Thank you.

[NonSequitur777]

@Nal_NR,

Do you have any updates regarding the OMEN by HP Obelisk Desktop 875-0xxx platform?

Kind Regards,

NonSequitur777

[Nal_NR]

@NonSequitur777 I am afraid there are currently no newer BIOS updates available from HP for this model.

This platform appears to have reached the mature/end-of-support stage of its product lifecycle, which is likely why no additional BIOS releases have been published.

Based on the product information shared, the latest BIOS version (Windows 11) was released on September 7, 2023, and no newer BIOS updates have been released since then.

[Donlullo73]

3 years for an HP laptop to go out of firmware support is very fast for top brand laptops! My laptop is a 5090 model, new, top model… but I am also not seeing support on this topic.  The fix has been laid out to you and once fixed for newer models its an easy fix for these models as well. 

I really expect more from a brand like HP, this is very concerning