En agosto de 2024 el NIST publicó los primeros estándares finales de criptografía post-cuántica: ML-KEM derivado de Kyber para intercambio de claves, ML-DSA derivado de Dilithium para firma digital, y SLH-DSA basado en Sphincs+ como firma conservadora. Desde entonces han pasado veinte meses y la conversación ha migrado del “cuándo empezar” al “cómo va realmente”. En abril de 2026, con dos años completos de despliegues reales a la vista, hay datos suficientes para separar lo que ha funcionado de lo que sigue atascado.
Qué se ha migrado de verdad
La parte que ha avanzado más es TLS público en la web. Los navegadores principales habilitaron por defecto intercambios híbridos X25519+ML-KEM a lo largo de 2025, y Cloudflare, Google y los grandes CDN negocian post-cuántica en casi todas las conexiones nuevas hacia sitios que atienden. Las mediciones de telemetría de Mozilla y Cloudflare sitúan el porcentaje de handshakes híbridos por encima del 60% del tráfico web global. Para servicios expuestos detrás de un CDN moderno, la migración ya ha ocurrido sin que operaciones tuviera que hacer nada especial.
La segunda área con avance real es SSH. OpenSSH 9.9 hizo sntrup761x25519-sha512 el intercambio por defecto hace tiempo, y OpenSSH 10.0 añadió mlkem768x25519-sha256 directamente en la especificación estandarizada. Los servidores actualizados desde 2025 vienen con híbridos negociados desde el arranque. En entornos gestionados con configuración automática, Debian Trixie o RHEL 10, la migración SSH sucedió sin intervención. En entornos donde la configuración está congelada por política o por miedo a romper bastiones antiguos, sigue atascada.
VPN corporativa es la tercera área con movimiento. WireGuard por sí solo no incorpora aún criptografía post-cuántica en el protocolo base, y lo previsiblemente definirá una revisión mayor que aún no existe en forma estable. Pero los fabricantes de VPN empresarial, Palo Alto, Fortinet, Cisco, Check Point, han añadido opciones de IPsec con IKEv2 en modo híbrido usando ML-KEM, y muchas grandes empresas han activado esa opción en los túneles sede-a-sede. Para usuarios remotos con cliente propietario la situación depende del fabricante y del cliente, con resultados dispares.
Qué sigue atascado
La parte más difícil ha sido, como era previsible, la firma. ML-DSA tiene firmas entre cinco y diez veces más grandes que las firmas clásicas equivalentes, y eso golpea sitios donde el tamaño importa. Certificados X.509 con ML-DSA, más cadenas, pesan varios kilobytes; en TLS esto infla el handshake lo suficiente como para provocar problemas visibles en redes marginales. La cadena de certificados de Let’s Encrypt empezó pruebas con ML-DSA en 2025 y sigue en pruebas limitadas en 2026 porque el coste de rodaje en producción ha resultado mayor de lo esperado.
Firma de código es otro frente lento. SLH-DSA es bastante grande, decenas de kilobytes por firma, lo que choca con formatos de firmware antiguos y con dispositivos embebidos donde cada kilobyte cuenta. Los fabricantes serios están migrando, pero por fases, y los dispositivos en campo heredados seguirán firmados con criptografía clásica durante su vida útil. La mitigación real aquí es cambiar dispositivos con el ciclo normal, no forzar migración retroactiva.
DNSSEC es el caso más problemático y honesto. Las firmas post-cuánticas son demasiado grandes para caber en paquetes UDP sin fragmentar, y DNS sobre UDP fragmentado es una pesadilla operativa conocida. La IETF está discutiendo soluciones desde 2024 y ha habido varios drafts, pero ninguna solución canónica en abril de 2026. Probablemente haga falta un protocolo transporte distinto o un diseño de firma específico, y eso llevará tiempo. Mientras tanto DNSSEC queda como caso donde la migración no se puede hacer “activando la opción nueva”.
Los problemas operativos reales
Los problemas serios de 2025 y principios de 2026 no han sido de criptografía sino de ingeniería. Incompatibilidad entre implementaciones porque un draft intermedio se consolidó distinto al estándar final, provocando incidencias donde un cliente no negociaba con un servidor actualizado más tarde. Incompatibilidad con aceleración hardware, porque HSMs antiguos no soportan ML-DSA y requieren firmware específico o reemplazo. Coste en CPU: ML-DSA es competitivo en firma y verificación, pero ML-KEM introduce ciclos adicionales sobre X25519 puro que se notan en nodos con miles de handshakes por segundo.
Menos técnico pero más frecuente: el inventario. La mayoría de organizaciones descubrió durante la migración que no sabía dónde tenía criptografía. Bibliotecas antiguas enlazadas en binarios productivos, llamadas a APIs criptográficas dentro de código de terceros, firmas incrustadas en formatos propietarios. El esfuerzo de cripto-agilidad, tener el inventario y la capacidad de cambiar algoritmos sin reescribir aplicaciones, ha sido en muchos casos mayor que la migración en sí. Y sigue siéndolo para quien no lo abordó en 2024.
Captura ahora, descifra después: qué significa hoy
La motivación económica de fondo sigue siendo la misma: tráfico cifrado capturado ahora con algoritmos clásicos podría ser descifrado dentro de una década si existe un ordenador cuántico útil para Shor. Las informaciones que sobreviven al 2035 y siguen siendo confidenciales deben protegerse hoy. Esto afecta a secretos industriales con vida útil larga, comunicaciones diplomáticas, historiales médicos de largo plazo, patentes no publicadas, registros legales.
La parte pragmática que se ha consolidado es que, para tráfico efímero de consumo, cuentas de usuario de retail, búsquedas en internet, sesiones de aplicaciones de uso breve, la criptografía clásica sigue siendo aceptable porque descifrarla en 2035 tendrá poco valor. Para tráfico sensible de largo plazo, la migración ya debería estar hecha. Esta segmentación por vida útil del secreto es lo que distingue a los equipos de seguridad que piensan en riesgos reales de los que escriben políticas uniformes.
Cómo se ve desde abril de 2026
Las previsiones oficiales seguían apuntando a final de década para tener un ordenador cuántico capaz de romper claves RSA o ECC de tamaños actuales, y en 2026 esa expectativa no ha cambiado de forma material. IBM tiene hoy procesadores de cuatro mil qubits físicos pero con ruido que limita el qubit lógico utilizable por debajo de lo necesario para Shor a escala criptográficamente relevante. Google, IonQ y Quantinuum siguen progresando en tolerancia a fallos, con hitos reales pero todavía lejos de descifrar TLS de producción. La ventana pragmática sigue siendo de siete a diez años para amenaza real.
# Verificar rápidamente si tu servidor negocia post-cuántica
openssl s_client -connect ejemplo.com:443 -tls1_3 -groups X25519MLKEM768:X25519 </dev/null 2>&1 \
| grep -E 'Server Temp Key|Cipher'Mi lectura
La migración post-cuántica está sucediendo, pero no uniformemente. El tráfico efímero público se ha resuelto casi solo. El tráfico corporativo intra-red depende de renovar equipos y configuraciones. La firma y la validación a largo plazo siguen siendo los casos complicados, y DNSSEC es el ejemplo extremo de transición no-trivial.
Cuándo compensa invertir hoy: si tu organización maneja secretos con vida útil de más de diez años, ya deberías tener plan y haberlo ejecutado parcialmente. Si tu carga principal es web pública detrás de CDN moderno, probablemente la migración ya te ha pasado por encima y lo que te falta es documentación. Para el resto, el trabajo útil en 2026 no es activar post-cuántica en todas partes, es hacer inventario honesto, cerrar la cripto-agilidad para poder cambiar algoritmos sin proyecto grande, y renovar los sistemas rotos con criterio en su ciclo natural. Los seguros se venden baratos cuando no llueve; este es uno de esos.
