HSM Encryption: Functioning and Private Keys (2026)

The security of digital transactions rests on a component often overlooked by IT departments: the Hardware Security Module (HSM). This dedicated hardware device generates, stores, and protects cryptographic keys without ever exposing them to the external software environment. As cyberattacks targeting PKI infrastructures increased by 43% between 2023 and 2025 according to the ENISA Threat Landscape 2025 report, understanding how HSM encryption works has become a strategic issue for any enterprise managing qualified electronic signatures, banking transactions, or sensitive data exchanges. This article decrypts the architecture of an HSM, the lifecycle of private keys, the cryptographic protocols implemented, and the selection criteria for B2B organisations.

Hardware architecture of an HSM: a cryptographic safe

An HSM is, by definition, a tamper-resistant physical device. Unlike a software solution, it integrates intrusion detection mechanisms that trigger automatic key deletion as soon as an attempt at physical breach is detected (mechanism known as zeroization).

Internal components and secure isolation

The internal architecture of an HSM rests on several complementary layers:

• Dedicated cryptographic processor: executes encryption operations (RSA, ECDSA, AES, SHA-256) in isolation from the host system.

• Hardware random number generator (TRNG): produces true entropy, essential to the strength of generated keys — hardware TRNGs far surpass software PRNGs in terms of unpredictability.

• Secure non-volatile memory: stores master keys in a physically protected area, inaccessible from outside even in case of dismantling.

• Tamper-evident enclosure: any attempt to open triggers an alarm and deletion of secrets.

HSMs are certified according to FIPS 140-2/140-3 standards (levels 2 to 4) published by the US NIST, and Common Criteria EAL 4+ for the most demanding European uses. An HSM at FIPS 140-3 level 3, for example, requires multifactor authentication for any access to keys and resists active physical attacks.

Deployment modes: on-premise, PCIe and cloud HSM

Three physical forms coexist on the B2B market:

• Network HSM (appliance): rack-mounted enclosure connected to the local network, shared between multiple application servers. Typically used by qualified trust service providers (TSP) certified under eIDAS.

• PCIe HSM card: module integrated directly into a server, offering better latencies for applications with high signature volumes.

• Cloud HSM: managed service offered by cloud providers (Azure Dedicated HSM, AWS CloudHSM, Google Cloud HSM). The hardware remains physically dedicated to the client but is hosted in the provider's datacentre — relevant for enterprises wishing to avoid hardware management while retaining exclusive control over their keys.

The choice between these modes directly conditions the level of compliance achievable with the eIDAS 2.0 regulation, notably for qualified signatures (QES) which require a qualified signature creation device (QSCD) — a certified HSM constitutes the QSCD par excellence.

Lifecycle of private keys in an HSM

The real value of an HSM lies in its ability to manage the entire lifecycle of cryptographic keys without a private key ever "leaving" in clear text its hardware perimeter.

Key generation and injection

Key generation within the HSM is fundamental. Any key generated externally and then imported presents a residual risk linked to its transit through an uncontrolled environment. Best practices therefore impose:

• Generation of the key pair (public/private) directly within the HSM via the integrated TRNG.

• The private key never leaves the hardware perimeter of the HSM — even system administrators do not have access to it in clear text.

• The public key, alone, is exported to be integrated into an X.509 certificate issued by a Certification Authority (CA).

Certain protocols such as PKCS#11 (OASIS standard) or JCE (Java Cryptography Extension) allow business applications to invoke HSM cryptographic operations via standardised API calls, without ever directly manipulating keys.

Cryptographic operations: signature, decryption, derivation

When a user signs a document, here is the exact technical flow:

• The application calculates the digital fingerprint (hash) of the document using a hash function (SHA-256 or SHA-384).

• The hash is transmitted to the HSM via the PKCS#11 interface or CNG (Cryptography Next Generation under Windows).

• The HSM internally signs the hash with the RSA-2048 or ECDSA P-256 private key, depending on configuration.

• The digital signature is returned to the application — never the key itself.

This principle of black-box operation guarantees that even total compromise of the application server does not allow an attacker to extract the private key.

