Microsoft acelera la criptografía post-cuántica

Microsoft está empujando a empresas y equipos de seguridad a mirar una fecha que antes sonaba lejana: 2029. La razón no es marketing ni una moda de laboratorio. Es una respuesta práctica a un problema muy concreto: los algoritmos de cifrado que hoy protegen certificados, firmas y canales TLS podrían quedar expuestos cuando la computación cuántica alcance suficiente madurez para romper parte de la criptografía de clave pública que usamos a diario.

La noticia importa porque baja un tema abstracto a decisiones reales de plataforma. No se trata solo de cambiar una librería o activar una opción en un panel. Hablamos de inventariar certificados, revisar dependencias, actualizar appliances, tocar HSMs, coordinar con proveedores y probar compatibilidad con sistemas que llevan años sin tocarse. Si trabajas en seguridad, infraestructura o arquitectura, esta migración te toca aunque todavía no hayas visto una computadora cuántica de cerca.

Qué anunció Microsoft y por qué acelera

Microsoft viene hablando de post-quantum cryptography desde hace tiempo, pero ahora acelera el calendario con una meta más concreta para 2029. La lectura práctica es simple: la empresa quiere que sus productos y servicios estén listos antes de que el riesgo sea masivo, no después. Eso incluye preparar soporte para algoritmos resistentes a ataques cuánticos en capas donde hoy dependes de RSA, ECDSA o ECDH.

La decisión encaja con una realidad incómoda: la migración lleva años. No porque el algoritmo nuevo sea difícil de implementar, sino porque el ecosistema es enorme. Un solo certificado puede estar atado a aplicaciones web, VPNs, dispositivos móviles, balanceadores, proxies, sistemas de firma de código y servicios internos. Si uno de esos puntos no soporta el cambio, todo el flujo se rompe.

Microsoft no está sola en este movimiento. El NIST ya publicó los primeros estándares de criptografía post-cuántica, y eso marca una dirección clara para la industria. Si quieres revisar la base técnica, puedes empezar por la documentación oficial del NIST sobre post-quantum cryptography: https://csrc.nist.gov/projects/post-quantum-cryptography. También vale la pena mirar el anuncio del estándar FIPS 203 para ML-KEM, uno de los bloques que está empujando la adopción: https://csrc.nist.gov/pubs/fips/203/final.

Qué significa “acelerar” en una empresa real

Acelerar no quiere decir migrar todo mañana. Quiere decir que los equipos de producto, seguridad y plataforma dejan de tratar esto como una deuda lejana y empiezan a meterlo en roadmaps, presupuestos y ciclos de prueba. En la práctica, eso se traduce en tres cosas: inventario, compatibilidad y piloto.

Primero, inventario. Necesitas saber dónde usas criptografía de clave pública. No solo en sitios web. También en API gateways, correo, mTLS entre microservicios, VPN, certificados de IoT, firma de binarios, S/MIME, SSH, PKI interna y servicios administrados en nube. Si no tienes ese mapa, cualquier plan de migración es una apuesta.

Segundo, compatibilidad. Muchos sistemas no fallan por el algoritmo en sí, sino por el tamaño de las claves, certificados o handshakes. Los esquemas post-cuánticos suelen tener firmas o claves más grandes que los actuales, y eso afecta latencia, almacenamiento y límites de ciertos dispositivos. Si tu appliance de seguridad tiene 6 años, probablemente no esté listo sin actualización.

Tercero, piloto. No necesitas esperar a una migración total para probar. Puedes levantar entornos de laboratorio con TLS híbrido, validar certificados, medir impacto en CPU y revisar qué rompe primero. Ese aprendizaje vale más que un documento de estrategia sin pruebas.

Qué cambia en la criptografía post-cuántica

La criptografía post-cuántica no es una sola técnica. Es una familia de algoritmos diseñados para resistir ataques de computadoras cuánticas futuras. El objetivo no es hacer cifrado “imposible”, sino mantener un nivel de seguridad razonable cuando cambie el modelo de amenaza.

