El Reino Unido encendió la alarma: la criptografía pública que usamos todos los días no alcanzará en la próxima década y la ventana para ordenar la transición empieza ahora. El mensaje no especula con la fecha del “Q-day”, pero sí fija un calendario de trabajo para evitar el caos operativo. El primer hito es clave: conocer qué, dónde y cómo ciframos antes de 2028 para no improvisar a último momento cuando el mercado exija pruebas de preparación.

La advertencia no llega en vacío. Los avances en computación cuántica convierten en objetivo a RSA y a las curvas elípticas porque un equipo con corrección de errores y escala suficiente puede ejecutar algoritmos como Shor y quebrar sus supuestos. La consecuencia no es solamente académica: certificados de servidores, firmas de software, túneles VPN, billeteras, identidades de máquinas y contratos digitales dependen de estas primitivas. Si no planificamos la sustitución por alternativas resistentes, la continuidad del negocio termina apoyada en un supuesto que deja de ser válido.

La guía oficial británica propone un recorrido realista, con una fase de descubrimiento hasta 2028, otra de migraciones prioritarias antes de 2031 y una tercera para completar el recambio en torno de 2035. El objetivo es quitarle dramatismo al cambio y convertirlo en un programa de ingeniería con hitos mensuales. En ese esquema, 2025 y 2026 sirven para armar el mapa criptográfico de la organización, separar los casos de “datos de larga vida” y validar agilidad de algoritmos en las plataformas críticas.

A partir de ahí, cada renovación de certificado o de contrato de soporte es una oportunidad para introducir componentes “crypto-agile” que acepten nuevos estándares sin volver a construir sistemas.

Mientras tanto, el riesgo no espera. El patrón “harvest-now, decrypt-later” ya es práctica conocida: actores recolectan tráfico y repositorios cifrados hoy para descifrarlos cuando dispongan de poder cuántico suficiente. Esto afecta de inmediato a información con valor extendido, como historiales clínicos, propiedad intelectual, secretos industriales, expedientes judiciales y datos que fijan identidades durante años. La urgencia no se mide por el día en que aparezca un computador cuántico de propósito general, sino por cuánto tiempo debe permanecer confidencial lo que protegemos.

La buena noticia es que el ecosistema ya tiene normas. NIST publicó en 2024 los primeros estándares poscuánticos: ML-KEM para establecimiento de claves y ML-DSA y SLH-DSA para firmas digitales. Esos algoritmos no exigen esperar hardware nuevo ni sacrificar interoperabilidad básica; conviven con TLS, SSH y PKI modernas, y los proveedores de nube y seguridad empezaron a exponerlos en modo preliminar. El paso responsable no es activarlos a ciegas, sino hacer pruebas con datos sintéticos, medir latencias y tamaños de clave, y confirmar compatibilidad con HSM, módulos criptográficos y librerías que ya usamos en producción.

Conviene también entender que la transición no es un “big-bang”, sino una cadena de decisiones pequeñas que acumulan efecto. Primero, inventariar dónde hay criptografía aplicada y cuál es su vida útil: servidores públicos, colas internas, respaldos offline, firmados de paquetes, dispositivos IoT y flotas móviles.

Después, introducir capas de agilidad: abstraer proveedores, evitar acoplar código a implementaciones concretas, parametrizar algoritmos y alejar claves de los binarios. Por último, alinear compras y contratos: exigir soporte de estándares poscuánticos en licitaciones y renuevos, y documentar la ruta de salida para evitar “lock-in” de algoritmos.

Todo esto convive con seguridad clásica. La criptografía simétrica no desaparece, pero sí necesita ajustes de tamaño de clave para sostener equivalencias frente a Grover. La gestión de identidades se vuelve más delicada, porque gran parte del control plane confía en firmas y certificados que vamos a reemplazar gradualmente.

Las cadenas de suministro de software requieren doble atención: firmar artefactos con esquemas poscuánticos cuando el ecosistema esté listo y, mientras tanto, mantener esquemas híbridos que no rompan validaciones en clientes y socios.

En Argentina y la región, la presión provendrá de dos lados. Por un lado, de reguladores y marcos de contratación pública o financiera que empiecen a exigir planes de migración verificables y capacidades de “crypto inventory”. Por otro, de clientes globales que pidan garantías de continuidad, listas de materiales criptográficas y plazos para adoptar estándares. La discusión no es filosófica: quien demuestre preparación gana licitaciones, integra ecosistemas sensibles y reduce el costo del seguro cibernético. Quien llegue tarde tendrá que migrar apurado y con menos poder de negociación.

El reloj cuántico avanza y la frase “nunca es demasiado temprano” deja de ser slogan para convertirse en criterio operativo. Si tus sistemas federan identidades, publican APIs, guardan secretos en módulos de hardware y comercian en múltiples jurisdicciones, la migración poscuántica es un proyecto de arquitectura, no un parche.

La pregunta correcta hoy es si tu infraestructura está lista para moverse sin perder seguridad ni control, y si el plan de trabajo evita que 2028 te encuentre todavía buscando dónde están tus claves.

¿Tu infraestructura está preparada para resistir un ataque cuántico? Migrá tu seguridad antes de 2028 o quedás expuesto. Nunca es demasiado temprano para tomar medidas preventivas. Al menos, ya sabés cuáles son los siguientes pasos.