HSM vs TPM vs Secure Enclave vs QSPU: Where Should Cryptographic Keys Live?

Cryptographic keys should be kept in a security boundary appropriate to their purpose, value, and workload. A device identity key, a certificate-authority key, a disk-encryption key, and a high-volume TLS traffic key do not have identical requirements. The relevant questions are where the key is generated, where it is stored, where it is used, whether it enters ordinary host memory, and what happens when the host operating system is compromised.

A hardware security module, or HSM, is a dedicated cryptographic device that safeguards and manages cryptographic keys and performs cryptographic operations. HSMs are commonly used for certificate-authority keys, code-signing keys, payment keys, database master keys, and other long-lived, high-value secrets. A key generated inside an HSM can be configured as non-exportable, so applications submit requests such as signing, decryption, wrapping, or unwrapping without receiving the raw private key. HSMs are available as network appliances, PCIe cards, USB devices, and managed cloud services.

An HSM is usually the appropriate location for a small number of high-value keys that must be retained for a long time and used under strict access control. It is designed for key custody, policy enforcement, auditability, backup procedures, operator authorization, and—in many models—physical tamper detection and response. It is not necessarily designed to carry all high-volume data traffic for a storage volume, database, or TLS service. In many deployments, the HSM protects a master key or private key while a separate software component performs bulk encryption on the host.csrc.

A Trusted Platform Module, or TPM, is a standardized secure cryptoprocessor attached to, integrated with, or implemented within a computing platform. TPMs are primarily used to establish device identity, record platform measurements, support attestation, protect device-bound secrets, and release keys only when expected platform conditions are met. TPM 2.0 provides facilities for cryptographic key generation, protected storage, signatures, sealing, and policy-controlled use.

A TPM is well suited to protecting a laptop or server’s disk-unlock key, device identity key, boot-integrity measurements, or attestation key. For example, a TPM can bind a disk-unlock key to expected measurements of firmware, Secure Boot configuration, bootloader, and operating-system state. If the platform is changed unexpectedly, the TPM can refuse to release the protected key. This protects against offline theft, unauthorized boot changes, and certain physical-access scenarios.

A TPM is not normally used as a high-throughput data-encryption engine. It has limited storage and is optimized for platform security operations rather than continuous encryption of server storage or TLS record traffic. When a TPM releases or unwraps a disk-encryption key for a conventional software full-disk-encryption stack, the host operating system can then use that active key to encrypt and decrypt data. The TPM protects the release of the key; it does not necessarily keep the working key outside host memory for the entire mounted session.nvlpubs.

A secure enclave, more generally called a trusted execution environment or TEE, is an isolated region of a processor designed to protect selected code and data from other software running on the system. Secure enclaves can isolate cryptographic keys, application logic, and sensitive data from the operating system, hypervisor, or other processes, depending on the architecture and threat model. Examples include processor-backed confidential-computing and application-isolation technologies.

A secure enclave is useful when an application needs to process secrets in a protected CPU memory region while continuing to execute custom application code. An enclave can hold an application key and perform cryptographic operations without exposing the protected memory region to ordinary processes. Its security depends on the processor architecture, enclave runtime, firmware, attestation process, application code, and mitigation of implementation-specific attacks. It remains part of the server’s processor platform rather than a separate cryptographic device with its own independent data path.

A QSPU is a hardware cryptographic processing unit designed to execute selected cryptographic workloads within a dedicated processing boundary. In the CTHR-01 architecture, the QSPU is implemented as a PCIe-attached FPGA accelerator with attached high-bandwidth memory. It is designed to generate, retain, and use selected keys within the FPGA boundary while performing data-path cryptography for storage encryption, TLS record protection, and post-quantum key establishment.

For the CTHR-01 storage path, the data-encryption key is generated inside the FPGA and used for AES-256-XTS block-device encryption. The key is stored outside the card only as a wrapped representation. For the keyless TLS 1.3 path, ephemeral private values, ECDH shared secrets, and derived traffic keys are generated or consumed within the FPGA and attached memory; the intended hardware path does not return those materials across PCIe to the host. ML-KEM-768 decapsulation keys are also generated and retained in an on-card vault on the supported post-quantum path.

A QSPU differs from a conventional HSM because it is designed to combine key custody with selected high-volume encryption paths. It differs from a TPM because it is not primarily a platform-attestation component or a disk-unlock mechanism. It differs from a secure enclave because the cryptographic boundary is implemented in dedicated hardware outside the host CPU, with data transferred to the hardware while selected secrets remain within the accelerator’s processing boundary.

Technology	Primary role	Typical key location	Typical workload	Main security value
HSM	High-assurance key custody and cryptographic operations	Dedicated tamper-resistant module	Signing, key wrapping, decryption, certificate issuance, payment cryptography	Keeps high-value keys in a controlled cryptographic module
TPM	Platform identity, measured boot, attestation, sealed storage	Motherboard, processor package, or platform security component	Device identity, boot measurements, disk-key release	Binds secrets to a specific device and measured platform state
Secure enclave / TEE	Isolated execution of selected application code and data	Protected processor memory region	Confidential application logic, key handling, protected computation	Isolates selected code and data from other host software
QSPU	Hardware-boundary execution of selected cryptographic data paths	Dedicated FPGA fabric and attached memory	Storage encryption, TLS key exchange and record protection, PQC key establishment	Combines key custody with selected data-path cryptographic execution

No single technology replaces the others. A server can use a TPM for measured boot, an HSM for a certificate-authority or code-signing key, a secure enclave for confidential application logic, and a QSPU for selected storage and TLS encryption paths. NIST key-management guidance emphasizes that cryptographic systems must manage keys throughout their lifecycle, including generation, storage, access control, use, rotation, backup, recovery, and destruction. The location of a key is one part of that lifecycle; the security boundary, interfaces, operational controls, and recovery design determine whether the key remains protected in practice.