Migración entre proveedores de HSM durante la actualización de PQC

Los módulos de seguridad de hardware (HSM) son el componente más conservador en la mayoría de las arquitecturas criptográficas. Son costosos, requieren certificación y su actualización es lenta, y esto se debe deliberadamente a que almacenan las claves en las que confía todo lo demás. Sin embargo, 2026 se perfila como un año de cambios inusuales en los HSM, y la razón es la criptografía postcuántica . Los principales proveedores han lanzado firmware que integra directamente los algoritmos postcuánticos del NIST en el módulo, y este cambio está impulsando a las organizaciones a reevaluar sus plataformas, consolidar sus sistemas y, en algunos casos, migrar entre proveedores.

La migración de claves entre plataformas HSM es una de las operaciones más críticas que puede realizar un equipo de criptografía. Si se realiza correctamente, es imperceptible. Si se realiza incorrectamente, puede interrumpir los servicios de firma, invalidar una raíz de confianza o dejar el material de clave en un estado no conforme. Este artículo explica por qué la actualización de PQC está impulsando las migraciones de HSM en la actualidad, qué implica la migración a nivel técnico, los riesgos específicos que se deben considerar y cómo secuenciar el trabajo para garantizar la seguridad y la disponibilidad en todo momento.

¿Por qué esto importa ahora?

Tres factores han transformado la migración de proveedores de HSM, que antes era un proyecto poco frecuente y complejo, en una cuestión crucial para muchos equipos en 2026. Los algoritmos post-cuánticos ya están estandarizados e integrados en el firmware de HSM más utilizado; la certificación de dicho firmware varía considerablemente entre proveedores; y los cambios en el rendimiento y el formato de clave que introduce la computación post-cuántica (PQC) justifican la necesidad de que las organizaciones reevalúen la plataforma en la que se ejecuta su raíz de confianza. Ya no se trata de una tarea a futuro: el intercambio de claves híbrido basado en ML-KEM ya está habilitado por defecto en los principales navegadores y pilas TLS, por lo que los algoritmos que debe admitir un HSM son los que se utilizan actualmente en producción, no una posibilidad futura.

PQC se ha trasladado al interior del módulo.

Durante años, la compatibilidad con la computación post-cuántica en los HSM implicaba un complemento o un paquete de opciones experimentales. Esto cambió en 2025. Entrust anunció que sus HSM nShield 5 habían completado la implementación de algoritmos post-cuánticos en el firmware y habían recibido la certificación CAVP para ML-DSA , ML-KEM y SLH-DSA, con este hito alcanzado en el firmware v13.8.0, lanzado en agosto de 2025. Thales siguió con el firmware v7.9 para Luna HSM, que ofrece ML-KEM (FIPS 203) y ML-DSA ( FIPS 204 ) nativos integrados en el firmware, eliminando explícitamente la necesidad de un módulo de funcionalidad externo. Cuando las dos plataformas HSM dominantes de propósito general lanzan PQC de producción en el mismo período, el ciclo de actualización se acelera en todo el mercado.

El conjunto estandarizado sigue en expansión. Junto con ML-KEM (FIPS 203), ML-DSA (FIPS 204) y SLH-DSA ( FIPS 205 ), el NIST seleccionó el algoritmo HQC basado en código en marzo de 2025 como mecanismo de encapsulación de claves de respaldo, construido sobre una base matemática diferente a la de ML-KEM, y se espera que FN-DSA (FALCON) sea la versión FIPS 206. Por lo tanto, un módulo adquirido hoy debe evaluarse en función de la facilidad con la que se pueden agregar algoritmos posteriormente, y no solo en función de los que incluye actualmente.

Los ciclos de actualización obligan a tomar decisiones sobre la plataforma.

Una actualización de firmware que incorpora PQC rara vez es un evento aislado. Suele coincidir con el fin de la vida útil del hardware, la planificación de capacidad para material de claves post-cuánticas de mayor tamaño y la renovación de contratos. Precisamente en esos momentos, las organizaciones reevalúan si deben mantener su plataforma actual o migrar. PQC también modifica el cálculo del rendimiento: los algoritmos post-cuánticos son más complejos que sus equivalentes clásicos, y tanto sus claves como sus firmas son sustancialmente más grandes, mientras que las operaciones de firma y establecimiento de claves requieren más recursos computacionales por operación que RSA o ECC.

