Migración de PQC en 2026: Creación de una hoja de ruta que sobreviva al contacto con producción.

El 13 de mayo de 2026, Microsoft lanzó la disponibilidad general de la compatibilidad con ML-DSA en los Servicios de certificados de Active Directory en Windows Server 2025, llevando la criptografía postcuántica de la documentación a los servidores donde se ejecutan la mayoría de las infraestructuras de clave pública (PKI) empresariales. Tres semanas antes, esos mismos equipos seguían debatiendo con los auditores sobre si sus jerarquías de CA podían siquiera ser inventariadas. La diferencia entre ambas conversaciones es lo que convierte a 2026 en el año en que una hoja de ruta para la migración a PQC deja de ser un mero documento de debate y se convierte en un programa de implementación con responsables definidos, presupuesto por partidas, listas de dependencias e informes trimestrales de cumplimiento.

Este artículo está dirigido a arquitectos de PKI, responsables de infraestructura y CISO que necesitan convertir ese programa de presentación de diapositivas a manual de procedimientos. Analizaremos el mapa de presiones regulatorias que configura los planes para 2026, el problema del inventario que nadie quiere abordar directamente, las tres estrategias de migración que se ajustan a diferentes perfiles de riesgo, por qué PKI es el factor limitante en cualquier hoja de ruta honesta, cómo se ve un despliegue por fases cuando las firmas ML-DSA son aproximadamente cuarenta y ocho veces más grandes que las ECDSA, y cómo instrumentar el programa para que sobreviva a los próximos dieciocho meses de cambios en los estándares y actualizaciones de la plataforma.

Mapa de presión de 2026

El cambio de “deberíamos planificar” a “necesitamos lanzar” se produjo según un calendario, no en teoría. Siete pilares definen ahora el horizonte de planificación que cualquier hoja de ruta empresarial debe respetar, y ninguno de ellos está a más de nueve años vista.

Comercial	Fuente	Fecha	Significado operativo
FIP 203 / 204 / 205 finalizado	NIST	13 de agosto de 2024	ML-KEM, ML-DSA y SLH-DSA son estándares aptos para producción, no borradores.
HQC fue seleccionado como KEM de respaldo.	NIST	Marzo 11, 2025	Diversidad de algoritmos en el ámbito de la gestión de la energía en la nube (KEM); se prevé la publicación del borrador de las normas FIPS en 2026 y la versión final en 2027.
Hoja de ruta del PQC del NIS CG de la UE	Comisión Europea, Grupo de Cooperación NIS	Publicado Junio ​​23, 2025	Los planes nacionales de los Estados miembros deben presentarse antes del 31 de diciembre de 2026.
Los módulos FIPS 140-2 se han movido a la sección Histórica.	CMVP del NIST	21 de septiembre de 2026	Las adquisiciones federales requieren módulos validados según FIPS 140-3; el retraso en la validación de FIPS 140-3 promedia más de 500 días.
ADCS ML-DSA GA en Windows Server 2025	Microsoft	Actualización de mayo 2026	Primera plataforma de CA empresarial convencional que emite certificados PQC en producción.
CNSA 2.0 puerta de adquisición	NSA	Enero 1, 2027	Las nuevas adquisiciones del Sistema de Seguridad Nacional deben ser compatibles con ML-KEM-1024 y ML-DSA-87.
Eliminación gradual del algoritmo NIST IR 8547	NIST	Depreciación en 2030, no permitida en 2035.	RSA-2048 / ECC P-256 quedarán obsoletos en 2030; los algoritmos vulnerables a la computación cuántica estarán prohibidos a partir de 2035.

En perspectiva, este no es un problema de 2035. Los plazos de adquisición, las transiciones a FIPS 140 y los cambios en la disponibilidad de la plataforma se concentran entre el último trimestre de 2026 y el 1 de enero de 2027. Las organizaciones que venden a los mercados federales, de seguridad nacional o de infraestructura crítica deben implementar la capacidad CNSA 2.0 dentro de ese plazo o se retiran de la licitación. Incluso las empresas no reguladas se ven afectadas indirectamente: sus proveedores ahora incluyen los requisitos de CNSA 2.0 en las solicitudes de propuestas (RFP), y los responsables de adquisiciones en sectores regulados están empezando a exigir planes de control de calidad de la plataforma (PQC) como parte de la debida diligencia. El plazo en el que "empezaremos a planificar el año que viene" es una respuesta válida a una pregunta de la junta directiva se cierra en el tercer trimestre de 2026.

Por qué HNDL no es una hipótesis

La frase « cosecha ahora, descifra después » se ha repetido tantas veces en textos de marketing que algunos equipos la interpretan como si fuera en tiempo futuro. Pero no lo es. La recopilación de datos se está llevando a cabo en la infraestructura actual: actores estatales capturan sesiones TLS, túneles IPsec y copias de seguridad cifradas almacenadas, las retienen y esperan a que un ordenador cuántico criptográficamente relevante (CRQC) permita recuperar las claves encriptadas. El borrador de la enmienda NIS2 de la UE, publicado a principios de 2026, señala que los ataques HNDL «probablemente ya están ocurriendo», lo que constituye la atribución más explícita realizada hasta la fecha en un texto normativo importante.

De esto se derivan dos implicaciones. Primero, la migración del cifrado es más urgente que la migración de firmas para cualquier dato con un requisito de confidencialidad superior al plazo previsto para la llegada del CRQC. Los registros de transacciones bancarias, los registros sanitarios sujetos a la retención de HIPAA, la propiedad intelectual vinculada a los ciclos de vida de los productos, el material clasificado, los registros de ciudadanos según el RGPD y los documentos de trabajo de fusiones y adquisiciones cumplen con estos requisitos. Segundo, la migración de firmas es más importante para las identidades de firma de larga duración (CA raíz, certificados de firma de código, claves de actualización de firmware), donde la firma debe seguir siendo fiable durante años después de su emisión. Una firma falsificada presenta un modelo de amenazas diferente al de un mensaje descifrado, pero la vida útil del activo determina la urgencia en ambos casos.

En resumen: priorice la implementación de ML-KEM para los canales críticos en materia de confidencialidad y asigne ML-DSA a las identidades firmantes con las colas más largas. Cualquier otro orden invierte el modelo de riesgo real.

¿Qué estándares son realmente viables para envíos hoy en día?

Actualmente, cinco algoritmos cumplen o están cerca de cumplir con los estándares NIST aptos para producción. Saber cuál implementar y dónde es lo que marca la diferencia entre una hoja de ruta de migración y un documento de adquisición.

Algoritmo	Estándar	Tipo	Estado de la producción a mediados de 2026
ML-KEM (Kyber)	FIP 203	Encapsulación de claves	KEM principal; ML-KEM-768 para uso civil, ML-KEM-1024 para CNSA 2.0
ML-DSA (Dilithium)	FIP 204	Firma digital	Firma principal; ML-DSA-65 civil, ML-DSA-87 CNSA 2.0
SLH-DSA (ESFINCAS+)	FIP 205	Firma basada en hash sin estado	Opción conservadora de reserva; no incluida en CNSA 2.0; firmas grandes
HQC	Se prevé que el borrador de las normas FIPS esté listo en 2026 y la versión final en 2027.	KEM de respaldo (matemáticas basadas en código)	Reserva de criptoagilidad en caso de que falle la matemática reticular.
FN-DSA (Halcón)	Borrador de la norma FIPS 206, prevista para finales de 2026 o principios de 2027.	Firma compacta	No está en CNSA 2.0; las firmas son más pequeñas que las de ML-DSA, pero es más difícil implementarlas de forma segura.

La selección de parámetros de CNSA 2.0 es crucial y suele sorprender a los equipos civiles. Las hojas de ruta que utilizan por defecto ML-KEM-768 y ML-DSA-65 no son compatibles con los entornos NSS sin modificaciones. Cualquier equipo de producto que venda a la base industrial de defensa debe planificar desde el principio el uso de ML-KEM-1024 y ML-DSA-87, con los tamaños de clave, texto cifrado y firma mayores que implican estos conjuntos de parámetros. CNSA 2.0 también prohíbe explícitamente HashML-DSA (la variante pre-hash) y no prevé la incorporación de futuros algoritmos NIST PQC como FN-DSA. El conjunto de algoritmos está diseñado para mantenerse estable durante la transición, lo que simplifica la planificación de los proveedores a costa de la flexibilidad.

El problema del inventario que nadie quiere ver

El descubrimiento es el punto donde se estanca toda hoja de ruta de PQC, y el modo de fallo es siempre el mismo: los equipos limitan el inventario criptográfico a los activos que ya gestionan y pasan por alto aquellos que representan el riesgo real. Un inventario fiable en 2026 debe abarcar al menos seis superficies de descubrimiento.

El escaneo de puntos finales y servidores detecta bibliotecas criptográficas (OpenSSL, BoringSSL, BCFIPS, la pila de criptografía de .NET) y sus versiones. El descubrimiento de red captura configuraciones TLS en puertos activos, incluidas las huellas digitales que revelan qué clientes aún negocian el intercambio de claves RSA o firmas SHA-1. Las API de CA y los registros de Transparencia de Certificados muestran los certificados emitidos públicamente, pero los registros de CT solo capturan la emisión públicamente confiable; las CA privadas (la mayoría de las PKI empresariales) requieren integración directa con AD CS o cualquier plataforma que emita confianza interna. Los inventarios de HSM muestran el material de clave, pero no los certificados que respaldan esas claves, por lo que la asignación de particiones de HSM necesita referencias cruzadas con las bases de datos de CA.

Las bases de datos de gestión de configuración (CMDB) y los repositorios de infraestructura como código exponen la configuración que vincula la criptografía con las aplicaciones, donde reside la criptografía oculta: cadenas de algoritmos codificadas en código Java heredado, proliferación de pares de claves SSH en sistemas de CI/CD, archivos JAR firmados con certificados integrados y claves privadas codificadas en repositorios. Las divulgaciones de proveedores y los materiales de base de datos (SBOM) reducen la brecha en las bibliotecas de terceros, especialmente para sistemas embebidos e IoT.

Las auditorías manuales ofrecen una instantánea obsoleta antes de que se cierre la hoja de cálculo. El descubrimiento continuo automatizado es el único enfoque que se mantiene a escala empresarial, y debe ejecutarse periódicamente, ya que el entorno criptográfico cambia a diario a medida que se inician contenedores, los proveedores implementan actualizaciones y los ingenieros incorporan nuevo código. El inventario debe registrar, para cada artefacto: algoritmo y parámetros, tamaño de clave, emisor, fecha de vencimiento, responsable comercial, responsable técnico, clasificación de datos, criticidad del sistema y complejidad de reemplazo. Sin estos campos, el inventario no puede alimentar la evaluación de riesgos.

Una prueba previa útil: pídale al equipo que enumere todos los certificados X.509 que caducarán en los próximos 90 días. Si la respuesta es "tendríamos que comprobarlo", el inventario no está listo para alimentar una hoja de ruta de migración, y dicha hoja de ruta presentará puntos ciegos.

Tres estrategias migratorias, tres perfiles de riesgo

La literatura ofrece diversas maneras de clasificar los enfoques de migración. En la práctica, tres patrones describen lo que la mayoría de las empresas implementarán en 2026, y la elección entre ellos viene determinada por la exposición regulatoria y el coste de un algoritmo erróneo.

Estrategia	Qué significa	Mejor ajuste	Compensación
Migración por etapas	Migrar primero los sistemas de claves a ML-KEM; las firmas a ML-DSA en una fase posterior.	Organizaciones con alta exposición a HNDL pero con capacidad limitada para cambiar la PKI.	Pospone la complejidad de la firma, pero deja expuestas las identidades de firma clásicas durante años.
Criptografía híbrida	Combine métodos clásicos (por ejemplo, X25519, ECDSA) con PQC en una sola operación; ambos deben cumplirse por motivos de seguridad.	Industrias reguladas, entornos de alta seguridad, cualquiera que desconfíe de las matemáticas de PQC para jóvenes.	Duplica el tamaño del artefacto criptográfico, complica las pruebas y crea una segunda migración (de híbrida a PQC pura) posterior.
Alineación CNSA 2.0	ML-KEM-1024, ML-DSA-87, AES-256, SHA-384 / SHA-512 en todos los ámbitos	NSS, base industrial de defensa, contratistas federales	Parámetros más estrictos que los predeterminados para uso civil; claves, firmas y textos cifrados más grandes; plazos de preparación de la plataforma y del HSM más largos.

