What really is the difference between a physical TPM and any implementation of a fTPM?

I get that both adhere to the same specification and in my mind should be the same thing, but then, I don't understand why there even are 5 or so different types of TPM - discrete, integrated, firmware, virtual, and, well, software, though here the distinction is a little bit more clear - having used one, it really is more like a simulator.

The advantage of a hardware device makes sense in theory -> the EK is literally etched in stone, so as the presence of a EK is required by specification I suppose fTPM just have the key saved somewhere.

Can the claim, that "a physical TPM offers most security" be backed up?

Let's imagine I put 100% trust in a system with a discrete TPM and in this hypothetical world such system is 100% secure. Do I have any reason to trust iTPM/fTPM/vTPM any less and is their purpose by definition the same?

  • 1
    A physical TPM offers most security ....well it's more like it protects by preventing it's own tampering/cloning. If it's not hardware it's easier to tamper with.
    – Overmind
    Jan 26, 2021 at 9:01
  • 1
    It's 90% marketing. even a custom "stone etching" might be vulnerable to glitching/pulsing/timing attacks or de-capping and microscope inspection, etc. Something built on top of an OS will have the attack surface of that OS in addition to vulns of their specific code. Something proprietary sure sounds secure, but it's merely obscure, and it's actual security is hard to determine.
    – dandavis
    Jan 26, 2021 at 20:50

3 Answers 3


It is very hard to quantify security and justify trust. Before you read on: think about what you want to protect against whom. Make a risk analysis.

I have heard mainly two justifications why physical TPMs are more secure.

1) Separation/Isolation

Generally, the better two systems are isolated, the harder it is to spread compromisation. For example, you can hardly attack network #2 from network #1 if they are not physically connected. If they were connected via a firewall, it might be possible, but still hard. The least secure option would be no separation at all.

The same applies to the isolation of the host machine and its TPM. A user-space TPM simulator would hardly be isolated at all and the least secure option. A fTPM is isolated much better, but it's still running on the same chip. A hardware TPM is much more isolated and therefore presumably better protected against software attacks from host malware.

Of course there is a whole variety of hardware attacks which is not affected by this isolation. Again, think about your assets and risks.

2) Certification

Physical TPMs are usually certified. That alone is not a guarantee for security. However, it ensures that certain requirements are met verifiably. Therefore it is evidence at least some level of security.

In particular, the Common Criteria Evaluation takes hardware security against e.g. timing, glitching and side-channel attacks into account. Currently, there are only physical TPMs which are Common Criteria evaluated (see here under Trusted Computing).

  • Thank you for your answer, definitely brings some insight
    – T. Maxx
    Jan 29, 2021 at 9:12

Indeed an appropriately designed and tested discreet TPM (dTPM), utilising a secure cryptoprocessor might be more secure against software attacks, in large due to the separation of function and smaller attack surface.

A recent concern of mine though, is about malicious hardware. In particular, the TPM relies on the CPU to provide the necessary measurements that the TPM then utilises. But, how can these measurement be authenticated to be true? There have been various spoofing attacks through probing the communication bus. Moreover, someone could, hypothetically, even replace the CPU with a malicious one that spoof measurements etc. (a proof-of-concept has been published in an academic paper).

While the TPM's primary purpose might not be to protect against hardware attachs (the well known "if they own the hardware, it's game over"), there could be some ways to provide some mitigations, by somehow "binding" a TPM so the system's configuration, the CPU in particular.

One way would be to utilise Physically Unclonable Functions and extend then into one of the dTPM's PCRs. This has, too, been shown as proof-of-concept in an academic article.

Another way, that doesnt require changes to the current specifications, would be firmware TPM. Assuming that the fTPM actually functions correctly, with the fTPM functions independently from the rest of the CPU etc., then I would say that an fTPM is actually MORE secure than a dTPM, since the Measurement Agent that provides the PCR valus is actually on the same chip and the verifier that verifies said PCRs. Basically, if someone tampers with the CPU, they also tamper with the fTPM inside said CPU, which should, ideally, destroy the secrets.

  • The TPM does not aim to protect against a malicious CPU. If an attacker has physical access to your machine, exchanging the CPU is probably the last they will do.
    – MemAllox
    Feb 23, 2022 at 17:07
  • Indeed the TPM's purpose may not be hardware attack detection/prevention, and I have mentioned that in my answer. But, an fTPM does provide some protection againt e.g. a malicious CPU, since the fTPM is part of the CPU and it's the CPU that actually does the measurements. Claims that dTPMs are more secure aren't quite substantiated... I haven't seen a TPM with EAL5+ etc. (yeah, EAL is better than FIPS, in my opinion). Counterargument: someone may more easily attack the fTPM of the CPU. Reply: If they have managed to subvert my CPU, I won't be saved my the, supposedly, secure dTPM. Feb 23, 2022 at 17:25
  • 1
    Good points. I just read how easy it was to sniff on the SPI so having the option in bios to use firmware TPM instead started to make a lot of sense. Oct 8, 2023 at 16:52

An interesting discussion. There are definitely different levels of assurance that can be calculated and used in a risk assessment related to the type of TPM (i.e., discrete, integrated, firmware, virtual, and, software. What certification is important to that negotiation as well. In the case of FIPS or EAL LOA, there are discrete assurances one can use to measure risk and apply a level of trust. It is not binary, especially in the case of TPM. I have yet to see a reliable assertion wrt to the TPM level(s) of protection(s). So if you a software TPM meets your risk profile, any TPM should be adequate. But what if your risk tolerance demands more assurance, say a discrete HW TPM certified at a particular LOA? I have not witnessed a real-time solution to confirm a particular TPMs LOA.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .