Por qué la confianza postcuántica comienza dentro del hardware

Publicado: septiembre de 2025. Actualizado: agosto de 2026. Revisado por los equipos de Servicios HSM y Asesoría PQC de Encryption Consulting.

Todo plan de migración post-cuántica acaba encontrándose con el mismo obstáculo: el algoritmo puede estandarizarse, la aplicación puede actualizarse y la política de certificados puede reescribirse, pero nada de esto sirve de nada si la clave privada de la que depende todo se generó, almacenó o firmó en un hardware que no es fiable para realizar estas tareas correctamente. Una biblioteca de software puede implementar la criptografía post-cuántica (PQC) a la perfección y aun así verse comprometida por una clave filtrada a través de un canal lateral, un generador de números aleatorios que no era realmente aleatorio o un firmware que recurrió silenciosamente a un algoritmo clásico bajo carga. Por eso, la confianza post-cuántica debe comenzar en el hardware, específicamente en el Módulo de Seguridad de Hardware (HSM), que es el que gestiona la generación de claves y la firma para todo lo que se encuentra después.

Esto cobra importancia ahora porque los estándares ya no son teóricos. El NIST finalizó FIPS 203 (ML-KEM) , FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) el 13 de agosto de 2024, y los proveedores de HSM han dedicado el último año a convertir esta estandarización en firmware comercial. La pregunta que queda para la mayoría de las empresas no es qué algoritmo elegir, sino si el hardware subyacente a su PKI, terminadores TLS, canalización de firma de código y sistemas de gestión de claves puede ejecutar estos algoritmos dentro de un límite de seguridad validado, a escala de producción, sin comprometer la disponibilidad.

¿Por qué la preparación para la era post-cuántica comienza en el nivel de hardware y HSM?

La preparación para la computación cuántica probabilística (PQC) comienza en el nivel de hardware, ya que el módulo de seguridad de hardware (HSM) es la raíz de confianza para cada clave que el algoritmo procesa. Si el módulo que genera, almacena y utiliza una clave ML-KEM o ML-DSA no es confiable, la solidez matemática del algoritmo resulta irrelevante. Cuatro garantías a nivel de hardware se mantienen directamente en la era PQC, y cada una cambia de manera específica y verificable una vez que se introducen claves post-cuánticas de mayor tamaño.

• Identidad inmutable del dispositivo. Una identidad vinculada al hardware, imposible de clonar o falsificar, autentica el propio módulo de seguridad de hardware (HSM) ante los sistemas que dependen de él. En un contexto poscuántico, esta identidad debe firmarse cada vez más con un algoritmo resistente a la computación cuántica para que un atacante con capacidad cuántica futura no pueda falsificarla retroactivamente.
• Almacenamiento de llaves a prueba de manipulaciones. Las claves generadas y utilizadas dentro del entorno criptográfico del HSM nunca salen en texto plano. Esto cobra mayor importancia con PQC, ya que las claves privadas ML-DSA y SLH-DSA, así como el estado operativo que requieren algunos esquemas de firma, son más grandes y su regeneración resulta más costosa en caso de verse comprometida.
• Generación de números aleatorios verdaderos. Los esquemas basados ​​en retículos, como ML-KEM y ML-DSA, dependen de una entropía de alta calidad para la generación de claves y, en algunas implementaciones, para la firma aleatoria. Un generador de números aleatorios verdaderos (TRNG) basado en hardware, que utiliza ruido físico, constituye una base más sólida para el material de clave PQC que un generador pseudoaleatorio por software.
• Arranque seguro y firma de firmware. El HSM valida su propio firmware antes de ejecutarse. A medida que las actualizaciones de firmware PQC se vuelven rutinarias, el arranque seguro necesita verificar esas actualizaciones con firmas resistentes a la computación cuántica, que es precisamente lo que exige la norma CNSA 2.0: LMS, XMSS o ML-DSA en contextos de firma de firmware y software.

Ninguna de estas cuatro garantías es nueva. Lo que cambia en la era PQC es el tamaño y la forma del material que protegen, y es ahí donde se manifiestan la mayoría de las deficiencias en la preparación para PQC en los sistemas HSM de producción.

CBOM seguro

Obtenga visibilidad completa con descubrimiento criptográfico continuo, inventario automatizado y remediación de PQC basada en datos.

Solicitar demostración

¿Cuál es el estado actual del soporte PQC de los proveedores de HSM?