El enfoque híbrido merece una mención especial. La implementación ADCS de Microsoft admite certificados compuestos que combinan una firma clásica (RSA o ECDSA) con una firma ML-DSA, requiriendo que ambas se validen para que el certificado sea confiable. El enfoque compuesto es operativamente más limpio que el híbrido paralelo de doble pila, ya que el certificado es un único artefacto, pero aumenta el tamaño de las cadenas y exige que las partes confiables comprendan el formato compuesto. Se recomienda planificar ambas formas durante el período de transición. La eliminación gradual de la norma NIST IR 8547 entre 2030 y 2035 eventualmente prohibirá el componente clásico, y cualquier construcción híbrida que debilite la mitad PQC no sobrevivirá a ese límite; NIST ha señalado este punto explícitamente en los comentarios públicos de IR 8547.

La decisión sobre criptoagilidad subyacente a los tres patrones es la misma. Ninguna de estas estrategias sobrevive sin una arquitectura que permita intercambiar algoritmos mediante políticas en lugar de modificar el código. Esa es la capacidad operativa que conviene desarrollar primero, independientemente del patrón de migración que se elija para el resto del programa.

La infraestructura de clave pública (PKI) es el limitador de velocidad.

La infraestructura de clave pública (PKI) es el obstáculo más grande en cualquier migración de control de calidad de procesos (PQC), y las razones son aritméticas.

ML-DSA-87 produce firmas de aproximadamente 4,627 bytes. ECDSA P-384 produce firmas de aproximadamente 96 bytes. Una cadena de cuatro certificados (raíz, intermedio, emisor, hoja) replica esa diferencia de tamaño en cada intercambio de claves TLS, cada respuesta OCSP y cada establecimiento de sesión autenticada. Las consecuencias posteriores son un mayor ancho de banda, más viajes de ida y vuelta para el intercambio de claves, fragmentación de MTU en segmentos de ruta que no anticiparon el cambio y presión sobre el rendimiento del HSM porque las operaciones de firma PQC procesan más bytes internamente. El pre-hashing ayuda a mitigar el impacto del HSM, y CNSA 2.0 lo prohíbe explícitamente para ese conjunto, lo que hace que las implementaciones de NSS necesiten HSM más capaces en lugar de un preprocesamiento más inteligente.

Las cadenas de certificados también presentan problemas de secuenciación jerárquica que la elección del algoritmo no puede solucionar. Migrar un certificado hoja a ML-DSA sin migrar previamente la CA emisora ​​provoca un fallo en la validación. Migrar la CA emisora ​​sin migrar previamente la raíz sin conexión genera una cadena basada en matemáticas clásicas, lo que socava el propósito de la migración.

La preparación de HSM complica el cronograma. Las plataformas SafeNet Luna y Thales han publicado soporte de firmware para ML-DSA en hardware de última generación, pero los módulos más antiguos requieren una actualización de hardware, una reestructuración de particiones y una reconfiguración de KSP en cada servidor Windows que los utilice. La actualización ADCS de mayo de 2026 depende de la selección del proveedor de almacenamiento de claves con la firma marcada en el manejo de solicitudes, y cualquier CA con una partición HSM registrada por número de serie en lugar de etiqueta de ranura necesita una nueva pasada de KspConfig antes de que pueda ver los nuevos algoritmos en el menú desplegable.

Prevea entre dieciocho y veinticuatro meses desde la decisión de adquisición hasta la implementación de una CA interna estable basada en PQC. Prevea un plazo mayor si trabaja con diferentes bosques o tiene middleware dependiente: NDES, los conectores SCEP de Intune, los almacenes de claves de Java y las canalizaciones de firma de código tienen sus propias curvas de preparación que la migración de la CA no puede eludir.

En resumen: todos los demás pasos de la migración de PQC dependen de PKI, y PKI es lo que más tarda en migrarse.

Secuencia de operadores de 2026

A continuación, se describe la secuencia que utilizamos cuando una empresa pregunta cómo se desarrollan los primeros dieciocho meses de una migración de PQC. Se parte de la base de un entorno con predominio de Microsoft, una jerarquía de AD CS de dos niveles, raíces respaldadas por HSM y una combinación de cargas de trabajo de TLS clásico, S/MIME y firma de código. Adapte la profundidad de cada paso al entorno; no los reordene.

