La criptografía postcuántica llega a AD CS: qué significa realmente la compatibilidad con ML-DSA para su infraestructura de clave pública de Microsoft.

El 12 de mayo de 2026, Microsoft lanzó uno de los cambios más importantes en los más de veinte años de historia de los Servicios de Certificados de Active Directory. La actualización de seguridad 2026-05 para Windows Server 2025 (KB5087539) permite a AD CS crear autoridades de certificación, emitir certificados y firmar respuestas OCSP mediante ML-DSA, el algoritmo de firma digital basado en retículos de módulos estandarizado por NIST en FIPS 204. Es el primer algoritmo post-cuántico que alcanza la disponibilidad general en la CA integrada de Microsoft.

Esto va más allá de la criptografía. AD CS sustenta discretamente la emisión de certificados en una gran parte de los entornos Windows empresariales del mundo: autenticación de dominios, tarjetas inteligentes, registro de dispositivos, TLS interno y firma de código . Durante años, se creyó que AD CS permanecía en modo de mantenimiento y que cualquier modernización criptográfica importante debía realizarse en otro lugar. El ciclo de lanzamiento 2025-2026 cambia esta perspectiva. En este artículo, analizamos las novedades, la criptografía subyacente, las funcionalidades actuales y las que no, los plazos regulatorios que impulsan todo esto y un cronograma práctico por fases que su equipo de PKI puede tener en cuenta.

Respuesta rápida: ¿Qué es la compatibilidad con ML-DSA en AD CS?

ML-DSA (FIPS 204) es el algoritmo de firma digital post-cuántica del NIST, ahora disponible en AD CS en Windows Server 2025 a través de KB5087539 (mayo de 2026) . Es solo para firma , requiere una nueva jerarquía de CA paralela (sin migración in situ) y cubre la firma de código, OCSP y la emisión interna de certificados. La confidencialidad de la sesión TLS requiere ML-KEM (Fase 2 planificada). NIST IR 8547 prohíbe todos los algoritmos vulnerables a la computación cuántica después de 2035.

Puntos Clave

• La actualización de seguridad de mayo de 2026 (KB5087539) trae ML-DSA (el NIST FIP 204 algoritmo de firma post-cuántica) para AD CS en Windows Server 2025. Las CA, las plantillas de certificados y los respondedores en línea ahora pueden firmar con claves resistentes a la computación cuántica.
• ML-DSA Se basa únicamente en la firma digital. Protege contra la falsificación futura de certificados y firmas de código; no garantiza la seguridad cuántica de las sesiones TLS ni de los datos cifrados. Para ello se requiere ML-KEM, que Microsoft ha previsto para una fase posterior junto con los certificados compuestos.
• No existe una migración directa. Las CA existentes no se pueden convertir a ML-DSA: es necesario establecer una nueva jerarquía paralela. Esto hace que el trabajo de laboratorio inicial sea económico y la postergación costosa.
• El plazo regulatorio es fijo, aunque el de la computación cuántica no lo sea: el NIST planea dejar de usar RSA-2048 y ECDSA P-256 después de 2030 y prohibir todos los algoritmos de clave pública vulnerables a la computación cuántica después de 2035. Los certificados de confianza emitidos hoy ya se superponen con esas fechas.
• El primer paso práctico no es un cambio de algoritmo: se trata de un inventario criptográfico y una capa de automatización que convierte el eventual cambio en una modificación de la configuración en lugar de un proyecto de varios años.
• Las empresas están retrasadas en todo el sector: el informe Perspectivas de preparación cuántica de DigiCert de julio de 2026 reveló que el 87 % de las organizaciones planean, prueban o implementan PQC, pero solo el 7 % ha implementado criptografía híbrida o segura frente a la computación cuántica en la mayoría de sus certificados. La primera fase de lanzamiento de AD CS ofrece a las empresas que utilizan principalmente Windows una solución concreta y nativa de Microsoft para empezar a cerrar esa brecha.

¿A quién debería importarle ML-DSA en la atención médica de pacientes con enfermedad de Alzheimer?

La compatibilidad con ML-DSA en AD CS no es decisión de un solo equipo. Los ingenieros de PKI son responsables de la implementación técnica, pero los arquitectos de seguridad, los equipos de cumplimiento, los ingenieros de DevSecOps y los CISO tienen responsabilidades específicas para garantizar que la jerarquía de CA, el conjunto de certificados y los procesos de firma de código de la organización estén correctamente configurados antes de las fechas límite de 2030 y 2035 de la norma NIST IR 8547.

