HSM vs TPM: qué diferencia hay y cuál elegir

Introducción: dos módulos, dos filosofías de seguridad

En el ámbito de la criptografía aplicada y la protección de claves digitales, dos tecnologías aparecen sistemáticamente en los debates de los DSI y RSSI: el HSM (Hardware Security Module) y el TPM (Trusted Platform Module). Estos dos dispositivos hardware comparten un objetivo común — proteger operaciones criptográficas sensibles — pero su arquitectura, casos de uso y nivel de certificación difieren fundamentalmente. Confundir los dos puede llevar a elecciones de infraestructura inadecuadas e incluso a brechas de cumplimiento normativo. Este artículo te proporciona las claves para entender la diferencia HSM vs TPM, identificar cuándo usar uno u otro, y tomar la mejor decisión para tu organización en 2026.

---

¿Qué es un HSM (Hardware Security Module)?

Un Hardware Security Module es un dispositivo hardware dedicado, diseñado específicamente para generar, almacenar y gestionar claves criptográficas en un entorno físicamente y lógicamente seguro. Se trata de un componente autónomo — frecuentemente en forma de tarjeta PCIe, appliance de red o servicio cloud (HSM as a Service) — cuya función principal es ejecutar operaciones criptográficas de alto rendimiento sin exponer nunca las claves en texto plano fuera del módulo.

Características técnicas del HSM

Los HSM están certificados según estándares internacionales rigurosos, en particular FIPS 140-2 / FIPS 140-3 (niveles 2, 3 o 4) publicados por el NIST estadounidense, y Common Criteria EAL4+ según la norma ISO/IEC 15408. Estas certificaciones implican mecanismos de resistencia a falsificación física (tamper-resistance), detectores de intrusión y destrucción automática de claves en caso de intento de compromiso.

Un HSM típico ofrece:

• Capacidad de procesamiento elevada: hasta varios miles de operaciones RSA o ECDSA por segundo
• Multi-tenencia: gestión de cientos de particiones criptográficas independientes
• Interfaces estandarizadas: PKCS#11, Microsoft CNG, JCA/JCE, OpenSSL engine
• Registro de auditoría completo: registro inmutable de cada operación

Casos de uso típicos del HSM

Los HSM son el núcleo de la firma electrónica cualificada en el sentido del reglamento eIDAS, donde la clave privada del firmante debe ser generada y almacenada en un dispositivo de creación de firma cualificado (QSCD). También equipan autoridades de certificación (CA/PKI), sistemas de pago (HSM de protocolo PCI-DSS), infraestructuras de cifrado de bases de datos y entornos de code signing.

La firma electrónica cualificada en empresa se basa casi sistemáticamente en un HSM certificado como QSCD para garantizar el valor jurídico máximo de las firmas.

---

¿Qué es un TPM (Trusted Platform Module)?

El Trusted Platform Module es un chip de seguridad integrado directamente en la placa base de un ordenador, servidor u objeto conectado. Estandarizado por el Trusted Computing Group (TCG), cuya especificación TPM 2.0 también está normalizada bajo ISO/IEC 11889:2015, el TPM está diseñado para securizar la plataforma en sí misma más que para servir como servicio criptográfico centralizado compartido.

Arquitectura y funcionamiento del TPM

A diferencia del HSM, el TPM es un componente de uso único, vinculado a un equipamiento hardware específico. No puede ser trasladado o compartido entre varias máquinas. Sus funciones principales incluyen:

• Medición de integridad del arranque (Secure Boot, Measured Boot) mediante Platform Configuration Registers (PCR)
• Almacenamiento de claves vinculado a la plataforma: las claves generadas por el TPM solo pueden utilizarse en la máquina que las creó
• Generación de números aleatorios criptográficos (RNG)
• Atestación remota: probar a un servidor remoto que la plataforma está en un estado de confianza conocido
• Cifrado de volumen: BitLocker en Windows, dm-crypt con TPM en Linux se apoyan directamente en el TPM

