HSM vs TPM: What's the Difference and Which One to Choose?

Introduction: two modules, two security philosophies

In the field of applied cryptography and digital key protection, two technologies consistently come up in discussions among CISOs and security managers: HSM (Hardware Security Module) and TPM (Trusted Platform Module). These two hardware devices share a common objective — protecting sensitive cryptographic operations — but their architecture, use cases, and certification levels differ fundamentally. Confusing the two can lead to inappropriate infrastructure choices or even regulatory compliance gaps. This article gives you the keys to understand the difference HSM vs TPM, identify when to use one or the other, and make the best decision for your organization in 2026.

---

What is an HSM (Hardware Security Module)?

A Hardware Security Module is a dedicated hardware device, specifically designed to generate, store, and manage cryptographic keys in a physically and logically secure environment. It is a standalone component — often in the form of a PCIe card, network appliance, or cloud service (HSM as a Service) — whose primary function is to execute high-performance cryptographic operations without ever exposing keys in plain text outside the module.

Technical characteristics of the HSM

HSMs are certified according to rigorous international standards, notably FIPS 140-2 / FIPS 140-3 (levels 2, 3, or 4) published by the US NIST, and Common Criteria EAL4+ according to ISO/IEC 15408 standard. These certifications involve mechanisms against physical tampering (tamper-resistance), intrusion detectors, and automatic key destruction in case of compromise attempts.

A typical HSM offers:

• High processing capacity: up to several thousand RSA or ECDSA operations per second
• Multi-tenancy: management of hundreds of independent cryptographic partitions
• Standardized interfaces: PKCS#11, Microsoft CNG, JCA/JCE, OpenSSL engine
• Complete audit trail: immutable logging of every operation

Typical HSM use cases

HSMs are the core of qualified electronic signature under the eIDAS regulation, where the signatory's private key must be generated and stored in a qualified signature creation device (QSCD). They also equip certification authorities (CA/PKI), payment systems (PCI-DSS protocol HSM), database encryption infrastructures, and CI/CD code signing environments.

Qualified electronic signature in business almost systematically relies on an HSM certified as QSCD to guarantee maximum legal validity of signatures.

---

What is a TPM (Trusted Platform Module)?

The Trusted Platform Module is a security chip integrated directly on the motherboard of a computer, server, or connected device. Standardized by the Trusted Computing Group (TCG), whose TPM 2.0 specification is also standardized under ISO/IEC 11889:2015, the TPM is designed to secure the platform itself rather than serve as a centralized shared cryptographic service.

TPM architecture and operation

Unlike the HSM, the TPM is a single-use component, tied to a specific hardware device. It cannot be moved or shared between multiple machines. Its main functions include:

• Boot integrity measurement (Secure Boot, Measured Boot) via Platform Configuration Registers (PCR)
• Platform-bound key storage: keys generated by the TPM can only be used on the machine that created them
• Cryptographic random number generation (RNG)
• Remote attestation: proving to a remote server that the platform is in a known trusted state
• Volume encryption: BitLocker on Windows, dm-crypt with TPM on Linux rely directly on the TPM

TPM limitations for advanced enterprise use cases

TPM 2.0 is certified FIPS 140-2 level 1 at best, which is significantly lower than the FIPS 140-3 level 3 certifications of professional HSMs. Its cryptographic processing capacity is limited (a few dozen operations per second), and it does not natively support PKCS#11 or CNG interfaces as completely as a dedicated HSM. For advanced or qualified electronic signature, the TPM alone is generally insufficient regarding the eIDAS annex II requirements for QSCDs.

---

Fundamental differences HSM vs TPM: comparative table

Understanding the difference HSM vs TPM Trusted Platform Module involves a structured comparison of criteria that are key to the enterprise.

Certification level and security assurance

| Criterion | HSM | TPM | |---|---|---| | FIPS certification | 140-3 level 2 to 4 | 140-2 level 1 | | Common Criteria | EAL4+ to EAL7 | EAL4 | | eIDAS QSCD qualification | Yes (e.g., Thales Luna, Utimaco) | No | | Advanced tampering protection | Advanced (auto-destruction) | Basic |