El salto de tamaño es tangible: una firma ML-DSA-65 ocupa aproximadamente 3.3 KB y una clave pública ML-KEM-768, alrededor de 1.2 KB, frente a una firma ECDSA P-256 de 64 bytes y una clave RSA-2048 de 256 bytes. Los datos de rendimiento publicados varían considerablemente según el conjunto de parámetros y la plataforma, pero la tendencia es consistente: más ciclos por operación y mucho más almacenamiento por clave y por firma. Un HSM dimensionado para una carga de trabajo RSA y ECC podría necesitar un redimensionamiento para una carga de trabajo post-cuántica, lo que constituye un factor determinante para la adquisición. Esto convierte la actualización PQC en un punto de decisión clave para decidir si renovar la plataforma actual o cambiar a un proveedor diferente.

La falta de certificación complica las migraciones reguladas.

Los compradores en sectores regulados se enfrentan a un sutil problema de sincronización. La certificación de algoritmos y la certificación de módulos son procesos separados y no se están implementando simultáneamente. A finales de 2025, varios proveedores contaban con la validación FIPS 140-3 Nivel 3 CMVP para sus HSM y, por separado, con la certificación CAVP para los algoritmos PQC, pero ninguno había obtenido aún la validación FIPS 140-3 Nivel 3 con soporte PQC integrado, y todos se encontraban todavía en la etapa de Módulos en Proceso o Implementación Bajo Prueba. Thales ha descrito su firmware Luna v7.9.2 como el próximo candidato FIPS con PQC, y Entrust ha presentado el firmware nShield 5 para la validación FIPS 140-3 Nivel 3 actualizada a través del CMVP.

Para una organización con un estricto mandato FIPS 140-3 Nivel 3, esto significa que PQC puede probarse y realizarse como piloto ahora, pero es posible que deba ejecutarse fuera del entorno validado hasta que se obtenga la certificación combinada. Este matiz debe influir en el cronograma de migración. En la práctica, implica tratar la validación FIPS combinada como un hito clave para la transición a producción, permitiendo las pruebas piloto de PQC solo en un entorno claramente marcado y no validado. Dos relojes externos refuerzan aún más esta precisión.

En primer lugar, la era FIPS 140-2 está llegando a su fin: el 21 de septiembre de 2026, el CMVP del NIST traslada todos los certificados FIPS 140-2 restantes a la Lista Histórica, tras lo cual las agencias federales no deberían citarlos para nuevas adquisiciones. Por ello, muchas organizaciones ya están llevando a cabo una actualización a FIPS 140-3 que ahora también funciona como actualización del PQC. En segundo lugar, la migración es cada vez más obligatoria en lugar de opcional.

La CNSA 2.0 de la NSA exige que los Sistemas de Seguridad Nacional migren a ML-KEM-1024 y ML-DSA-87, y se espera que las nuevas adquisiciones den soporte al conjunto a partir de 2027. La firma del software y el firmware tiene como fecha límite de uso exclusivo el año 2030, y la Orden Ejecutiva 14144 de enero de 2025 reforzó el cronograma federal. Para los compradores afectados, la decisión sobre HSM ya no es puramente técnica; se trata de un problema de plazos de adquisición.

¿Cómo funciona la migración de HSM?

La transferencia de claves entre proveedores de HSM está limitada por la función principal de cada HSM: proteger las claves privadas contra la extracción. Planificar una migración segura comienza por comprender qué se transfiere, qué permanece bloqueado dentro del módulo y cómo las dos plataformas líderes implementan actualmente los algoritmos post-cuánticos. Las siguientes secciones abordan cada aspecto por separado.

Lo que realmente mueve la migración de HSM

La migración entre HSM no es una simple copia de archivos. El material clave en un HSM generalmente no se puede exportar en texto plano por diseño; solo sale del módulo encapsulado o nunca sale y se regenera. Por lo tanto, una migración debe tener en cuenta las claves en sí, el modelo de acceso y autenticación que las rodea (como particiones, roles y autenticación de quórum o PED ), las políticas que restringen cómo se pueden usar las claves y las relaciones de confianza que dependen de las claves, incluidas las jerarquías de autoridades de certificación y las integraciones de aplicaciones vinculadas a través de PKCS#11.

El modelo de migración de proveedores

Los proveedores ofrecen rutas de migración estructuradas, y comprender su funcionamiento es fundamental incluso si se trata de una migración entre diferentes proveedores en lugar de una actualización dentro de uno mismo. Thales documenta tres métodos para migrar claves a un nuevo Luna HSM: copia de seguridad y restauración, clonación directa de ranura a ranura y clonación mediante un grupo de alta disponibilidad temporal creado exclusivamente para la migración. La guía de Thales especifica que los tres métodos invocan los protocolos de clonación subyacentes a los comandos que se emiten, y que, una vez utilizado un grupo de alta disponibilidad temporal para la migración, este debe eliminarse, ya que sus miembros no comparten la misma versión de software.