Rol	POR QUÉ ES IMPORTANTE	Acción
Ingenieros de PKI y equipos de certificación	Es responsable de la implementación técnica de la jerarquía de CA ML-DSA paralela: instalación de CA, configuración de plantillas, configuración de OCSP, pruebas de inscripción y la trampa NoHash en instalaciones con scripts; las cinco configuraciones de plantilla que controlan ML-DSA (CNG KSP, propósito de la firma, sin cifrado de clave, sin EKU EFS/S/MIME, nivel de compatibilidad) deben ser correctas o ML-DSA desaparecerá silenciosamente de la pestaña Criptografía; el informe de CyberArk de 2025 sobre el estado de la seguridad de la identidad de las máquinas reveló que el 34 % de las organizaciones aún gestionan manualmente los ciclos de vida de los certificados, y una jerarquía ML-DSA paralela operada sin automatización CLM no será escalable a la fase de migración masiva.	Aplique KB5087539 a una CA de laboratorio de Windows Server 2025 y KB5067036 a los clientes de prueba antes de cualquier trabajo de producción; establezca una jerarquía de laboratorio ML-DSA de dos niveles (CA raíz + CA emisora) y valide la plantilla, la inscripción, OCSP y Authenticode de extremo a extremo; agregue la jerarquía paralela a Administrador de CertSecure para un seguimiento unificado del inventario y la renovación junto con el patrimonio clásico; construya el inventario criptográfico del patrimonio clásico existente utilizando CBOM seguro antes de tocar la producción; involucrar PKI como servicio si la capacidad de ingeniería de PKI interna es insuficiente para operar dos jerarquías concurrentes
Arquitectos de seguridad	Controlar el modelo de gobernanza para la transición a PQC: definir qué cargas de trabajo se trasladan ahora a ML-DSA puro (firma de código de bucle cerrado, OCSP, atestación interna), cuáles esperan certificados compuestos (rutas de confianza mixta) y cuáles esperan la Fase 2 (TLS público, inicio de sesión con tarjeta inteligente, certificados de dispositivos NDES); la amenaza de "cosechar ahora, descifrar después" significa que el cronograma de transición no está determinado por la llegada de las computadoras cuánticas, sino por los períodos de validez de las anclas de confianza emitidas hoy; una raíz de 20 años emitida en 2026 seguirá vigente en 2046, once años después de la fecha de deshabilitación de 2035.	Defina la política de clasificación de carga de trabajo utilizando la matriz de decisión de 8 filas en este artículo; especifique los requisitos de HSM para las CA de ML-DSA de producción (verifique la compatibilidad con ML-DSA CNG KSP y el estado de validación FIPS 140-3 con los proveedores de HSM antes de comprometerse); diseñe la arquitectura de jerarquía paralela (CA raíz fuera de línea, CA emisora, CDP/AIA, OCSP) para el entorno PQ; planifique la ruta de adopción de certificados compuestos para la Fase 2 para que las migraciones de partes confiables de confianza mixta se diseñen antes de que se envíe la Fase 2; realice un seguimiento de la planificación de migración de algoritmos a través de la Centro de Excelencia PQC
Equipos de DevSecOps y firma de código	Los pipelines internos de firma de código y firma de firmware, que son las cargas de trabajo de producción iniciales más fiables para una jerarquía PQ en la Fase 1: Authenticode (Set-AuthenticodeSignature/Get-AuthenticodeSignature) y las API .NET 10 MLDsa/MLDsaCng funcionan de extremo a extremo en un bucle cerrado que la organización controla por completo; la firma de código es también una de las aplicaciones de firma de mayor duración (un binario firmado que se verifique años después debe encadenarse a un ancla de confianza que siga siendo infalsificable en el momento de la verificación), lo que la convierte en una de las cargas de trabajo de mayor prioridad para migrar a ML-DSA.	Implementar la firma de código ML-DSA Authenticode en la jerarquía de laboratorio y validar el ciclo completo de firma y verificación utilizando Set-AuthenticodeSignature y Get-AuthenticodeSignature en clientes Windows 11 24H2/25H2 parcheados; crear una matriz de compatibilidad de partes confiables (versiones de Windows, OpenSSL 3.5+, Java, macOS, dispositivos de red, ejecutores de CI/CD) antes de promover la firma de código ML-DSA a producción; integrar la gestión del ciclo de vida del certificado de firma ML-DSA en la automatización de la canalización de CI/CD; evaluar CodeSign seguro para flujos de trabajo de firma ML-DSA basados ​​en políticas y respaldados por HSM en Windows, Linux, macOS y pipelines de CI/CD
Equipos de Cumplimiento y GRC	Es necesario confirmar que la organización cuenta con un programa documentado de migración post-cuántica antes de que la presión de descontinuación de NIST IR 8547 comience a materializarse en las auditorías; la encuesta Quantum Computing Pulse Poll de ISACA de abril de 2025 reveló que solo el 5 % de las organizaciones tienen una estrategia definida de computación cuántica; las industrias reguladas, incluidas las agencias federales (CNSA 2.0, requisito de adquisición de 2027), la atención médica, los servicios financieros y la defensa, pueden enfrentar requisitos de preparación PQC específicos del marco antes de la fecha límite de NIST de 2030; el informe Quantum Readiness Outlook de DigiCert de julio de 2026 reveló que solo el 7 % de las organizaciones han implementado criptografía segura cuántica o híbrida en la mayoría de sus certificados.	Confirme que la organización cuenta con una hoja de ruta documentada para la migración de PQC alineada con NIST IR 8547 y los requisitos del marco aplicable (CNSA 2.0 para el sector federal, DORA para el sector financiero, CMMC para el sector de defensa); incluya el progreso de la migración de PQC en el paquete trimestral de evidencia de cumplimiento: integridad del inventario criptográfico, estado del laboratorio de jerarquía paralela, cobertura de la clasificación de carga de trabajo y plan de validación de HSM; asigne los plazos de NIST IR 8547 (desuso en 2030, prohibición en 2035) a los hitos de cumplimiento internos; evalúe Preparación para PQC Servicios para una evaluación estructurada y una hoja de ruta.
CISO	La transición a la criptografía cuántica probabilística (PQC) representa un riesgo para la junta directiva, ya que el calendario de cumplimiento está fijado independientemente de la fecha de llegada de las computadoras cuánticas: los anclajes de confianza de larga duración emitidos hoy en criptografía clásica seguirán vigentes cuando se cumplan los plazos de 2030 y 2035; el informe Perspectivas de preparación cuántica de DigiCert de julio de 2026 reveló que el 87 % de las organizaciones están planificando o realizando pruebas piloto de PQC, pero solo el 7 % la ha implementado a gran escala; la actualización KB5087539 elimina el obstáculo de que "Microsoft aún no ha lanzado nada" para las organizaciones centradas en Windows, lo que convierte la ausencia de un programa de PQC en una aceptación deliberada del riesgo en lugar de una brecha tecnológica.	Financiar el programa PQC como una inversión estratégica: el inventario criptográfico (Fase 0), la validación de la jerarquía del laboratorio (Fase 1) y el desarrollo de la automatización CLM (Fases 2-4) requieren personal y presupuesto dedicados que deberían estar en la hoja de ruta ahora, no en 2029; exigir que el progreso de la migración de PQC (cobertura del inventario criptográfico, estado de la jerarquía paralela, porcentaje de migración de la carga de trabajo) se informe trimestralmente como un KPI a nivel de junta directiva; evaluar PKI como servicio Para las organizaciones que necesitan una jerarquía ML-DSA totalmente administrada en HSM de nivel 3 FIPS 140-3 sin construir ni operar la infraestructura internamente; se exige que el plan de migración post-cuántica se revise en la revisión anual del programa PKI de acuerdo con el cronograma NIST IR 8547.

Una actualización discreta con fuertes implicaciones.

Esto va más allá de la criptografía. AD CS sustenta discretamente la emisión de certificados en una gran parte de los entornos Windows empresariales del mundo: autenticación de dominio, tarjetas inteligentes, registro de dispositivos, TLS interno y firma de código . Durante años, se creyó que AD CS permanecía en modo de mantenimiento y que cualquier modernización criptográfica importante debía realizarse en otro lugar. El ciclo de lanzamiento 2025-2026 (particionamiento de CRL, mejoras de auditoría y ahora PQC) cambia por completo esta perspectiva. El mensaje de Microsoft es inequívoco: la CA integrada participa en la transición poscuántica, no se ve afectada por ella.

En este blog analizamos en detalle lo que se entregó, la criptografía que lo respalda, lo que funciona hoy en día y lo que no, los plazos regulatorios que impulsan todo esto y un cronograma pragmático por fases que su equipo de PKI puede tener en cuenta.

Por qué se necesita la criptografía postcuántica y por qué la infraestructura de clave pública (PKI) es la primera en implementarse.

Cada certificado que emite su CA hoy en día se basa en RSA o en matemáticas de curva elíptica. Ambos algoritmos derivan su seguridad de problemas (factorización de enteros y logaritmos discretos) que una computadora cuántica suficientemente grande y tolerante a fallos, que ejecute el algoritmo de Shor, resolvería eficientemente. La criptografía simétrica ofrece un rendimiento mucho mejor: el algoritmo de Grover solo reduce a la mitad la fuerza efectiva de la clave, por lo que AES-256 y SHA-2 siguen siendo suficientemente seguros. El problema fundamental se concentra precisamente donde reside la infraestructura de clave pública (PKI): las claves asimétricas y las firmas digitales.

Nadie puede precisar el año en que llegará una computadora cuántica relevante desde el punto de vista criptográfico. Pero el riesgo ya es una realidad hoy en día, por dos razones distintas:

• Cosecha ahora, descifra despuésLos adversarios están registrando el tráfico cifrado y el texto cifrado robado con la intención de descifrarlo una vez que la capacidad cuántica esté lo suficientemente desarrollada. Cualquier dato cuya confidencialidad deba perdurar más allá del horizonte cuántico (registros médicos, propiedad intelectual, secretos de Estado) queda expuesto en el momento en que se transmite a través de un intercambio de claves vulnerable a la computación cuántica.
• Confianza duradera. Este es un problema específico de la infraestructura de clave pública (PKI), y se centra en las firmas, no en la confidencialidad. Un certificado de CA raíz emitido en 2026 con un período de validez de quince o veinte años debe permanecer infalsificable hasta 2041 o más allá. Una firma de código o firmware aplicada hoy será verificada por las partes que confían en ella dentro de varios años. Si el algoritmo subyacente se encuentra dentro de ese plazo, un atacante puede generar certificados fraudulentos y actualizaciones falsificadas que se encadenan perfectamente a sus anclas de confianza, contaminando retroactivamente todo lo que se basa en ellas.

Si se hacen los cálculos, la urgencia deja de ser teórica. Los anclajes de confianza son los artefactos criptográficos de mayor duración en cualquier empresa. Una apuesta clásica actual consiste en creer que la computación cuántica no madurará hasta dentro de dos décadas, una apuesta que el NIST, la NSA y Microsoft han rechazado públicamente.

Los estándares que respaldan el cambio

En agosto de 2024, tras una competición mundial de ocho años, el NIST finalizó sus tres primeros estándares post-cuánticos. Todos ellos se basan en problemas matemáticos (principalmente retículos estructurados) para los que no se conoce ningún algoritmo cuántico eficiente:

Estándar	Algoritmo (linaje)	Propósito	Estado en Windows
FIP 204	ML-DSA (CRISTALES-Dilitio)	Firmas digitales	GA, y ahora vivo en AD CS
FIP 203	ML-KEM (CRISTALES-Kyber)	Encapsulación de claves / intercambio de claves	GA en las API de GNC; soporte para AD CS planificado (Fase 2)
FIP 205	SLH-DSA (ESFINCAS+)	Firmas sin estado basadas en hash	Disponible en las bibliotecas criptográficas de Microsoft; actualmente no es un algoritmo AD CS.

Un cuarto estándar de firma, FN-DSA (basado en Falcon), aún está en fase de borrador. Para la planificación de PKI empresarial, la combinación clave es sencilla: ML-DSA reemplaza a RSA/ECDSA para la firma; ML-KEM reemplaza el cifrado RSA y (EC)DH para el establecimiento de claves. La Fase 1 de AD CS proporciona la primera parte de esta combinación.

El reloj con el que realmente estás compitiendo.

La respuesta honesta a la pregunta "¿cuándo romperán las computadoras cuánticas el RSA?" es que nadie lo sabe. La respuesta en materia de cumplimiento normativo es mucho más concreta, porque los reguladores han decidido no esperar a tener certeza. Tres plazos convergen ahora en la misma década:

Fecha	Milestone
2024 de agosto	El NIST finaliza FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIP 205 (SLH-DSA).
nov 2024	El documento NIST IR 8547 (borrador), Transición a los estándares de criptografía post-cuántica, publica la hoja de ruta para la descontinuación de RSA. ECDSA, ECDH, DSA y DH de campo finito.
2025	Microsoft anuncia su programa Quantum Safe y distribuye algoritmos PQC a través de SymCrypt y las API de CNG a los participantes del programa Windows Insider; la compatibilidad con Linux se habilita posteriormente mediante SymCrypt-OpenSSL.
Octubre-noviembre de 2025	PQC estará disponible de forma general en Windows Server 2025, Windows 11 24H2/25H2 (habilitación del cliente mediante KB5067036) y .NET 10.
12 de mayo de 2026	Soporte para AD CS ML-DSA GA En Windows Server 2025 mediante la actualización de seguridad KB5087539.
2027	NSA CNSA 2.0Las nuevas adquisiciones para los Sistemas de Seguridad Nacional de EE. UU. deben ser compatibles con algoritmos resistentes a la computación cuántica.
2029	El objetivo declarado de Microsoft es la rápida adopción de PQC en todos sus productos y servicios.
2030	NIST IR 8547: Los algoritmos con nivel de seguridad de 112 bits (RSA-2048 y ECDSA P-256) están obsoletos. Su uso continuado requiere la aceptación documentada del riesgo.
2033	Microsoft se ha fijado como objetivo completar su transición a PQC dos años antes de la fecha límite federal.
2035	NIST IR 8547 / NSM-10: Se prohíben todos los algoritmos de clave pública vulnerables a la computación cuántica (RSA de cualquier tamaño de clave, ECDSA, ECDH, DSA, FFDH). No queda ninguna opción para aceptar riesgos.

Ahora, superponga la duración de sus propios certificados en esa tabla. Un certificado raíz de 20 años emitido en 2026 caduca en 2046, once años después de la fecha límite. Una CA emisora ​​de 10 años creada el año que viene seguirá operativa cuando RSA-2048 se convierta en un hallazgo de auditoría documentado. Por eso Microsoft implementó primero la compatibilidad con las CA: los objetos con mayor duración en la jerarquía son los que deben migrar antes.

La brecha de preparación: lo que muestran los datos recientes

Tres encuestas independientes publicadas en los últimos dieciocho meses coinciden en la misma conclusión: existe un alto nivel de conocimiento sobre la transición post-cuántica, pero su implementación no lo es.

• Encuesta de pulso sobre computación cuántica de ISACAUn estudio publicado el 28 de abril de 2025, basado en las respuestas de más de 2,600 profesionales globales de confianza digital, ciberseguridad, auditoría de TI y gestión de riesgos, reveló que el 62 % teme que la computación cuántica rompa el cifrado actual, pero solo el 5 % afirma que su organización cuenta con una estrategia o plan de acción definido para la computación cuántica.
• Segundo informe anual de DigiCert sobre la preparación cuántica.Un estudio publicado el 23 de julio de 2026, basado en una encuesta realizada a 1,001 responsables de la toma de decisiones en TI y ciberseguridad en EE. UU., Reino Unido y Australia, reveló que el 87 % de las organizaciones están planificando, probando o implementando iniciativas de criptografía cuántica predictiva (PQC), pero solo el 7 % informa utilizar criptografía híbrida o segura frente a la computación cuántica en más de la mitad de sus certificados digitales: un aumento de menos de dos puntos porcentuales con respecto al 5 % que DigiCert registró en mayo de 2025.
• Informe de CyberArk sobre el estado de la seguridad de la identidad de las máquinas en 2025Un estudio publicado el 13 de marzo de 2025, basado en una encuesta realizada a 1,201 responsables de la toma de decisiones en materia de seguridad y TI, reveló que el 72 % de las organizaciones experimentaron al menos una interrupción relacionada con certificados en 2024, mientras que el 34 % aún gestiona los ciclos de vida de la identidad de las máquinas con métodos manuales o no automatizados.

En conjunto, estas cifras describen la brecha exacta en la que se inserta la Fase 1 de AD CS: las organizaciones saben que la transición se avecina, la mayoría no ha implementado criptografía resistente a la computación cuántica a una escala cercana a la de producción, y un tercio aún gestiona los ciclos de vida de los certificados manualmente: el mismo proceso manual que una jerarquía ML-DSA paralela, y el calendario de validez de TLS público cada vez más reducido, no tolerarán. Cerrar esa brecha comienza con el trabajo de descubrimiento en la Fase 0 del cronograma de migración que se muestra a continuación, no con el cambio de algoritmo en sí; consulte nuestra guía sobre cómo crear una lista de materiales criptográficos para conocer lo que realmente implica ese trabajo de descubrimiento.

Lo que Microsoft realmente lanzó en AD CS

La fase 1 tiene un alcance definido: abarca el plano de firma de una infraestructura de clave pública (PKI) de Microsoft , de extremo a extremo. En concreto, AD CS en un servidor Windows Server 2025 actualizado ahora puede:

• Instale las CA raíz, subordinada, empresarial e independiente cuyas operaciones de firma de certificados y pares de claves utilicen ML-DSA, incluida una cadena totalmente post-cuántica cuando todos los niveles la utilicen.
• Publicar plantillas de certificados que emitan certificados hoja ML-DSA para firma de código, TLS/servidor web, usuario y ordenador.
• Inscriba esos certificados a través del complemento Certificados de MMC y certreq.exe, incluida la evaluación de ACL de plantilla de estilo inscripción automática.
• Firme OCSP respuestas con un certificado de firma de ML-DSA Online Responder.
• Verifique y aplique firmas de código Authenticode con certificados ML-DSA: Set-AuthenticodeSignature y la interfaz de usuario de firma funcionan de principio a fin, y .NET 10 expone el algoritmo a los desarrolladores a través de las clases MLDsa / MLDsaCng.

Microsoft ha publicado explícitamente la hoja de ruta futura. El soporte llega por fases, y el equipo de la plataforma se ha comprometido a extender PQC a través de los servicios de rol de AD CS: la Política de inscripción de certificados y los Servicios web de inscripción (CEP/CES), NDES y el Respondedor en línea:

Capacidad	Estándar	Propósito	Estado de AD CS
ML-DSA (puro)	FIP 204	firmas digitales PQ	Ya disponible (Fase 1)
ML-KEM	FIP 203	Encapsulación de clave PQ	Planificado (Fase 2)
ML-DSA compuesto	Borrador de IETF LAMPS	Firma clásica + PQ en un solo certificado	Planificado (Fase 2)
ML-KEM compuesto	Borrador de IETF LAMPS	Encapsulación de clave clásica + PQ	Planificado (Fase 2)
Cobertura de servicios de rol CEP / CES / NDES / OCSP	N/A	Inscripción y revocación de PQ en fontanería	Comprometidos; llegando gradualmente