Key backup, rotation and destruction

The complete lifecycle of a key includes:

• Encrypted backup: keys can be exported in encrypted form (Wrapped Key) using a key encryption key (KEK), itself stored in another master HSM — principle of the Key Ceremony documented by CAs.

• Periodic rotation: recommended every 1 to 3 years depending on certificate lifespan and risk level. The eIDAS 2.0 regulation and ETSI TS 119 431 policies govern these timescales for TSPs.

• Revocation and destruction: at end of life, the key is destroyed by zeroization — an irreversible operation guaranteeing that no reconstruction is possible.

For organisations wishing to understand how qualified electronic signature relies on these mechanisms, the HSM constitutes the technical core of the QSCD imposed by eIDAS.

Cryptographic protocols and standards supported by HSMs

A modern enterprise HSM supports an extended catalogue of cryptographic primitives and protocols.

Asymmetric and symmetric algorithms

The integration of post-quantum algorithms (PQC) is a burning topical issue: NIST finalised the first PQC standards in 2024 (FIPS 203, 204, 205), and several HSM manufacturers (Thales, nCipher/Entrust, Utimaco) already offer as of 2026 firmware supporting these algorithms in hybrid RSA+Kyber mode.

Integration interfaces and protocols

The ecosystem for HSM integration rests on several open standards:

• PKCS#11: the most widespread C API interface, supported by OpenSSL, EJBCA, and the majority of Java application servers.

• Microsoft CNG/KSP: native integration into the Windows Server / Active Directory Certificate Services ecosystem.

• KMIP (Key Management Interoperability Protocol): OASIS standard for centralised key management between heterogeneous HSMs — particularly useful in multi-cloud architectures.

• Proprietary REST APIs: modern cloud HSMs expose REST APIs for fluid DevOps integration (Infrastructure as Code, Terraform providers).

Mastery of these interfaces is essential for integrating an HSM into a electronic signature platform for high-volume enterprises.

Criteria for choosing an HSM for B2B enterprises in 2026

Faced with a diverse market offering, several objective criteria should guide the purchase decision or subscription to an HSM-as-a-Service.

Certification level and regulatory compliance

For use within the framework of qualified electronic signature (eIDAS) or banking processes subject to PSD2/DSP2:

• FIPS 140-3 level 3 minimum for data of a sensitive personal or financial nature.

• Common Criteria EAL 4+ certification with protection profile EN 419221-5 for eIDAS QSCDs — this is the reference standard for European trusted lists (ETSI TS 119 612 Trusted Lists).

• ANSSI qualification for French entities subject to specific regulatory requirements (defence, operators of vital importance).

Performance, high availability and TCO

High-end network HSMs (Thales Luna Network HSM 7, Entrust nShield Connect XC) display performance of several thousand RSA-2048 operations per second, with active-active configurations for high availability. The TCO over 5 years of an on-premise HSM includes: hardware, maintenance, qualified personnel, and Key Ceremony management — elements that often make Cloud HSM more attractive for SMEs and mid-sized companies.

For organisations evaluating the overall return on investment of their signature infrastructure, use of a ROI calculator dedicated to electronic signature allows precise quantification of operational gains associated with HSM-based security.

Key governance and access control

An HSM is only worth the quality of its governance:

• M-of-N principle: any sensitive operation (master key generation, initialisation) requires the simultaneous presence of M administrators among N designated — typically 3 among 5.

• Immutable audit logs: each cryptographic operation is traced in timestamped and signed logs, requirement of the GDPR (art. 5.2, accountability) and ETSI frameworks.

• Role separation: HSM administrator, key operator, and auditor are distinct roles — in compliance with the requirements of ETSI EN 319 401 certification policies.

Understanding the requirements of the eIDAS 2.0 regulation is essential to properly calibrate key governance in a context of European qualified signature.

Legal framework applicable to HSM encryption in enterprise

The deployment of an HSM for cryptographic key management occurs at the intersection of a dense regulatory corpus, at the crossroads of electronic signature law, personal data protection and cybersecurity.