El detalle que suele causar problemas a los equipos es la compatibilidad de protocolos entre las distintas generaciones de firmware. En el modelo Luna, los HSM más antiguos, anteriores a la versión 7.8.0, utilizan un protocolo de clonación que desconoce la existencia de múltiples dominios, por lo que el HSM antiguo solo puede interactuar con el dominio principal designado en un HSM más reciente. En la práctica, según Thales, la consecuencia es que el dominio común entre el origen y el destino debe configurarse como dominio principal en cualquier HSM con firmware 7.8.0 o posterior antes de la clonación. Las migraciones entre generaciones y entre proveedores dependen precisamente de estas limitaciones de compatibilidad.

Los roles y la autenticación también se mantienen.

La migración no se trata solo de claves, sino también de quién las controla. Los procedimientos de Luna requieren roles de partición específicos: el Oficial de Seguridad de Partición debe realizar operaciones de alta disponibilidad y crear el Oficial de Criptografía, y el Oficial de Criptografía de Partición debe realizar las operaciones de copia de seguridad, restauración y clonación. Cuando el origen utiliza autenticación de quórum multifactor (PED) y el destino se autentica mediante contraseña, la documentación indica que los HSM autenticados con contraseña no pueden usar PED remoto, por lo que se debe conectar un PED localmente. Estos detalles operativos forman parte del diseño de la migración, no son añadidos posteriores.

La migración entre proveedores es más difícil que la actualización dentro del mismo proveedor.

Cuando el origen y el destino son de proveedores diferentes, generalmente no existen rutas de clonación y alta disponibilidad convenientes, ya que los protocolos de clonación son específicos de cada proveedor. Estas rutas dependen de un protocolo de clonación propietario compartido y un dominio de seguridad común que solo existe dentro del ecosistema de un único proveedor; por lo tanto, una partición Luna no puede clonarse en un nShield, ni viceversa. Los únicos puentes entre proveedores son mecanismos basados ​​en estándares, como el cifrado de claves PKCS#11, e incluso estos solo funcionan cuando la política de claves permite la exportación y ambas plataformas implementan un mecanismo de cifrado compatible.

La migración entre proveedores suele implicar uno de tres enfoques: regenerar las claves en la nueva plataforma y volver a emitir los certificados o credenciales que dependen de ellas, lo cual es más sencillo cuando las claves se pueden rotar; encapsular e importar las claves cuando ambas plataformas admiten un mecanismo de encapsulación compatible y la política permite la exportación; o, para una autoridad de certificación, establecer una nueva CA con raíz en el nuevo HSM y certificar o migrar la confianza subordinada con el tiempo. La opción correcta depende de si las claves se pueden rotar, si deben permanecer dentro de un límite FIPS en todo momento y cuánto tiempo de inactividad pueden tolerar los servicios dependientes.

Riesgos y dificultades

Las migraciones de HSM concentran varias categorías de riesgo en una única ventana de cambio.

Supervisión	Causa	Consecuencia
Pérdida de la raíz de la confianza	Las claves de firma de la CA se gestionaron incorrectamente o no se migraron correctamente.	Los certificados emitidos ya no se pueden validar ni renovar.
Estado de clave no conforme	Claves importadas a una configuración fuera del límite validado.	Pérdida de cumplimiento con el nivel 3 de FIPS 140-3 para cargas de trabajo reguladas.
incompatibilidad de protocolo	El firmware de origen y el de destino utilizan protocolos de clonación incompatibles.	La migración falla o utiliza silenciosamente una ruta más débil.
Tiempo de inactividad del servicio	Los servicios de firma o TLS dependen de claves durante la migración.	Interrupciones en PKI, firma de códigoo procesamiento de transacciones.
déficit de capacidad	El módulo HSM está dimensionado para cargas de trabajo clásicas, no para PQC.	Degradación del rendimiento tras la puesta en marcha de los algoritmos post-cuánticos.
Error de autenticación	La fuente autenticada con PED se movió al destino autenticado con contraseña.	Bloqueo operativo o soluciones alternativas inseguras.

El plazo de cumplimiento es la restricción más difícil

Para los compradores regulados, el factor más importante en la planificación es la brecha de certificación descrita anteriormente. Ejecutar claves PQC en una configuración que aún no cuenta con la validación CMVP FIPS 140-3 Nivel 3 puede ser aceptable para pruebas y proyectos piloto, pero no es lo mismo que ejecutarlas dentro del marco validado. Las organizaciones sujetas a FedRAMP, FISMA o regímenes similares deben alinear su cronograma de migración con el progreso de CMVP de los proveedores y decidir con precisión si implementar PQC en producción ahora, fuera de la validación combinada, o posponer su implementación hasta obtener la certificación. Esta es una decisión de riesgo documentada, no un detalle que se descubra durante una auditoría.