Los tres principales proveedores de HSM, Thales, Entrust y Utimaco, ahora incluyen soporte para ML-KEM y ML-DSA validado por NIST CAVP en su firmware actual, como una actualización en lugar de un reemplazo de hardware. La cobertura de SLH-DSA y los esquemas de firma basados ​​en hash con estado es donde los proveedores aún difieren, y la validación del módulo FIPS 140-3, que combina algoritmos PQC dentro del límite certificado, y no solo los algoritmos de forma aislada, es el factor diferenciador más reciente y trascendental.

Proveedor y línea de productos	Envío de algoritmos PQC	Método de entrega	Estado de FIPS 140-3 (a fecha de actualización)
Módulo de seguridad de hardware Thales Luna (firmware 7.9, julio de 2025)	ML-KEM (FIPS 203), ML-DSA (FIPS 204), PQC híbrido para copia de seguridad y sincronización de claves	Actualización de firmware para hardware Luna existente, no se necesita ningún módulo de funcionalidad externo.	Se informó que la validación FIPS 140-3 de nivel 3 estaba en curso al momento de la publicación.
Thales Trusted Cyber ​​Technologies Luna T-Series (firmware 7.15.1, certificado 5450)	ML-DSA, ML-KEM, LMS, el conjunto completo de PQC de CNSA 2.0	Luna PCIe HSM fabricado en EE. UU., Luna Network HSM, Luna como servicio, CipherTrust Manager	Validado según FIPS 140-3 Nivel 3 a partir de agosto de 2026, la primera línea HSM en combinar todos los algoritmos PQC de CNSA 2.0 dentro de una única validación FIPS 140-3.
Thales Luna 8 (anunciado en agosto de 2026)	Algoritmos clásicos y post-cuánticos en un procesador criptográfico personalizado.	Nueva generación de hardware, diseñada específicamente para cargas de trabajo de la era de la inteligencia artificial y el control de calidad de procesos (PQC).	La evaluación de FIPS 140-3 Nivel 3 y Criterios Comunes está en curso y aún no se ha finalizado al momento del anuncio.
Entrust nShield (firmware 13.8.0, publicado el 22 de agosto de 2025)	ML-DSA, ML-KEM, SLH-DSA, los tres validados por NIST CAVP.	Compatibilidad con firmware nativo, anunciada con validación NIST CAVP el 10 de septiembre de 2025.	Se confirma la validación CAVP a nivel de algoritmo; verifique el estado FIPS 140-3 actual a nivel de módulo antes de la adquisición.
Módulo de seguridad de hardware (HSM) Utimaco u.trust GP (series Se y CSe)	ML-DSA (FIPS 204), ML-KEM (FIPS 203), LMS, con SLH-DSA en la hoja de ruta.	Paquete de aplicación Quantum Protect, activado en el hardware existente, sin necesidad de cambiar el hardware.	Se confirma la validación CAVP a nivel de algoritmo para los algoritmos de envío; incluye un diseño de gestión de estado propietario para LMS y XMSS en escenarios de alta disponibilidad y respaldo.

Hay dos puntos que conviene aclarar. Primero, la validación del algoritmo y la validación del módulo no son lo mismo, y considerar el anuncio CAVP de un proveedor como prueba de que un dispositivo HSM específico está completamente validado según FIPS 140-3 con PQC integrado es un error común en las adquisiciones; Encryption Consulting aborda esta distinción en detalle en ¿ Están sus HSM preparados para PQC? Segundo, la compatibilidad con SLH-DSA (FIPS 205) es realmente desigual: Entrust lo tiene validado, Utimaco lo incluye en su hoja de ruta, y las fuentes de Thales revisadas para esta actualización no lo confirman en el firmware de distribución. Si su hoja de ruta de PQC depende específicamente de SLH-DSA, por ejemplo, como una alternativa conservadora basada en hash para claves de firma de larga duración, confirme el estado actual del proveedor directamente antes de comprometerse con una plataforma.

¿Qué es la criptoagilidad a nivel de hardware y por qué es importante?

La criptoagilidad a nivel de hardware permite que un HSM adopte nuevos algoritmos mediante una actualización de firmware y un SDK modular, sin necesidad de reemplazar el hardware físico ni rediseñar las aplicaciones que lo utilizan. Las actualizaciones de firmware de Thales, Entrust y Utimaco mencionadas anteriormente son la prueba práctica: las tres añadieron ML-KEM y ML-DSA al hardware que los clientes ya poseían, mediante una actualización en lugar de un reemplazo completo.

