Skip to content

Raspberry Pi 5 TPM 2.0 Module Selection Guide

Choose a Raspberry Pi TPM module by its exact chip, electrical requirements, Linux kernel driver, and documented Device Tree integration—not by a product title that merely says “TPM” or “security module.” Raspberry Pi 5 has no built-in discrete TPM, so compatibility must be proven for the external module and current kernel.

Purchase checklist

Do not order until the seller or manufacturer documentation answers all of these:

  • Is it a discrete TPM 2.0, rather than TPM 1.2 or only a secure element?
  • What is the exact chip and hardware revision?
  • Does the board use SPI, I2C, or another interface?
  • Are logic and supply voltages compatible with Raspberry Pi's 3.3 V GPIO?
  • Which Linux driver binds the chip?
  • Is a Raspberry Pi Device Tree overlay supplied and maintained?
  • Does the board conflict with an NVMe HAT, fan, display, or other GPIO hardware?
  • Does it expose /dev/tpmrm0 on the intended Raspberry Pi OS/kernel?
  • Is ownership/provisioning documented without requiring closed software?
  • Can the module be physically replaced, and what is the recovery plan when it fails?

TPM, secure element, and hardware security module

Device class Typical strength Typical limitation
TPM 2.0 Standard commands, PCRs, sealing policies, quotes, key objects Requires supported bus/driver and a measurement design
Secure element Protected device identity and signing keys Usually lacks TPM PCR/policy semantics
USB security token Portable user authentication, FIDO2 or smart-card functions Not a platform-measurement TPM
General HSM Central or high-assurance key operations Often excessive for one Raspberry Pi and may require a service

Use a TPM when software expects TPM2 APIs, PCR policies, or attestation. Use a secure element when the requirement is primarily a non-exportable device identity. Do not substitute them without checking the application protocol.

SPI versus I2C

Criterion SPI TPM I2C TPM
GPIO usage Clock, MOSI, MISO, chip select plus optional interrupt/reset SDA, SCL plus optional interrupt/reset
Bus sharing Separate chip selects can share the controller Devices share addresses on one bus
Linux binding Commonly a TPM TIS SPI-family driver for compatible chips Requires the exact I2C-compatible driver/ID
Common conflict Display, ADC, or HAT already using SPI/chip select Address collision or bus electrical problem
Selection rule Verify chip select, maximum bus rate, and overlay Verify address, voltage, pull-ups, and overlay

Interface type alone does not guarantee compatibility. The Linux TPM FIFO/TIS driver family covers standardized interfaces, but the chip still needs a matching compatible string and transport driver. See the Linux TPM TIS driver documentation.

Audit the Raspberry Pi before buying

Identify the board and OS:

1
2
3
cat /proc/device-tree/model
cat /etc/os-release
uname -a

List active overlays and bus declarations:

1
2
grep -nE '^[[:space:]]*(dtparam|dtoverlay)' /boot/firmware/config.txt
dtoverlay -l

Inspect GPIO consumers where debugfs is available:

1
2
sudo cat /sys/kernel/debug/gpio 2>/dev/null
ls -l /dev/i2c-* /dev/spidev* 2>/dev/null

Make a pin/bus map for every connected HAT and cable. Stacking mechanically compatible boards can still create chip-select, interrupt, reset, or power conflicts.

What good vendor documentation contains

A supportable module should provide:

  1. Schematic or complete pin assignment
  2. Exact TPM chip and revision
  3. Supply and logic-voltage limits
  4. Linux driver/compatible string
  5. Device Tree source or named upstream overlay
  6. Tested Raspberry Pi models and OS/kernel versions
  7. /dev/tpm0 and /dev/tpmrm0 verification steps
  8. TPM provisioning, firmware-update, and reset guidance
  9. Hardware errata and support lifecycle

A wiring diagram without a kernel-binding procedure is incomplete. A custom binary image without source or a documented update path creates maintenance risk.

Installation safety

  1. Shut down with sudo systemctl poweroff.
  2. Disconnect power and wait for activity to stop.
  3. Confirm module orientation and pin 1.
  4. Never apply 5 V to a 3.3 V logic pin.
  5. Install only the overlay supplied for the exact board/chip.
  6. Boot with local-console recovery available.
  7. Inspect kernel binding before running TPM provisioning commands.

Do not create a guessed Device Tree overlay from a generic chip name. Reset, interrupt polarity, chip-select, bus frequency, and compatible strings can differ by module revision.

Enable the required controller

Use Raspberry Pi's supported configuration tool for the bus, then apply the module manufacturer's overlay instructions:

1
sudo raspi-config

