Migración a Criptografía Post-Cuántica: Marco Operativo 2026

9 min de lectura

Ultima actualizacion: May 17, 2026

Durante la mayor parte de la última década, la criptografía post-cuántica (PQC) fue una conversación académica que los CTOs podían posponer. En 2024, NIST finalizó los primeros estándares. En 2025, la NSA publicó CNSA 2.0 con timeline obligatorio para sistemas de seguridad nacional. En 2026, los principales vendors (AWS, Google, Cloudflare, Microsoft) ya despliegan PQC híbrido en TLS por defecto. La conversación pasó de “si” a “cuándo y cómo”, y el cuándo es ahora.

Este artículo presenta el marco operativo de migración PQC: qué estándares importan, cómo hacer inventario criptográfico, qué significa el modo híbrido y cómo construir crypto-agility para no repetir esta migración cada vez que algo cambie.

El reloj que ya está corriendo: “harvest now, decrypt later”

Aunque los computadores cuánticos relevantes para romper RSA-2048 o ECDH-P256 probablemente no existan antes de 2030-2035, el riesgo no espera a esa fecha. Adversarios sofisticados (estados-nación, grupos APT) están capturando y almacenando tráfico cifrado hoy para descifrarlo cuando la capacidad cuántica esté disponible. Cualquier dato con valor a largo plazo (registros médicos, secretos comerciales, datos clasificados, propiedad intelectual estratégica) está efectivamente expuesto hoy si se transmite con cifrado solamente clásico.

Esto significa que la pregunta no es “¿cuándo debo migrar?” sino “¿cuánto tiempo de exposición acumulada puedo aceptar?”. Para datos sensibles con horizonte de confidencialidad mayor a cinco años, la respuesta empieza a parecerse a “empezar ya”.

Los estándares NIST PQC: qué son y dónde aplican

NIST finalizó cuatro algoritmos en su primera ronda de estandarización, cada uno cubriendo un caso de uso distinto. La nomenclatura ha cambiado entre los borradores y los estándares finales; use los nombres FIPS oficiales.

• ML-KEM (anteriormente Kyber, FIPS 203): mecanismo de encapsulamiento de claves (KEM). Reemplaza el rol de RSA-OAEP y ECDH para establecimiento de claves en TLS, VPN, intercambio de sesión. Tres niveles de seguridad: ML-KEM-512, 768, 1024.
• ML-DSA (anteriormente Dilithium, FIPS 204): firma digital. Reemplaza RSA-PSS y ECDSA para firma de certificados, código, documentos. Niveles 44, 65, 87.
• SLH-DSA (anteriormente SPHINCS+, FIPS 205): firma digital basada en hash. Más lenta y con firmas más grandes que ML-DSA, pero apoyada en supuestos criptográficos extremadamente conservadores. Para casos donde la longevidad importa más que el rendimiento.
• FALCON (FIPS 206 en draft): firma digital alternativa basada en lattice. Firmas más compactas que ML-DSA, útil en contextos con limitaciones estrictas de tamaño (firmware embedded, certificados X.509 con limitaciones).

La selección operativa por defecto: ML-KEM-768 para establecimiento de claves y ML-DSA-65 para firma, como reemplazo de propósito general de los algoritmos clásicos equivalentes en seguridad. SLH-DSA y FALCON se evalúan caso por caso.

Fase de inventario: lo que no puede medir, no puede migrar

La fase más subestimada y más crítica. Antes de migrar nada, debe saber qué criptografía existe en su organización, dónde vive y cuál es su exposición cuántica. Sin inventario, la migración es un caos de ad hoc.

Áreas a inventariar