La criptoagilidad del hardware depende de algunas decisiones de diseño específicas que conviene tener en cuenta en cualquier decisión de adquisición o renovación de un módulo de seguridad de hardware (HSM):

• Mecanismo de actualización del firmware. ¿Es posible ofrecer compatibilidad con nuevos algoritmos mediante una actualización de firmware firmada, y está protegido dicho proceso de actualización por una firma resistente a la computación cuántica para que no pueda ser falsificado durante la transición?
• Proveedores criptográficos modulares. ¿La compatibilidad con PQC está integrada en el firmware principal, como en el enfoque de Thales Luna, o se ofrece como un paquete de aplicaciones independiente, como en el caso de Quantum Protect de Utimaco? Ambos modelos funcionan, pero las implicaciones en cuanto a adquisición y licenciamiento difieren.
• Alineación de API y estándares. ¿El HSM expone las operaciones PQC a través de los identificadores del mecanismo PKCS#11 actuales y las versiones del SDK del proveedor que sus aplicaciones ya utilizan, o requiere una ruta de integración paralela?
• Margen de maniobra para el próximo estándar. El NIST sigue evaluando esquemas de firma adicionales más allá de los tres estándares FIPS iniciales. Una plataforma HSM ágil debería poder integrar una cuarta familia de algoritmos sin necesidad de un nuevo ciclo de hardware.

La criptoagilidad es una medida de precaución, no una meta final. Un HSM que teóricamente se puede actualizar solo es ágil en la práctica si su organización cuenta con el proceso de actualización de firmware, el entorno de pruebas y la disciplina de control de cambios necesarios para aplicar dicha actualización antes de que los algoritmos que protege se conviertan en el eslabón débil.

¿Qué aspecto tiene una topología de despliegue HSM híbrida clásica más PQC?

Casi ninguna organización pasa directamente de operaciones HSM exclusivamente clásicas a operaciones HSM nativas de PQC. La topología de implementación realista ejecuta algoritmos clásicos y post-cuánticos en paralelo dentro del mismo clúster HSM durante un período de transición de varios años, utilizando intercambio de claves híbrido y, cuando la aplicación lo permite, firmas duales o compuestas.

Una topología híbrida típica tiene tres capas:

1. La capa de clúster HSM. Un clúster HSM de alta disponibilidad, ya sean dispositivos locales, instancias HSM en la nube o un HSM como servicio El despliegue ejecuta un firmware que admite algoritmos clásicos (RSA, ECC) y PQC (ML-KEM, ML-DSA) simultáneamente, con particionamiento para que diferentes grupos de aplicaciones puedan migrarse en cronogramas independientes.
2. La capa de protocolo. Los terminadores TLS y los sistemas de emisión de PKI negocian un intercambio de claves híbrido, por ejemplo, X25519 combinado con ML-KEM-768, de modo que una sesión permanece segura si se vulnera el componente clásico o el post-cuántico. Las autoridades de certificación emiten certificados compuestos o duales cuando el ecosistema del cliente los admite, y recurren a certificados clásicos únicamente para los clientes que aún no negocian PQC.
3. La capa de aplicación. Los flujos de trabajo de firma de código, cifrado de bases de datos y firma de documentos de larga duración invocan al HSM para que utilice el algoritmo apropiado en cada caso de uso, en función del tiempo que la firma o el texto cifrado deba permanecer fiable, en lugar de cambiar todas las cargas de trabajo a PQC el mismo día.

La decisión sobre qué capa migrar primero debe basarse en la exposición, no en la conveniencia. El establecimiento de claves utilizado para la confidencialidad (claves de sesión TLS, túneles VPN, copias de seguridad cifradas) está expuesto a ataques de recolección y descifrado, ya que el texto cifrado capturado puede descifrarse retroactivamente una vez que exista una computadora cuántica criptográficamente relevante. Las firmas digitales utilizadas para la autenticación presentan un perfil de riesgo diferente: una firma validada hoy no se invalida retroactivamente, por lo que las cargas de trabajo de firma generalmente pueden secuenciarse ligeramente después de las de cifrado, con la notable excepción de las claves de firma de código y firmware de larga duración, donde una firma falsificada dentro de años seguiría siendo perjudicial hoy. Esta priorización basada en la exposición es la misma lógica que Encryption Consulting aplica en RSA: Secure Today, Scheduled for Retirement , que analiza el lado del algoritmo clásico de esta misma migración.

