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 Chief Information Security Officers and Information Security Directors: the HSM (Hardware Security Module) and the 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 inadequate infrastructure choices and even regulatory compliance gaps. This article gives you the keys to understand the HSM vs TPM difference, 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 designed specifically to generate, store, and manage cryptographic keys in a physically and logically secure environment. It is an autonomous 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 HSM

HSMs are certified according to rigorous international standards, notably FIPS 140-2 / FIPS 140-3 (levels 2, 3, or 4) published by the American NIST, and Common Criteria EAL4+ per ISO/IEC 15408. These certifications entail anti-tampering mechanisms (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 each operation

Typical HSM use cases

HSMs are at the heart of qualified electronic signature within the meaning of 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 HSM protocol), database encryption infrastructures, and CI/CD code signing environments.

Qualified electronic signature in enterprises almost systematically relies on an HSM certified as a QSCD to guarantee maximum legal value 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.

Architecture and TPM 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

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 comprehensively as a dedicated HSM. For advanced or qualified electronic signature, the TPM alone is generally insufficient regarding eIDAS requirements in annex II on QSCDs.

---

Fundamental differences HSM vs TPM: comparative table

Understanding the HSM vs TPM difference goes through a structured comparison of decisive criteria for 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 | | Anti-tampering mechanisms | 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 firmware integrity. For electronic signature operations in document workflows, a TPM cannot play the role of a shared cryptographic service.

Cost and deployment

An enterprise-grade 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 into nearly 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 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 certification authority's root 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 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 maintain key control (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 boot: 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 dependence on an external service
• Hardware authentication of workstations: Windows Hello for Business uses the TPM to store authentication private keys with no possibility of extraction
• NIS2 compliance on endpoint security: the NIS2 directive (EU 2022/2555), transposed into French law by the law of June 13, 2024, imposes proportionate technical measures for information system security; the TPM directly contributes to securing material assets
• Industrial IoT projects: TPMs embedded in automation systems and SCADA allow remote attestation without dedicated HSM infrastructure

Hybrid HSM + TPM architectures

In large organizations, HSM and TPM do not oppose each other: 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 (signature, application data encryption) are delegated to a network HSM cluster. This architecture is recommended by the ANSSI in its guide on risk management related to trust service providers (PSCE). Consulting the electronic signature glossary can help technical teams harmonize terminology when defining this architecture.

Legal and regulatory framework applicable to HSM and TPM

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 private key confidentiality, its uniqueness, and its inviolability. The list of recognized QSCDs is published by national accreditation bodies (in France: ANSSI). HSMs certified 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 the 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 maintained under conditions likely to guarantee its integrity". Article 1367 specifies the conditions of 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 for appropriate technical measures (article 32) require the protection of cryptographic keys used to encrypt personal data. Resorting to a certified HSM constitutes a state-of-the-art measure (état de l'art within the meaning of recital 83 of the GDPR) to demonstrate compliance during a CNIL inspection.

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

The NIS2 directive, applicable to essential and important entities since October 2024, imposes measures in article 21 for risk management 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 trust service providers) and ETSI EN 319 411-1/2 (requirements for CAs issuing qualified certificates) require storage of CA keys in certified HSMs. The ETSI EN 319 132 standard (XAdES) and ETSI EN 319 122 (CAdES) define signature formats that presume the use of certified secure modules.

ANSSI Recommendations

ANSSI publishes the RGS (General Security Reference) and its guides on HSMs, recommending the use of certified modules for any sensitive PKI infrastructure in public organizations and OIV/OSE. Non-compliance with these recommendations may 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 reporting (AIFMD, MiFID II) and investment contracts with qualified legal value. It deploys an internal PKI whose root keys (Root CA) and intermediate keys (Issuing CA) 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 AMF audits confirm compliance, and the time to sign investment documents drops from 4 days to less than 2 hours. The HSM infrastructure cost is amortized in less than 18 months compared to potential non-compliance costs.

Scenario 2: a small industrial company of 150 employees 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 RSSI 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 into the MDM solution (Microsoft Intune). No HSM is necessary in this context: TPMs integrated into Dell and HP workstations are sufficient. Result: the risk of data leakage following laptop theft is reduced to nearly zero, and the SME's cybersecurity maturity score advances 40% according to CMMC self-assessment. Additional cost: €0 (TPM already integrated into machines).

Scenario 3: a SaaS multi-client electronic signature platform operator

A SaaS operator offering electronic signature services to several hundred client enterprises must guarantee cryptographic isolation between clients and eIDAS qualification of its service. It deploys an architecture based on HSMs in dedicated cloud mode (AWS CloudHSM or Thales DPoD), with one HSM partition per large tenant and a shared pool for standard clients. Each client benefits from keys isolated 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, allowing 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 sector 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 of 2026, the two coexist with complementary and non-substitutable roles.

If your organization is looking to deploy a qualified electronic signature solution relying on a certified HSM infrastructure without managing 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.