TPM 2.0 and Secure Boot let anti-cheat verify that Windows started through a trusted boot chain: Secure Boot rejects unapproved early code, while TPM attestation gives the server signed evidence of that state. The TPM can also expose a hardware-rooted endorsement key, but requiring both features does not prove a game uses that key for bans. The difference between a launch gate and an identity anchor is the part most explanations miss.
What your game is actually asking for
Activision lists Black Ops 7's TPM and Secure Boot requirement alongside the same requirement for Call of Duty: Warzone. It says its other currently available Call of Duty titles do not require both. Battlefield 6, which set the precedent, also requires TPM 2.0 and Secure Boot through EA AntiCheat. Epic applies Secure Boot, TPM, and IOMMU to Fortnite tournament play rather than regular matches.
These checks answer a narrow question before the game opens: did this PC boot through a configuration the publisher accepts? They do not, by themselves, say why an account was banned or reveal which hardware fields an enforcement record contains.
The prerequisite chain causes most setup trouble. Secure Boot expects UEFI firmware mode, and a Windows system booting in UEFI normally needs its system disk partitioned as GPT rather than MBR. A PC can contain TPM 2.0 hardware yet still fail the launch check because Windows is using Legacy BIOS mode, Secure Boot keys are not enrolled, or the measured boot state does not match policy.
Publishers are raising this floor because a boot-time driver or bootkit can load before a game and position itself below later security checks. The game still uses the kernel drivers these checks sit on top of, but it now asks for evidence about what happened before those drivers began trusting Windows.
Secure Boot in one page
Secure Boot is a UEFI signature policy. The Platform Key (PK) establishes who controls the platform. Key Exchange Keys (KEKs) authorize changes to the allowed signature database (DB) and the forbidden or revoked signature database (DBX). During startup, UEFI checks bootloaders and other pre-OS components against those trust records before allowing them to run.
For anti-cheat, the useful result is that an unsigned or revoked driver cannot quietly load before Windows and sit underneath a kernel-level monitor. A known-bad component can also be denied through DBX even if it once had a valid signature. That closes one route used by bootkits and early-loading drivers.
Secure Boot has a limit. It tells firmware what was permitted to load; it does not continuously describe every process, driver, or memory change after startup. Windows can expose a Secure Boot State value, but a local API result is still a claim made by the machine being inspected. Code with enough control could interfere with that reporting path.
This is why an anti-cheat does not have to accept a simple “On” flag. Secure Boot supplies the policy boundary, while Measured Boot records what actually passed through the boot chain. TPM 2.0 makes that record verifiable outside the PC.
TPM 2.0 in one page
A TPM is a protected place for cryptographic keys and boot measurements. A discrete TPM (dTPM) is a separate chip on the motherboard. AMD fTPM and Intel PTT provide the same TPM interface through platform firmware, which is the form many consumer PCs use. For an anti-cheat attestation check, both can hold keys and sign a statement about boot state.
The root identity is the Endorsement Key (EK), backed by an EK certificate from the TPM or platform manufacturer. An Attestation Key (AK) can be created to sign proofs without exposing the EK directly on every request. The verifier can validate the key relationship and decide whether it trusts the platform that produced the statement.
Clearing a TPM resets owner-controlled material and storage hierarchies. It does not mint a replacement EK.
On firmware TPM implementations, the protected seed is tied to the platform implementation, commonly with CPU-derived material. Software does not rewrite that manufacturing root in the way it can rewrite an operating-system identifier. Any product promising to change the EK deserves suspicion.
Keep these terms separate:
Secure Boot: a UEFI allow-and-revoke policy for code used during startup.
Measured Boot: a sequence of measurements describing what actually started.
Attestation: a signed proof sent to a verifier that applies its own policy.
Endorsement Key (EK): the TPM's manufacturer-rooted identity and the hard limit for software rewriting.
Attestation Key (AK): a TPM-held signing key used to present proofs without routinely exposing the EK.
PCR: a register containing the accumulated result of boot measurements.
fTPM: a firmware implementation such as AMD fTPM or Intel PTT, rather than a separate chip.
Measured Boot: why the game does not trust Windows
A Platform Configuration Register (PCR) behaves like a running hash. Each boot stage measures the next component before handing over control, then extends that measurement into a PCR with an operation such as TPM2_PCR_Extend. Extending combines the old PCR value with the new measurement, so software cannot remove one earlier entry or rewind the register to a convenient state without rebooting.
PCRs 0 through 7 commonly describe parts of the firmware, option ROMs, Secure Boot policy, and the bootloader. They are compact results, not a readable diary of every event. An accompanying measurement log lets a verifier replay the sequence and check that it produces the quoted PCR values.
When RICOCHET or another verifier requests attestation, TPM2_Quote signs selected PCR values with an Attestation Key. A fresh challenge can be included so an old clean quote cannot simply be replayed. The server receives cryptographic evidence tied to a TPM-held key instead of trusting a Windows API that local code might have hooked.
That sequence explains the user-facing “Failed Attestation Status” named in Activision's support material. Its Secure Attestation Wizard is checking more than whether a settings screen says TPM 2.0 and Secure Boot are enabled. Firmware state, enrolled keys, boot measurements, and the verifier's accepted policy all have to agree.
Attestation still does not prove that a player has never cheated. It proves a narrower property: this boot produced measurements that the verifier accepts and a trusted TPM signed them. Runtime detection, account evidence, and enforcement remain separate systems.
Where the TPM actually fits into a hardware ban
A launch gate and a ban anchor solve different problems. A launch gate refuses to start unless TPM 2.0, Secure Boot, and an accepted quote are present. An identity anchor uses a stable key or certificate as part of the machine record consulted during later enforcement. A publisher can implement the first without documenting or using the second.
The familiar hardware-ban composite can contain the SMBIOS/BIOS serial and motherboard UUID, a physical disk firmware serial, a filesystem volume serial (VolumeID), a NIC MAC address, and MachineGuid at HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid. TPM 2.0 endorsement-key material and Secure Boot state occupy a different trust layer.
See the full map of what anti-cheat reads for the device interfaces and read paths. The practical point here is that the classic composite fields are rewritable, while the EK is not.
TraceX Spoofer rewrites the supported identifiers in that classic composite as a permanent, one-time change. You run TraceX once, keep the rewritten values, then delete the tool. It does not rewrite the TPM endorsement key, and this page does not imply otherwise.
If a title only uses TPM and Secure Boot as its launch gate, the unchanged EK does not automatically become the ban key. If a publisher truly anchors enforcement to that EK, software cannot replace it. Understanding how a hardware ban is recorded and enforced keeps a signed boot proof separate from the account-side ban decision.
The same boundary matters when weighing replacing parts versus rewriting identifiers. Replacing an SSD does not replace a motherboard TPM, while changing a rewritable composite does not erase an account record or manufacture a new EK.
How to check your state without breaking your boot
Check Windows before changing firmware. The labels below are vendor-neutral, and they expose the dependency that motherboard menu guides often hide.
Press
Win + R, runtpm.msc. Read the Status line and Specification Version; the version must say 2.0.Press
Win + R, runmsinfo32. Read BIOS Mode, which must be UEFI rather than Legacy, and Secure Boot State, which must be On.If BIOS Mode reads Legacy, Secure Boot cannot be enabled until the system disk is converted to GPT. Back up first.
mbr2gptis Microsoft's conversion tool, and a failed conversion can leave the machine unable to boot.If the TPM is absent, look for fTPM on AMD systems or PTT on Intel systems in firmware setup. The platform implementation may exist but be switched off.
Enable Secure Boot in firmware setup only after confirming UEFI and GPT. Some boards require their standard Secure Boot keys to be enrolled or require Setup Mode to be left first.
After rebooting, run
msinfo32again and confirm Secure Boot State reads On. If the game still reports failed attestation, a boot component may fall outside the accepted policy; a leftover unsigned driver is a common cause.
Do not clear the TPM as a ban fix. It can invalidate keys used by Windows security features and does not replace the EK. Do not convert MBR to GPT without a recoverable backup. Those operations affect boot and stored credentials, while neither guarantees that a game's attestation policy will accept the next startup.
Where this is going
Secure Boot handles the approved boot chain, TPM attestation supplies proof, and IOMMU closes a different hole: direct memory access from a PCIe device that can bypass normal CPU-controlled paths. Epic's Fortnite tournament requirement now names that trio. HVCI can add another Windows isolation boundary, but it does not replace any of the three.
Expect more publishers to treat platform trust as an eligibility check while keeping runtime detection and account enforcement separate. Riot Vanguard, EA AntiCheat, and RICOCHET differ in policy, so a requirement in one title should not be projected onto every protected game. Linux and Steam Deck compatibility also depends on whether their boot and attestation path can satisfy the publisher's policy.
Your decision comes down to the signal that is actually blocking you. Fix UEFI, GPT, Secure Boot, or attestation when the game is rejecting the boot state. If a confirmed HWID ban is keyed to the rewritable composite rather than an EK anchor, you can rewrite the identifiers a ban is actually keyed to once, keep the permanent change, and delete TraceX afterward. No firmware bypass or TPM promise belongs in that answer.