¿Cómo se aplica el límite FIPS 140-3 a los HSM validados por PQC?

La validación FIPS 140-3 se aplica a un límite definido del módulo criptográfico, no a un algoritmo en abstracto. Esta distinción es el aspecto más incomprendido de la adquisición de PQC para HSM. El Programa de Validación de Algoritmos Criptográficos (CAVP) del NIST comprueba si una implementación de ML-KEM o ML-DSA es matemáticamente correcta. El Programa de Validación de Módulos Criptográficos (CMVP) del NIST comprueba si el módulo completo de hardware y firmware, incluyendo la implementación del algoritmo, la gestión de claves, la protección física contra manipulaciones y las autocomprobaciones, cumple con los requisitos FIPS 140-3 como una unidad. Un proveedor puede tener un certificado CAVP válido para ML-KEM mucho antes de que el dispositivo HSM que lo ejecuta tenga un certificado de módulo FIPS 140-3 actualizado que cubra las operaciones PQC dentro del límite.

Esta brecha no es hipotética. La actualización de firmware de Thales Luna de julio de 2025 incluyó soporte para ML-KEM y ML-DSA con una validación FIPS 140-3 Nivel 3 descrita como en curso, lo que significa que los algoritmos estaban disponibles antes de que se finalizara el certificado del módulo que los cubría. No fue hasta agosto de 2026 que la serie Luna T de Thales Trusted Cyber ​​Technologies, con el firmware 7.15.1 bajo el certificado 5450, se convirtió en la primera línea HSM documentada en combinar el conjunto completo de algoritmos CNSA 2.0 PQC, ML-DSA, ML-KEM y LMS, dentro de una validación FIPS 140-3 Nivel 3 completada. Esto representa aproximadamente un año entre la disponibilidad de los algoritmos y un límite de módulo validado que los compradores regulados pueden citar en una auditoría.

Para organizaciones en entornos regulados, como DFARS, FedRAMP, PCI DSS o agencias sujetas a CNSA 2.0, la regla práctica es: no considere el anuncio del algoritmo PQC de un proveedor como equivalente a un módulo validado que pueda implementar en una carga de trabajo regulada. Pregunte específicamente qué número de certificado FIPS 140-3 cubre la versión de firmware que pretende ejecutar y confirme que la lista de algoritmos validados de dicho certificado incluya los algoritmos PQC que planea utilizar, y no solo el conjunto de algoritmos clásicos originales del módulo.

¿Qué cambios se producen en la ceremonia de entrega de llaves para la generación de claves PQC?

Una ceremonia de clave PQC sigue la misma estructura de gobernanza que una clásica: control dual, generación presenciada, funciones de custodio documentadas, pero los detalles técnicos de dicha ceremonia cambian de maneras que un guion escrito para RSA o ECC no contemplará.

• Material clave y de firma de mayor tamaño. Una clave pública ML-KEM-768 ocupa aproximadamente 1.2 KB, mientras que una clave pública y su firma ML-DSA-65 ocupan varios kilobytes en conjunto, en comparación con los 32 a 64 bytes de una clave ECC de seguridad equivalente. Los guiones de la ceremonia, la planificación de la capacidad de los medios de respaldo y cualquier proceso que transcriba o verifique manualmente las huellas digitales de las claves deben tener esto en cuenta antes de la ceremonia, no durante ella.
• Requisitos de entropía. La generación de claves basada en retículos consume más entropía por operación que la generación de claves ECC. Confirme que el rendimiento del generador de números aleatorios verdaderos (TRNG) del HSM esté validado para los volúmenes de generación de claves PQC que requiere su plan de ceremonia, especialmente para eventos de generación masiva de claves previos a una ola de migración.
• Las firmas basadas en hash con estado necesitan disciplina de estado, no solo disciplina de clave. LMS y XMSS, los esquemas basados ​​en hash con estado aprobados por CNSA 2.0 para la firma de firmware y software, generan un número fijo de hojas de firma de un solo uso por clave. Los procedimientos de la ceremonia deben documentar cómo se realiza el seguimiento del estado de firma de la clave privada y nunca reutilizarla, ni siquiera en copias de seguridad o clones de dicha clave, ya que reutilizar una hoja de firma de un solo uso invalida por completo la garantía de seguridad.
• Guion de la ceremonia y formación de testigos. Los testigos y custodios capacitados en las ceremonias RSA y ECC necesitan una breve y específica explicación sobre lo que realmente confirma un paso de verificación de la ceremonia PQC, ya que comparar visualmente una huella digital de clave pública de varios kilobytes no es lo mismo que comparar una huella digital ECC corta.