Hoy, gran parte de la seguridad de internet depende de problemas matemáticos como la factorización de enteros o el logaritmo discreto. Esos problemas son duros para computadoras clásicas, pero un computador cuántico suficientemente grande podría debilitarlos con algoritmos como Shor. Por eso la industria está moviéndose a esquemas basados en otros problemas, como retículas, códigos o funciones hash.

El cambio no afecta igual a todo. El cifrado simétrico y los hashes siguen siendo útiles, aunque con ajustes de tamaño de clave o salida. El punto más delicado está en la criptografía asimétrica: intercambio de claves, firmas digitales y certificados. Ahí es donde la migración duele más y donde Microsoft quiere que el ecosistema se prepare antes.

Lo que ya está estandarizado

El NIST ya publicó estándares que sirven como base para implementación. Los nombres que más vas a ver son ML-KEM para encapsulación de claves y ML-DSA para firmas digitales. Eso importa porque saca el tema de la teoría y lo pone en un camino de adopción más claro para proveedores y empresas.

No necesitas memorizar los nombres, pero sí entender el impacto. Si tu proveedor de VPN, tu CA corporativa o tu stack de identidad no soportan esos estándares, vas a tener que esperar a que actualicen o buscar alternativas. Y en entornos regulados, esperar puede costarte meses.

Por qué el tamaño importa

Uno de los cambios más visibles es el tamaño de algunos artefactos criptográficos. Certificados, firmas y mensajes de handshake pueden crecer bastante frente a RSA o ECDSA. Ese detalle parece menor hasta que lo llevas a producción.

Por ejemplo, un aumento de tamaño puede afectar:

1. el tiempo de establecimiento de conexiones TLS en dispositivos con CPU limitada;
2. el consumo de ancho de banda en enlaces con poca capacidad;
3. el almacenamiento de certificados en hardware con memoria restringida;
4. la compatibilidad con middleboxes que inspeccionan tráfico;
5. el rendimiento de aplicaciones que hacen miles de handshakes por minuto.

Si operas una plataforma con tráfico alto, no basta con preguntar si “soporta PQC”. Necesitas medir cuánto cuesta en latencia, CPU y memoria. Ahí es donde los pilotos dejan de ser opcionales.

Cómo aterrizar la migración en entornos reales

La mejor forma de pensar esta transición es como una migración de PKI y protocolos, no como una actualización de software aislada. En empresas medianas y grandes, el problema suele empezar por la visibilidad. Nadie tiene un inventario completo de certificados, algoritmos y dependencias. Sin ese mapa, no puedes priorizar.

Un enfoque razonable es dividir la migración en capas. Primero, lo que está expuesto a internet y tiene vida útil larga. Después, las comunicaciones internas críticas. Luego, los sistemas heredados que no puedes tocar sin una ventana de mantenimiento larga. Y al final, los activos que ya están cerca de su retiro natural.

La clave es evitar el error de querer reemplazar todo de una vez. En una empresa con cientos de servicios, eso solo genera parálisis. Lo que sí funciona es priorizar por riesgo y por ciclo de renovación. Si un certificado vence en 90 días, ese es tu mejor punto de entrada para probar un esquema nuevo.

Un plan de 90 días para empezar

Si hoy tu equipo no tiene nada avanzado, puedes arrancar con un plan corto y realista:

1. Inventaria certificados, CAs, HSMs, VPNs, gateways y servicios que usen criptografía asimétrica.
2. Clasifica cada activo por criticidad, exposición y fecha de renovación.
3. Identifica proveedores que ya publiquen soporte para algoritmos post-cuánticos o rutas híbridas.
4. Monta un laboratorio con un servicio interno y mide latencia, CPU y fallos de compatibilidad.
5. Documenta dependencias de terceros: CDN, WAF, IAM, MDM, correo, firma de código.
6. Define una política de renovación que priorice activos con mayor tiempo de vida útil.
7. Prepara un plan de reversa por si un piloto rompe clientes antiguos.