• TLS: qué versiones, qué cipher suites, qué clientes y servidores. Auditar load balancers, ingress controllers, service mesh, conexiones outbound a APIs externas.
• Code signing: certificados que firman binarios, artefactos de release, contenedores. Apple, Microsoft, Google Play.
• PKI interna: CAs raíz, intermedias, certificados emitidos. ¿Cuántos años de vida tienen los certificados emitidos hoy?
• S/MIME y correo: firma y cifrado de email corporativo, especialmente en sectores regulados.
• VPN: IPsec, WireGuard, OpenVPN. Algoritmos de intercambio de claves y autenticación.
• Secretos en reposo: bases de datos cifradas con KMS, secrets managers, HSMs. Algoritmos del wrapping de claves.
• SSH: claves de servidor, claves de usuario, claves de despliegue. Identidades automatizadas con muchos años de existencia.
• Blockchain o firma distribuida: si aplica, sistemas que dependen de ECDSA tienen exposición específica.
• Hardware embedded e IoT: dispositivos en campo con criptografía cementada que no se actualizan en años.

Herramientas que aceleran el inventario: SBOMs criptográficos (CBOMs) emergentes en CycloneDX 1.6, scanners como pqc-prepared, auditoría TLS con sslscan/testssl.sh. La parte difícil no es técnica: es organizacional. Hay sistemas legacy que nadie quiere tocar y que probablemente contienen criptografía hardcoded de hace quince años.

Modo híbrido: la única opción razonable para 2026

Los algoritmos PQC son nuevos y no han sufrido el mismo escrutinio criptanalítico durante décadas que RSA o ECC. Una nueva vulnerabilidad teórica en ML-KEM o ML-DSA es plausible. La defensa contra este riesgo es el modo híbrido: combinar un algoritmo clásico con un algoritmo PQC de manera que romper la combinación requiera romper ambos.

En TLS, esto significa cipher suites híbridas como X25519MLKEM768, que ya están desplegadas en Chrome, Firefox y los principales CDNs en 2025-2026. El cliente y el servidor establecen una clave de sesión que es función de ambos intercambios; un atacante necesita romper X25519 (clásico) y ML-KEM-768 (post-cuántico) para descifrar.

• Ventaja: protección frente a fallos catastróficos en cualquiera de los dos algoritmos.
• Desventaja: tamaño de handshake mayor (relevante en redes muy restringidas o protocolos UDP con MTU).
• Conclusión operativa: use híbrido como default hasta que la confianza criptanalítica en PQC iguale a la confianza histórica en algoritmos clásicos. Probablemente esto sea cinco a diez años más.

Timeline realista: NSA 2030, industria 2035

Los timelines de referencia que cualquier CTO debe conocer:

• 2024-2026 (presente): estándares NIST finalizados, soporte en bibliotecas principales (BoringSSL, OpenSSL 3.x, AWS-LC, rustls). Despliegues PQC híbrido en TLS por defecto en navegadores y CDNs.
• 2027-2028: ventana de transición acelerada. Vendors empiezan a deprecar negociación solo-clásico. Auditorías SOC 2 y similares empiezan a preguntar por crypto-agility.
• 2030 (CNSA 2.0 NSA): sistemas de seguridad nacional y proveedores federales con sistemas nuevos requieren PQC. Sistemas existentes deben tener plan de migración aprobado.
• 2035 (industria amplia): deprecación generalizada de RSA-2048 y ECDH P-256 como algoritmos solo-clásicos. Cumplimiento regulatorio en sectores críticos (finanzas, salud, infraestructura) requerirá PQC.

El error táctico común: tratar 2030/2035 como fechas distantes y posponer. La realidad operacional: migrar criptografía a través de una organización de miles de sistemas toma de tres a cinco años cuando se hace con disciplina. Empezar en 2032 es llegar tarde.

Crypto-agility: el patrón que importa más que el algoritmo

La lección estratégica de PQC no es que necesitamos ML-KEM en lugar de RSA. Es que necesitamos sistemas que puedan cambiar de algoritmo sin reescritura. Esto se llama crypto-agility, y la mayoría de software empresarial no la tiene.

Patrones de crypto-agility

• Algoritmos como configuración, no como código: el código no asume RSA-2048; consulta una abstracción que devuelve el algoritmo activo. Cambiar de algoritmo es un cambio de configuración, no de código.
• Identificadores versionados en formatos persistidos: cada firma, cada blob cifrado, cada certificado lleva metadata explícita del algoritmo usado. Permite que múltiples algoritmos coexistan durante la transición.
• Validación de múltiples algoritmos en paralelo: los verificadores aceptan firmas clásicas y PQC durante la transición. Los firmantes pueden producir cualquiera según política.
• Rotación de claves probada regularmente: si nunca rotó una CA, no podrá rotar para migrar a PQC. La rotación es un drill que debe ejecutarse en producción.
• Inventario continuo, no único: CBOMs generados en CI/CD, no auditorías manuales anuales.