Limitaciones del TPM para usos empresariales avanzados

El TPM 2.0 está certificado FIPS 140-2 nivel 1 como máximo, lo que es considerablemente inferior a las certificaciones FIPS 140-3 nivel 3 de los HSM profesionales. Su capacidad de procesamiento criptográfico es limitada (decenas de operaciones por segundo), y no soporta de forma nativa las interfaces PKCS#11 o CNG con tanta completitud como un HSM dedicado. Para la firma electrónica avanzada o cualificada, el TPM solo es generalmente insuficiente respecto a los requisitos eIDAS anexo II sobre QSCD.

---

Diferencias fundamentales HSM vs TPM: tabla comparativa

Entender la diferencia HSM vs TPM Trusted Platform Module pasa por una comparación estructurada de los criterios determinantes para la empresa.

Nivel de certificación y garantía de seguridad

| Criterio | HSM | TPM | |---|---|---| | Certificación FIPS | 140-3 nivel 2 a 4 | 140-2 nivel 1 | | Common Criteria | EAL4+ a EAL7 | EAL4 | | Cualificación eIDAS QSCD | Sí (ej: Thales Luna, Utimaco) | No | | Resistencia a falsificación física | Avanzada (autodestrucción) | Básica |

Capacidad, escalabilidad e integración

Los HSM son dispositivos multi-usuario y multi-aplicación: una única appliance de red puede servir simultáneamente a cientos de clientes, aplicaciones y servicios mediante PKCS#11 o REST API. Se integran en arquitecturas de alta disponibilidad (clusters activo-activo) y soportan débitos criptográficos industriales.

El TPM, en cambio, es mono-máquina y mono-tenant por diseño. Destaca en la securización de la estación de trabajo, la protección de credenciales de acceso Windows Hello for Business e integridad del firmware. Para operaciones de firma electrónica en flujos documentarios, un TPM no puede jugar el rol de un servicio criptográfico compartido.

Coste y despliegue

Un HSM de red de nivel empresarial (Thales Luna Network HSM, Utimaco SecurityServer, AWS CloudHSM) representa una inversión de 15.000 € a 80.000 € para hardware on-premise, o entre 1,50 € y 3,00 € por hora en modo cloud gestionado según los proveedores. El TPM, por su parte, está integrado sin coste adicional en la práctica totalidad de los PC profesionales, servidores y sistemas embarcados desde 2014 (obligatorio para Windows 11 desde 2021).

---

¿Cuándo usar un HSM, cuándo usar un TPM en empresa?

La respuesta a esta pregunta depende de tu contexto operativo, tus obligaciones normativas y la arquitectura de tu sistema de información.

Elegir un HSM para:

• Desplegar una PKI interna: las claves raíz de tu autoridad de certificación deben residir imperativamente en un HSM certificado para obtener la confianza de los navegadores (CA/Browser Forum Baseline Requirements)
• Emitir firmas electrónicas cualificadas: conforme al anexo II del reglamento eIDAS n°910/2014, los QSCD deben estar certificados según estándares equivalentes a EAL4+ como mínimo; el comparativo de soluciones de firma electrónica detalla estos requisitos
• Securizar transacciones financieras de alto volumen: los estándares PCI-DSS v4.0 (sección 3.6) imponen la protección de claves de cifrado de datos de tarjeta en HSM
• Cifrado de bases de datos o cloud: AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM permiten mantener el control de las claves (BYOK / HYOK)
• Code signing e integridad de builds CI/CD: la firma de artefactos software para supply chain segura requiere un HSM para prevenir el robo de claves

Elegir un TPM para:

• Securizar el arranque de estaciones de trabajo y servidores: Secure Boot + Measured Boot + atestación remota mediante TPM 2.0 constituye la base del Zero Trust en endpoint
• Cifrado de discos full-disk: BitLocker with TPM protege los datos en reposo sin dependencia de un servicio externo
• Autenticación hardware de estaciones: Windows Hello for Business usa el TPM para almacenar claves privadas de autenticación sin posibilidad de extracción
• Conformidad NIS2 sobre seguridad de endpoints: la directiva NIS2 (UE 2022/2555), transpuesta en derecho francés por la ley del 13 de junio de 2024, impone medidas técnicas proporcionales para la seguridad de sistemas de información; el TPM contribuye directamente a la securización de activos hardware
• Proyectos IoT industrial: los TPM embarcados en autómatas y sistemas SCADA permiten atestación remota sin infraestructura HSM dedicada

Arquitecturas híbridas HSM + TPM

En grandes organizaciones, HSM y TPM no se oponen: se complementan. Un servidor equipado con TPM 2.0 puede atestar su integridad ante un servicio de gestión centralizado, mientras que las operaciones criptográficas de negocio (firma, cifrado de datos de aplicación) se delegan a un cluster HSM de red. Esta arquitectura es recomendada por la ANSSI en su guía sobre control de riesgos vinculados a proveedores de servicios de confianza (PSCE). Consultar el glosario de firma electrónica puede ayudar a los equipos técnicos a armonizar la terminología al definir esta arquitectura.

Marco legal y normativo aplicable a HSM y TPM

La elección entre HSM y TPM compromete directamente la conformidad de tu organización a varios referentes normativos europeos e internacionales.

Reglamento eIDAS n°910/2014 y eIDAS 2.0 (reglamento UE 2024/1183)

El artículo 29 del reglamento eIDAS impone que las firmas electrónicas cualificadas se creen mediante un Qualified Signature Creation Device (QSCD), definido en el anexo II. Estos dispositivos deben garantizar la confidencialidad de la clave privada, su unicidad e inviolabilidad. La lista de QSCD reconocidos es publicada por los organismos nacionales de acreditación (en Francia: ANSSI). Los HSM certificados FIPS 140-3 nivel 3 o Common Criteria EAL4+ figuran en estas listas; los TPM no figuran. Un proveedor de firma como Certyneo se basa en HSM cualificados para garantizar el máximo valor probatorio de las firmas emitidas.

Código Civil francés, artículos 1366 y 1367

El artículo 1366 reconoce el valor jurídico del escrito electrónico «a condición de que la persona de cuya emisión proceda pueda ser debidamente identificada y de que esté establecido y conservado de manera que se garantice su integridad». El artículo 1367 precisa las condiciones de la firma electrónica fiable, remitiendo implícitamente a los requisitos eIDAS para firmas cualificadas.

RGPD n°2016/679, artículos 25 y 32

El principio de privacy by design (artículo 25) y la obligación de medidas técnicas apropiadas (artículo 32) imponen la protección de claves criptográficas utilizadas para cifrar datos personales. El recurso a un HSM certificado constituye una medida del estado de la técnica (estado de la técnica en el sentido del considerando 83 del RGPD) para demostrar conformidad durante un control de la CNIL.

Directiva NIS2 (UE 2022/2555), transpuesta en Francia

La directiva NIS2, aplicable a entidades esenciales e importantes desde octubre de 2024, impone en el artículo 21 medidas de gestión de riesgos incluyendo la seguridad de la cadena de suministro software y el cifrado. Los HSM responden directamente a estos requisitos para operaciones críticas, mientras que los TPM contribuyen a la securización de endpoints.

Normas ETSI

La norma ETSI EN 319 401 (requisitos generales para proveedores de servicios de confianza) y ETSI EN 319 411-1/2 (requisitos para CA que emiten certificados cualificados) imponen el almacenamiento de claves CA en HSM certificados. La norma ETSI EN 319 132 (XAdES) y ETSI EN 319 122 (CAdES) definen los formatos de firma que presuponen el uso de módulos securizados certificados.

Recomendaciones ANSSI