¿Cómo se evalúa la preparación para el PQC en toda su infraestructura de HSM?

Una evaluación estructurada determina si cada HSM de su infraestructura puede ejecutar PQC actualmente, si se puede actualizar para ejecutarlo o si necesita ser reemplazado antes de la fecha límite de migración. Encryption Consulting lleva a cabo este proceso en cinco pasos:

1. Inventaria cada módulo de seguridad de hardware (HSM) y su versión de firmware. Cree un inventario completo de activos criptográficos que abarque dispositivos locales, instancias HSM en la nube y módulos integrados, registrando el modelo, la versión del firmware y el estado actual del certificado FIPS 140-3 para cada uno.
2. Asociar el uso de algoritmos con la exposición empresarial. Identificar qué HSM protegen el establecimiento de claves para datos confidenciales de larga duración (exposición de recopilación inmediata y descifrado posterior) frente a las firmas para artefactos de confianza de larga duración, como las CA raíz y las claves de firma de firmware, ya que estos factores generan diferentes niveles de urgencia en la migración.
3. Confirme la hoja de ruta de control de calidad del proveedor y el estado de validación por modelo. Para cada modelo de HSM en el sistema, confirme la disponibilidad actual del firmware ML-KEM, ML-DSA y, si es necesario, SLH-DSA o LMS/XMSS, así como el certificado FIPS 140-3 que cubre dicho firmware, y no solo el anuncio general de PQC del proveedor.
4. Probar el funcionamiento híbrido en un entorno que no sea de producción. Antes de implementarlo en producción, valide las actualizaciones de firmware, el intercambio de claves híbridas y el manejo de claves y firmas de mayor tamaño con tráfico de aplicaciones reales, incluyendo el rendimiento y la latencia bajo la carga prevista.
5. Elaborar el plan de migración y desmantelamiento por fases. Secuenciar las actualizaciones según la exposición y el riesgo empresarial, marcar cualquier HSM que no pueda alcanzar la preparación PQC mediante firmware y requiera reemplazo, y establecer fechas de desmantelamiento que se alineen con su cronograma de cumplimiento interno o CNSA 2.0.

¿Qué consideraciones de alta disponibilidad y copia de seguridad se aplican a los HSM habilitados para PQC?

El diseño de alta disponibilidad y respaldo para HSM habilitados para PQC debe resolver dos problemas que el clúster HSM clásico no resolvía: el movimiento de material de clave más grande entre los miembros del clúster y, para firmas basadas en hash con estado, evitar que cualquier evento de respaldo o conmutación por error reutilice un estado de firma.

El clustering HSM estándar replica las claves entre los miembros para que un fallo de nodo no interrumpa las operaciones de firma o descifrado. Con ML-KEM y ML-DSA, esa replicación simplemente mueve más datos por clave, lo que es un aspecto de planificación de capacidad y ancho de banda, no un problema estructural. LMS y XMSS son el caso más complejo: si un clúster conmuta a una copia de seguridad que tiene una vista desincronizada de qué hojas de firma de un solo uso ya se han utilizado, la misma hoja puede firmarse dos veces, lo que rompe por completo la garantía de seguridad del algoritmo. El paquete Quantum Protect de Utimaco aborda esto directamente con lo que el proveedor describe como un enfoque patentado de gestión de estado diseñado específicamente para escenarios de alta disponibilidad y copias de seguridad con algoritmos con estado; cualquier proveedor o plataforma HSM que evalúe para la compatibilidad con LMS o XMSS debería poder explicar, en términos técnicos específicos, cómo evita la reutilización de estado durante la conmutación por error del clúster y la restauración de la copia de seguridad, no solo que admite el algoritmo.

Los procedimientos de copia de seguridad y restauración también requieren que se actualicen las suposiciones sobre capacidad y plazos. El mayor tamaño de las claves y firmas PQC implica que los medios de copia de seguridad, los archivos de exportación cifrados y las ventanas de restauración para la recuperación ante desastres deben redefinirse en lugar de asumir que coinciden con el tamaño y los plazos de la era clásica.

¿Cuáles son los requisitos previos de integración antes de habilitar PQC en los HSM de producción?