Regulation eIDAS No. 910/2014 and eIDAS 2.0 revision

The eIDAS regulation establishes the technical and legal conditions for qualified electronic signatures (QES). Its Article 29 requires that qualified signature creation devices (QSCD) guarantee the confidentiality of the private key, its uniqueness, and the impossibility of deriving it. These technical requirements can only be satisfied by an HSM certified to the EN 419221-5 protection profile or equivalent. The eIDAS 2.0 revision (Regulation EU 2024/1183, in force since May 2024) strengthens these obligations with the introduction of the European digital identity wallet (EUDIW), which itself relies on compliant QSCDs.

Applicable ETSI standards

The ETSI standards family precisely frames the practices of trust service providers (TSP):

• ETSI EN 319 401: general security requirements for TSPs, including HSM management and role separation.

• ETSI EN 319 411-1/2: certification policies and practices for CAs issuing qualified certificates.

• ETSI EN 319 132: XAdES profile for advanced electronic signature — signature operations invoke HSMs.

• ETSI TS 119 431-1: specific requirements for remote signing services (Remote Signing), where the HSM is operated by the TSP on behalf of the signer.

French Civil Code (Articles 1366-1367)

Article 1366 of the Civil Code recognises the legal value of electronic writing when it is possible to identify its author and its integrity is guaranteed. Article 1367 equates qualified electronic signature with handwritten signature. Protection of the private key by HSM is the technical mechanism that makes this presumption of imputability irrefutable before courts.

GDPR No. 2016/679

When an HSM processes keys linked to the identity of natural persons (qualified nominative certificates, audit logs including identifying data), the GDPR applies in full. Article 25 (privacy by design) requires data protection to be built in from design — the HSM meets this requirement by rendering it technically impossible to access private keys outside the defined operational framework. Article 32 requires the implementation of appropriate technical measures: the HSM constitutes the state of the art in cryptographic protection.

NIS2 Directive (EU 2022/2555)

Transposed into French law by the law of 15 April 2025, the NIS2 directive requires essential and important operators (OES/OEI) to implement risk management measures explicitly including security of the cryptographic supply chain. Recourse to certified HSMs for the protection of signature and encryption keys falls directly within this framework, notably for the health, finance, energy and digital infrastructure sectors.

Liability and legal risks

A compromise of private key resulting from an absence of HSM or insufficient configuration can engage the civil and criminal liability of the data controller, expose the organisation to CNIL sanctions (up to 4% of global turnover), and retroactively invalidate all signatures issued with the compromised key. The failure to log HSM operations constitutes moreover a characterised non-compliance with ETSI and GDPR frameworks.

Use cases: the HSM in action in B2B enterprises

Scenario 1 — Qualified signature platform for a multi-site industrial group

A European industrial group with 15 subsidiaries and managing approximately 4,000 supplier contracts per year decides to centralise its qualified electronic signature chain. The security team deploys two network HSMs in active-active high availability configuration across two distinct datacentres (geographical resilience strategy). The qualified signature keys of each legal entity are generated and stored exclusively in the HSMs, accessible via a PKCS#11 interface exposed to the SaaS signature platform.

Results observed after 12 months: zero security incidents related to key management, total compliance during the eIDAS audit carried out by an accredited conformity assessment body (CAB), and 67% reduction in average contract signature time (from 8.3 days on average to 2.8 days). The total HSM deployment cost was recovered in 14 months thanks to productivity gains and elimination of residual paper processes.

Scenario 2 — Law firm and client mandate signature management

A 45-person business law firm, handling merger and acquisition and commercial litigation files, seeks to secure flows of signature of mandates, engagement letters and procedural documents. Faced with the impossibility of using an on-premise HSM (absence of dedicated IT team), the firm subscribes to a Cloud HSM service integrated into a electronic signature solution for law firms.

Each partner has a qualified certificate whose private key is stored in the provider's dedicated HSM, certified FIPS 140-3 level 3 and referenced on the European trusted list. The firm benefits from complete traceability of operations (timestamped logs, exportable for evidence purposes in case of litigation), with no hardware infrastructure to manage. The reduction in time spent on administrative management related to document handling is estimated at 3.5 hours per employee per week according to industry benchmarks from comparable firms.