For SPI, enable SPI under Interface Options. For I2C, enable I2C. Reboot when requested.

Enabling the controller is only the first layer. A working TPM should be claimed by a TPM kernel driver; it should not remain merely as a generic userspace SPI/I2C device.

Verify kernel detection

Check boot messages and device nodes:

1
2
3
journalctl -k -b --no-pager | grep -iE 'tpm|tis'
ls -l /dev/tpm* 2>/dev/null
ls -l /sys/class/tpm 2>/dev/null

Inspect the driver link:

1
readlink -f /sys/class/tpm/tpm0/device/driver 2>/dev/null

Install diagnostic tools only after a TPM device appears:

1
2
3
4
5
6
sudo apt update
sudo apt install tpm2-tools
tpm2_getcap properties-fixed
tpm2_getcap algorithms
tpm2_getcap pcrs
tpm2_selftest --fulltest

The tpm2_getcap reference lists capability groups. Save the output with the module and OS version, but review identifiers before publishing it.

Detection evidence hierarchy

Evidence What it proves
Controller enabled Raspberry Pi bus driver loaded
Address responds or SPI device exists Something may be electrically reachable
Kernel log names TPM driver Driver attempted or completed binding
/dev/tpm0 exists Raw TPM interface registered
/dev/tpmrm0 exists Kernel TPM resource manager registered
tpm2_getcap succeeds TPM2 command path and TCTI work
Self-test and repeatable PCR reads succeed Basic device operation works

An I2C address scan can disturb some devices and cannot identify a TPM securely. Use the vendor's documented address and kernel binding as the primary test.

Record a compatibility result

Publish a reproducible record instead of “works on Raspberry Pi”:

Field Value
Raspberry Pi model/revision
Raspberry Pi OS and kernel
TPM module/chip/revision
Interface and pins
Overlay name/source/version
Driver name
/dev/tpmrm0 present
TPM manufacturer/firmware properties
Self-test result
Other HATs and conflicts tested
Cold-boot repetitions
Raw diagnostic log

Do not publish endorsement certificates, private keys, authorization values, or unreviewed unique identifiers.

TPM provisioning boundaries

Detection does not require clearing or taking destructive ownership actions. Before provisioning:

  • determine whether the TPM is new, reused, or already protects data
  • back up every recovery credential
  • inventory persistent and NV handles
  • understand vendor firmware-update requirements
  • document who owns authorization values
  • test on a non-production module

Never use tpm2_clear as a generic “initialize” step. It can invalidate sealed secrets and make encrypted data inaccessible.

Failure and replacement planning

Assume the module or GPIO connection will eventually fail. For each protected secret decide:

  • whether a passphrase/recovery slot exists
  • where the offline recovery material is held
  • how an administrator proves authorization
  • how the failed TPM token is removed
  • how the replacement is enrolled
  • how recovery is audited and tested

A soldered or enclosed module may resist casual removal but can increase repair time. A pluggable module is serviceable but easier to replace physically. The right choice follows the threat and availability model.

Common purchase mistakes

  • Buying TPM 1.2 for software requiring TPM 2.0
  • Confusing a secure element with a TPM
  • Assuming a PC motherboard TPM header matches Raspberry Pi GPIO
  • Ignoring 3.3 V logic limits
  • Choosing a board with no maintained Linux driver/overlay
  • Forgetting HAT and chip-select conflicts
  • Relying on a product page that omits the actual chip revision
  • Clearing the TPM when initial detection fails
  • Removing recovery credentials after the first successful auto-unlock

FAQ

Which TPM module is best for Raspberry Pi 5?

The best module is the one with an exact TPM 2.0 chip, compatible voltage and form factor, maintained Linux driver and Device Tree support, no bus conflicts, and a replacement/recovery process. A universal product recommendation without those details is unsafe.

Can Raspberry Pi use a PC TPM header module?

Not directly unless its electrical interface, pinout, voltage, transport, and driver all match. PC header layouts are not a Raspberry Pi standard.

Is SPI always faster than I2C for TPM use?

Raw bus speed is rarely the deciding factor because TPM operations are control-plane actions. Driver support, reliable wiring, GPIO conflicts, and boot integration matter more.

Why does /dev/spidev0.0 exist but /dev/tpm0 not exist?

The SPI controller is exposed to userspace, but a TPM driver has not claimed the device. Check the correct overlay, compatible string, chip select, wiring, power, and kernel log.

Should I buy two modules?

For a production design, a tested spare can reduce recovery time, but replacement still requires recovery credentials and re-enrollment. A second module does not automatically contain the first module's keys.