Línea base de la plataforma. PQC en AD CS requiere Windows Server 2025 con la actualización de seguridad 2026-05 (KB5087539) o posterior en la CA, y Windows 11 24H2/25H2 con la actualización 2025-10 (KB5067036) o posterior en los clientes de inscripción. No hay indicios de una retrocompatibilidad: no se espera que las CA de Windows Server 2019 y 2022 reciban soporte para PQC. Si sus CA emisoras todavía se ejecutan en plataformas más antiguas, la actualización del sistema operativo ahora está formalmente en la ruta crítica de PQC. Todos los algoritmos de PQC también requieren proveedores de almacenamiento de claves CNG: los CSP de CryptoAPI heredados no son compatibles.

Requisitos previos, pasos de configuración y errores comunes de ML-DSA

Utilice esta tabla antes de acceder a la consola de AD CS. Cada fila relaciona un requisito previo o una puerta de configuración con la comprobación de validación que confirma su cumplimiento, el error común cuando no se cumple, la reversión o la solución, y el equipo responsable. Trabajar con esta tabla en un entorno de laboratorio antes de la implementación en producción evita los cinco errores que aparecen con frecuencia en las implementaciones iniciales de ML-DSA.

Requisito previo / Paso de configuración	Verificación de validación	Error común si no se cumple	Corrección / Reversión	Propietario
Windows Server 2025 + KB5087539 en el host de CA	winver muestra Windows Server 2025; wmic qfe get HotFixID muestra KB5087539; ML-DSA aparece en la lista de algoritmos de claves del Administrador del servidor durante la configuración de CA.	El algoritmo ML-DSA no aparece en el asistente de configuración de CA; la configuración falla con el error "Algoritmo no compatible".	Aplique la actualización acumulativa 2026-05 (KB5087539) o posterior; confirme que la actualización aparece en la lista de actualizaciones instaladas antes de volver a intentar la instalación de CA.	Ingeniero de PKI / Infraestructura de Windows
Windows 11 24H2/25H2 + KB5067036 en clientes inscritos	En el asistente de inscripción, el campo Tamaño de clave muestra un valor real (10,496 / 15,616 / 20,736) y no 0; la inscripción se completa correctamente y el certificado aparece en Certificados MMC.	El asistente de inscripción muestra ML-DSA, pero falla al enviarlo; el campo de tamaño de clave muestra 0, lo que indica que el algoritmo solo está parcialmente activado en el KSP del cliente.	Confirme que KB5067036 esté instalado en el cliente; aplique las actualizaciones acumulativas pendientes; vuelva a intentar la inscripción después de confirmar que el tamaño de la clave muestra un valor válido.	Ingeniero de PKI / Ingeniería de escritorio / Ingeniería de cliente
Proveedor de almacenamiento de claves CNG seleccionado (no CSP anterior)	En la pestaña Criptografía de la plantilla de certificado, la categoría de proveedor es Proveedor de almacenamiento de claves; ML-DSA aparece en la lista de algoritmos cuando el propósito se establece en Firma.	ML-DSA no aparece en la pestaña Criptografía incluso después de aplicar el parche; la plantilla está utilizando la categoría de proveedor CSP de CryptoAPI heredada.	En la pestaña Criptografía de la plantilla, seleccione Proveedor de almacenamiento de claves como Categoría de proveedor; ML-DSA aparecerá cuando el Propósito se establezca en Firma.	Ingeniero de PKI
Propósito de la plantilla establecido en Firma (exactamente)	La pestaña Gestión de solicitudes muestra Propósito: Firma; ML-DSA aparece en la lista de algoritmos de la pestaña Criptografía; no hay Cifrado de clave ni Acuerdo de clave en la extensión Uso de clave	ML-DSA desaparece silenciosamente de la pestaña Criptografía; no se muestra ningún mensaje de error; el único síntoma es que ML-DSA no aparece en la lista a pesar de que se ha seleccionado CNG KSP.	Abra la pestaña "Manejo de solicitudes" de la plantilla y establezca "Propósito" en "Firma"; elimine cualquier valor de "Cifrado de clave", "Acuerdo de clave" o "EKU EFS/S/MIME"; ML-DSA volverá a aparecer en la lista de algoritmos.	Ingeniero de PKI
NoHash se pasa explícitamente en la instalación de CA mediante script	El script de instalación de CA incluye -HashAlgorithmName “NoHash”; después de la instalación, certsrv.msc muestra Algoritmo de hash: NoHash y Algoritmo de firma: ML-DSA; pkiview.msc muestra que la CA está en buen estado.	La configuración de la CA falla con un error en el algoritmo hash o se instala con el hash SHA-256 aplicado a una clave ML-DSA, lo que produce un certificado de CA no conforme; el error puede ser silencioso si el script no valida el certificado resultante.	Agregue -HashAlgorithmName “NoHash” al cmdlet de PowerShell Install-AdcsCertificationAuthority o a su equivalente certutil -installcert; valide el algoritmo de firma del certificado CA instalado antes de emitir cualquier certificado; vuelva a construir la CA si se aplicó SHA-256 a una clave ML-DSA.	Ingeniero de PKI / Automatización
HSM CNG KSP verificado para soporte ML-DSA	La documentación del proveedor de HSM confirma la compatibilidad con ML-DSA en la versión de firmware instalada; la generación de claves ML-DSA a través del HSM CNG KSP se realiza correctamente en una prueba; el certificado de validación FIPS 140-3 cubre el algoritmo ML-DSA y la versión de firmware instalada.	El HSM no genera la clave ML-DSA o devuelve un error de algoritmo no compatible a través del CNG KSP; la instalación de la CA falla en el paso de generación de clave.	Verifique la versión del firmware y el grado de madurez de la integración de CNG KSP con el proveedor de HSM; actualice el firmware de HSM si la compatibilidad con ML-DSA está disponible en una versión posterior; ejecute el laboratorio de la Fase 1 en Microsoft Software KSP mientras espera la validación de HSM.	Ingeniero de PKI / Administrador de HSM

ML-DSA bajo el capó: lo que los ingenieros de PKI deben saber

ML-DSA deriva de CRYSTALS-Dilithium, la firma principal ganadora del concurso del NIST. Su seguridad se basa en la dificultad de los problemas de Aprendizaje con Errores y Solución de Enteros Cortos sobre retículos estructurados, matemáticas sin un ataque cuántico eficiente conocido. Dos de sus propiedades influyen directamente en el comportamiento de AD CS, por lo que conviene comprenderlas antes de usar una consola.

Es un algoritmo que solo utiliza firmas.

ML-DSA no puede cifrar datos ni realizar intercambio de claves. Este hecho explica la mayoría de las limitaciones de configuración que encontrará: las plantillas deben ser para firmas, el uso de claves de cifrado y acuerdo de claves está prohibido, se rechazan las EKU de EFS y correo electrónico seguro, y la confidencialidad de la sesión TLS permanece intacta hasta que llegue ML-KEM. Si un flujo de trabajo necesita una clave para proteger datos en lugar de probar la identidad o la integridad , ML-DSA no es la herramienta adecuada.

Tres conjuntos de parámetros, tres compensaciones entre seguridad y tamaño.

AD CS admite los tres conjuntos de parámetros FIPS 204 en modo puro (no compuesto). Elija según la categoría de seguridad que necesite y el presupuesto que pueda gestionar:

Conjunto de parámetros	Categoría NIST	Llave pública	Llave privada	Firma	Tamaño de la tecla mostrado en la interfaz de usuario de Windows
ML-DSA-44	Nivel 2	1,312 B	2,560 B	2,420 B	10,496 bits de
ML-DSA-65	Nivel 3	1,952 B	4,032 B	3,309 B	15,616 bits de
ML-DSA-87	Nivel 5	2,592 B	4,896 B	4,627 B	20,736 bits de

Un detalle que suele confundir a la gente al principio: la interfaz de usuario de Windows muestra tamaños de clave de 15,616 bits, lo que resulta extraño comparado con RSA-2048. Se trata simplemente de la longitud de la clave pública expresada en bits (1,952 bytes x 8). Nada exótico: solo una clave mucho más grande. Como guía práctica, ML-DSA-65 es la opción predeterminada sensata para emitir CA y certificados hoja (la categoría 3 se sitúa junto a AES-192), ML-DSA-87 es adecuada para raíces y anclas de larga duración donde se busca el máximo margen, y ML-DSA-44 se utiliza en casos con limitaciones de tamaño reales donde la categoría 2 es una alternativa aceptable.

¿Por qué desaparece el menú desplegable del algoritmo hash?

La infraestructura de clave pública clásica (PKI) se basa en el método de hash y firma: la autoridad de certificación (CA) calcula un resumen de los datos que se van a firmar y, a continuación, lo firma con su clave privada. La elección del hash era un parámetro configurable, lo que provocó que la industria utilizara MD5 y SHA-1 firmados con claves perfectamente válidas, y posteriormente tuviera que realizar migraciones complejas para solucionarlo. ML-DSA elimina este parámetro: el procesamiento de mensajes es parte integral del esquema de firma, está predefinido internamente y no puede ser seleccionado por el operador.

