HSM Encryption: How It Works and Private Keys (2026)

The security of digital transactions rests on a component often overlooked by IT management: 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 infrastructure 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 organisation 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 erasure as soon as a physical violation is detected (a mechanism called zeroization).

Internal Components and Secure Isolation

The internal architecture of an HSM is built 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 if disassembled.
• Tamper-evident enclosure: any attempt to open triggers an alarm and erasure of secrets.

HSMs are certified according to FIPS 140-2/140-3 standards (levels 2 to 4) published by the American NIST, and Common Criteria EAL 4+ for the most demanding European uses. An FIPS 140-3 level 3 HSM, for example, mandates multi-factor authentication for all key access and resists active physical attacks.

Deployment Modes: On-Premise, PCIe and Cloud HSM

Three physical forms coexist in the B2B market:

1. Network HSM (appliance): rack-mounted box connected to the local network, shared between multiple application servers. Typically used by Trust Service Providers (TSP) certified under eIDAS.
2. PCIe HSM card: module integrated directly into a server, offering better latencies for high-volume signature applications.
3. 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 data centre — relevant for organisations wishing to avoid hardware management while retaining exclusive control over their keys.

The choice between these modes directly conditions the level of compliance achievable under the eIDAS 2.0 regulation, particularly for qualified signatures (QES) which require a qualified signature creation device (QSCD) — a certified HSM is the prime example of a QSCD.

Lifecycle of Private Keys in an HSM

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

Key Generation and Injection

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

• Generation of the key pair (public/private) directly within the HSM via the integrated TRNG.
• The private key never leaves the HSM's hardware perimeter — even system administrators have no 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: Signing, Decryption, Derivation

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

1. The application calculates the digital fingerprint (hash) of the document using a hash function (SHA-256 or SHA-384).
2. The hash is transmitted to the HSM via the PKCS#11 or CNG interface (Cryptography Next Generation on Windows).
3. The HSM signs the hash internally with the RSA-2048 or ECDSA P-256 private key, depending on the configuration.
4. 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.

Backup, Rotation and Destruction of Keys

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 — the principle of Key Ceremony documented by CAs.
• Periodic rotation: recommended every 1 to 3 years depending on certificate validity periods and risk level. Regulation eIDAS 2.0 and ETSI TS 119 431 policies govern these periods for TSPs.
• Revocation and destruction: at end of life, the key is destroyed by zeroization — an irreversible operation guaranteeing no reconstruction is possible.

For organisations wishing to understand how qualified electronic signatures rely on these mechanisms, the HSM constitutes the technical core of the QSCD mandated 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

| Family | Common Algorithms | Typical Usage | |---|---|---| | Asymmetric | RSA-2048/4096, ECDSA P-256/P-384, Ed25519 | Digital signature, key exchange | | Symmetric | AES-128/256-GCM, 3DES (legacy) | Data encryption, key wrapping | | Hashing | SHA-256, SHA-384, SHA-512 | Integrity, document fingerprint | | Post-quantum (PQC) | CRYSTALS-Kyber, CRYSTALS-Dilithium (NIST FIPS 203/204) | Cryptographic transition 2026+ |

Integration of post-quantum algorithms (PQC) is a hot topic: NIST finalised the first PQC standards in 2024 (FIPS 203, 204, 205), and several HSM manufacturers (Thales, nCipher/Entrust, Utimaco) offer by 2026 firmware supporting these algorithms in hybrid mode RSA+Kyber.

Integration Interfaces and Protocols

The HSM integration ecosystem relies 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 in 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 to integrate an HSM into a electronic signature platform for enterprises with high signing volume.

HSM Selection Criteria for B2B Organisations in 2026

Faced with a diverse market offering, several objective criteria should guide the decision to purchase or subscribe 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 sensitive personal or financial data.
• Common Criteria EAL 4+ certification with EN 419221-5 protection profile for eIDAS QSCDs — this is the reference standard for European trust lists (ETSI TS 119 612 Trusted Lists).
• ANSSI qualification for French entities subject to specific sectoral regulations (defence, vital infrastructure operators).

Performance, High Availability and TCO

Top-tier network HSMs (Thales Luna Network HSM 7, Entrust nShield Connect XC) deliver thousands of RSA-2048 operations per second, with active-active configurations for high availability. The 5-year TCO 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-market enterprises.