1. Poner en marcha criptografía continua descubrimientoImplemente un escáner automatizado en todos los puntos finales, segmentos de red, bases de datos de CA, particiones HSM, imágenes de contenedores y repositorios de código. Genere un inventario dinámico vinculado al propietario del negocio, la fecha de vencimiento, el algoritmo, el conjunto de parámetros y la sensibilidad de los datos. Sin esto, cada paso posterior será una mera conjetura disfrazada de planificación.
2. Evalúe el riesgo según la duración de la confidencialidad de los datos, no según la cantidad de activos. Cree una matriz de riesgo que clasifique los certificados y las claves según el tiempo que los datos que protegen deben permanecer confidenciales, ponderado por la exposición a HNDL y la criticidad del sistema. Un certificado TLS de 90 días para un sitio de marketing se clasifica por debajo de una clave de firma de código cuyas firmas deben validarse durante diez años. La priorización por cantidad genera una lista de espera dominada por activos de bajo valor.
3. Cree una jerarquía de prueba ML-DSA que no sea de producción. En un entorno de laboratorio Windows Server 2025 con la actualización de mayo de 2026 aplicada, configure una jerarquía AD CS paralela de dos niveles utilizando ML-DSA-65 para la CA emisora ​​y ML-DSA-87 para la raíz sin conexión. Emita certificados de prueba para firma de código, autenticación de servidor web, autenticación de equipo y autenticación de usuario. Documente lo que funciona actualmente (la firma de código es el escenario más limpio), lo que es parcial (servidor web TLS, ciertos escenarios de autenticación) y lo que aún no es compatible (amplio TLS(VPN, Escritorio remoto). El análisis de brechas de este laboratorio es la base de cada decisión de producción posterior.
4. Implemente TLS híbrido en una carga de trabajo controlada. Seleccione una única aplicación interna con un alcance limitado. Configure su punto final TLS para el intercambio de claves híbridas X25519MLKEM768 con clientes modernos. Mida el tamaño del protocolo de enlace, la latencia, el tamaño de la cadena de certificados y el rendimiento del HSM en comparación con la configuración de referencia clásica. Documente las diferencias, incluyendo la MTU y el comportamiento del balanceador de carga que se activa con el protocolo de enlace de mayor tamaño. Estos datos, y no los informes técnicos del proveedor, serán los que determinen la aprobación para producción.
5. Preparar la plataforma HSM y CA. Auditar cada partición HSM con respecto a los niveles de firmware del proveedor que admiten ML-DSA. Programar las actualizaciones de firmware dentro de las ventanas de mantenimiento que respeten la cadencia de la ceremonia raíz sin conexión. Para las plataformas CA, validar que AD CS o su plataforma CLM puedan emitir certificados PQC y que los consumidores posteriores (Intune, NDES, canalizaciones de firma de código, aplicaciones que consumen certificados) puedan solicitarlos, entregarlos y validarlos. Tenga en cuenta que la emisión de PQC de ADCS actualmente requiere la selección de KSP con Firma configurada en Gestión de solicitudes, y ciertas versiones de plantillas deben volver a publicarse.

Ninguno de estos pasos requiere la existencia de una computadora cuántica criptográficamente relevante. Todos ellos se ven obstaculizados por el problema de descubrimiento del primer paso, razón por la cual todo programa PQC creíble asigna un propietario de inventario antes de asignar cualquier otra cosa.

Cómo CertSecure Manager ofrece una gestión del ciclo de vida de los certificados compatible con PQC.

CertSecure Manager (CSM) está diseñado para funcionar como una capa de ciclo de vida de certificados independiente de la CA en poblaciones de certificados clásicos, híbridos y PQC, que es la forma de implementación que realmente exige la migración a PQC.

Orquestación de múltiples CA : CSM gestiona la emisión y renovación en Microsoft AD CS, otras plataformas de CA empresariales y CA públicas desde un único plano de políticas, de modo que un cambio de RSA a ML-DSA en la CA de back-end no interrumpe el flujo de trabajo de inscripción de la aplicación consumidora.

Descubrimiento criptográfico continuo : Los escáneres de red y de puntos finales alimentan a CSM con un inventario en tiempo real de certificados, algoritmos, conjuntos de parámetros, tamaños de clave y ventanas de vencimiento, asignados a propietarios técnicos y comerciales y a la sensibilidad de los datos.

Agilidad criptográfica basada en políticas : la selección de algoritmos reside en la política, no en el código de la aplicación. Cambiar una población de certificados de ECDSA P-384 a ML-DSA-65 se convierte en una actualización de política, no en una redistribución, que es la única manera de cumplir con los plazos de FIPS 140 y CNSA 2.0.

Compatibilidad con certificados compuestos e híbridos : CSM se está ampliando para admitir el formato de certificado compuesto ADCS definido por Microsoft y los patrones de certificado híbrido IETF, de modo que los artefactos de transición se validen de extremo a extremo en todas las aplicaciones que los utilizan.

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

Encryption Consulting lleva más de una década implementando programas de PKI, criptografía y CLM para empresas reguladas de los sectores de servicios financieros, sanidad, energía, telecomunicaciones y manufactura. En el centro de nuestra solución PQC se encuentra CertSecure Manager , una plataforma de gestión del ciclo de vida de los certificados independiente de la CA que coordina la emisión, renovación, detección y políticas en Microsoft AD CS, otras plataformas de CA empresariales y CA públicas (clásicas, híbridas y PQC) desde un único plano de control.

Complementamos esto con nuestros Servicios de Asesoría PQC para la planificación de migraciones y hojas de ruta de criptoagilidad, Servicios PKI para la evaluación y modernización de jerarquías de CA empresariales, y Servicios HSM para plataformas SafeNet Luna y Thales preparadas para ML-DSA. Para comenzar a desarrollar su hoja de ruta, contáctenos en [email protected] o visite www.encryptionconsulting.com.

Preguntas frecuentes

¿Qué es la migración de PQC?

La migración PQC es el programa para reemplazar los algoritmos criptográficos vulnerables a la computación cuántica (RSA, ECDSA, ECDH, Diffie-Hellman) en todos los sistemas, aplicaciones, certificados, claves, bibliotecas y protocolos de una organización con algoritmos resistentes a la computación cuántica estandarizados por el NIST en FIPS 203, 204 y 205. Se trata de un programa plurianual, no de una actualización puntual, que afecta simultáneamente a los flujos de trabajo de PKI, identidad, red, aplicaciones y adquisiciones.

¿Por qué 2026 es el año en que la migración de PQC pasó de la planificación a la implementación?

Tres fechas independientes convergen a finales de 2026 y principios de 2027: la transición de la norma FIPS 140-2 del NIST a la categoría de "histórica" ​​el 21 de septiembre de 2026, el hito de la estrategia nacional del Grupo de Cooperación NIS de la UE el 31 de diciembre de 2026 y la fase de adquisición de la NSA CNSA 2.0 el 1 de enero de 2027. Las tres convierten las directrices consultivas en mecanismos de contratación, auditoría y cumplimiento que afectan a los contratos que se firman hoy.

¿Qué es el lenguaje HNDL (Harvest Now, Decrypt Later) y por qué es importante hoy en día?

HNDL describe cómo los adversarios capturan datos cifrados hoy y los almacenan para su posterior descifrado una vez que se disponga de un ordenador cuántico criptográficamente relevante. Esto es importante hoy porque los datos capturados ahora ya están expuestos. La migración del cifrado debe producirse antes de que exista el CRQC, no después, y el proyecto de enmienda NIS2 de la UE, previsto para principios de 2026, menciona explícitamente los ataques HNDL como algo que ya está ocurriendo.

¿Cuál es la diferencia entre ML-KEM y ML-DSA?

ML-KEM (FIPS 203, anteriormente Kyber) es un mecanismo de encapsulación de claves que se utiliza para establecer claves compartidas, reemplazando el intercambio de claves clásico como ECDH. ML-DSA (FIPS 204, anteriormente Dilithium) es un algoritmo de firma digital que reemplaza los esquemas de firma clásicos como ECDSA y RSA. Ambos resuelven problemas diferentes y su migración se produce en plazos distintos.

¿Es necesario reemplazar AES-256 como parte de la migración de PQC?

No. AES-256 es un cifrado simétrico y se considera resistente a la computación cuántica cuando se implementa correctamente. La migración a PQC se centra en la criptografía de clave pública (RSA, ECDSA, ECDH) utilizada en el intercambio de claves y las firmas digitales, donde el algoritmo de Shor ofrece una ventaja cuántica. Los algoritmos simétricos solo necesitan ajustar el tamaño de sus claves para tener en cuenta el algoritmo de Grover, que AES-256 ya admite.

¿Cuáles son los plazos de descontinuación de la norma NIST IR 8547?

Según el borrador público inicial de NIST IR 8547 (noviembre de 2024), los algoritmos que proporcionan seguridad de 112 bits (RSA-2048, ECC P-256) quedarán obsoletos para 2030. Todos los algoritmos de clave pública vulnerables a la computación cuántica estarán prohibidos en los estándares de NIST para 2035, en consonancia con la fecha límite del Memorando de Seguridad Nacional 10. El período comprendido entre 2030 y 2035 constituye una etapa de migración controlada, no un paso libre.

¿Es necesaria la criptografía híbrida durante la migración de PQC?

Si bien el enfoque híbrido no es obligatorio en todos los casos, se recomienda para entornos de alta seguridad y la implementación de ADCS de Microsoft lo utiliza mediante certificados compuestos que combinan una firma clásica con una firma ML-DSA. En implementaciones civiles, se puede optar directamente por el control de calidad físico (PQC) puro para los nuevos artefactos; en entornos regulados, el enfoque híbrido suele implementarse durante el período de transición para garantizar una defensa en profundidad.

¿Cómo será compatible Microsoft AD CS con PQC en 2026?

La actualización de mayo de 2026 de Windows Server 2025 introdujo la disponibilidad general de ML-DSA-44, ML-DSA-65 y ML-DSA-87 en AD CS, lo que permite a las CA raíz emisoras y sin conexión firmar certificados con algoritmos resistentes a la computación cuántica. Los escenarios de firma de código funcionan de forma fiable a partir de mediados de 2026; los escenarios más amplios de TLS, VPN y Escritorio remoto siguen siendo compatibles parcialmente y requieren validación para cada carga de trabajo.

¿CertSecure Manager es compatible actualmente con los certificados PQC?

CertSecure Manager funciona como una capa de ciclo de vida independiente de la CA que gestiona la emisión de certificados en Microsoft AD CS, otras plataformas de CA empresariales y CA públicas, con una selección de algoritmos basada en políticas que incluye ML-DSA cuando la CA de back-end lo admite. La compatibilidad con certificados compuestos e híbridos se está ampliando para abarcar los formatos Microsoft ADCS e IETF, y la detección, la automatización y la generación de informes de cumplimiento ya están listas para su uso en producción.

¿Cuál es el primer paso más importante para una hoja de ruta de migración de PQC?

Descubrimiento criptográfico continuo. Hasta que una organización no sepa dónde residen realmente sus dependencias criptográficas (algoritmos en el código, bibliotecas en contenedores, certificados en bases de datos de CA, claves en HSM, secretos codificados en CI/CD), no se puede evaluar el riesgo, asignar prioridades ni medir el progreso de la migración. Todo programa de control de calidad de procesos (PQC) fiable asigna un responsable del inventario antes de asignar cualquier otra cosa.

Conclusión

Las fuerzas que convergen hacia 2026 ya no son abstractas. El NIST ha publicado tres estándares y un cuarto de respaldo; la NSA ha fijado el 1 de enero de 2027 como la nueva fecha límite para la adquisición de estándares; la Comisión Europea ha fijado las estrategias de los Estados miembros para el 31 de diciembre de 2026; Microsoft ha integrado ML-DSA en la plataforma de la que ya dependen la mayoría de las infraestructuras de clave pública empresariales . Cada una de estas iniciativas convierte un documento de planificación en un requisito de entrega, y cada una conlleva consecuencias en materia de adquisiciones o auditorías que se materializan mucho antes de 2030.

La evidencia operativa es igualmente contundente. Las firmas PQC son aproximadamente dos órdenes de magnitud mayores que las firmas clásicas. El firmware de los HSM no está actualizado de forma uniforme. Las jerarquías PKI se secuencian desde la raíz hacia afuera, y este proceso lleva meses. El descubrimiento es el principal obstáculo. El inventario criptográfico aún es un proyecto en desarrollo antes de convertirse en un sistema. Todas las empresas que han intentado simplificar estos pasos han descubierto que es imposible, y que posteriormente se pagan las consecuencias en términos de costos de respuesta a incidentes, hallazgos de auditoría y descalificaciones en adquisiciones.

En criptografía, el calendario es decisivo. La fecha de descontinuación de 2030 está más cerca que el tiempo transcurrido entre la última ronda del concurso NIST PQC y hoy. La hoja de ruta que sobreviva al contacto con la producción es aquella cuyo primer paso comienza ahora.