Migración post-cuántica: lo que está pasando de verdad

Actualizado: 2026-05-03

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.
• SLH-DSA (basado en Sphincs+) como firma conservadora alternativa.

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.

Puntos clave

• El tráfico web público se ha migrado casi solo: más del 60% de handshakes globales son ya híbridos post-cuánticos.
• La firma (ML-DSA, SLH-DSA) sigue siendo el frente difícil por el tamaño de las firmas.
• DNSSEC es el caso más problemático: las firmas post-cuánticas no caben en UDP sin fragmentar.
• El problema más frecuente en las migraciones reales no ha sido criptográfico sino de inventario: las organizaciones no saben dónde tienen criptografía.
• La ventana pragmática para la amenaza real sigue siendo de siete a diez años.

Qué se ha migrado de verdad

TLS público en la web es el área que ha avanzado más. 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. 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.

SSH es la segunda área con avance real. OpenSSH 9.9 hizo sntrup761x25519-sha512 el intercambio por defecto, 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. 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 con resultados dispares.

Qué sigue atascado

La firma ha sido, como era previsible, la parte más difícil. ML-DSA tiene firmas entre cinco y diez veces más grandes que las firmas clásicas equivalentes. 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.

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. 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. 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. 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:

• Incompatibilidades entre implementaciones porque un draft intermedio se consolidó distinto al estándar final.
• Incompatibilidad con aceleración hardware: HSMs antiguos no soportan ML-DSA y requieren firmware específico o reemplazo.
• Coste en CPU: 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í.

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:

• 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. 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 ven los plazos 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.
• 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 no es activar post-cuántica en todas partes; es hacer inventario honesto, cerrar la cripto-agilidad y renovar los sistemas rotos con criterio en su ciclo natural.

Los seguros se venden baratos cuando no llueve; este es uno de esos. La misma lógica de planificación anticipada que aplica a la migración post-cuántica aplica a la gobernanza de agentes en empresa: el coste de hacerlo bien antes es siempre menor que el de remediarlo después de un incidente.