La migración a criptografía poscuántica ya es un problema de operaciones
La criptografía poscuántica ya no debe tratarse como un proyecto de investigación pendiente. Ahora es un problema de operaciones. El punto de inflexión no fue solo el avance teórico, sino también la madurez de los estándares y de la guía práctica. En 2024, NIST finalizó FIPS 203, FIPS 204 y FIPS 205, y además dejó claro que ahora es el momento de iniciar la planificación de la migración. Eso cambia la conversación. La pregunta ya no es si el riesgo cuántico merece atención, sino si su organización puede identificar dónde vive la criptografía, sustituirla sin romper sistemas y hacerlo antes de que la deuda técnica se convierta en exposición real.
Esto importa porque los atacantes no necesitan hoy un ordenador cuántico tolerante a fallos para causar daño mañana. El modelo harvest-now-decrypt-later ya es racional para cualquier adversario que recopile tráfico sensible con largos requisitos de confidencialidad. Si sus datos deben permanecer secretos durante años, el reloj de la migración ya empezó. Por eso el centro de gravedad se está desplazando desde la teoría criptográfica hacia la gestión de activos, la entrega de software, la gestión del ciclo de vida de certificados, la compra y el control de cambios.
Los estándares hicieron el problema concreto
Durante años, muchos equipos de seguridad podían retrasar el trabajo de PQC diciendo que los estándares seguían moviéndose. Esa excusa es más débil ahora. La finalización en 2024 de FIPS 203 para ML-KEM, FIPS 204 para ML-DSA y FIPS 205 para SLH-DSA ofrece una base clara para proveedores, gobiernos y empresas. No elimina todas las dudas de ingeniería, pero sí reduce la mayor parte de la ambigüedad estratégica.
Eso no significa reemplazar todos los sistemas de la noche a la mañana. Significa dejar de tratar la migración como un evento futuro y empezar a tratarla como un programa con responsables, calendario, dependencias, pruebas, rollback y presupuesto.
El verdadero bloqueo es el inventario
La mayoría de las organizaciones no tiene un mapa limpio de dónde se usa la criptografía. Conocen sus sitios públicos, sus VPN principales y sus autoridades de certificación. Pero suelen tener menos claridad sobre dispositivos embebidos, SDK de terceros, rutinas antiguas de cifrado de archivos, bibliotecas hardcoded, API internas y servicios heredados que nadie toca desde hace años. Esa incertidumbre es el impuesto real de la migración.
No se puede migrar lo que no se puede encontrar. Un programa práctico de PQC empieza con inventario: qué aplicaciones dependen de criptografía de clave pública, qué protocolos usan, qué bibliotecas la implementan, quién es su dueño y qué datos con qué vida útil están protegiendo. Algunas organizaciones descubrirán que el mayor riesgo no está en el tráfico de internet, sino en datos archivados, copias de seguridad, firmware firmado o identidades de larga vida en entornos industriales.
La agilidad criptográfica es un asunto de gobernanza
Los arquitectos de seguridad llevan años hablando de crypto agility, pero PQC la convierte de buena práctica en requisito medible. Muchos sistemas todavía asumen un algoritmo, una biblioteca o una ruta de protocolo. Esos supuestos vuelven el cambio lento y frágil. Estar listo para PQC significa poder soportar despliegues híbridos, actualizaciones de políticas, negociación de algoritmos, reemisión de certificados, sustitución de bibliotecas y pruebas de rendimiento sin romper producción.
Eso no es solo una cuestión de diseño de software, sino de gobernanza. ¿Quién aprueba los cambios de algoritmo? ¿Cómo se siguen las excepciones? ¿Compras exige hojas de ruta a los proveedores? ¿Plataforma ofrece patrones estándar de migración? La agilidad criptográfica solo existe cuando la organización puede cambiar componentes criptográficos con esfuerzo controlado.
Los proveedores marcarán su ritmo
Ni siquiera los equipos maduros controlan toda la pila. Dependen de nubes, plataformas SaaS, hardware de red, HSM, clientes móviles y equipos especializados. Algunos irán rápido y otros no. Por eso un programa serio de PQC necesita también una visión de terceros: qué proveedores ya publicaron planes, qué productos adoptarán primero modos híbridos y dónde existen restricciones de hardware o de contrato.
Qué deberían hacer ahora los líderes de seguridad
Empiece con un programa acotado, aburrido y disciplinado. Primero, construya un inventario de criptografía de clave pública en sistemas expuestos a internet, identidad, firma de código, VPN y flujos de datos sensibles con alta necesidad de confidencialidad. Segundo, priorice activos por vida útil de los datos, exposición y complejidad de dependencias. Tercero, pida a los proveedores clave hojas de ruta explícitas de PQC alineadas con los estándares finales de NIST. Cuarto, identifique debilidades de crypto agility, incluidas bibliotecas hardcoded, cuellos de botella en emisión de certificados y sistemas heredados sin soporte. Quinto, ejecute pilotos o pruebas híbridas en entornos contenidos para madurar rendimiento, interoperabilidad y procedimientos operativos antes de los cambios más sensibles.
El error estratégico ahora es esperar un único gran hito cuántico. Para entonces, las organizaciones sin inventario, sin presión sobre proveedores y sin capacidad de migración estarán corriendo tarde. PQC ya salió del laboratorio y entró en el backlog operativo. Ganarán quienes lo traten como un programa multianual de cambio operativo que empieza por conocer su entorno y desarrollar capacidad de adaptación.
Si lidera seguridad o infraestructura, haga concreta la siguiente acción este trimestre: nombre un responsable ejecutivo, publique un objetivo de inventario criptográfico y convierta la pregunta de PQC en obligatoria en cada conversación con proveedores críticos. Así es como empieza una migración real.