Antes de habilitar las operaciones de PQC en un HSM de producción, confirme que se cumplen estos requisitos previos, ya que la falta de alguno convierte una actualización planificada en una interrupción del servicio:

• Versiones del SDK del cliente y del proveedor PKCS#11. Las aplicaciones se integran con el HSM a través de una biblioteca cliente y PKCS#11 o un SDK específico del proveedor; dicha biblioteca necesita una versión que reconozca los nuevos identificadores del mecanismo PQC antes de la actualización del firmware, o las llamadas fallarán aunque el firmware del HSM sea compatible con el algoritmo.
• Compatibilidad con software PKI y CA. Su software de autoridad de certificación, ya sea local o en las instalaciones, PKI gestionado como servicio La plataforma, o la integración con una CA pública, debe admitir la emisión de certificados contra claves públicas PQC o híbridas antes de que esas claves sean útiles en producción.
• Soporte para la negociación de redes y protocolos. Los terminadores TLS, los balanceadores de carga y las puertas de enlace VPN en la ruta de tráfico necesitan pilas TLS que admitan grupos de intercambio de claves híbridos; un HSM que pueda generar claves ML-KEM no sirve de nada si nada en la ruta de conexión puede negociarlas.
• Manejo de MTU y fragmentación. Las claves y certificados PQC de mayor tamaño aumentan el tamaño de los mensajes de protocolo de enlace TLS, lo que puede hacer que los protocolos de enlace superen los límites de MTU de ruta en algunas rutas de red y expongan errores de manejo de fragmentación en equipos de red antiguos que los protocolos de enlace de tamaño clásico nunca activaron.
• Actualizaciones de seguimiento y alertas. Los paneles operativos y los umbrales de alerta ajustados para la latencia de generación y firma de claves clásicas necesitan actualizar sus parámetros de referencia, ya que las operaciones de PQC tienen un coste computacional diferente, generalmente más elevado, por operación.

Una plataforma de descubrimiento e inventario criptográfico es la forma más rápida de confirmar estos requisitos previos en un gran conjunto de sistemas, en lugar de comprobarlos aplicación por aplicación; esta es la brecha específica que CBOM Secure está diseñado para cerrar.

¿Para qué modos de fallo debería planificar?

La mayoría de los fallos de PQC en el hardware se engloban en un número reducido de categorías predecibles. Planificar para solucionarlos antes de la migración reduce la probabilidad de una interrupción imprevista o de que se descubra una deficiencia en el cumplimiento normativo durante una auditoría.

Modo de fallo	Por qué sucede	Mitigación
El firmware no se puede actualizar para PQC.	El hardware HSM que ha llegado al final de su ciclo de vida o que ya no recibe soporte nunca recibe una actualización de firmware PQC por parte del proveedor.	Fechas de fin de vida útil del firmware del inventario ya disponibles; actualización de hardware económica para cualquier modelo sin una hoja de ruta de firmware PQC confirmada.
El rendimiento y la latencia se degradan bajo carga PQC.	La firma ML-DSA y el manejo de claves más grandes requieren más recursos computacionales por operación que RSA o ECC en el mismo hardware.	Realice pruebas de carga en las operaciones de PQC al volumen de producción previsto antes de la puesta en marcha; confirme las cifras de rendimiento publicadas por el proveedor comparándolas con sus propios patrones de tráfico.
Reutilización del estado de firma con estado durante la conmutación por error	Los miembros del clúster HA o las restauraciones de copias de seguridad se desincronizan en el estado de firma única de LMS o XMSS.	Utilice plataformas HSM con garantías de sincronización de estado documentadas y probadas para algoritmos con estado en entornos de alta disponibilidad y copias de seguridad.
El tamaño del protocolo de enlace o del mensaje interrumpe las rutas de red heredadas.	Las claves y certificados PQC de mayor tamaño superan las suposiciones de MTU o búfer en los equipos de red más antiguos.	Pruebe los protocolos de enlace TLS híbridos a lo largo de la ruta de red real, incluidos los balanceadores de carga o dispositivos intermedios heredados, antes del despliegue en producción.
Algoritmo validado pero el límite del módulo no lo es.	La validación del algoritmo CAVP se considera equivalente a un certificado de módulo FIPS 140-3 completo.	Confirme el número de certificado FIPS 140-3 específico y su lista de algoritmos validados para la versión exacta del firmware desplegada.
Incompatibilidad del cliente o de la biblioteca de la aplicación	La versión del proveedor o SDK de PKCS#11 es anterior a los identificadores del mecanismo PQC que expone el nuevo firmware.	Actualice y pruebe las bibliotecas cliente en un entorno de prueba antes de la actualización del firmware, no al mismo tiempo.

