Subscribe to the Non-Human & AI Identity Journal
Home Glossary Authentication, Authorisation & Trust Trusted Platform Module
Authentication, Authorisation & Trust

Trusted Platform Module

← Back to Glossary
By NHI Mgmt Group Updated July 8, 2026 Domain: Authentication, Authorisation & Trust

A Trusted Platform Module is secure hardware that helps protect keys and other credentials on a device. In passwordless models, it supports stronger assurance because the private key is not handled like a shared password and is harder to extract or reuse elsewhere.

Expanded Definition

A Trusted Platform Module, or TPM, is a hardware-based security component that stores cryptographic keys, measures boot integrity, and supports device attestation. In NHI security, it matters because it can anchor device-bound credentials without exposing private keys to normal software access, which is especially relevant for passwordless authentication and machine-to-machine trust.

Usage is still evolving across vendors and operating models. Some teams treat a TPM as a general-purpose key vault, while others rely on it only for device attestation, secure boot validation, or key sealing. That distinction matters: a TPM can strengthen trust in the device state, but it does not by itself replace policy, lifecycle control, or revocation discipline. For broader identity governance, it should be considered one control layer within a larger program informed by NIST Cybersecurity Framework 2.0 and NHI lifecycle practices described in Ultimate Guide to NHIs — The NHI Market.

The most common misapplication is assuming TPM-backed storage makes a credential inherently safe, which occurs when organisations ignore endpoint compromise, attestation failures, or recovery procedures.

Examples and Use Cases

Implementing TPM-backed identity rigorously often introduces device dependency and recovery complexity, requiring organisations to weigh stronger key protection against the operational cost of managing hardware-bound trust.

  • A service account key is sealed to a specific device so the private key cannot be copied into a different host and reused elsewhere.
  • An agentic AI workload uses TPM-backed attestation before receiving a token, ensuring the runtime is on approved hardware rather than an imaged clone.
  • A build runner stores signing material in a TPM to reduce exposure during CI/CD execution, while rotation and offboarding remain controlled through a separate secrets process.
  • A fleet of laptops uses TPM measurements to support device trust decisions, complementing policy checks in NIST CSF rather than replacing them.
  • Security teams reference the NHI exposure patterns described in Ultimate Guide to NHIs — The NHI Market when deciding whether device-bound keys are justified for a specific workload.

Why It Matters in NHI Security

TPM-backed protection reduces the chance that a compromised host can simply extract a reusable secret, but it does not eliminate identity misuse, privilege sprawl, or poor revocation. That is why NHI governance still matters even when hardware security is present. NHIMG reports that 97% of NHIs carry excessive privileges, and that scale of over-permissioning turns a protected key into only one part of a larger exposure problem.

For non-human identities, the practical question is not whether a key can be stored securely, but whether the identity can be attested, rotated, revoked, and recovered without creating blind spots. A TPM can support those goals when paired with policy, telemetry, and lifecycle controls described in Ultimate Guide to NHIs — The NHI Market. It also aligns with the device-trust emphasis in NIST Cybersecurity Framework 2.0, but no single hardware feature should be mistaken for complete identity assurance.

Organisations typically encounter TPM relevance only after a stolen image, leaked signing key, or compromised endpoint forces them to prove whether the device and its credentials were truly trustworthy, at which point TPM-based attestation becomes operationally unavoidable to address.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-01Covers identity trust and device-bound credential protection for non-human identities.
NIST CSF 2.0PR.AAIdentity and authentication outcomes include hardware-backed device trust and credential protection.
NIST Zero Trust (SP 800-207)PE/IAZero Trust depends on validated device and identity signals, which TPMs can strengthen.

Use TPMs as one layer in identity assurance, then enforce rotation, revocation, and monitoring.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on July 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org