Capacity, scalability, and integration

HSMs are multi-user and multi-application devices: a single network appliance can simultaneously serve hundreds of clients, applications, and services via PKCS#11 or REST API. They integrate into high-availability architectures (active-active clusters) and support industrial cryptographic throughputs.

The TPM, conversely, is single-machine and single-tenant by design. It excels at securing workstations, protecting Windows Hello for Business access credentials, and ensuring firmware integrity. For electronic signature operations in document workflows, a TPM cannot serve as a shared cryptographic service.

Cost and deployment

An enterprise-level network HSM (Thales Luna Network HSM, Utimaco SecurityServer, AWS CloudHSM) represents an investment of €15,000 to €80,000 for on-premise hardware, or between €1.50 and €3.00 per hour in managed cloud mode depending on vendors. The TPM, meanwhile, is integrated at no additional cost in virtually all professional PCs, servers, and embedded systems since 2014 (mandatory for Windows 11 since 2021).

---

When to use an HSM, when to use a TPM in the enterprise?

The answer to this question depends on your operational context, regulatory obligations, and your information system architecture.

Choose an HSM for:

• Deploying an internal PKI: your root certification authority keys must imperatively reside in a certified HSM to obtain browser trust (CA/Browser Forum Baseline Requirements)
• Issuing qualified electronic signatures: in accordance with annex II of eIDAS regulation 910/2014, QSCDs must be certified according to standards equivalent to EAL4+ minimum; the comparison of electronic signature solutions details these requirements
• Securing high-volume financial transactions: PCI-DSS v4.0 standards (section 3.6) require protection of card data encryption keys in HSMs
• Database or cloud encryption: AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM allow you to retain control of keys (BYOK / HYOK)
• Code signing and CI/CD build integrity: signing software artifacts for secure supply chain requires an HSM to prevent key theft

Choose a TPM for:

• Securing workstation and server startup: Secure Boot + Measured Boot + remote attestation via TPM 2.0 forms the basis of Zero Trust on endpoint
• Full-disk encryption: BitLocker with TPM protects data at rest without dependency on an external service
• Hardware authentication of workstations: Windows Hello for Business uses the TPM to store authentication private keys without extraction possibility
• NIS2 compliance on endpoint security: the NIS2 directive (EU 2022/2555), transposed into French law by the June 13, 2024 law, imposes proportionate technical measures for information system security; the TPM directly contributes to hardware asset security
• Industrial IoT projects: TPMs embedded in automata and SCADA systems allow remote attestation without dedicated HSM infrastructure

Hybrid HSM + TPM architectures

In large organizations, HSM and TPM are not opposed: they complement each other. A server equipped with a TPM 2.0 can attest its integrity to a centralized management service, while business cryptographic operations (signing, application data encryption) are delegated to a network HSM cluster. This architecture is recommended by ANSSI in its guide on managing risks related to trusted service providers (PSCE). Consulting the electronic signature glossary can help technical teams align terminology when defining this architecture.

Legal and regulatory framework applicable to HSMs and TPMs

The choice between HSM and TPM directly engages your organization's compliance with several European and international regulatory frameworks.

eIDAS regulation 910/2014 and eIDAS 2.0 (EU regulation 2024/1183)

Article 29 of the eIDAS regulation requires that qualified electronic signatures be created using a Qualified Signature Creation Device (QSCD), defined in annex II. These devices must guarantee the confidentiality of the private key, its uniqueness, and its inviolability. The list of recognized QSCDs is published by national accreditation bodies (in France: ANSSI). Certified HSMs FIPS 140-3 level 3 or Common Criteria EAL4+ appear on these lists; TPMs do not. A signature provider like Certyneo relies on qualified HSMs to guarantee maximum probative value of issued signatures.

French Civil Code, articles 1366 and 1367

Article 1366 recognizes the legal value of electronic writing "provided that the person from whom it emanates can be duly identified and that it is established and preserved in conditions capable of guaranteeing its integrity". Article 1367 clarifies the conditions for reliable electronic signature, implicitly referring to eIDAS requirements for qualified signatures.

GDPR 2016/679, articles 25 and 32

