A Hardware Security Module (HSM) is a dedicated physical device built for one purpose: generating, storing, and using cryptographic keys in hardware that the keys can never leave. Every cryptographic operation involving a key stored in an HSM happens inside the device. Software sends data in, the HSM performs the operation, and only the result comes out. The key itself never crosses the hardware boundary.
HSMs sit at the foundation of modern digital trust. Certificate Authority root keys live in HSMs. Payment networks process card transactions through HSMs. And since June 2023, every commercially issued code signing certificate has its private key in an HSM, either a USB token in the publisher’s hands or a cloud HSM operated by the CA.
The Core Idea: Keys That Cannot Be Stolen by Copying
Software-stored keys have a fundamental weakness: they exist as data. A private key in a PFX file, a PEM file, or memory can be copied. Once copied, the attacker has the key forever, and the theft may never be detected because nothing is missing.
HSMs eliminate this attack class. The key is generated inside the device and is marked non-exportable at creation. There is no API call, no administrative command, and no configuration that releases the raw key material. An attacker who fully compromises the host computer connected to an HSM can ask the HSM to sign things while connected, which is bad, but cannot take the key away. Disconnect the HSM and the attacker has nothing.
This is the property that the CA/B Forum’s June 2023 hardware requirement targets for code signing. Before the change, a stolen PFX file meant silent, permanent key compromise: attackers could sign malware as the legitimate publisher indefinitely. With HSM storage, key theft requires physically stealing the token or compromising the HSM itself, both of which are detectable events that trigger revocation.
What Happens Inside an HSM During a Signing Operation
A code signing operation through an HSM follows this flow:
- The host computes the hash: signtool or the signing client hashes the file (SHA-256) on the host computer. The full file never enters the HSM, only its fixed-length digest.
- The digest is sent to the HSM: over USB (token), PCIe (card), or an authenticated network/API channel (network or cloud HSM), along with authentication (PIN, credentials, or API token).
- The HSM authenticates the request: wrong PIN or invalid credentials and the operation is refused. Repeated failures lock the device.
- The HSM signs the digest internally: the private key is loaded into the HSM’s internal cryptographic processor, the signature is computed, and the key returns to protected storage. The key exists in usable form only inside the secure boundary.
- The signature comes out: the host receives the signature bytes and embeds them in the file alongside the certificate chain. The signed file is complete.
From the outside, the HSM behaves like a black box that answers signing requests. That is exactly the design intent.
Physical Security: Tamper Evidence and Tamper Response
HSMs defend against physical attack, not just software attack. The defenses scale with certification level:
- Tamper evidence: seals, coatings, and enclosures that cannot be opened without leaving visible damage. An attacker may get in, but the intrusion is detectable on inspection.
- Tamper response: sensors that detect drilling, probing, temperature manipulation, or voltage attacks, and respond by zeroizing (erasing) all key material before it can be extracted. The attacker who breaches the enclosure finds a device that has already destroyed its own keys.
- Environmental protection: resistance to side-channel attacks that infer keys from power consumption, electromagnetic emissions, or timing variations during cryptographic operations.
FIPS 140 Certification Levels Explained
FIPS 140-2 (and its successor FIPS 140-3) is the US government standard for cryptographic modules, used worldwide as the benchmark for HSM assurance. The four levels:
| Level | Requirement | Typical devices |
| Level 1 | Approved algorithms correctly implemented; no physical security requirements | Software crypto libraries, basic crypto hardware |
| Level 2 | Level 1 + tamper-evident physical security and role-based authentication | USB code signing tokens, many TPMs; the CA/B Forum minimum for code signing keys |
| Level 3 | Level 2 + tamper response with key zeroization, identity-based authentication, physical separation of interfaces | Enterprise network HSMs, cloud HSM services (DigiCert KeyLocker, eSigner run on Level 3 hardware) |
| Level 4 | Level 3 + complete envelope of protection detecting all physical attacks including environmental (temperature, voltage) manipulation | Rare; highest-security government and root CA contexts |
FIPS 140-3 replaced 140-2 for new validations in 2020, aligning with the international ISO/IEC 19790 standard. Existing 140-2 certificates remain valid through their transition period, which is why both designations appear in vendor documentation. For code signing purchases, either certification at Level 2 or above satisfies the CA/B Forum requirement.
HSM Form Factors: From Pocket to Datacenter
USB tokens
Pocket-sized devices (SafeNet eToken 5110, Thales Luna T-series, YubiHSM 2) holding one or a few keys. Operations run at human speed: fine for a developer signing releases, not built for high-volume automation. This is how CAs ship code signing certificates to individual publishers.
PCIe cards
Cards installed inside a server (Thales Luna PCIe, Entrust nShield Solo) delivering thousands of operations per second to that one host. Used where a single application needs high-throughput cryptography: database encryption, high-volume document signing.
Network appliances
Rack-mounted devices (Thales Luna Network HSM, Entrust nShield Connect, Utimaco) shared by many servers over the network with mutual authentication. This is the form factor inside Certificate Authorities, banks, and enterprise PKI deployments. Clustering provides redundancy; partitioning isolates different applications’ keys on the same physical device.
Cloud HSMs
HSM capacity as a service: AWS CloudHSM, Azure Dedicated HSM, Azure Key Vault Managed HSM, Google Cloud HSM, and CA-operated signing services (DigiCert KeyLocker, SSL.com eSigner, Microsoft Trusted Signing). The physical hardware sits in the provider’s datacenter; your keys are isolated in your partition; you reach the device through authenticated APIs.
The shared responsibility split: the provider secures the physical hardware, firmware, and datacenter; you secure the API credentials that authorize operations. A leaked cloud HSM credential lets an attacker sign through your key until revoked, even though the key itself never leaves the hardware. Credential hygiene matters as much as the hardware.
Where HSMs Are Used
| Industry / context | What the HSM protects | Why hardware is required |
| Certificate Authorities | Root and intermediate CA private keys | A stolen CA key lets an attacker issue trusted certificates for anything; root keys live offline in Level 3+ HSMs |
| Code signing | Publisher private keys (OV/EV) | CA/B Forum mandate since June 2023; prevents silent key copying that enabled signed malware |
| Payments | PIN encryption keys, card transaction keys | PCI PTS HSM requirements; card networks mandate certified hardware for PIN processing |
| Databases | Transparent Data Encryption (TDE) master keys | Separates encryption keys from the encrypted data; DBA access does not equal key access |
| Document signing | eIDAS qualified signature keys (EU) | Qualified electronic signatures legally require keys in certified devices (QSCDs) |
| Blockchain / custody | Wallet private keys for institutional crypto custody | Key theft equals irreversible asset theft; custody regulations require hardware protection |
Choosing an HSM for Code Signing
For software publishers, the decision usually reduces to two questions: who signs, and from where?
- One developer, one machine: the USB token your CA ships is sufficient. Plug in, enter the PIN, sign. No extra purchase needed.
- A team, or CI/CD pipelines: a cloud HSM signing service. Tokens cannot plug into cloud build runners, and sharing a physical token across a team creates both logistics problems and audit gaps. Cloud HSM services authenticate each signing request, log every operation, and work from any pipeline. Options include DigiCert KeyLocker, SSL.com eSigner, Sectigo’s cloud signing, and Microsoft Trusted Signing (around $10/month).
- Enterprise PKI or regulated workloads: network HSMs (Thales, Entrust, Utimaco) with clustering, partitioning, and formal key ceremony procedures. This tier involves dedicated infrastructure and is justified by internal CA operations, payment processing, or compliance mandates rather than code signing alone.
If your only HSM need is code signing in a CI/CD pipeline, do not buy a network HSM. The CA-operated cloud signing services exist precisely for this case: Level 3 hardware, per-operation authentication, audit logs, and signtool compatibility, at a fraction of the cost and zero hardware management.
Frequently Asked Questions
Is a YubiKey an HSM?
The standard YubiKey is a security key built for authentication (FIDO2, smart card, OTP) and can hold a small number of certificates and keys, but it is not marketed or certified as a general-purpose HSM. Yubico’s YubiHSM 2 is a distinct product: a USB device designed as a small HSM with FIPS-certified variants, suitable for protecting signing keys in servers and low-volume signing scenarios. For CA-issued code signing certificates, the relevant device is whatever certified token your CA ships, or their cloud HSM service.
Can keys be backed up if they can never leave the HSM?
Yes, through controlled mechanisms that preserve the security model. Enterprise HSMs support key wrapping: the key is exported only in encrypted form, wrapped by another key, and can only be unwrapped inside another HSM of the same security domain. Some support M-of-N splitting, where the backup is divided among multiple smart cards and a quorum (for example 3 of 5) is required to restore. The raw key never exists in usable form outside certified hardware at any point. For CA-issued code signing tokens, there is typically no backup path: if the token is lost or destroyed, the certificate is revoked and reissued on new hardware.
Does using an HSM make signing slower?
For code signing, not noticeably. The host hashes the file; the HSM only signs the small digest, an operation taking milliseconds on any form factor. A USB token adds a PIN prompt on first use of a session. Cloud HSMs add network round-trip latency, typically well under a second per signature. Throughput only becomes a consideration in high-volume scenarios (thousands of signatures per second), which is what PCIe and network HSMs are built for.
Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.
Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.