La ANSSI publica el referencial RGS (Referencial General de Seguridad) y sus guías sobre HSM, recomendando el uso de módulos certificados para toda infraestructura PKI sensible en organismos públicos y OIV/OSE. El incumplimiento de estas recomendaciones puede constituir un fallo en las obligaciones NIS2 para entidades concernidas.

Escenarios de uso: HSM o TPM según el contexto

Escenario 1: una sociedad de gestión de activos financieros con PKI interna

Una sociedad de gestión que gestiona varios miles de millones de euros de activos bajo gestión necesita firmar electrónicamente reportes normativos (AIFMD, MiFID II) y contratos de inversión con máximo valor jurídico cualificado. Despliega una PKI interna cuyas claves raíz (Root CA) e intermedias (Issuing CA) están protegidas en dos HSM de red en cluster de alta disponibilidad, certificados FIPS 140-3 nivel 3. Los certificados cualificados se emiten en HSM de partners conformes a eIDAS QSCD. Resultado: el 100 % de las firmas tienen valor cualificado, los auditorios normativos AMF confirman conformidad, y el plazo de firma de documentos de inversión pasa de 4 días a menos de 2 horas. El coste de infraestructura HSM se amortiza en menos de 18 meses respecto a los costes de no conformidad potenciales.

Escenario 2: una PYME industrial de 150 empleados securizando su parque de estaciones de trabajo

Una PYME del sector de fabricación aeronáutica, proveedor de rango 2 sujeto a requisitos CMMC (Cybersecurity Maturity Model Certification) y recomendaciones NIS2, debe securizar 150 estaciones Windows contra robo de datos técnicos sensibles. El RSSI despliega BitLocker con TPM 2.0 en la totalidad del parque, acoplado a Windows Hello for Business para autenticación sin contraseña. La atestación remota mediante TPM se integra en la solución MDM (Microsoft Intune). Ningún HSM es necesario en este contexto: los TPM integrados en estaciones Dell y HP son suficientes. Resultado: el riesgo de fuga de datos por robo físico de laptop se reduce a casi cero, y la puntuación de madurez ciberseguridad de la PYME progresa un 40 % según autoevaluación CMMC. Coste adicional: 0 € (TPM ya integrado en máquinas).

Escenario 3: un operador de plataforma SaaS de firma electrónica multi-cliente

Un operador SaaS que proporciona servicios de firma electrónica a varios cientos de empresas clientes debe garantizar el aislamiento criptográfico entre clientes y la cualificación eIDAS de su servicio. Despliega una arquitectura basada en HSM en modo cloud dedicado (AWS CloudHSM o Thales DPoD), con una partición HSM por tenant de gran tamaño y un pool compartido para clientes estándar. Cada cliente se beneficia de claves aisladas en su partición, auditables independientemente. Los TPM equipan los servidores de aplicación para atestación de integridad de la plataforma durante auditorios de certificación eIDAS (QTSP). Resultado: el operador obtiene la cualificación QTSP ante la ANSSI, permitiendo emitir firmas cualificadas. El modelo HSM as a Service reduce los capex de infraestructura un 60 % respecto a solución on-premise, según benchmarks sectoriales comparables.

Conclusión

La diferencia entre HSM y TPM es fundamental: el HSM es un servicio criptográfico compartido, de alto rendimiento y multi-aplicativo, indispensable para PKI, firmas cualificadas eIDAS y conformidad PCI-DSS o NIS2 a gran escala. El TPM es un componente de confianza vinculado a una plataforma hardware específica, ideal para securizar endpoints, arranque seguro y autenticación local. En la mayoría de arquitecturas enterprise maduras de 2026, ambos coexisten con roles complementarios e insustituibles.

Si tu organización busca desplegar una solución de firma electrónica cualificada apoyándose en una infraestructura HSM certificada, sin gestionar la complejidad técnica internamente, Certyneo te propone una plataforma SaaS llave en mano, conforme a eIDAS y RGPD. Descubre los precios Certyneo o contacta nuestros expertos para una auditoría de tus necesidades criptográficas.