Somewhere on nearly every modern computer motherboard sits a small, easily overlooked component that most users will never interact with directly, yet it quietly underpins several of the security features Windows now depends on. The Trusted Platform Module, almost always referred to by its abbreviation TPM, is a dedicated cryptographic processor built for one narrow purpose: generating, storing, and protecting encryption keys in a way that ordinary software running on the main processor cannot reach, read, or tamper with. When Microsoft set the minimum requirements for Windows 11, this once obscure component became a mandatory piece of hardware rather than an optional extra, and that decision is worth understanding on its own technical merits.
What a Trusted Platform Module Actually Is Inside a Computer
A TPM is best described as a small, isolated computer within a computer, built specifically to handle sensitive cryptographic operations in a physically and logically separate environment from the main processor and operating system. It can generate random numbers suitable for cryptographic use, create and store encryption keys, produce and verify digital signatures, and perform encryption and decryption, all inside a boundary that ordinary software, including a fully compromised operating system, cannot directly access. This isolation is the entire point of the design: a piece of malware that has gained full administrator control over Windows itself still cannot simply read the private keys sitting inside the TPM, because those keys are never exposed outside the chip in a usable form.
The chip achieves this through a combination of hardware level access control and tamper resistance. Physical protections inside the module are built to resist attempts to extract key material by probing the chip directly, while the module's internal firmware refuses to release private keys through any software interface, regardless of what privilege level the requesting process holds on the rest of the machine. A key generated inside the TPM can be used to sign or decrypt data, but the private half of that key pair generally never leaves the chip at all, which is a fundamentally different security model from software based key storage, where a sufficiently privileged attacker can eventually locate and copy the key file itself.
How the Chip Generates and Protects Cryptographic Keys
Every TPM ships with a permanent, unique identity called an endorsement key, burned into the chip during manufacturing and effectively serving as the module's own cryptographic fingerprint. This key underpins a hierarchy of additional keys the TPM can generate for specific purposes, some tied permanently to that one physical chip and unusable if moved to different hardware, and others created fresh for individual tasks such as encrypting a single disk volume. Because these keys can be cryptographically bound to the specific machine's hardware and firmware state, data protected by a TPM backed key is far harder to recover simply by moving a hard drive to a different computer, since the key needed to unlock that data may refuse to release its output unless the exact original hardware and boot configuration are present.
This binding capability is what security engineers describe as sealing a key to a particular system state. Rather than only asking whether the correct password was entered, the TPM can additionally verify that the machine itself has not been tampered with before agreeing to release a protected key, checking that critical startup components match values recorded during a known good configuration. If those values do not match, perhaps because unauthorized firmware was flashed onto the machine or a boot component was swapped out, the TPM withholds the key entirely, even if every password and credential presented to it is otherwise correct.
Measured Boot and How TPM Detects Tampering Before Windows Loads
The mechanism behind this tamper detection is called measured boot, and it relies on a set of storage locations inside the TPM known as Platform Configuration Registers. As the computer starts up, each stage of the boot process, from the firmware itself through the boot loader and into the earliest stages of the operating system, calculates a cryptographic hash of the next component about to run and records that value into one of these registers before handing control over to it. Because each new measurement is combined with the value already stored rather than simply overwriting it, altering any single component earlier in the chain changes every register value that follows, making tampering anywhere in the sequence immediately detectable by comparing the final values against what a known, untampered boot should have produced.
This process happens before Windows itself has fully loaded, which is precisely why it can catch threats that operate below the level ordinary antivirus software can see, including malicious firmware modifications and boot loader tampering designed specifically to run before any security software gets the chance to start. A machine whose measured boot values do not match expectations can be configured to refuse to release the key needed to decrypt its own storage, effectively locking an attacker out of the data even if they have physical possession of the device and have already modified its firmware or boot sequence.
Why TPM 2.0 Differs From the Older TPM 1.2 Standard
TPM 2.0 replaced the earlier TPM 1.2 specification with a substantially more flexible design rather than simply patching individual weaknesses. The older standard was built around a fixed set of cryptographic algorithms, most notably relying on SHA-1 for hashing, which has since been shown to have practical weaknesses that make it unsuitable for security sensitive applications going forward. TPM 2.0 introduced what is generally described as algorithm agility, meaning the specification is not locked to any single cryptographic algorithm and can support newer, stronger options such as SHA-256 hashing and a wider set of encryption schemes, allowing the standard to remain useful as cryptographic best practices continue to evolve rather than becoming obsolete the moment its original algorithms are broken.
Beyond algorithm support, TPM 2.0 also expanded the range of key types and operations the chip can perform, added support for more flexible authorization policies governing when a key can be used, and improved how the chip interacts with modern firmware based boot environments. These are not cosmetic differences; they directly determine what security features an operating system built on top of the chip can offer, which is why Microsoft treats the version number as a hard requirement rather than a recommendation, since features designed around TPM 2.0 capabilities simply cannot fall back gracefully onto the more limited older standard.
How BitLocker and Windows Hello Rely on the Chip Directly
Two of the most visible Windows security features depend on TPM 2.0 working correctly behind the scenes. BitLocker, the built in full disk encryption feature, uses the TPM to store the key that unlocks an encrypted drive, sealing that key to the machine's measured boot state so the drive can only be decrypted on hardware that has not been tampered with. Without a TPM, BitLocker either cannot be used at all in its default configuration or falls back to weaker protection methods that place more of the security burden on a password the user has to remember and manually enter at every startup.
Windows Hello, the platform's biometric and PIN based sign in system, relies on the same chip for a related but distinct purpose. Rather than storing a copy of a fingerprint, facial scan, or PIN anywhere on the computer that could be copied and reused, Windows Hello uses the TPM to generate and protect the cryptographic keys tied to that authentication method, meaning the actual biometric data or PIN never has to be transmitted anywhere or stored in a form usable outside the specific device it was set up on. This design makes credential theft considerably harder, since an attacker who compromises the operating system cannot simply extract a reusable password equivalent the way they historically could with older, purely software based authentication methods.
Why Microsoft Made TPM 2.0 Mandatory Rather Than Recommended
Microsoft's stated justification for making TPM 2.0 a strict Windows 11 requirement centers on the growing sophistication of firmware and boot level attacks, a category of threat that traditional antivirus software, running only after the operating system has already loaded, is poorly positioned to detect or prevent. By requiring the hardware foundation that measured boot and hardware bound key storage depend on, Microsoft effectively raised the security baseline for every device running the operating system rather than leaving these protections as an optional feature only security conscious users would bother enabling. Independent analysis of Microsoft's own vulnerability disclosures has repeatedly shown that a large share of critical security flaws would be less exploitable, or not exploitable at all, if the underlying hardware level protections a TPM enables were consistently present and properly configured across the installed base of machines.
The requirement was not entirely new when Windows 11 introduced it as mandatory. Microsoft had already required PC manufacturers to ship new Windows 10 machines with TPM 2.0 present and enabled by default starting in the middle of the previous decade, though the requirement was not strictly enforced for the operating system to install and run, leaving many machines with TPM chips that sat disabled in firmware without their owners realizing the capability was available. Windows 11 closed that gap by refusing to install through official channels at all without a working TPM 2.0 present, converting what had been a soft recommendation into an actual precondition for using the operating system as intended.
Discrete Firmware and Pluton Implementations Found in Modern PCs
Not every TPM 2.0 implementation takes the same physical form, and this variation is a common source of confusion for anyone checking whether their machine meets the requirement. Some systems include a discrete TPM, a physically separate chip soldered onto the motherboard or installed into a dedicated header, which offers the strongest level of isolation since it is a completely independent piece of silicon from the main processor. Far more common on modern consumer hardware is a firmware based implementation, where the TPM functionality is built directly into the main processor's chipset rather than existing as a separate physical component, commonly branded as Intel Platform Trust Technology or AMD firmware TPM depending on the processor manufacturer. These firmware implementations meet the same TPM 2.0 specification and provide equivalent functionality for Windows, even though there is no separate chip to point to on the motherboard.
A newer approach, developed jointly with processor manufacturers and branded Pluton, integrates the security processor even more deeply into the main chip itself, aiming to close a category of attack that targets the communication pathway between a discrete TPM and the main processor, since that pathway can theoretically be intercepted even when the TPM chip itself remains secure. Regardless of which implementation a given machine uses, the practical requirement for Windows 11 is the same: a working TPM reporting specification version 2.0, whether that presence comes from a physical chip, firmware built into the processor, or a more tightly integrated security processor design, since Windows itself does not distinguish between these forms when checking whether the requirement has been met.