Scenario 3 — Healthcare establishment and protection of electronic prescription data

A hospital group of approximately 1,200 beds implements secure electronic medical prescription (e-prescription) in compliance with requirements from ANS (Digital Numeracy Agency in Health) and the framework of My Health Space. Prescriptions must be signed with a healthcare professional certificate (CPS) whose private key cannot in any way be exposed on practitioners' workstations.

The IT department deploys an HSM certified Common Criteria EAL 4+ integrated into its identity management infrastructure (internal IGC). The CPS keys of doctors are stored in the HSM; practitioners authenticate themselves via smart card + PIN to trigger the signature operation delegated to the HSM. This mechanism, compliant with eIDAS regulation and ETSI standards, reduces the risk of key theft by 89% compared to software storage on workstation, and allows centralised revocation in less than 5 minutes in case of departure or loss of card.

Frequently Asked Questions

What is the difference between an HSM and a password vault like a software password manager?

A password manager is a software application that encrypts sensitive data through the operating system, thereby exposing secrets to the server's RAM. An HSM is a physically isolated hardware component: cryptographic keys are generated and used within it without ever passing into the software environment, even during a signing operation. This hardware separation makes it incomparably more resistant to software attacks and unauthorised access.

Is an HSM mandatory for issuing a qualified electronic signature under eIDAS?

Yes, the eIDAS regulation requires that every qualified signature (QES) be based on a qualified signature creation device (QSCD). In practice, an HSM certified according to recognised standards such as FIPS 140-3 level 3 or Common Criteria EAL 4+ constitutes the reference device for meeting this requirement. Without this hardware component, a trust service provider cannot obtain the qualification necessary to issue signatures having the same legal value as a handwritten signature in the European Union.

What happens if an HSM fails: are the private keys lost?

A hardware failure does not necessarily result in loss of keys, provided that a backup procedure has been implemented. Best practices call for exporting keys in encrypted form, known as a "wrapped key", to a secondary or backup HSM during a formalised key ceremony. This encrypted copy can only be decrypted by another HSM possessing the corresponding key encryption key, which preserves confidentiality whilst ensuring business continuity.

Does Cloud HSM offer the same level of security as an HSM deployed on premises?

A Cloud HSM uses physically dedicated hardware hosted in a provider's data centre: the client retains exclusive control over its keys without sharing them with other tenants. The level of hardware certification is generally equivalent to that of an on-premises HSM. The difference lies in the shared responsibility for the data centre's physical security and dependence on the provider's availability. For use cases subject to eIDAS or strict sector-specific regulations, it is advisable to verify that the chosen service is listed on the qualified devices list published by the competent national authority.

How does the PKCS#11 interface allow an application to sign without accessing the private key?

PKCS#11 is a standardised programming interface that allows an application to send a cryptographic operation to the HSM, for example "sign this hash", without ever receiving the private key in return. The application obtains only the result of the operation, that is, the digital signature. This mechanism, known as black-box operation, ensures that even if the application server is compromised, an attacker cannot extract the private key residing in the HSM.

Conclusion

HSM encryption constitutes the cornerstone of any infrastructure for qualified electronic signature and secure management of private keys in enterprise. By combining material isolation, proven cryptographic algorithms, strict key governance and compliance with FIPS 140-3, Common Criteria and ETSI standards, the HSM offers an unparalleled level of protection against current threats and European regulatory requirements. Whether you opt for on-premise deployment, a PCIe card or a managed Cloud HSM, the essential point is to align your choice with your level of risk exposure and your legal obligations under eIDAS, GDPR and NIS2.

Certyneo natively integrates certified HSMs into its qualified electronic signature infrastructure, enabling you to benefit from this enterprise-level security without operational complexity. Ready to secure your document flows with a compliant and certified solution? Start for free on Certyneo or consult our pricing to find the offer adapted to your organisation.