Las políticas clave de exportación pueden bloquear el camino obvio.

En ocasiones, los equipos asumen que las claves se pueden simplemente encapsular y transferir. En un entorno de seguridad FIPS 140-3 Nivel 3, el HSM solo admite algoritmos y tipos de clave aprobados, y las claves no exportables no se pueden extraer. Thales también señala una restricción actual de Luna: para la versión 7.9.0, no se admite la encapsulación de claves ML-DSA y ML-KEM, lo que afecta directamente a la forma en que se pueden transferir las claves post-cuánticas. Confirme la política de exportación y encapsulación para cada clase de clave antes de decidirse por un método de migración.

Mejores prácticas de implementación

Una migración de HSM bien planificada sigue una secuencia de descubrimiento, diseño y transición para que la raíz de confianza nunca corra peligro. Los pasos que se describen a continuación se ejecutan en orden, asumiendo que el anterior se ha completado, ya que omitir el descubrimiento o las comprobaciones de compatibilidad puede provocar que una migración deje una clave aislada que no se puede transferir.

1. Inventaría cada clave y sus dependencias: Claves de catálogo por tipo, exportabilidad, política, propietario y los servicios que dependen de ellas. Autoridad certificada Una clave de firma, una clave de firma de código y una clave TLS requieren un manejo diferente, y no se puede planificar un método de migración sin saber qué claves se pueden rotar y cuáles no. Las claves protegidas por la inexportabilidad del hardware, como una raíz de CA, necesitan una estrategia diferente a la de las claves que simplemente se pueden volver a emitir. CBOM seguro Automatiza este proceso de descubrimiento, creando una lista de materiales criptográficos que relaciona cada clave con su propietario, política y sistemas dependientes.
2. Decida el método de migración para cada clase clave: Utilice la rotación y la reemisión cuando las claves puedan cambiar, la clonación del proveedor o la copia de seguridad y restauración para las actualizaciones del mismo proveedor, y el encapsulado de claves solo cuando ambas plataformas y políticas lo permitan. No dé por sentado que un solo método sirve para todo el entorno y documente el método elegido para cada clase de clave, de modo que el plan de transición sea auditable.
3. Primero, solucione la compatibilidad del firmware y del protocolo: Para las actualizaciones del mismo proveedor, confirme las versiones del protocolo de clonación y la configuración del dominio antes de realizar cualquier cambio de clave, incluida la configuración del dominio compartido como principal en el firmware más reciente cuando sea necesario.
4. Defina con precisión el nivel de cumplimiento: Mapee la migración en función del progreso de CMVP del proveedor y documente explícitamente si PQC se ejecutará dentro o fuera del límite validado durante la transición. Obtenga la aprobación de esta decisión antes de la implementación. Los Servicios de Asesoría de PQC consultan el certificado CMVP y la política de seguridad, no el folleto, por lo que la postura se basa en lo que la validación cubre realmente.
5. Tamaño para carga post-cuántica: Valide el rendimiento de HSM frente a los algoritmos PQC más exigentes en una prueba piloto y planifique la aceleración del proveedor cuando esté disponible. Entrust, por ejemplo, señala que nShield 5 utiliza un procesador de seguridad basado en FPGA cuya aceleración PQC se puede implementar mediante una actualización de firmware posterior. Confirmar si la aceleración está presente en el firmware que está validando evita sorpresas desagradables al medir el rendimiento bajo carga. Cuando no sea práctico implementar internamente hardware validado con capacidad PQC, HSM-as-a-Service lo proporciona bajo demanda.
6. Mantenga la disponibilidad con ejecución en paralelo: Implemente la nueva plataforma junto con la antigua, migre o regenere las claves, valide los servicios dependientes con el nuevo HSM y solo entonces realice la transición. Para jerarquías de CA, considere la certificación cruzada para que la confianza se transfiera gradualmente.
7. Ensaya y luego mantén una estrategia de retroceso: Pruebe el procedimiento completo en un entorno que no sea de producción, mantenga los HSM de origen disponibles y con copias de seguridad hasta que se verifique la migración, y desactive la plataforma solo después de confirmar que los servicios dependientes funcionan de forma estable en la nueva plataforma. Una migración no finaliza cuando las claves llegan al nuevo HSM; finaliza cuando la plataforma antigua se puede retirar sin que nadie lo note.

¿Qué significa esto para los equipos de seguridad?