Coste operativo: lo que nadie quiere admitir

Los algoritmos PQC son más caros en CPU, en ancho de banda y en almacenamiento que sus equivalentes clásicos. Las firmas ML-DSA son aproximadamente diez veces más grandes que las firmas ECDSA. Los handshakes TLS híbridos transmiten kilobytes adicionales. Para sistemas de bajo volumen, el coste es despreciable; para sistemas a escala (CDNs, IoT con millones de dispositivos, redes con conexiones por segundo en seis dígitos), el coste agregado es material.

• Tamaño de certificados: certificados X.509 con firmas ML-DSA o SLH-DSA son significativamente más grandes. Impacto en CDN cache, en almacenamiento de certificate transparency logs, en handshakes TLS.
• CPU de servidor: ML-KEM en TLS handshake añade carga al servidor TLS. En arquitecturas con millones de handshakes diarios, esto se traduce en capacidad adicional.
• Ancho de banda mobile y edge: handshakes más grandes en redes lentas o con MTU restringido pueden requerir múltiples roundtrips, degradando latencia percibida.
• Almacenamiento de firmas: SLH-DSA produce firmas de varios kilobytes. Aceptable para firma de release única; problemático para sistemas que firman millones de eventos.

La estrategia de mitigación incluye benchmark en condiciones representativas antes de la migración masiva, selección de niveles de seguridad PQC adecuados al contexto (ML-KEM-512 puede ser suficiente donde ML-KEM-1024 sería sobre-ingeniería), y aceleración por hardware donde aplica (HSMs PQC-ready, instrucciones vectoriales modernas).

Dependencias de terceros: el eslabón débil

Aunque su organización migre completamente a PQC, su exposición real depende de la criptografía usada por cada proveedor, cada API externa, cada CDN, cada CA. Una organización con TLS PQC interno pero que se conecta a procesadores de pago, APIs de partners y servicios SaaS con TLS clásico no ha eliminado su exposición; la ha movido.

El programa de migración serio incluye un componente de gestión de proveedores: encuestar a vendors críticos sobre su roadmap PQC, incluir cláusulas de crypto-agility en contratos nuevos, monitorizar continuamente qué algoritmos negocian las conexiones externas y priorizar la migración de los vendors más expuestos (procesadores financieros, identity providers, sistemas de comunicación segura).

Los proveedores grandes (AWS, Google, Microsoft, Cloudflare) están bien posicionados y migrarán transparentemente. Los proveedores pequeños y especializados son donde se concentra el riesgo de quedar varado en criptografía clásica más allá del timeline organizacional. El inventario de proveedores con exposición PQC es tan importante como el inventario interno.

Cuándo aplica este marco, cuándo no

Cuándo aplica: organizaciones que manejan datos con horizonte de confidencialidad mayor a cinco años (salud, financiero, defensa, propiedad intelectual estratégica); proveedores federales o de infraestructura crítica con timelines regulatorios; cualquier organización con PKI propia, code signing significativo o sistemas embedded en producción de larga duración.

Cuándo no aplica con urgencia: aplicaciones donde el horizonte de confidencialidad es menor a dos años (los datos pierden valor antes de que la amenaza cuántica madure); sistemas que dependen exclusivamente de proveedores cloud cuyos servicios gestionados (KMS, ALB, CloudFront) habilitarán PQC transparentemente. En estos casos, la prioridad es asegurarse de estar en versiones de servicio que reciben PQC automáticamente, no construir migración propia.

La migración PQC es la mayor transición criptográfica desde la adopción de TLS. Las organizaciones que la tratan como un proyecto único (“migremos a Kyber en 2029”) la van a fallar. Las que la tratan como una inversión en crypto-agility (“construyamos la capacidad de cambiar de algoritmo en general”) van a sobrevivir a esta transición y a la siguiente sin reescribir todo otra vez.