Crypto-agility — el boss final

¿Cuánto tardarías en cambiar?

Hagamos un experimento mental. Mañana por la mañana sale un paper que rompe ML-KEM. No teórico — práctico. Un equipo en GitHub publica un script que recupera la clave en horas. NIST anuncia inmediatamente la deprecación. ¿Cuánto tardarías en cambiar todos tus sistemas a otro algoritmo?

Si la respuesta es "horas", tu organización tiene crypto-agility. Si es "meses", tienes deuda criptográfica. Si es "no lo sé", tienes el problema más común de todos. Y aquí está el punto crucial: el día Q no requiere que aparezca un ordenador cuántico. Requiere cualquier cosa que rompa los algoritmos que usas hoy. Un avance algorítmico clásico, una vulnerabilidad de implementación, una mandato regulatorio. La capacidad de cambiar es el activo, no el algoritmo concreto.

NIST lo define así oficialmente: "the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations". Traducción para devs: cuando alguien decide cambiar el algoritmo, no tienes que reescribir aplicaciones, parar servicios, ni romper la compatibilidad con clientes.

Esto es lo que separa una organización ágil de una rígida. No es qué algoritmo usas — es dónde vive la decisión. Si la decisión vive en el código fuente de cada microservicio, en cada Dockerfile, en cada config de Helm, no tienes agility. Si vive en una policy centralizada que tu KMS interpreta, sí.

El calendario regulatorio

A diferencia de las otras estaciones, aquí la "historia" no es de protocolos sino de mandatos normativos. Y los mandatos vienen con fechas concretas. Si trabajas con sectores regulados o con contratos que incluyen US gov, esto no es opcional.

• Ene 2022
  NSM-8 · National Security Memorandum 8
  Primer mandato federal US: directrices para Sistemas de Seguridad Nacional (NSS). Inicio del calendario PQC oficial.
• May 2022
  NSM-10 · National Security Memorandum 10
  Mandato para sistemas no-NSS. Inventarios anuales de cripto vulnerable, migración a 2035. Es la directriz general que casi todos los países han copiado.
• Sep 2022
  CNSA 2.0 · NSA
  Suite oficial post-cuántica para NSS. ML-KEM y ML-DSA como algoritmos obligatorios. Calendarios concretos para cada categoría de equipo.
• Ene 2023
  OMB M-23-02 · Quantum Cybersecurity Preparedness Act
  Obliga a agencias federales a inventariar sistemas cripto-vulnerables anualmente hasta 2035. Aquí nace el concepto operativo de CBOM.
• Ago 2024
  NIST FIPS 203/204/205
  Estándares finales: ML-KEM, ML-DSA, SLH-DSA. Acaba la incertidumbre sobre qué algoritmos hay que adoptar. La pelota pasa a los implementadores.
• 2025
  Hito 2025 · primeras transiciones obligadas
  Ciertos NSS validados deben haber transicionado a CNSA 2.0 a finales de 2025. NIST CSWP 39 publicado: guía oficial sobre crypto-agility.
• 2027
  Hito 2027 · todas las nuevas adquisiciones US gov
  Cualquier nuevo sistema NSS debe usar algoritmos PQC desde el día uno. Si vendes a US gov, tu producto necesita ser PQC para entonces. El presupuesto se decide ahora.
• 2030
  NIST · deprecación de RSA / ECC
  NIST deprecará formalmente la cripto tradicional. CNSA 2.0 exige que todo equipo y servicio NSS que no soporte PQC esté fuera de servicio.
• 2035
  Deadline final · NSM-10
  Migración completa para todos los sistemas federales US. UK, Australia, India, Corea del Sur tienen calendarios alineados a esta fecha. 10 años desde hoy.

Cómo se ve una organización ágil

Antes de meternos con PQC, esta es la línea base de una organización con buena crypto-agility. Algunas de estas prácticas son maduras (TLS negociado), otras emergentes (CBOM). Pero juntas definen el "bien hecho" de 2026.

Si tu organización tiene la mayoría de estos puntos, la migración a PQC va a ser aburrida — es decir, exitosa. Si te faltan tres o cuatro, te toca primero construir la infraestructura que permita la migración. Y eso es justo lo que NSM-10 y CNSA 2.0 te están diciendo entre líneas: no te están pidiendo que migres a PQC, te están pidiendo que construyas la capacidad de hacerlo.

Los anti-patrones que matan la agility

A diferencia de las siete estaciones anteriores, aquí la "amenaza cuántica" no es Shor o Grover — es la deuda criptográfica acumulada en tu organización. Estos son los anti-patrones más comunes y por qué son problema.

El día que aparezca el próximo Shor — sea cuántico o no — la pregunta no es qué algoritmo usabas. Es cuánto tiempo tenías para reaccionar. Y eso depende de decisiones que tomaste hace cinco años.

Hay un dato que merece destacarse: la mayoría de organizaciones no saben qué cripto usan. NSM-10 obliga a las agencias federales US a hacer inventarios anuales precisamente porque al hacer los primeros, se descubrió que nadie tenía idea. Empresas privadas suelen estar igual o peor — solo que sin nadie obligándoles a contarlo. Tu primera tarea de crypto-agility no es migrar nada, es saber qué tienes.

Patrones de ingeniería para construir agility

Aquí no hay algoritmo PQC que recomendar — eso ya lo cubrieron las siete estaciones anteriores. Esta sección es sobre prácticas de ingeniería que hacen que cualquier migración criptográfica futura — esta o las próximas — sea barata.

Una hoja de ruta razonable

Si tu organización está empezando de cero, este es el orden que recomienda NIST y la práctica del sector:

Los 6 criterios meta de la auditoría

Esta es la única estación donde los criterios no son sobre algoritmos. Son sobre cómo organizas tu cripto. Una organización con TLS 1.0 pero buena agility migrará a PQC más rápido que una con TLS 1.3 sin agility. Sorprendente y verdadero.

Mapeo a badge: 0–30 Classical · 31–55 Hybrid-Ready · 56–75 Quantum-Safe · 76–90 Q-Day Proof. Una verdad incómoda para cerrar Cryptolab: la mayoría de organizaciones que se sienten seguras porque "ya están en TLS 1.3" tienen un score de 15-30 en esta estación. Y eso significa que cuando llegue el momento de cambiar — sea en 2030 o en 2032 o en 2027 — van a llegar tarde. La agility se construye antes de necesitarla, no después.

Has completado las 8 estaciones

Has visto cómo TLS migró antes que IPSec, cómo SSH llegó pronto y Wi-Fi llegó tarde. Has visto que MACsec ya es cuántico-seguro hoy y que la VPN consumer va por delante de la enterprise. Y ahora sabes que nada de esto importa tanto como tu capacidad de cambiar.

El examen final integra los 8 checklists. Te genera un score por estación, un badge global, y un reporte con tus áreas ciegas. Sin guardar nada. Sin login. Local en tu navegador. Igual que el resto de Cryptolab, sin trucos.

Cuando lo hagas, recuerda: el badge no mide cuántico-seguridad real, mide preparación. La seguridad real depende de qué pase con los ordenadores cuánticos en los próximos años, qué vendors entreguen sus roadmaps, y qué decisiones tomes tú. Cryptolab te da la herramienta para tomar mejores decisiones.

Q-Day no es una fecha. Es una métrica de preparación. Y la métrica empieza ahora.