La migración de un HSM durante la actualización de PQC no es un proyecto exclusivo de un solo equipo; afecta a todos los que dependen de la raíz de confianza. Las responsabilidades varían según el rol, pero la combinación de un cambio de proveedor y una transición criptográfica aumenta la complejidad para todos.

Los CISO asumen el riesgo de una migración que afecte la base de confianza de la organización y necesitan garantías de que el cumplimiento normativo se mantenga durante el proceso, ya que cualquier fallo en la cobertura validada durante la migración constituye, en sí mismo, un hallazgo en una auditoría. Un servicio de consultoría de PQC les proporciona un plan de migración documentado y sólido al que pueden recurrir.

Los equipos de criptografía y PKI son responsables de la mecánica: gestión de claves, continuidad de la jerarquía de CA y las decisiones de migración de clave por clave que determinan el éxito. PKI-as-a-Service puede mantener la jerarquía de CA durante la migración sin interrupciones.

Los arquitectos de seguridad deciden si la actualización es también el momento de consolidar proveedores, adoptar la criptoagilidad y rediseñar la plataforma para adaptarla a la era post-cuántica. Un inventario de CBOM Secure les muestra qué es lo que realmente necesita migrar primero.

Los ingenieros de infraestructura planifican el entorno de ejecución en paralelo, los grupos de alta disponibilidad y la capacidad para cargas de trabajo PQC más pesadas. HSM-as-a-Service puede absorber esa carga sin necesidad de adquirir hardware.

Los equipos de cumplimiento y auditoría necesitan el registro documentado de cómo se migraron las claves y si permanecieron dentro de un perímetro validado en todo momento. Este rastro de evidencia es un resultado directo del mismo servicio de consultoría.

¿Cómo puede ayudar la consultoría de cifrado?

La migración de HSM durante la actualización de PQC rara vez es un simple cambio de hardware; es un proceso dentro de una modernización criptográfica más amplia, y las partes más difíciles son las decisiones estratégicas: qué claves se pueden transferir, qué cubre realmente el certificado CMVP y cómo secuenciar la transición sin comprometer la raíz de confianza. Aquí es precisamente donde entran en juego los Servicios de Asesoramiento Criptográfico Post-Cuántico de Encryption Consulting . El equipo evalúa su exposición a la computación cuántica, analiza el certificado y la política de seguridad en lugar del folleto del proveedor, y elabora un plan de migración adaptado a sus requisitos de cumplimiento, que abarca el descubrimiento criptográfico, la preparación de HSM, la selección de algoritmos, la implementación híbrida y una transición gradual.

Cuando el plan requiere herramientas para su ejecución, la misma solución utiliza CBOM Secure para el descubrimiento criptográfico y una lista de materiales criptográficos dinámica, HSM como servicio para la protección de claves con validación FIPS y capacidad PQC sin necesidad de instalar hardware interno, y PKI como servicio cuando la migración implica la reconstrucción o la certificación cruzada de jerarquías de CA. El resultado es un programa único, liderado por expertos, que transforma la migración de un proveedor de HSM, de un proyecto puntual y arriesgado a un paso controlado hacia la criptoagilidad. Para definir el alcance de su proyecto, contacte con Encryption Consulting para obtener una evaluación de la preparación post-cuántica y una hoja de ruta para la transición de HSM.

Conclusión

La llegada de la criptografía postcuántica nativa al firmware nShield 5 y Luna 7.9 ha transformado el HSM, que antes era la parte más estática de la pila, en un objetivo de migración activo. Esto representa una oportunidad para modernizarse, pero la migración del HSM concentra un riesgo real: la raíz de confianza, el cumplimiento normativo, la disponibilidad del servicio y la confidencialidad de las claves dependen de que se realice correctamente. La brecha de certificación, donde los algoritmos PQC cuentan con la validación CAVP y los módulos con la validación FIPS 140-3 Nivel 3, pero aún no se han combinado, es la principal limitación para los compradores regulados y debería influir en los plazos.

La migración entre proveedores de HSM durante la actualización de PQC se basa principalmente en la preparación. Inventarie cada clave y sus dependencias, elija un método de migración para cada clase de clave, resuelva la compatibilidad del firmware y del protocolo antes de cualquier movimiento, defina cuidadosamente su postura de cumplimiento y ejecute la migración en paralelo con una reversión probada. Considere la migración de HSM como la reubicación cuidadosa de una raíz de confianza en lugar de una actualización de hardware, y la actualización posterior a la computación cuántica se convertirá en un paso controlado hacia la criptoagilidad en lugar de una amenaza para las claves de las que depende todo lo demás.