HSM vs TPM: what's the difference and which to choose?

Introduction: two modules, two security philosophies

In the field of applied cryptography and protection of digital keys, two technologies come up systematically in discussions among CISOs and Information Security Officers: 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 level differ fundamentally. Confusing the two can lead to unsuitable infrastructure choices, or 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 organisation 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 plaintext outside the module.

Technical characteristics of HSM

HSMs are certified 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+ according to ISO/IEC 15408 standard. These certifications require anti-tampering mechanisms (tamper-resistance), intrusion detectors, and automatic key destruction if a compromise is attempted.

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
• Standardised 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 signatures 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 a QSCD to guarantee the maximum legal value of signatures.

---

What is a TPM (Trusted Platform Module)?

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

TPM architecture and operation

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

• Measurement of boot integrity (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 (tens of 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 signatures, the TPM alone is generally insufficient with respect to eIDAS annex II requirements on QSCDs.

---

Fundamental differences HSM vs TPM: comparative table

Understanding the HSM vs TPM Trusted Platform Module difference involves a structured comparison of the determining criteria for business.

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 (physical) | 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 throughput.

The TPM, by contrast, 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-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 providers. The TPM, meanwhile, is built in at no extra cost to 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 business?

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 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 n°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 retain control of keys (BYOK / HYOK)
• Code signing and CI/CD build integrity: signing software artefacts 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 foundation 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 without extraction capability
• NIS2 compliance on endpoint security: the NIS2 directive (EU 2022/2555), transposed into French law by the law of 13 June 2024, imposes proportionate technical measures for information system security; the TPM directly contributes to hardware asset security
• Industrial IoT projects: TPMs embedded in automation systems and SCADA systems allow remote attestation without dedicated HSM infrastructure

Hybrid HSM + TPM architectures

In large organisations, HSM and TPM are not opposed: they complement each other. A server equipped with a TPM 2.0 can attest its integrity to a centralised management service, while business cryptographic operations (signature, 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 harmonise terminology when defining this architecture.

Legal and regulatory framework applicable to HSM and TPM

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

eIDAS Regulation n°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 recognised QSCDs is published by national accreditation bodies (in France: ANSSI). FIPS 140-3 level 3 or Common Criteria EAL4+ certified HSMs 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 recognises the legal value of electronic writing "on condition that the person from whom it emanates can be duly identified and that it is established and preserved in conditions of a nature to guarantee its integrity". Article 1367 clarifies the conditions of reliable electronic signature, implicitly referring to eIDAS requirements for qualified signatures.

GDPR n°2016/679, articles 25 and 32

The privacy by design principle (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 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, requires in article 21 risk management measures including software supply chain security and encryption. HSMs directly meet these requirements for critical operations, whilst 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 (XAdES) and ETSI EN 319 122 (CAdES) standards define signature formats that presuppose use of certified secure modules.

ANSSI recommendations

ANSSI publishes the RGS framework (General Security Reference) and its guides on HSMs, recommending the use of certified modules for any sensitive PKI infrastructure in public organisations and critical operators. Failure to comply with these recommendations may constitute a breach of NIS2 obligations for entities concerned.

Use case scenarios: HSM or TPM depending on context

Scenario 1: an asset management company with internal PKI

An asset management company managing several billion euros of 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 (Root CA) and intermediate (Issuing CA) keys are protected in two HSM network appliances 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 document signature time falls from 4 days to less than 2 hours. The HSM infrastructure cost is amortised 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 aeronautical 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 into the MDM solution (Microsoft Intune). No HSM is needed in this context: the TPMs built into Dell and HP workstations are sufficient. Result: the risk of data leakage following physical laptop theft is reduced to near-zero, and the SME's cybersecurity maturity score improves by 40% according to CMMC self-assessment. Additional cost: €0 (TPM already integrated into machines).

Scenario 3: a SaaS electronic signature platform operator serving multiple clients

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 cloud-dedicated HSM mode (AWS CloudHSM or Thales DPoD), with one HSM partition per large-size 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 and multi-application cryptographic service, essential for PKIs, eIDAS qualified signatures and large-scale PCI-DSS or NIS2 compliance. The TPM is a trust component linked to a specific hardware platform, ideal for securing endpoints, secure boot and local authentication. In the majority of mature enterprise architectures in 2026, both coexist with complementary and non-substitutable roles.

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