AD CS lo revela con total transparencia. En el momento en que se selecciona un algoritmo de clave ML-DSA durante la configuración de la CA, la lista de algoritmos hash se reduce a una sola entrada: NoHash. En las plantillas de certificados, el selector de hash y el control de "formato de firma alternativo" (el interruptor PKCS#1 v2.1) aparecen deshabilitados: no hay ninguna variante de esquema de firma para elegir. NoHash no significa que los datos no estén cifrados; significa que el cifrado está integrado en FIPS 204 y AD CS no pretende que se pueda elegir. Toda una clase de configuración incorrecta histórica de PKI simplemente deja de existir.

Certificados puros frente a certificados compuestos: La cuestión de la transición

Los certificados post-cuánticos se presentan en dos variantes arquitectónicas, y la hoja de ruta de Microsoft incluye deliberadamente ambas:

• Pura. El certificado utiliza un único algoritmo post-cuántico: el que AD CS distribuye actualmente. Es el estado final más limpio, pero cada parte que confía en él debe comprender ML-DSA para validarlo. En un entorno heterogéneo con numerosos dispositivos, pilas integradas y middleware heredado, esto supone una limitación importante.
• Compuesto. El certificado contiene una clave clásica (RSA o ECDSA) y una clave post-cuántica, y su firma incluye ambas. La validación requiere la verificación de ambas, por lo que falsificarlo implica romper ambos algoritmos, y el certificado permanece seguro mientras una de ellas sea válida. El inconveniente es el tamaño (se transportan dos copias de cada elemento) y la necesidad de que los validadores comprendan el formato compuesto, actualmente definido en los borradores de IETF LAMPS.

Lectura práctica: ML-DSA puro se adapta a ecosistemas de circuito cerrado y de nueva creación donde se controla cada validador: firma de código interna, certificación de infraestructura, confianza entre máquinas dentro de un conjunto gestionado. Composite es la solución de migración para entornos mixtos, donde se necesita protección post-cuántica sin depender de la compatibilidad universal con ML-DSA desde el primer día. La Fase 2 de AD CS incluirá ML-DSA compuesto y ML-KEM compuesto ; hasta entonces, se recomienda planificar las implementaciones puras en torno a pruebas de compatibilidad con las partes que confían en el sistema.

¿Qué cargas de trabajo deberían migrarse a ML-DSA ahora? Una matriz de decisión

No todas las cargas de trabajo de certificados están listas para migrar, y el alcance de la Fase 1 hace que esta decisión sea principalmente mecánica: si una carga de trabajo requiere cifrado o depende de un servicio de rol que aún no se ha implementado, debe esperar. Utilice esta matriz para organizar su propia lista de tareas pendientes antes de abrir la consola de AD CS.

carga de trabajo	¿Cambiar a ML-DSA ahora?	Por qué
Firma de código interno y firma de firmware	Sí, piloto ahora	Las API de Authenticode y MLDsa de .NET 10 funcionan de extremo a extremo, y usted controla cada validador en una cadena de firma de circuito cerrado.
Firma de respuesta de OCSP	Sí, piloto ahora	La compatibilidad de Online Responder con ML-DSA es de disponibilidad general, y un certificado de firma tiene un bajo impacto en las pruebas.
Certificados de usuario interno o de equipo a través de MMC/certreq	Sí, en una jerarquía de laboratorio paralela	La inscripción es de disponibilidad general (GA), pero la inscripción automática y el NDES no lo son, así que planifique la emisión manual o mediante scripts durante la fase piloto.
Certificados TLS/de servidor web de acceso público	Todavía no	Schannel no vincula los certificados de servidor ML-DSA para HTTPS, y la mayoría de las partes públicas que confían en ellos no pueden validar las cadenas ML-DSA.
Inicio de sesión con tarjeta inteligente y PKINIT	Todavía no	Los flujos de autenticación Kerberos/PKINIT no son compatibles con ML-DSA en esta versión.
Certificados de dispositivos emitidos por NDES/SCEP (MDM)	Todavía no	La inscripción en NDES para ML-DSA aún no se ha enviado; espere a que se complete la cobertura del servicio de rol comprometida.
Cifrado S/MIME o EFS	Nunca con ML-DSA específicamente	ML-DSA solo utiliza firmas; las cargas de trabajo de cifrado requieren ML-KEM, una fase posterior e independiente.
Certificados validados por partes mixtas o terceros que confían en ellos.	Espere los certificados compuestos	El método Composite ML-DSA (Fase 2) permite que un certificado se valide tanto con verificadores clásicos como post-cuánticos durante la transición.

El patrón subyacente a la tabla es el siguiente: todo lo que aparece en las filas "sí" representa un ciclo cerrado que usted controla de principio a fin, mientras que todo lo que aparece en las filas "aún no" depende de un servicio de rol, un protocolo o una entidad externa que Microsoft aún no ha extendido a ML-DSA. Esta es también la forma más rápida de explicar el límite de la fase a una persona interesada que no estuvo presente en la reunión previa sobre la firma del acuerdo.

Cómo establecer una CA ML-DSA: ¿Qué funciona hoy?

Solo nuevas jerarquías, por diseño.

El hecho más importante para la implementación: las CA de ML-DSA deben instalarse desde cero. No es posible convertir una CA existente directamente ni renovarla con un nuevo algoritmo: cambiar el algoritmo de clave pública implica una nueva clave, un nuevo certificado y, en consecuencia, una nueva identidad de CA. Microsoft recomienda crear una jerarquía post-cuántica paralela junto con la infraestructura de clave pública (PKI) de producción y migrar las cargas de trabajo de forma planificada. Aunque pueda parecer engorroso, esto refleja la forma en que siempre se han rotado las generaciones de PKI, y permite comenzar la evaluación hoy mismo sin riesgo alguno para la emisión en producción.

Instalación de la CA

En el asistente de configuración de AD CS del Administrador del servidor, los tres conjuntos de parámetros ML-DSA aparecen ahora en la lista de algoritmos de clave junto con RSA y ECDSA, y al seleccionar uno, la lista de hashes se reduce a NoHash.

Nota de campo: la trampa NoHash. Debe pasar explícitamente -HashAlgorithmName “NoHash”. El motor de configuración de AD CS inicializa sus valores predeterminados a RSA con SHA-256 y conserva ese hash SHA-256 incluso después de cambiar el algoritmo de clave a ML-DSA, por lo que una instalación de ML-DSA que omita el parámetro fallará. La misma lógica se aplica en la automatización: cualquier script de implementación que codifique SHA256 de forma fija necesita una bifurcación condicional antes de acceder a una CA de PQ.

Tras la instalación, certsrv.msc muestra exactamente lo que cabría esperar: el proveedor de almacenamiento de claves de software de Microsoft que contiene una clave ML-DSA, el algoritmo hash NoHash y un certificado de CA cuyo algoritmo de firma es ML-DSA. La creación de la cadena, la publicación de CDP/AIA y las comprobaciones de estado de pkiview.msc funcionan con normalidad.

Plantillas de certificados: cinco configuraciones que lo controlan todo

ML-DSA aparece en la pestaña Criptografía de la plantilla solo cuando la plantilla tiene el formato correcto, y varios de los requisitos se remontan directamente a "solo firma":

Configuración de plantilla	Valor requerido	Por qué importa
Categoría de proveedor criptográfico	Proveedor de almacenamiento de claves de GNC	PQC solo existe en la pila CNG; las plantillas heredadas basadas en CSP nunca incluirán ML-DSA.
Compatibilidad (CA y destinatario)	Windows Server 2008 o posterior	Los proveedores de GNC solo aparecen en la lista de proveedores con este nivel de compatibilidad o superior.
Gestión de solicitudes – Propósito	Firma: exactamente	Este es el problema que hace perder una tarde a la gente: con cualquier otro propósito (incluido "Firma y cifrado"), ML-DSA desaparece silenciosamente de la pestaña de Criptografía.
Políticas de la aplicación (EKU)	Sin EFS, sin correo electrónico seguro	Ambas implican operaciones de cifrado que ML-DSA no puede realizar.
Extensión de uso de teclas	Sin cifrado de clave, no hay acuerdo de clave.	Por la misma razón: el par de claves no puede establecer ni transportar secretos.

Inscripción, OCSP y firma de código

Actualmente, la inscripción funciona mediante el asistente MMC de certificados y certreq.exe en clientes Windows 11 24H2/25H2 actualizados. La inscripción NDES (SCEP) aún no está disponible: esto es relevante si los certificados de dispositivo emitidos por MDM dependen de NDES.

Nota de campo: el cliente parcialmente parcheado. En un cliente Windows 11 parcialmente parcheado, el asistente de inscripción puede mostrar ML-DSA y luego fallar al intentar inscribirse. Compruebe el campo Tamaño de clave del asistente para saber por qué: un valor real (10 496 / 15 616 / 20 736) significa que el cliente está completamente habilitado, mientras que 0 significa que el algoritmo solo está parcialmente activado en el proveedor de almacenamiento de claves del cliente: finalice la aplicación de parches antes de culpar a la CA.

El Respondedor en línea acepta un certificado de firma de respuesta OCSP ML-DSA (duplique la plantilla predeterminada en lugar de editarla) y firma las respuestas sin problemas. Una peculiaridad estética: la propiedad hash-algorithm del respondedor puede mostrar un valor sin sentido para las configuraciones ML-DSA, porque no hay ningún hash que mostrar. Ignore la cadena y confíe en pkiview.msc , que informa que el respondedor está en buen estado. Authenticode es igualmente completo: la firma y la verificación con Set-AuthenticodeSignature / Get-AuthenticodeSignature funcionan de extremo a extremo, lo que convierte la firma de código interna en una de las cargas de trabajo de producción iniciales más fiables para una jerarquía PQ.

Lo que aún no está ahí

Una definición honesta del alcance es la mitad de una buena consultoría, así que aquí está la línea divisoria actual en una vista:

Obras actuales (Fase 1)	Aún no / planeado
Autoridades de certificación raíz, subcategoría, empresarial e independientes de ML-DSA (instalaciones nuevas)	Migración in situ o renovación de algoritmos de las CA existentes: no se producirá; se planificarán jerarquías paralelas.
Emisión de hojas ML-DSA: firma de código, servidor web, usuario, plantillas de computadora	Inscripción en NDES/SCEP; cobertura completa del servicio web CEP/CES (comprometida, incremental)
Inscripción mediante certificados MMC y certreq.exe	Enlaces HTTPS de IIS con certificados de servidor ML-DSA: la autenticación TLS de Schannel aún no está habilitada.
Firma de respuesta OCSP con ML-DSA	Kerberos / PKINIT y flujos de inicio de sesión con tarjeta inteligente
Firma y verificación de código Authenticode; API MLDsa de .NET 10	Todo lo relacionado con el cifrado (EFS, cifrado S/MIME): por diseño hasta que se implemente ML-KEM.
Compatibilidad con plataformas Windows Server 2025 + Windows 11 24H2/25H2	Certificados compuestos ML-DSA / ML-KEM (Fase 2); Windows Server 2019/2022 (no se prevé retrocompatibilidad)

Lea atentamente la columna de la derecha antes de prometerle a alguien una «intranet cuánticamente segura». La versión de hoy garantiza la seguridad del plano de emisión y firma . El plano de sesión (intercambio de claves TLS y, por lo tanto, protección de recopilación y descifrado posterior para datos en tránsito) depende de la integración de ML-KEM a través de la pila TLS. Los terceros que confían en los certificados representan un desafío aparte: muchas aplicaciones, dispositivos y middleware adyacente a HSM aún no analizan los certificados ML-DSA, por lo que cada proyecto piloto necesita una matriz de compatibilidad, no una suposición.

Realidades operativas: tamaño, HSM y funcionamiento de dos PKI

Todo se hace más grande

La seguridad de Lattice se paga en bytes. Compare los artefactos que su infraestructura realmente mueve y almacena:

Algoritmo	Llave pública	Firma	Firma vs. RSA-2048
RSA-2048	256 B	256 B	1x (línea base)
ECDSA P-256	~ 64 B	~ 70 B	~ 0.3x
ML-DSA-44	1,312 B	2,420 B	~ 9x
ML-DSA-65	1,952 B	3,309 B	~ 13x
ML-DSA-87	2,592 B	4,627 B	~ 18x

Un certificado hoja que pesa aproximadamente 1-1.5 KB con RSA se sitúa en el rango de 6-7 KB en ML-DSA-65 una vez que se tiene en cuenta la clave pública incrustada más la firma de la CA emisora; una cadena de tres niveles supera los 20 KB incluso antes de que comience el handshake. Las respuestas OCSP aumentan con una firma más, normalmente, un certificado de firma incrustado. Presupuesta las consecuencias ahora: ancho de banda y caché de CDP/AIA y OCSP, almacenes de certificados y la base de datos de CA, inventarios CLM, comportamiento de los registros TLS y MTU una vez que llegan los handshakes ML-KEM, y límites de capacidad estrictos en tarjetas inteligentes, TPM y dispositivos con recursos limitados. Nada de esto es prohibitivo (la PKI web pública está absorbiendo el mismo cambio), pero pertenece a tu modelo de capacidad, no a tu análisis posterior al incidente.

HSM: verifique antes de prometer

La experiencia de la Fase 1 se ejecuta en el Proveedor de Almacenamiento de Claves de Software de Microsoft, que es adecuado para laboratorios y muchas jerarquías internas. Los entornos de producción y las CA emisoras en entornos regulados requerirán claves ML-DSA respaldadas por hardware, y esto depende completamente de que el proveedor CNG de su proveedor de HSM exponga el algoritmo en un firmware que esté (o esté en proceso de estar) validado según FIPS 140-3. Los principales proveedores (Thales Luna, entrust nShield, servicios HSM en la nube) han estado agregando soporte para FIPS 203/204 en las últimas generaciones de firmware, pero el estado de validación y la madurez de la integración del KSP varían según el modelo y la versión. Incluya "muéstrenme ML-DSA a través de su KSP CNG y muéstrenme la documentación de validación" como un punto clave en su plan piloto, y decida conscientemente si las fases iniciales se ejecutan con claves de software mientras se actualiza el hardware.

Estarás gestionando dos PKI durante años.

Una jerarquía paralela no es un laboratorio de fin de semana: es un segundo entorno de producción con sus propias plantillas, publicación de CDP/AIA, OCSP, monitorización, ceremonias de claves, deltas de CP/CPS y, finalmente, un plan de desmantelamiento para el lado clásico. Las organizaciones que gestionan esto bien son las que tratan la transición como un programa de criptoagilidad : si la emisión y renovación de certificados ya están automatizadas y basadas en inventario, el cambio de algoritmos se convierte en un cambio de configuración ejecutado por la maquinaria. Si su infraestructura aún renueva certificados mediante hojas de cálculo y recordatorios de calendario, la migración a PQC se sentirá como la obsolescencia de SHA-1, pero en todos los certificados que posee, con cargas útiles más grandes y plazos más estrictos.

Un cronograma de migración pragmático

Al relacionar las fechas regulatorias con el trabajo concreto de PKI, se obtiene un plan de cinco fases. Los plazos que se muestran a continuación presuponen una empresa de tamaño considerable que comienza aproximadamente ahora; puede ajustarlos según sus necesidades, pero mantenga el orden: cada fase reduce los riesgos de la siguiente. Para obtener una versión más completa y transversal de esta hoja de ruta, más allá de AD CS específicamente, consulte nuestra guía «Migración a PQC en 2026» . Realice un seguimiento de la planificación general de la migración post-cuántica a través del Centro de Excelencia de PQC.

Fase	Ventana	Qué hacer realmente
0. Inventario y mapeo de la exposición	Ahora – finales de 2026	Construir un inventario criptográfico (un CBOM) en CA, plantillas, claves, protocolos, aplicaciones y dispositivos integrados. Señale las dos clases de alto riesgo: firmas de larga duración (raíces, firma de código/firmware, confianza de documentos) y datos confidenciales a largo plazo expuestos a la recopilación y descifrado posterior. Actualice las plataformas de CA a Windows Server 2025 y la flota de clientes a la base compatible con PQC.
1. Piloto PQ paralelo	2026 – 2027	Configure una jerarquía ML-DSA de dos niveles aislada en el laboratorio. Realice pruebas de instalación de CA, plantillas, inscripción en MMC/certreq, OCSP y Authenticode de extremo a extremo. Ejecute una matriz de compatibilidad de partes confiables (Windows, OpenSSL 3.5+, Java, dispositivos de red, middleware). Mida las diferencias de tamaño y rendimiento. Redacte ahora las enmiendas de CP/CPS y los requisitos de HSM, mientras no haya urgencia.
2. Uso de producción dirigido	2027 – 2028	Priorice las cargas de trabajo de firma de circuito cerrado (firma de código interno, certificación de infraestructura, firma de documentos) donde usted controla a cada validador. Adopte certificados compuestos para rutas de confianza mixta a medida que se implemente la Fase 2. Incorpore la compatibilidad con PQC en el lenguaje de adquisición para que cada nuevo dispositivo, HSM y aplicación llegue listo.
3. Transición jerárquica	2028 – 2030	Emita la próxima generación de certificados raíz y autoridades de certificación emisoras como ML-DSA o compuestos. Desactive por defecto la emisión de certificados RSA-2048 y P-256 antes de su descontinuación en 2030. Integre ML-KEM para TLS, ya que Windows y su sistema de equilibrio de carga/inspección lo habilitan.
4. Migración de patrimonio y jubilación	2030 – 2033	Migración masiva de fincas foliares mediante Herramientas automatizadas para la gestión del ciclo de vida de los certificadosCon el volumen actual de certificados y su vida útil cada vez más corta, la migración manual no es una cuestión de números redondos. Retire las jerarquías clásicas según un calendario publicado, en consonancia con el objetivo de transición completa de Microsoft para 2033.
Parada brusca	2035	RSA, ECDSA y DH clásico no están permitidos según la norma NIST IR 8547. No debe quedar ningún elemento vulnerable a la computación cuántica en las rutas de confianza de producción.

Lo que esto dice sobre el futuro de AD CS

Aquí hay una señal de segundo orden que vale la pena mencionar. Durante una década, se dio por sentado que AD CS nunca volvería a recibir inversiones significativas, y las decisiones sobre la plataforma se tomaron en consecuencia. El lanzamiento de un algoritmo de firma actualizado por el NIST (con una hoja de ruta multifase publicada que abarca ML-KEM, certificados compuestos y los servicios de roles de inscripción) no es un comportamiento propio del modo de mantenimiento.

El momento también coincide con un cambio más sutil en el ecosistema de confianza pública: las CA públicas están eliminando la EKU de autenticación de cliente de los certificados TLS a medida que los programas raíz separan la confianza del servidor y del cliente, lo que significa que el enorme mundo de mTLS (mallas de servicios, flotas de dispositivos, autenticación de API B2B) está migrando a CA privadas, lo hayan planeado o no. Una plataforma de CA privada que se incluye en la licencia del sistema operativo, se integra con la identidad de AD y ahora firma con algoritmos post-cuánticos se convierte de repente en una zona de aterrizaje muy lógica para esas cargas de trabajo. AD CS no solo está sobreviviendo a la transición de PQC, sino que la está utilizando para volver a entrar en el debate.

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

Todo lo anterior se reduce a un problema de secuenciación: saber qué se tiene, demostrar qué funciona, automatizar el intercambio y cumplir con las fechas ya programadas. Precisamente en eso se basa la labor diaria de Encryption Consulting: hemos ayudado a más de 100 organizaciones de la lista Fortune 500 a evaluar, diseñar y operar sus sistemas criptográficos, y nuestros servicios de asesoramiento PQC se crearon precisamente para esta transición.

Donde los equipos se atascan	Cómo te ayudamos
“En realidad, no sabemos dónde reside la criptografía vulnerable a la computación cuántica en nuestro entorno.”	Nuestro compromiso de asesoramiento PQC comienza con una evaluación de amenazas cuánticas y CBOM seguro Crea una lista de materiales criptográficos automatizada y actualizada continuamente que abarca certificados, claves, algoritmos y protocolos: el inventario del que depende cada fase posterior.
“Necesitamos una hoja de ruta sólida, no un proyecto científico.”	Ofrecemos una hoja de ruta y una estrategia de preparación cuántica alineadas con las directrices del NIST, la CISA y la NSA: hitos por fases, un modelo operativo de criptoagilidad y validación de prueba de concepto de los algoritmos candidatos antes de que nada llegue a producción.
“Nuestro entorno AD CS necesita una jerarquía PQ paralela diseñada correctamente.”	Nuestros Evaluación de PKI y los servicios de diseño/implementación cubren la arquitectura jerárquica, la integración de HSM, el desarrollo de CP/CPS y la gobernanza de plantillas, y PKI como servicio Puede alojar la generación post-cuántica en módulos de seguridad de hardware (HSM) FIPS 140-3 de nivel 3 si prefiere consumirla en lugar de construirla.
“Cuando cambie el algoritmo, tendremos que transferir decenas de miles de certificados.”	Administrador de CertSecureNuestra plataforma de gestión del ciclo de vida de los certificados se diseñó con la criptoagilidad como eje central: descubrimiento continuo en AD CS, HashiCorp Vault, la nube y los entornos de dispositivos, inventario con perfil de riesgo y renovación sin intervención a escala de flota: de modo que una migración de algoritmo se convierte en un cambio de política, no en un proyecto de varios trimestres.
“Nuestro sistema de firma de código debe sobrevivir a la transición sin sufrir daños.”	CodeSign seguro Proporciona flujos de trabajo de firma basados ​​en políticas y respaldados por HSM en Windows, Linux, macOS y pipelines de CI/CD: el plano de control natural para trasladar la firma de Authenticode y firmware a algoritmos post-cuánticos.

Conclusión

La actualización de mayo de 2026 puede entenderse como el pistoletazo de salida. AD CS ahora puede crear un plano de firma totalmente post-cuántico (jerarquía de CA, emisión, OCSP, firma de código ) sobre criptografía estandarizada y aprobada por el NIST, con encapsulación de claves y certificados compuestos ya incluidos en la hoja de ruta publicada. La pregunta tecnológica ha pasado de "¿cuándo se moverá Microsoft?" a "¿qué tan preparado está mi entorno para seguir el ejemplo?".

La incertidumbre sobre el hardware cuántico tiene dos caras, pero el calendario de cumplimiento no: 2030 y 2035 están fijados, y los acuerdos de confianza firmados hoy seguirán vigentes cuando lleguen esas fechas. Las organizaciones que afrontarán esta transición con tranquilidad serán aquellas que la traten como un programa de criptoagilidad: primero el inventario, luego la automatización y, por último, los algoritmos. Establezca la jerarquía del laboratorio, detecte las incompatibilidades cuando sean económicas y deje que el cambio en sí sea sencillo. Así es como siempre ha sido una buena ingeniería de infraestructura de clave pública (PKI).

Esta publicación se revisa trimestralmente, teniendo en cuenta la vigencia de la norma NIST IR 8547, la hoja de ruta de Microsoft AD CS y los cronogramas de validación PQC de los proveedores de HSM, y de inmediato cada vez que Microsoft lanza una nueva funcionalidad PQC de AD CS o NIST actualiza el cronograma de descontinuación.

Preguntas frecuentes

¿Puedo actualizar mi AD CS CA existente a ML-DSA?

No. Las CA de ML-DSA deben instalarse de nuevo: no existe conversión in situ ni renovación con un nuevo algoritmo, ya que cambiar el algoritmo de clave pública implica una nueva clave y una nueva identidad de CA. El patrón compatible es una jerarquía post-cuántica paralela que opera junto con su PKI existente mientras se migran las cargas de trabajo.

¿La implementación de ML-DSA en AD CS hace que mi TLS sea seguro frente a ataques cuánticos?

Todavía no. ML-DSA abarca las firmas: integridad de certificados y OCSP, firma de código y autenticación de identidades. La confidencialidad de la sesión depende del intercambio de claves, que requiere ML-KEM a través de la pila TLS; actualmente, IIS ni siquiera vincula un certificado de servidor ML-DSA para HTTPS . La protección de recopilación y descifrado de datos en tránsito se implementa con la fase de encapsulación de claves, no con esta.

¿Qué conjunto de parámetros de ML-DSA debo estandarizar?

ML-DSA-65 (categoría 3 del NIST) es la opción predeterminada práctica para la emisión de CA y certificados hoja. Reserve ML-DSA-87 para certificados raíz y anclas de larga duración donde el margen máximo justifique el tamaño, y considere ML-DSA-44 como una excepción deliberada para escenarios con limitaciones de tamaño donde la categoría 2 sea una decisión de riesgo aceptada.

¿Por qué no puedo elegir un algoritmo hash al usar ML-DSA en AD CS?

Dado que FIPS 204 integra el procesamiento de mensajes en el propio esquema de firma, no es necesario configurar un paso adicional de hash y firma. AD CS lo representa como la única opción NoHash. Recuerde especificarla explícitamente en las instalaciones mediante scripts; la configuración predeterminada del motor de configuración sigue siendo RSA/SHA-256 y no se corrige automáticamente al seleccionar una clave ML-DSA.

¿Windows Server 2019 o 2022 contarán con soporte para ML-DSA/PQC en AD CS?

No hay indicios de una adaptación a versiones anteriores: PQC en AD CS es una funcionalidad de Windows Server 2025. Si sus CA se ejecutan en plataformas más antiguas, la actualización del sistema operativo ahora forma parte de la ruta crítica posterior a la computación cuántica y debería incluirse en el plan del próximo año, no en el de 2030.

¿Cuál es la principal conclusión de este artículo sobre la compatibilidad con ML-DSA en AD CS?

La actualización de Microsoft de mayo de 2026 (KB5087539) otorga a AD CS la capacidad de crear un plano de firma totalmente post-cuántico mediante ML-DSA (FIPS 204). ML-DSA solo admite firmas y requiere nuevas jerarquías paralelas en lugar de una migración in situ. El primer paso práctico es un inventario criptográfico, no un cambio de algoritmo: NIST IR 8547 desaconseja RSA-2048 y ECDSA P-256 después de 2030 y prohíbe todos los algoritmos vulnerables a la computación cuántica después de 2035, y los anclajes de confianza de larga duración emitidos hoy ya se superponen con esas fechas.

¿Por qué es importante ML-DSA en AD CS para los equipos de PKI empresariales?

AD CS sirve de base para la emisión de certificados en entornos Windows empresariales: autenticación de dominio, tarjetas inteligentes, registro de dispositivos, TLS interno y firma de código. El informe Perspectivas de preparación cuántica de DigiCert de julio de 2026 reveló que el 87 % de las organizaciones están planificando o probando PQC, pero solo el 7 % ha implementado criptografía híbrida o segura frente a la computación cuántica en la mayoría de sus certificados. El artículo KB5087539 ofrece a los equipos de PKI centrados en Windows un punto de partida concreto y nativo de Microsoft. El plazo regulatorio es fijo: RSA-2048 y ECDSA P-256 quedarán obsoletos después de 2030, y todos los algoritmos vulnerables a la computación cuántica estarán prohibidos después de 2035 según la norma NIST IR 8547.

¿Qué riesgos aumentan si la planificación de la infraestructura de clave pública (PKI) post-cuántica se gestiona de forma manual o reactiva?

Aumentan tres categorías de riesgo: exposición a anclas de confianza de larga duración (una raíz de 20 años emitida en 2026 seguirá vigente en 2046, once años después de la fecha de prohibición de 2035); exposición a la recopilación de datos ahora y el descifrado posterior (los adversarios que registran el tráfico cifrado hoy pretenden descifrarlo una vez que la capacidad cuántica madure); y complejidad de la migración de activos (el informe de CyberArk de 2025 reveló que el 34 % de las organizaciones aún gestionan manualmente los ciclos de vida de los certificados, lo que convierte la migración masiva de ML-DSA en un evento de nivel SHA-1 a una escala mucho mayor).

¿Qué requisitos previos se necesitan antes de implementar ML-DSA en AD CS?

Se deben cumplir cinco requisitos previos: Windows Server 2025 + KB5087539 en el host de la CA; Windows 11 24H2/25H2 + KB5067036 en los clientes inscritos; proveedor de almacenamiento de claves CNG seleccionado en la plantilla de certificado (no CSP heredado); propósito de la plantilla de certificado establecido exactamente en Firma; y -HashAlgorithmName “NoHash” pasado explícitamente en cualquier instalación de CA mediante script. La tabla de requisitos previos que aparece al principio de este artículo cubre la comprobación de validación, el error común y la solución para cada uno.

¿Qué errores comunes deben tener en cuenta los administradores al implementar ML-DSA en AD CS?

Aparecen cinco errores de forma constante: ML-DSA no aparece en la pestaña Criptografía (la plantilla Propósito no está configurada exactamente como Firma); la configuración de la CA falla con un error de algoritmo hash (se omitió NoHash en el comando de instalación); la inscripción falla en un cliente que muestra ML-DSA con un tamaño de clave de 0 (el cliente está parcialmente parcheado); el algoritmo hash OCSP muestra un valor sin sentido para ML-DSA (solo estético, confíe en pkiview.msc); y el HSM no genera una clave ML-DSA (el firmware del HSM aún no admite ML-DSA a través del CNG KSP). La tabla de requisitos previos y errores comunes de este artículo relaciona cada error con su solución.

Referencias y lecturas adicionales

• Descripción general de la criptografía postcuántica en AD CS (Microsoft Learn)
• ¿Qué es la compatibilidad con ML-DSA en AD CS? (Microsoft Learn)
• KB5087539: Actualización de seguridad del 12 de mayo de 2026 para Windows Server 2025
• Comunidad de seguridad de Microsoft: Las API de criptografía postcuántica ya están disponibles de forma general en las plataformas de Microsoft.