Disclaimer: This is the first in a three-part series on how modern platform security is changing anti-cheat. We’ll start with TPM and system trust, then look at the different layers cheats try to exploit, before moving on to what happens when cheating shifts outside those protections and toward behavioral detection.
Anti-cheat has an interesting problem at its core: it is trying to protect a game running on a computer it does not control.
And modern cheats do not necessarily stay inside the game. They can operate deeper in the system, using privileged drivers or manipulating parts of the operating system, move to the hardware level, or even outside the gamer’s PC altogether, for example through computer-vision-assisted cheats running on a second system. At that point, spotting suspicious software is only part of the challenge. There is a more fundamental question: can you trust the environment the game is running in? And the answer, most of the time, is no.
That’s where the Trusted Platform Module, or TPM, becomes relevant.
A TPM does not detect cheats. Instead, it provides the pieces an anti-cheat can use to verify that it is really communicating with a genuine TPM rather than an attacker spoofing TPM measurements. This includes the TPM’s certificate and the measurements it produces during startup. The anti-cheat can then use those measurements to check how the system started.
A TPM is a hardware security component built into modern PCs. It has been part of the Windows security baseline for years: Microsoft has required TPM 2.0 to be enabled by default on new PC models since 2016, and it is now a requirement for Windows 11. With Windows 11 accounting for around three-quarters of Windows systems in Steam’s September 2026 hardware survey, TPM is already part of the environment most PC gamers are using today.
It can generate and protect cryptographic keys, so private keys remain inside the TPM. It also comes with certificates that form a chain of trust back to the manufacturer. That certificate hierarchy allows the TPM’s identity to be verified as coming from a trusted manufacturer, while its unique identity can be used to distinguish one TPM from another.
The TPM also plays an important role during startup. As a PC boots, different parts of the system are measured before they run. Microsoft’s Measured Boot, for example, records measurements of components including the Windows kernel, Early Launch Anti-Malware drivers and boot drivers in the TPM.
The TPM is not deciding whether those components are ‘good’ or ‘bad.’ It is simply keeping a protected record of what was loaded and how the system started.
If something important in the boot process changes, the measurements change too. To understand why, we need to look at how those measurements are created and recorded.
The measurements recorded during startup are created using cryptographic hashes. A hash is essentially a fixed-length fingerprint of some data: change the data, and the fingerprint changes with it.
The TPM uses Platform Configuration Registers, or PCRs, to build a running cryptographic representation of these measurements. Rather than simply replacing one value with the next, each new measurement is combined with the value already there. This creates a chain, where the final PCR value reflects the sequence of measurements that came before it.
For example, if a boot driver changes, that change affects the measurements that follow it, so the final PCR value will be different from the one produced by the expected boot sequence.
Together, those measurements give you a cryptographic picture of how the system booted. The PCR value alone, however, does not tell you what was loaded or in what order. For that, you also need the boot log.
A PCR value on its own is not very informative. It can tell you that the boot process produced a particular result, but not which components were measured along the way.
The boot log fills in that missing context by showing which measurements were taken and in what order. By replaying those measurements and calculating what the PCR value should be, security software can compare that result with the value held by the TPM. If they match, the boot log and the TPM’s protected record are consistent with each other.
Attestation is what makes those measurements useful outside the machine itself. The TPM can provide cryptographic evidence about its current measurements, allowing another system to verify claims about the machine’s state without simply taking the running operating system at its word.
Instead of just trusting what the operating system reports, security software gets evidence it can check for itself.
For anti-cheat, the real benefit is that some low-level tampering becomes much harder to hide.
If a cheat depends on weakening security settings, modifying parts of the boot process or gaining privileged access before the game starts, those changes can affect the measurements the system produces. An anti-cheat can then use that information as part of the decision to allow the game to run, require a security feature to be enabled, or flag the machine for further checks.
It won’t catch every type of cheat, but it makes techniques that rely on compromising the system underneath the game harder and more expensive to pull off. TPM still only covers one part of the problem. Its value becomes clearer when you look at it alongside the other protections built into modern PCs.
TPM is useful, but it is not an anti-cheat system, and it does not make a PC impossible to compromise. Its role is much narrower: helping establish and protect evidence about the state of the machine.
Other technologies protect different parts of the system. Secure Boot helps control what is trusted during startup. VBS and HVCI add stronger isolation around sensitive parts of Windows, while IOMMU can restrict how hardware devices access memory.
The TPM records measurements that reflect the state of these protections. Once the anti-cheat has verified that it is talking to a genuine TPM, it can check those measurements to see whether the required protections are enabled and in the expected state. If they are, the PC passes the trust check.
Each of these technologies protects a different part of the system. None of them stop cheating by itself, but together, they make some attacks completely impossible to pull off.
That is also why they are worth looking at separately. The next articles in this series will go deeper into how those protections work and where they matter most for anti-cheat.
The bigger opportunity is not simply to give anti-cheat more access to a player’s PC. As platform security gets stronger, more of the work can be done by protections already built into the system.
That changes what anti-cheat needs to do. Rather than trying to verify everything itself, it can rely more on security guarantees provided by the platform and focus on the areas those protections do not cover.
Cheating does not disappear as a result. It moves. As some system-level attack paths become harder or more expensive to use, cheat developers look for others.
That is where anti-cheat gets more interesting: once the operating system becomes harder to manipulate, the fight starts moving elsewhere.
Want to explore what this could mean for your own anti-cheat strategy? Reach out to the Denuvo by Irdeto team to learn more.