GlossaryHardware

Hardware Security Module (HSM)

A hardware security module stores keys and runs cryptography in a protected unit so keys never leave it. Enterprise and automotive HSMs, standards and typical flaws.

Updated October 7, 2026This page as Markdown

In short

A hardware security module (HSM) is a dedicated, hardened piece of hardware that generates, stores and uses cryptographic keys so that the keys never leave it in plain form. In data centres it is an appliance or card for PKI and payment systems; in vehicles and devices it is a separate core inside the microcontroller that anchors secure boot, authenticated messaging and diagnostic access. An HSM protects keys; whether the product is secure depends on how the firmware around it uses them.

What is a hardware security module?

A hardware security module is hardware built for one purpose: to keep cryptographic keys secret while still making them usable. Keys are generated inside, stored inside and used inside for signing, verification, encryption and key derivation; what leaves the module is the result, never the key. Good HSMs add protection against physical tampering, side channels and fault injection, and enforce who may use which key for what.

Two very different products share the name. The enterprise HSM is a network appliance or PCIe card that protects certificate authority keys, code signing keys, payment keys and database encryption keys. The embedded or automotive HSM is a security subsystem inside a microcontroller: a separate CPU core with its own RAM, flash and crypto accelerators, isolated from the application cores by hardware. The application talks to it over a defined interface and gets services such as verify this signature, compute this message authentication code, or derive this session key.

Where is it defined?

There is no single standard for the HSM as such. FIPS 140-3, which is based on ISO/IEC 19790, defines security requirements for cryptographic modules at four levels and is the reference for enterprise HSM evaluation. NIST SP 800-57 describes how keys should be generated, distributed, used and retired, which is what an HSM is meant to support. For vehicles, the EU research project EVITA defined the reference architecture for automotive HSMs with the full, medium and light variants that most automotive microcontroller vendors follow, and the Secure Hardware Extension (SHE) specification defined a minimal key store and AES engine that is still widely implemented. AUTOSAR integrates these through its crypto stack; ISO/SAE 21434 does not prescribe an HSM but expects the TARA to produce the requirements for key protection that an HSM then fulfils.

What it means in practice

In vehicles an HSM is the root of trust for secure boot, the keeper of the keys for SecOC message authentication, the engine behind UDS SecurityAccess and Authentication, and the holder of TLS keys for the back end. Having the hardware is now common. Using it correctly is not, and that is where our hardware and ECU penetration tests spend their time:

HSM present, keys elsewhere. The microcontroller has a security core, but the key that matters is a constant in the application flash because provisioning the HSM was planned for a later release.
The interface has no access control. Any code on the application core can ask the HSM to compute a MAC or decrypt a blob. A single bug in a network-facing parser then gives an attacker the HSM as an oracle.
Debug access left open. JTAG or SWD still enabled on production units, or the eFuses that lock them never programmed. The HSM holds the key, the debugger reads the result wherever the application stores it.
One key for the fleet. Extracting it from one unit, by firmware analysis or a hardware attack, compromises every unit.

Our analyses of power-electronics and lighting ECUs on 32-bit automotive microcontrollers have combined firmware reverse engineering with tests of the HSM interface to show which of these applied, and what the fix in the boot chain or the key management had to be.

Common misunderstandings

An HSM is not a security strategy; it is one component of one. A certified HSM says nothing about the firmware that calls it. And an HSM does not prevent firmware extraction or reverse engineering: it keeps the keys, not the code. If the code contains the vulnerability, the HSM will faithfully sign whatever the exploited code asks it to.

FAQ

Frequently asked questions

What is the difference between an HSM, a TPM and a secure element?

All three keep keys in protected hardware. A TPM is a standardised chip for PCs and servers with a fixed command set defined by the Trusted Computing Group. A secure element is a small tamper-resistant chip, typically in phones and payment cards. An HSM is the more general term: a network appliance in the data centre, or in embedded systems a dedicated security core inside the main microcontroller with its own memory and peripherals.

Does an HSM make my ECU or device secure?

It gives you a place where keys cannot be read out by firmware bugs or debug access. That is necessary but not sufficient. If the application can ask the HSM to sign or decrypt anything without checks, the HSM becomes a service for the attacker who controls the application. Secure boot, access control on the HSM interface and good key provisioning decide the outcome.

Is FIPS 140-3 certification required?

Not by EU product law. FIPS 140-3 is a US government requirement and a useful quality signal for enterprise HSMs. For automotive and industrial controllers the HSM is usually not certified at all; the evidence comes from the product security case, the TARA and testing of the integration.

Sources

← Glossary