La migración a la criptografía poscuántica significa localizar todos los lugares en los que su organización utiliza criptografía de clave pública vulnerable a la computación cuántica, clasificar el riesgo, probar sustitutos aprobados por NIST y desplegarlos sin romper los sistemas. Empiece ahora si protege datos que deben seguir siendo confidenciales durante años. NIST finalizó ML-KEM, ML-DSA y SLH-DSA en 2024 y dijo que estaban listos para su uso inmediato, pero la migración real llevará años.
Por qué la migración a la criptografía poscuántica ha pasado de la teoría al plan de proyecto
La intención de búsqueda aquí es informativa con un marcado enfoque práctico: quiere saber qué hacer, en qué orden y por qué el momento importa. La versión corta es incómoda. Esperar a que exista un gran ordenador cuántico criptográficamente relevante es el desencadenante equivocado.
Los atacantes pueden capturar ahora tráfico cifrado o archivos almacenados y conservarlos para descifrarlos más adelante. NIST, Google y otros equipos de seguridad describen esto como “harvest now, decrypt later” o “store now, decrypt later.” Si sus contratos, historiales médicos, secretos de Estado, diseños de producto o archivos de clientes necesitan mantenerse en secreto hasta la década de 2030, el reloj del riesgo ya está en marcha.
NIST cambió la conversación el 13 de agosto de 2024 al aprobar los tres primeros estándares de criptografía poscuántica: FIPS 203 para ML-KEM, FIPS 204 para ML-DSA y FIPS 205 para SLH-DSA. FIPS 203 procede de CRYSTALS-Kyber, FIPS 204 de CRYSTALS-Dilithium y FIPS 205 de SPHINCS+. NIST dijo que los estándares finalizados estaban “ready for immediate use” y animó a los administradores a comenzar la integración porque la adopción completa lleva tiempo.
Hay otro punto de presión. El 7 de septiembre de 2022, la NSA publicó los requisitos CNSA 2.0 para National Security Systems y dijo a propietarios, operadores y proveedores que planificaran, prepararan y presupuestaran la transición a algoritmos resistentes a la computación cuántica. Ese lenguaje importa porque los proveedores tienden a moverse cuando los equipos de compras empiezan a hacer preguntas concretas.
¿De qué exactamente se está migrando?
Una migración a la criptografía poscuántica no es cambiar un certificado por otro. Está abandonando sistemas de clave pública que se consideran vulnerables a futuros ataques cuánticos, especialmente RSA, Diffie-Hellman sobre campos finitos, Diffie-Hellman de curva elíptica y ECDSA en los casos en los que los algoritmos cuánticos podrían comprometerlos.
El cifrado simétrico es otra historia. AES y los hashes de la familia SHA no se sustituyen de la misma manera, aunque los tamaños de clave y los márgenes de seguridad siguen mereciendo revisión. El trabajo complicado está en TLS, VPN, SSH, la firma de código, la identidad de dispositivos, la PKI, S/MIME, los sistemas de pago, las actualizaciones de firmware, las APIs, los sistemas de gestión de claves, las integraciones HSM y las viejas aplicaciones Java que nadie quiere tocar.
NIST y el National Cybersecurity Center of Excellence describen dos grandes líneas de trabajo para la migración de 2024 a 2026: descubrimiento e inventario criptográfico, y después pruebas de interoperabilidad de algoritmos PQC estandarizados por NIST. Suena árido. Es todo el trabajo.
Si su equipo ya está haciendo seguimiento de una inversión más amplia en seguridad, conecte este esfuerzo con su planificación de riesgos existente en lugar de tratarlo como un proyecto científico. Las mismas conversaciones presupuestarias que aparecen en planificación de tendencias de ciberseguridad de 2026 se aplican aquí: la visibilidad de activos, la responsabilidad de los proveedores y la modernización por fases son mejores que comprar por pánico.
Los estándares de NIST que puede usar ahora y lo que aún está por llegar
Tres estándares son el punto de partida práctico para la mayoría de las organizaciones. ML-KEM, estandarizado como FIPS 203 en 2024, se utiliza para el establecimiento de claves y flujos generales de cifrado en los que la encapsulación de claves es apropiada. ML-DSA, estandarizado como FIPS 204 en 2024, es para firmas digitales. SLH-DSA, estandarizado como FIPS 205 en 2024, es una opción de firma digital sin estado basada en hashes.
No interprete esa lista en exceso. No significa que todos los protocolos, bibliotecas, servicios en la nube, dispositivos, autoridades de certificación y regímenes de cumplimiento estén igual de preparados. Los estándares son necesarios. Los productos desplegables son otra cuestión.
| Estándar o elemento | Año | Basado en | Función principal | Relevancia para la migración |
|---|---|---|---|---|
| FIPS 203: ML-KEM | 2024 | CRYSTALS-Kyber | Establecimiento de claves / cifrado | KEM principal aprobado por NIST para probar en TLS, VPN y otros casos de uso de intercambio de claves |
| FIPS 204: ML-DSA | 2024 | CRYSTALS-Dilithium | Firmas digitales | Principal candidato de firma para certificados, firma y flujos de trabajo de identidad |
| FIPS 205: SLH-DSA | 2024 | SPHINCS+ | Firmas basadas en hash sin estado | Útil cuando se prefieren firmas conservadoras basadas en hash, sujeto a compromisos de rendimiento y tamaño |
| HQC | Seleccionado en 2025 | Familia HQC | KEM adicional | NIST lo seleccionó para complementar ML-KEM; se esperaba la publicación final tras el borrador y la revisión de comentarios públicos, aproximadamente dos años después de 2025 |
| FIPS 206: FN-DSA | Trabajo en borrador en 2025 | Falcon | Firmas digitales | Estándar de firma adicional todavía en desarrollo en 2025 |
HQC merece una mención cuidadosa. El 11 de marzo de 2025, NIST seleccionó HQC para su estandarización como segundo mecanismo de encapsulación de claves para complementar ML-KEM, con la publicación final prevista aproximadamente dentro de dos años tras la revisión del borrador y de los comentarios públicos. Esto es útil para una diversidad futura, no es una razón para paralizar hoy las pruebas de ML-KEM.
NIST también siguió redactando FIPS 206 para FN-DSA, basado en Falcon, en 2025. Si opera en un entorno muy restringido en el que importan el tamaño de la firma, la velocidad de verificación o la complejidad de implementación, siga de cerca ese trabajo. Sin embargo, para la mayoría de las organizaciones, la decisión sensata es hacer inventario ahora y realizar pruebas piloto con los estándares de 2024 allí donde exista soporte de los proveedores.
Elabore su inventario criptográfico antes de comprar nada
El mayor escollo del que nadie habla con la suficiente claridad: muchas empresas no saben dónde reside su criptografía de clave pública. Conocen su autoridad de certificación y quizá sus endpoints TLS expuestos a internet. No saben qué hay dentro de los controladores industriales, las aplicaciones móviles, los procesos de compilación, las API de proveedores, las herramientas de copia de seguridad, los almacenes de datos, los antiguos concentradores VPN o las integraciones SaaS a SaaS.
Empiece por el descubrimiento. La guía de migración de NIST/NCCoE indica que las organizaciones deben identificar los usos de algoritmos de clave pública vulnerables a la computación cuántica en hardware, software y servicios, y después elaborar inventarios criptográficos y hojas de ruta priorizadas. En lenguaje sencillo, necesita una lista de materiales de la criptografía.
- Enumere los sistemas que utilizan RSA, Diffie-Hellman, Diffie-Hellman de curva elíptica, ECDSA y mecanismos relacionados de clave pública.
- Registre dónde aparece cada uso: TLS, SSH, VPN, PKI, firma de código, firma de firmware, S/MIME, cifrado de bases de datos, autenticación de API, HSM o servicios gestionados por proveedores.
- Etiquete los datos protegidos por cada sistema y durante cuánto tiempo deben seguir siendo confidenciales.
- Identifique las dependencias de protocolos y bibliotecas, incluidos OpenSSL, BoringSSL, los proveedores criptográficos de Java, el firmware de los HSM y los servicios KMS en la nube, cuando corresponda.
- Pida a los proveedores hojas de ruta de PQC, algoritmos NIST compatibles, opciones de modo híbrido, planes de certificación y plazos de actualización.
- Clasifique los sistemas según la exposición, la sensibilidad de los datos, la criticidad operativa y la dificultad de sustitución.
Un cálculo concreto ayuda. Suponga que tiene 240 aplicaciones y que un primer escaneo detecta que 35% usan TLS expuesto externamente, 20% usan mTLS interno, 15% dependen de la firma de código y 10% integran funciones SSH o VPN. Incluso con solapamientos, puede que esté contemplando entre 120 y 160 puntos de contacto criptográficos, no 240 simples actualizaciones de aplicaciones. Si cada punto de contacto necesita una entrevista con un responsable, una comprobación con el proveedor, una prueba y una ventana de cambio, una migración “pequeña” se convierte en cientos de tareas.
Los servicios en la nube dificultan más el inventario, no lo facilitan. Puede que no controle la implementación criptográfica dentro de una base de datos gestionada, una CDN, un proveedor de identidad o una pasarela de pago, pero la decisión sobre el riesgo sigue siendo suya. Los informes públicos de Cloudflare sobre tendencias de adopción del cifrado post-cuántico son un recordatorio útil de que la adopción a nivel de plataforma puede avanzar rápidamente mientras las dependencias empresariales se quedan atrás.
Dé prioridad a los sistemas en los que el retraso provoque un daño real
No todas las cargas de trabajo merecen la misma urgencia. Una página pública de marketing con TLS convencional no es lo mismo que un archivo de investigación, un expediente gubernamental o historiales clínicos que deben seguir siendo privados durante décadas. Su migración a la criptografía post-cuántica debería comenzar allí donde coincidan la confidencialidad a largo plazo y la interceptación de alto valor.
Clasifique en primer lugar los sistemas que protegen datos con una larga vida útil de secreto. Los registros legales, los documentos de identidad, los archivos de fusiones, la investigación farmacéutica, la información de defensa, las claves de firma de código fuente y las autoridades de certificación raíz o intermedias merecen atención temprana. Una VPN que transporta el correo electrónico de directivos puede ser más urgente que un panel interno con telemetría desechable.
Hay un contraargumento que conviene tomarse en serio: desplegar integraciones inmaduras demasiado pronto puede provocar interrupciones y nuevas vulnerabilidades. Estoy de acuerdo. Cambiar a ciegas los sistemas de producción a lo que sea que su proveedor etiquete como “PQC-ready” es una temeridad. La mejor respuesta es realizar pruebas híbridas, un despliegue por fases y criptoagilidad, no un retraso disfrazado de prudencia.
La agilidad criptográfica significa que puedes cambiar algoritmos, tamaños de clave, bibliotecas y perfiles de certificado sin reconstruir la mitad de tu infraestructura. Si tus sistemas codifican algoritmos de forma rígida o asumen tamaños de firma diminutos, tienes un problema de diseño que la PQC pondrá en evidencia. El coste oculto se parece al de cualquier gran actualización tecnológica; el lastre presupuestario descrito en costes de modernización tecnológica empresarial se aplica dolorosamente bien a la criptografía.
Prueba la interoperabilidad antes del despliegue en producción
NIST/NCCoE identifica las pruebas de interoperabilidad de algoritmos PQC estandarizados como una línea de trabajo de migración independiente por una razón. Los algoritmos pueden ser sólidos mientras que las implementaciones discrepan, rinden mal o fallan bajo restricciones reales del protocolo. Los certificados se hacen más grandes. Los handshakes pueden cambiar. Los dispositivos embebidos pueden quedarse sin memoria. Los middleboxes pueden comportarse mal.
Crea un banco de pruebas no productivo que refleje tus patrones de tráfico reales. Incluye navegadores, clientes móviles, puertas de enlace de API, balanceadores de carga, service meshes, clientes VPN, HSM, herramientas de registro, productos de seguridad de endpoints y sistemas de monitorización. Sinceramente, aquí es donde muchos planes de migración se hacen reales por primera vez.
Conviene observar la postura de Google porque sus decisiones de infraestructura tienden a influir en los navegadores, las pilas TLS y las expectativas de los desarrolladores. La información pública de abril de 2026 decía que Google había fijado un calendario interno hasta 2029 para “asegurar la era cuántica” mediante la migración a métodos PQC, considerando el riesgo de store-now-decrypt-later como una preocupación actual. Tómalo como una señal, no como una norma.
Las conferencias de seguridad también están convirtiendo la PQC de investigación en hojas de ruta de producto. Si haces seguimiento de las afirmaciones de los proveedores en eventos como RSAC, compáralas con la cobertura fundamentada de innovaciones en ciberseguridad presentadas en RSAC 2026 y luego haz una pregunta aburrida: ¿puede este producto mostrar una integración funcional con FIPS 203, FIPS 204 o FIPS 205 en tu entorno?
Vigila los casos límite. La verificación de firmware sin conexión puede necesitar firmas PQC pero disponer de almacenamiento limitado. Es posible que los dispositivos IoT no admitan claves o firmas más grandes sin cambios de firmware. Los certificados raíz de larga duración pueden ser difíciles de rotar. Los archivos de copia de seguridad cifrados bajo supuestos antiguos de establecimiento de claves pueden seguir expuestos si el intercambio de claves que los protegía fue capturado.
Una hoja de ruta práctica para la migración a la criptografía poscuántica
Una hoja de ruta viable tiene etapas, responsables y fechas. No debería ser una diapositiva que diga “monitorizar el riesgo cuántico”. La orientación de NIST, CISA y alineada con la NSA de 2024 a 2026 apunta a la misma secuencia: inventariar la criptografía, identificar los usos de clave pública vulnerables a la computación cuántica, priorizar los datos sensibles de larga duración y los sistemas críticos, probar la interoperabilidad, actualizar productos y protocolos, desplegar por fases y mantener la agilidad criptográfica.
Para la planificación de 2026, yo dividiría el trabajo en cuatro líneas. Primero, descubrimiento de activos y criptografía. Segundo, preparación de proveedores y protocolos. Tercero, pruebas de interoperabilidad en laboratorio. Cuarto, migración a producción para los sistemas de mayor riesgo. El orden importa, pero parte del trabajo puede ejecutarse en paralelo una vez que el inventario sea lo bastante bueno.
La contratación necesita un nuevo lenguaje. Pregunta a los proveedores qué estándares PQC de NIST admiten, si el soporte es híbrido o PQC puro, qué versiones se requieren, cómo se gestionan los certificados y las claves, y si la funcionalidad está disponible de forma general o solo como vista previa. Pide fechas. El vago marketing de “quantum-safe” no es un plan.
Los equipos de políticas también deberían vigilar los plazos del sector público. Una presentación de NIST de 2025 hacía referencia a la migración obligatoria del gobierno de EE. UU. a PQC para 2035, respaldada por NIST IR 8547 y el trabajo de migración de NCCoE. Aunque no seas una agencia federal, ese tipo de calendario puede dar forma a los requisitos de los proveedores, las auditorías y el lenguaje contractual.
Por último, conecta el proyecto con la estrategia cuántica en lugar de tratarlo como una tarea puntual de cumplimiento. El debate más amplio sobre el lugar de la computación cuántica entre los grandes cambios tecnológicos es interesante, pero tu equipo de seguridad necesita una respuesta más concreta: ¿qué secretos seguirán importando cuando lleguen las máquinas cuánticas criptográficamente relevantes?
Preguntas frecuentes
¿Cuándo debería una empresa empezar la migración a la criptografía poscuántica?
Empiece en 2026 si protege datos que deben seguir siendo confidenciales durante años, o si opera sistemas críticos con largos ciclos de actualización. NIST afirmó que las tres primeras normas de PQC finalizadas estaban listas para su uso inmediato en 2024, al tiempo que advirtió de que la integración completa llevará tiempo.
¿Cuál es el primer paso en una migración a PQC?
El primer paso es un inventario criptográfico. Identifique dónde aparecen RSA, Diffie-Hellman, el intercambio de claves de curva elíptica, ECDSA y los mecanismos relacionados de clave pública en hardware, software, servicios en la nube, certificados, sistemas de firma y productos de proveedores.
¿Es ML-KEM lo mismo que Kyber?
ML-KEM, estandarizado como FIPS 203 en 2024, deriva de CRYSTALS-Kyber. Para la planificación de la migración, utiliza el nombre estándar de NIST al redactar requisitos y lenguaje de adquisición.
¿Sustituirá la criptografía poscuántica a AES?
No de la misma manera. El objetivo urgente de la migración es la criptografía de clave pública vulnerable a la computación cuántica que se utiliza para el intercambio de claves y las firmas; el cifrado simétrico como AES necesita una revisión del margen de seguridad, no una sustitución equivalente por PQC.
¿Deberías esperar a HQC o FN-DSA antes de migrar?
Normalmente no. HQC fue seleccionado por NIST en 2025 como un KEM adicional, y el trabajo sobre FN-DSA continuó en 2025, pero las organizaciones pueden inventariar, priorizar y probar con los estándares de 2024 ahora.
ES 
EN 
FR