The principle of privacy by design (article 25) and the obligation to implement appropriate technical measures (article 32) require protection of cryptographic keys used to encrypt personal data. Recourse to a certified HSM constitutes a state-of-the-art measure (état de l'art within the meaning of GDPR recital 83) to demonstrate compliance during a CNIL audit.

NIS2 Directive (EU 2022/2555), transposed in France

The NIS2 directive, applicable to essential and important entities since October 2024, requires under article 21 risk management measures including software supply chain security and encryption. HSMs directly address these requirements for critical operations, while TPMs contribute to endpoint security.

ETSI standards

The ETSI EN 319 401 standard (general requirements for trusted service providers) and ETSI EN 319 411-1/2 (requirements for CAs issuing qualified certificates) require CA key storage in certified HSMs. The ETSI EN 319 132 standard (XAdES) and ETSI EN 319 122 (CAdES) define signature formats that presuppose the use of certified secure modules.

ANSSI recommendations

ANSSI publishes the RGS (General Security Reference) framework and its HSM guides, recommending the use of certified modules for any sensitive PKI infrastructure in public organizations and OIV/OSE. Non-compliance with these recommendations can constitute a breach of NIS2 obligations for concerned entities.

Usage scenarios: HSM or TPM depending on context

Scenario 1: an asset management company with internal PKI

An asset management company managing several billion euros in assets under management needs to electronically sign regulatory reports (AIFMD, MiFID II) and investment contracts with qualified legal value. It deploys an internal PKI whose root (Root CA) and intermediate (Issuing CA) keys are protected in two network HSMs in high-availability cluster, certified FIPS 140-3 level 3. Qualified certificates are issued on partner HSMs compliant with eIDAS QSCD. Result: 100% of signatures have qualified value, regulatory audits by the AMF confirm compliance, and the time to sign investment documents drops from 4 days to less than 2 hours. The cost of HSM infrastructure is recovered in less than 18 months compared to potential non-compliance costs.

Scenario 2: a 150-employee industrial SME securing its workstation fleet

An SME in the aerospace manufacturing sector, a tier 2 supplier subject to CMMC (Cybersecurity Maturity Model Certification) requirements and NIS2 recommendations, must secure 150 Windows workstations against theft of sensitive technical data. The CISO deploys BitLocker with TPM 2.0 across the entire fleet, coupled with Windows Hello for Business for passwordless authentication. Remote attestation via TPM is integrated in the MDM solution (Microsoft Intune). No HSM is necessary in this context: TPMs integrated in Dell and HP workstations are sufficient. Result: the risk of data leakage following physical laptop theft is reduced to nearly zero, and the company's cybersecurity maturity score improves by 40% according to CMMC self-assessment. Additional cost: €0 (TPM already integrated in machines).

Scenario 3: a SaaS platform operator offering electronic signature to multiple clients

A SaaS operator providing electronic signature services to several hundred client companies must guarantee cryptographic isolation between clients and eIDAS qualification of its service. It deploys an architecture based on cloud-dedicated HSMs (AWS CloudHSM or Thales DPoD), with one HSM partition per large tenant and a shared pool for standard clients. Each client benefits from isolated keys in its partition, independently auditable. TPMs equip application servers for platform integrity attestation during eIDAS certification audits (QTSP). Result: the operator obtains QTSP qualification from ANSSI, enabling it to issue qualified signatures. The HSM as a Service model reduces infrastructure capex by 60% compared to an on-premise solution, according to comparable industry benchmarks.

Conclusion

The difference between HSM and TPM is fundamental: the HSM is a shared, high-performance, multi-application cryptographic service, essential for PKI, eIDAS qualified signatures, and PCI-DSS or NIS2 compliance at scale. The TPM is a trust component tied to a specific hardware platform, ideal for securing endpoints, secure boot, and local authentication. In the majority of mature enterprise architectures in 2026, the two coexist with complementary and non-substitutable roles.

If your organization is seeking to deploy a qualified electronic signature solution relying on a certified HSM infrastructure without managing the technical complexity internally, Certyneo offers you a turnkey SaaS platform, eIDAS and GDPR compliant. Discover Certyneo pricing or contact our experts for an audit of your cryptographic needs.