Limitaciones

• El documento NIST IR 8547 sigue siendo un borrador público inicial a fecha de esta actualización; el plazo para presentar comentarios finalizó el 10 de enero de 2025, y el cronograma de transición que propone aún no está finalizado y puede sufrir modificaciones.
• El estado de la certificación FIPS 140-3 y la compatibilidad con PQC del proveedor cambian con frecuencia. Los detalles del proveedor que aparecen en este artículo reflejan la información pública disponible hasta la fecha de esta actualización; confirme la versión exacta del firmware y el número de certificado con el proveedor antes de la compra o la implementación.
• Los hitos obligatorios de CNSA 2.0 se aplican directamente a los sistemas de seguridad nacional de EE. UU.; las empresas comerciales no están obligadas por CNSA 2.0, pero muchas la utilizan como referencia de planificación para la selección y la sincronización de algoritmos.
• Las cifras de rendimiento para las operaciones PQC varían significativamente según el modelo de HSM, la versión del firmware y la carga de trabajo; considere las directrices generales aquí presentadas como un punto de partida para sus propias pruebas de carga, no como un sustituto de las mismas.

¿Qué recomendaría Encryption Consulting?

Considere la capa HSM como la primera puerta de entrada en cualquier migración PQC, no la última. Concretamente, esto significa comenzar con un inventario criptográfico en lugar de una prueba piloto del algoritmo, confirmar el estado del módulo FIPS 140-3 en lugar de confiar en un encabezado CAVP, y configurar los cambios en la ceremonia de clave y el manual de alta disponibilidad antes de generar una sola clave de producción.

Los servicios de asesoramiento PQC de Encryption Consulting gestionan esto como una hoja de ruta estructurada de nueve fases que abarca el descubrimiento criptográfico, la priorización basada en riesgos, la evaluación de proveedores y hardware, el diseño de arquitectura híbrida y la implementación por fases, de modo que la capa de hardware y la capa de aplicación migren según un cronograma coordinado en lugar de hacerlo de forma independiente.

Cuando la brecha radica específicamente en el hardware, nuestro equipo de Servicios HSM evalúa el firmware actual de HSM y el estado de validación FIPS según sus requisitos PQC, realiza pruebas de concepto para configuraciones híbridas y nativas de PQC, y diseña los cambios de alta disponibilidad y ceremonia de claves que requieren los algoritmos con estado. Para entornos donde el primer problema es simplemente desconocer qué está implementado y dónde, CBOM Secure crea y mantiene el inventario criptográfico continuo que posibilita cada paso posterior.

Servicios de asesoramiento de PQC

Obtenga preparación post-cuántica con una evaluación criptográfica dirigida por expertos, una estrategia de migración y una implementación práctica alineada con los estándares NIST.

Más Información

Conclusión

En la mayoría de las conversaciones sobre PQC, los algoritmos acaparan la atención, pero es la capa HSM la que decide si son fiables en la práctica. El hardware debe generar claves PQC con entropía real, almacenarlas dentro de un límite validado, soportar una ruta de actualización de firmware que se mantenga al día con un estándar en constante evolución y admitir procedimientos de alta disponibilidad y copias de seguridad que respeten los requisitos específicos que introducen los esquemas de firma con estado. Thales, Entrust y Utimaco han subsanado gran parte de la brecha de compatibilidad de algoritmos durante el último año, y los primeros módulos validados por FIPS 140-3 que combinan la suite completa de PQC CNSA 2.0 llegaron en 2026. Lo que queda por hacer es operativo: inventariar la infraestructura HSM, confirmar la validación a nivel de módulo en lugar de los anuncios a nivel de algoritmo, y reconstruir los manuales de procedimientos de ceremonia de claves y alta disponibilidad en torno a claves más grandes y, cuando corresponda, al estado de firma de un solo uso. Las organizaciones que consideran la capa de hardware como el punto de partida para la migración a PQC, en lugar de un añadido posterior a la capa de aplicación, serán las que estén preparadas cuando lleguen los plazos importantes.

Preguntas frecuentes