For organisations evaluating the overall return on investment of their signature infrastructure, using a dedicated ROI calculator for electronic signatures enables precise quantification of operational gains associated with HSM security.

Key Governance and Access Control

An HSM is only as good as the quality of its governance:

• M-of-N principle: any sensitive operation (master key generation, initialisation) requires the simultaneous presence of M administrators out of N designated — typically 3 out of 5.
• Immutable audit logs: every cryptographic operation is traced in timestamped and signed logs, a requirement of GDPR (art. 5.2, accountability) and ETSI referential standards.
• Role separation: HSM administrator, key operator, and auditor are distinct roles — in line with ETSI EN 319 401 certification policy requirements.

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

Legal Framework Applicable to HSM Encryption in the Enterprise

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

Regulation eIDAS No. 910/2014 and eIDAS 2.0 Revision

Regulation eIDAS establishes the technical and legal conditions for qualified electronic signatures (QES). Its Article 29 mandates that qualified signature creation devices (QSCDs) guarantee confidentiality of the private key, its uniqueness, and the impossibility of deriving it. These technical requirements can only be satisfied by an HSM certified according 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 also relies on compliant QSCDs.

Applicable ETSI Standards

The ETSI standards family precisely governs the practices of Trust Service Providers (TSPs):

• 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 signatures — signing operations call upon 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 validity of electronic writing when it is possible to identify its author and that its integrity is guaranteed. Article 1367 assimilates qualified electronic signature to handwritten signature. Protection of the private key by HSM is the technical mechanism that makes this presumption of attribution irrefutable before courts.

GDPR No. 2016/679

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

NIS2 Directive (EU 2022/2555)

Transposed into French law by the Act of 15 April 2025, the NIS2 Directive mandates essential and important entities (OES/OEI) to implement risk management measures explicitly including cryptographic supply chain security. The use of certified HSMs to protect signature and encryption keys falls squarely within this framework, particularly for the health, finance, energy and digital infrastructure sectors.

Liabilities and Legal Risks

A private key compromise resulting from 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. Failure to log HSM operations is a material non-compliance with ETSI and GDPR referential standards.

Use Cases: HSM in Action in B2B Enterprises

Scenario 1 — Qualified Signature Platform for a Multi-Site Industrial Group

A European industrial group with 15 subsidiaries 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 separate data centres (geographical resilience strategy). The qualified signature keys of each legal entity are generated and stored exclusively in 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, full compliance during the eIDAS audit conducted by an accredited Conformity Assessment Body (CAB), and 67% reduction in average contract signature timescales (from 8.3 days on average to 2.8 days). The total HSM deployment cost was amortised in 14 months thanks to productivity gains and elimination of residual paper processes.

Scenario 2 — Legal Consulting Firm and Signature of Client Mandates

A 45-lawyer law firm specialising in mergers and acquisitions and commercial litigation, handling mandate signatures, engagement letters and pleadings, seeks to secure its signature flows. Facing the impossibility of deploying an on-premise HSM (no 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 listed on the European trust list. The firm benefits from complete operation traceability (timestamped logs, exportable for evidence purposes in case of disputes), without any hardware infrastructure to manage. The reduction in administrative time related to document management is estimated at 3.5 hours per employee per week according to sectoral benchmarks of comparable firms.

Scenario 3 — Healthcare Facility and Protection of E-Prescription Data

A hospital group of approximately 1,200 beds implements secured electronic medical prescriptions (e-prescription) in compliance with ANS (French Digital Agency) requirements and the Mon Espace Santé framework. Prescriptions must be signed with a professional health certificate (CPS) whose private key cannot under any circumstances be exposed on practitioner workstations.

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

Conclusion

HSM encryption constitutes the cornerstone of any qualified electronic signature infrastructure and secure private key management in the enterprise. By combining hardware isolation, proven cryptographic algorithms, strict key governance and compliance with FIPS 140-3, Common Criteria and ETSI standards, the HSM offers unparalleled protection against current threats and European regulatory requirements. Whether you opt for an on-premise deployment, a PCIe card or a managed Cloud HSM, the key is to align your choice with your risk exposure level 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 workflows with a compliant and certified solution? Start free on Certyneo or check our pricing to find the offer suited to your organisation.