Este tipo de plan no resuelve todo, pero evita el error más común: descubrir el problema cuando el certificado ya venció o cuando el proveedor te dice que la actualización no está disponible.

Tabla de impacto por componente

Qué deberían preparar seguridad y plataforma

Si trabajas en seguridad, tu primera tarea es gobernanza. Necesitas una política clara sobre qué algoritmos se permiten, cuáles están en evaluación y quién aprueba excepciones. Sin ese marco, cada equipo va a tomar decisiones distintas y la migración se fragmenta.

Si trabajas en plataforma, tu foco debe estar en compatibilidad operativa. Eso incluye automatización de certificados, renovación, observabilidad y rollback. La migración a post-cuántica no sirve si cada renovación requiere intervención manual de un ingeniero a las 3 de la mañana.

Aquí conviene separar responsabilidades. Seguridad define el estándar y el riesgo aceptable. Plataforma implementa, prueba y opera. Arquitectura ayuda a decidir dónde empezar. Compras y gestión de proveedores tienen que presionar a terceros para que den fechas reales de soporte.

Lo que no puede faltar en tu checklist

• Inventario completo de activos criptográficos, con dueño y fecha de renovación.
• Lista de proveedores con soporte confirmado para algoritmos post-cuánticos.
• Pruebas de compatibilidad con clientes viejos, móviles y sistemas embebidos.
• Métricas de latencia, CPU, memoria y tamaño de certificados en piloto.
• Política de fallback si un sistema no acepta el nuevo esquema.
• Revisión de HSM, CA y herramientas de firma de código.
• Plan de comunicación para equipos internos y terceros.

Si tu empresa opera en LatAm, añade otra capa: conectividad irregular, equipos más antiguos y presupuestos más ajustados. En Ecuador y la región, muchas organizaciones conviven con hardware que todavía funciona bien, pero no siempre recibe soporte moderno de criptografía. Eso no te deja fuera de la migración, pero sí te obliga a priorizar mejor.

Qué mirar en proveedores y en la nube

La migración no depende solo de tu código. También depende de lo que ofrezcan tus proveedores de nube, identidad, seguridad y conectividad. Si usas servicios gestionados, necesitas saber si el soporte a post-cuántica está en roadmap, en beta o ya disponible.

En nube pública, la pregunta correcta no es solo “¿soporta PQC?”. También debes preguntar si el soporte aplica a TLS de entrada, a certificados gestionados, a VPN, a balanceadores, a IAM y a servicios administrados. Un proveedor puede tener soporte parcial y eso puede ser suficiente para un piloto, pero no para producción.

Si quieres ir a la fuente, revisa la documentación del proveedor de cada servicio. En Microsoft, la información suele aparecer en blogs técnicos y documentación de producto; en otras plataformas, el soporte puede estar disperso entre notas de versión y páginas de seguridad. No asumas compatibilidad por una sola mención comercial.

Señales de que tu stack está listo para probar

• El proveedor publica soporte explícito para ML-KEM o ML-DSA.
• Tu CA puede emitir certificados de prueba sin romper validación.
• Tus clientes soportan extensiones o modos híbridos.
• Tienes observabilidad sobre errores de handshake y renegociación.
• Puedes hacer rollback sin reinstalar infraestructura.

Si una de esas piezas falta, todavía puedes avanzar, pero el piloto debe ser más pequeño. Eso no es un fracaso; es una manera de reducir riesgo antes de ampliar el alcance.

Tabla resumen

La señal que deja Microsoft es clara: la post-cuántica ya no es una conversación de laboratorio, sino de calendario. Si tu organización todavía no la puso sobre la mesa, este es el momento de hacerlo. No necesitas migrar todo en una sola etapa, pero sí necesitas saber qué tienes, qué depende de qué y qué proveedor te va a acompañar en el camino.

La ventaja de empezar ahora es que puedes decidir con datos, no con urgencia. Y en seguridad, esa diferencia vale mucho más que cualquier anuncio.