¿Necesitamos hardware HSM nuevo para admitir PQC, o basta con una actualización de firmware? Para la mayoría de los HSM de última generación, una actualización de firmware es suficiente. Thales, Entrust y Utimaco han añadido compatibilidad con ML-KEM y ML-DSA a su hardware existente mediante actualizaciones de firmware. Los modelos HSM más antiguos o descatalogados, que nunca recibirán una actualización de firmware PQC, son la excepción, y es necesario identificarlos y presupuestar su reemplazo cuanto antes.

¿El anuncio del algoritmo PQC de un proveedor es lo mismo que un módulo compatible con PQC validado según FIPS 140-3? No. La validación del algoritmo mediante el programa CAVP del NIST y la validación del módulo mediante CMVP son procesos independientes, y en la generación actual de versiones de firmware PQC, suele haber un lapso de aproximadamente un año entre ambos. Confirme el número de certificado FIPS 140-3 específico que cubre la versión de firmware que planea implementar.

¿Qué algoritmo PQC debería admitir primero nuestro HSM, ML-KEM o ML-DSA? La prioridad debe basarse en la exposición, no en la preferencia. ML-KEM protege el establecimiento de claves, que actualmente está expuesto a ataques de recolección y descifrado en cualquier tráfico capturado ahora y descifrado una vez que exista una computadora cuántica criptográficamente relevante. ML-DSA protege las firmas, donde la ventana de exposición se abre más tarde para la mayoría de los casos de uso, excepto para las claves de firma de código y firmware de larga duración, que deben tratarse con una urgencia similar a la del establecimiento de claves.

¿LMS y XMSS requieren un manejo operativo diferente al de ML-DSA? Sí. LMS y XMSS son esquemas de firma basados ​​en hash con estado y un número fijo de hojas de firma de un solo uso por clave; reutilizar una hoja, lo cual puede ocurrir durante una conmutación por error de alta disponibilidad o una restauración de copia de seguridad mal gestionadas, compromete la seguridad. ML-DSA y ML-KEM no requieren este tipo de gestión de estado.

¿Cuánto más grandes son las claves y firmas PQC que las RSA o ECC en la práctica? Una clave pública ML-KEM-768 tiene un tamaño aproximado de 1.2 KB, frente a los 32 a 64 bytes de una clave ECC de seguridad equivalente, y las claves públicas y firmas ML-DSA, en conjunto, ocupan varios kilobytes. Tenga esto en cuenta al considerar la capacidad de los medios de almacenamiento de respaldo, los límites de tamaño de los certificados y del protocolo de enlace, y cualquier proceso de ceremonia que verifique manualmente el material de la clave.

Referencias

• NIST FIPS 203, Estándar de mecanismo de encapsulación de claves basado en retículos de módulos: https://csrc.nist.gov/pubs/fips/203/final
• NIST FIPS 204, Estándar de firma digital basado en módulos reticulares: https://csrc.nist.gov/pubs/fips/204/final
• NIST FIPS 205, Estándar de firma digital sin estado basado en funciones hash: https://csrc.nist.gov/pubs/fips/205/final
• NIST IR 8547 (Borrador público inicial, noviembre de 2024), Transición a los estándares de criptografía post-cuántica: https://csrc.nist.gov/pubs/ir/8547/ipd
• Guía de la NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0): https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
• Thales y Luna HSM v7.9 ofrecen preparación para PQC a gran escala: https://cpl.thalesgroup.com/blog/encryption/luna-hsm-pqc-quantum-safe-encryption
• Thales Trusted Cyber ​​Technologies, fabricante estadounidense de HSM post-cuántico, obtiene la certificación FIPS 140-3 de nivel 3: https://www.thalestct.com/hsm-fips140-3-validation/
• Thales Group, Thales desarrolla seguridad criptográfica para la era de la IA y la computación postcuántica (Luna 8): https://www.thalesgroup.com/en/news-centre/press-releases/thales-builds-cryptographic-security-age-ai-and-post-quantum-computing
• Los algoritmos de criptografía post-cuántica de los HSM de Entrust y nShield obtienen la validación del Programa de Validación de Algoritmos Criptográficos del NIST: https://www.entrust.com/company/newsroom/entrust-nshield-hsms-achieve-validation-from-nist-cryptographic-algorithm-validation-program
• Utimaco, La fecha límite post-cuántica de 2029: ¿Podrán sus HSM realizar la migración?: https://utimaco.com/news/blog-posts/post-quantum-hsm-migration-2029