← CRA Glossary
Product Security Engineering

Hardware Security Module (HSM)

A Hardware Security Module (HSM) is a dedicated hardware device that securely generates, stores, and manages cryptographic keys in a tamper-resistant environment. HSMs are used in CRA-compliant products to protect root keys for Secure Boot, firmware signing, and device identity — ensuring keys cannot be extracted even if other system components are compromised.

A Hardware Security Module (HSM) is a dedicated hardware device that securely generates, stores, and manages cryptographic keys in a tamper-resistant environment. HSMs are used in CRA-compliant products to protect root keys for Secure Boot, firmware signing, and device identity — ensuring keys cannot be extracted even if other system components are compromised.

Product Security Engineering

What Is a Hardware Security Module?

A Hardware Security Module (HSM) is a dedicated hardware device or chip that performs cryptographic operations and key management within a physically secure, tamper-resistant boundary. HSMs are designed so that cryptographic keys cannot be extracted — even if an attacker gains physical access to the device. All cryptographic operations using keys stored in the HSM are performed inside the module; the key material never leaves the HSM in plaintext. HSMs come in two main forms: network-attached HSMs (rack-mounted devices used in data centre environments for CA operations, code signing, and payment processing) and embedded HSMs (chips integrated into IoT devices, SoCs, or TPM modules). For CRA manufacturers, both types are relevant: network HSMs for the manufacturing and signing infrastructure, and embedded HSMs for device-level key protection.

CRA reference:Annex I

HSMs in CRA Manufacturing and Signing Workflows

Manufacturers subject to CRA requirements use network-attached HSMs in their product development and manufacturing infrastructure for:

  • Firmware signing: The root key that signs firmware images for Secure Boot must be protected in an HSM. If this key is stolen, an attacker can create firmware that all devices will accept as legitimate. HSM storage ensures the key is never exposed even during signing operations.
  • Certificate authority operations: Manufacturing-time certificate injection (provisioning device identity certificates) uses an HSM-backed CA to ensure certificate private keys are never exposed.
  • Code signing for OTA updates: All OTA update packages must be signed; the signing key should be HSM-protected to prevent supply chain attacks via compromised build systems.
  • Declaration of conformity: Some regulators accept HSM-backed digital signatures on electronic declarations of conformity as legally equivalent to physical signatures.
CRA reference:Annex I

Embedded HSMs and TPMs for Device-Level Security

For the device itself, embedded HSM functionality is provided by several hardware technologies:

  • TPM (Trusted Platform Module): A standardised chip (ISO/IEC 11889) providing secure key storage, attestation, and cryptographic operations. TPM 2.0 is widely available in x86 platforms and increasingly in ARM-based IoT hardware.
  • Secure Element (SE): A tamper-resistant microcontroller used in smart cards, SIM cards, and IoT devices for secure key storage and cryptographic operations. Common in payment terminals and NFC-enabled devices.
  • ARM TrustZone: A hardware security architecture in ARM processors that creates a 'secure world' isolated from the normal OS environment, where sensitive key material and cryptographic operations can be protected.
  • SoC-integrated OTP fuses: One-time-programmable fuses in SoCs that store root keys immutably — once programmed during manufacturing, they cannot be changed or overwritten.
CRA reference:Annex I

HSM Integration in Product Threat Modelling

The presence or absence of HSM-equivalent hardware in a product design should be explicitly addressed in the product's threat model, as required by the CRA's Annex I risk assessment obligations. Threat models should consider:

  • Physical attack scenarios: Can an attacker extract firmware signing keys by decapping the chip or probing debug interfaces? HSM/secure element protection mitigates this.
  • Debug interface lockdown: JTAG/SWD debug interfaces that remain accessible in production firmware can bypass all software security controls. Secure Boot should be combined with debug port lockdown.
  • Key injection security: The process by which production devices receive their unique keys during manufacturing is a critical security control. This process should be performed in a secure manufacturing environment with HSM-backed CA infrastructure.

Manufacturers should document their key management architecture in the Annex VII technical file as part of the security-relevant design documentation.

CVD Portal makes Hardware Security Module (HSM) compliance straightforward.

Public CVD submission portal, acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Free forever for EU manufacturers.

Start your free portal

Frequently asked

Is an HSM required for CRA compliance?+

The CRA does not mandate HSMs by name. However, the Annex I requirements for integrity protection, key management, and secure update mechanisms effectively require the functionality that HSMs provide for manufacturing infrastructure. Storing firmware signing keys in software (e.g., encrypted files on a build server) is inadequate for CRA-covered products because software key stores are vulnerable to extraction via malware on the build system. An HSM or equivalent hardware-backed key protection is the accepted mechanism for satisfying the key management requirements implicitly required by Annex I.

What FIPS level HSM should a CRA manufacturer use?+

The CRA does not reference FIPS (Federal Information Processing Standards), which is a US government standard. However, FIPS 140-2 or FIPS 140-3 certification is widely accepted as evidence of HSM quality and tamper resistance. For root CA and firmware signing key protection, FIPS 140-2 Level 3 or higher is the industry standard. Level 3 adds physical tamper resistance and is appropriate for the highest-security key material. Level 2 may be acceptable for less critical operations. European equivalents include CC (Common Criteria) EAL4+ evaluations for HSM hardware.

Are cloud-based HSMs acceptable for firmware signing?+

Cloud-based HSM services (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM) provide FIPS 140-2 Level 3 hardware in a managed cloud environment. They are generally acceptable for CRA firmware signing workflows, with some caveats: the manufacturer must be confident the cloud provider's access controls and key isolation adequately protect the signing key; the signing workflow must be implemented such that private key material never leaves the HSM API boundary; and the cloud HSM service continuity must be contractually assured. On-premises HSMs provide greater control but require more operational overhead.

Browse the full CRA Compliance Checklist

See how Hardware Security Module (HSM) fits into your complete CRA compliance programme.

View checklists →