TPM vs HSM: Architecture, Security Models, and Enterprise Use Cases

TPMs (Trusted Platform Modules) and HSMs (Hardware Security Modules) are both hardware devices that store cryptographic keys and perform security operations in protected hardware. They share a common purpose but are designed for different contexts, operate at different assurance levels, and are not interchangeable in most security frameworks.

For software developers and publishers, the distinction matters most in the context of code signing: the CA/B Forum’s Code Signing Certificate Requirements mandate that code signing private keys be stored on hardware meeting FIPS 140-2 Level 2 standards. Understanding which hardware category satisfies this requirement, and why, directly affects how you manage your code signing certificate.

What Is a TPM?

A Trusted Platform Module is a dedicated security chip that implements the TPM specification maintained by the Trusted Computing Group (TCG). TPM 2.0 is the current standard; TPM 1.2 is its predecessor and is considered legacy. Windows 11 requires TPM 2.0.

The TPM is typically soldered directly onto the motherboard, though firmware TPM (fTPM) implementations built into CPU firmware have become common. Being part of the device, the TPM is not portable: it is tied to the specific machine on which it is installed.

What TPMs do

TPMs perform a specific set of security functions designed around device integrity and local key protection:

• Platform integrity measurement: TPMs measure the boot process through Platform Configuration Registers (PCRs), recording cryptographic hashes of each stage from firmware through operating system startup. This chain of measurements is used by Secure Boot to detect tampering with the boot process.
• Local key storage: Private keys sealed to the TPM are generated and stored within the hardware. BitLocker disk encryption keys, Windows Hello for Business authentication keys, and device attestation keys are examples. These keys cannot be exported from the TPM in usable form.
• Attestation: A TPM can prove to a remote party that it is a genuine TPM of a specific type with specific configuration, enabling remote attestation of device health. This is used in zero-trust network access and device compliance scenarios.
• Random number generation: TPMs include a hardware random number generator, providing cryptographically secure entropy for key generation.

TPM FIPS certification

Many TPM implementations hold FIPS 140-2 certifications, but typically at Level 1 or Level 2. The specific certification level depends on the TPM vendor and implementation. Intel’s Platform Trust Technology (PTT), AMD’s firmware TPM, and discrete TPM chips from Infineon, STMicroelectronics, and Nuvoton have varying FIPS certification profiles.

The FIPS level matters because different security frameworks specify minimum levels. FIPS 140-2 Level 1 requires only that the cryptographic algorithms be approved; Level 2 adds physical tamper-evidence requirements. Level 3 requires active tamper resistance that zeroizes keys when physical intrusion is detected.

What Is an HSM?

A Hardware Security Module is a dedicated device designed specifically for cryptographic key management and cryptographic operations at high assurance levels. Unlike the TPM, which is a general platform security component integrated into devices, an HSM is a purpose-built security appliance.

HSM form factors

• USB tokens: Small USB devices (SafeNet eToken, Thales Luna T, Yubico YubiHSM 2) that store keys internally and perform cryptographic operations on-device. These are the most common form factor for code signing certificates delivered by CAs.
• PCIe cards: High-throughput HSMs installed inside servers (Thales Luna PCIe, Entrust nShield). Used in enterprise PKI, payment systems, and high-volume signing operations requiring fast cryptographic throughput.
• Network HSMs: Standalone network appliances (Thales Luna Network HSM, Entrust nShield Connect) accessed over the network by multiple servers. Used in CA infrastructure, enterprise key management, and payment processing.
• Cloud HSMs: HSM capacity provided as a cloud service where the hardware is operated by the cloud provider but keys are isolated per customer. AWS CloudHSM, Azure Dedicated HSM, Azure Key Vault HSM-backed secrets, and Google Cloud HSM are examples. CA services including DigiCert KeyLocker and SSL.com eSigner provide cloud HSM storage specifically for code signing certificates.

HSM FIPS certification

HSMs used in security-sensitive contexts are typically certified at FIPS 140-2 Level 2 or Level 3. Level 2 requires physical tamper-evidence: the device must show evidence of tamper attempts. Level 3 adds active tamper response: the device zeroes cryptographic keys if physical intrusion is detected.

Code signing certificate requirements specify FIPS 140-2 Level 2 as the minimum. Cloud HSMs and most USB tokens sold by major security vendors for code signing meet this minimum.

TPM vs HSM: Direct Comparison

Why TPMs Do Not Satisfy the Code Signing Certificate Storage Requirement

The CA/B Forum’s Code Signing Certificate Requirements (CSBRs) specify that private keys for code signing certificates must be generated and stored on a cryptographic module meeting FIPS 140-2 Level 2 or equivalent. This requirement exists to prevent code signing private keys from being exported, copied, or stolen.

While some TPMs achieve FIPS 140-2 Level 2 certification, TPMs are not accepted by CAs as the delivery medium for code signing certificates in practice, for several reasons:

• Verification at issuance: When a CA issues a code signing certificate, it must have reasonable assurance that the private key was generated on approved hardware. With physical USB tokens and cloud HSMs, the CA controls the delivery mechanism and can verify the hardware storage. The CA has no way to verify that a subscriber used their TPM for key generation rather than generating the key in software and then importing it.
• Key generation accountability: CA/B Forum requirements state that the key must be generated by the hardware module, not imported into it. With a CA-delivered USB token, the CA generates the key on the token or verifies the key was generated on-token. The CA has no visibility into a subscriber’s TPM to make this verification.
• Portability requirements: Code signing keys are often used across multiple machines (developer workstations, build servers, CI systems). A TPM-stored key is bound to the specific device and cannot be moved. The signed binary production workflow often requires the signing key to be accessible from build infrastructure that does not have a TPM enrolled for this purpose.
• CA delivery mechanisms: CAs have established workflows for delivering code signing certificates on USB tokens (shipped to the subscriber) or via cloud HSM enrollment (subscriber authenticates to the CA’s cloud service). TPM enrollment is not part of any CA’s current delivery workflow for code signing certificates.

The CA/B Forum CSBR requirement for hardware key storage was extended to all code signing certificates (not just EV) effective June 1, 2023. Before this date, standard OV code signing certificates could be delivered as software credentials (exportable PFX files). Since June 2023, all code signing private keys must be in FIPS 140-2 Level 2+ hardware, delivered either as physical USB tokens or via cloud HSM services.

Cloud HSMs for Code Signing: The Practical Solution

For developers and teams who need code signing in automated pipelines without managing physical USB tokens, cloud HSM services provided by CAs are the standard solution:

• DigiCert KeyLocker: DigiCert’s cloud HSM service for code signing. The private key is stored in DigiCert’s FIPS 140-2 Level 3 HSMs. Signing operations are authenticated API calls. Compatible with signtool via a PKCS#11 interface or DigiCert’s signing client.
• com eSigner: SSL.com’s cloud signing service. FIPS 140-2 Level 3 certified HSMs. Supports signing via the eSigner CodeSignTool or API integration.
• Sectigo cloud signing: Sectigo’s cloud HSM offering for code signing certificates.
• Microsoft Trusted Signing: Microsoft’s own cloud signing service at approximately $10/month. Keys stored in Microsoft’s Azure HSM infrastructure. Direct integration with signtool and CI/CD pipelines.

Cloud HSMs solve the CI/CD pipeline problem that physical USB tokens cannot: a USB token cannot be plugged into a cloud build runner. Cloud HSMs allow automated pipeline signing through API authentication, while the private key never leaves the HSM hardware boundary.

When to Use Each: Practical Decision Guide

Frequently Asked Questions

Can I use my PC’s built-in TPM for my code signing certificate?

No, for CA-issued OV or EV code signing certificates. Certificate Authorities deliver code signing certificates on physical USB tokens or via cloud HSM enrollment, not by enrolling a subscriber’s TPM. Even if your TPM meets FIPS 140-2 Level 2, the CA has no mechanism to verify key generation on your TPM and no established workflow for TPM-based code signing certificate delivery. For self-signed development certificates, using the TPM for local key storage is technically feasible but not the typical approach; most developers use the Windows Certificate Store or a local software store for development certificates.

What is the difference between FIPS 140-2 Level 2 and Level 3?

Level 2 requires physical tamper-evidence: the device must bear evidence of physical intrusion attempts (tamper-evident seals, coatings, or enclosures that cannot be opened without visible damage). Level 3 requires active tamper response: the device must detect physical intrusion attempts and respond by zeroizing (erasing) the cryptographic keys before they can be extracted. Level 3 HSMs are used in high-security contexts like CA key management and payment processing. Code signing certificate requirements specify Level 2 as the minimum; many CAs use Level 3 HSMs for their cloud services.

Why do cloud HSMs count as ‘hardware’ storage for code signing?

Cloud HSM services perform cryptographic operations inside certified FIPS 140-2+ hardware modules operated by the service provider. The private key is generated inside the HSM and never exists outside its hardware boundary, even during signing operations: the signing API sends the data to be signed into the HSM, the HSM performs the signing operation with the stored private key, and the HSM returns only the signature. The key itself never crosses the hardware boundary into software. This satisfies the CA/B Forum’s requirement that the private key be stored and used within a certified hardware module, even though the hardware is operated remotely rather than by the subscriber.

Do I need a TPM to use Windows BitLocker?

BitLocker can operate with or without a TPM. Without a TPM, BitLocker requires a startup key on a USB drive at every boot. With a TPM, BitLocker seals the encryption key to the TPM and the key is released automatically during the boot process if the platform measurements match expected values. The TPM-based mode is more convenient (no USB drive required) and provides protection against offline attacks. Windows 11 requires TPM 2.0, which ensures all Windows 11 devices have TPM-based BitLocker capability available.

Gloria Bradford

Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.

Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.