Migración criptoágil: plan de acción para la era poscuántica

30 de julio de 2026

La criptografía poscuántica ya tiene estándares. Lo que falta en la mayoría de las empresas es una hoja de ruta operativa. Esta es la tuya.

En agosto de 2024, el NIST publicó los primeros estándares definitivos de criptografía poscuántica. ML-KEM (FIPS 203), ML-DSA (FIPS 204) y SLH-DSA (FIPS 205) dejaron de ser propuestas para convertirse en normativa. El punto de partida de la migración ya no es "cuando haya estándares". El punto de partida es ahora.

Sin embargo, la distancia entre “hay estándares” y “tenemos un plan” sigue siendo enorme en la mayoría de las empresas. Los equipos de seguridad entienden la urgencia conceptualmente pero no saben por dónde empezar. Los presupuestos no se han movido porque no hay una propuesta concreta. Y los proveedores tecnológicos envían mensajes contradictorios sobre plazos y compatibilidades.

Vamos a una guía de acción. No una introducción a la mecánica cuántica ni un resumen de estándares. Un plan estructurado en fases con entregables concretos, decisiones clave y señales de progreso que un CISO puede llevar a su empresa la semana que viene.

La criptoagilidad permite alcanzar cualquier objetivo criptográfico futuro sin rediseñar una arquitectura desde cero.

Qué significa realmente ser criptoágil

El término criptoagilidad se usa con frecuencia y pocas veces se define con precisión. En la práctica, una empresa criptoágil tiene cuatro capacidades concretas:

  • Visibilidad total sobre qué algoritmos criptográficos usa, dónde, en qué sistemas y con qué versiones. Sin inventario no hay agilidad; solo oscuridad.
  • Capacidad de sustitución rápida de un algoritmo por otro sin interrumpir el servicio ni reescribir las aplicaciones desde cero. Esto requiere que la criptografía esté abstraída en capas separadas de la lógica de negocio.
  • Soporte simultáneo de múltiples algoritmos durante períodos de transición. Los sistemas deben poder negociar y operar con RSA clásico y ML-KEM poscuántico en paralelo hasta que la migración esté completa.
  • Gobierno activo sobre el ciclo de vida criptográfico, quién decide qué algoritmos se usan, con qué criterios, con qué frecuencia se revisan y cómo se responde a una vulnerabilidad emergente.

Vamos a hacer la migración, en un plan de cinco fases:

1. Inventario criptográfico  INICIAR
La fotografía del punto de partida · 0–6 meses

No puedes migrar lo que no ves. El inventario criptográfico es el paso cero de cualquier programa de transición poscuántica, y también el que más empresas omiten por considerarlo laborioso. Lo es, pero sus alternativas son peores.

Un inventario criptográfico completo responde a cuatro preguntas por cada activo: qué algoritmo se usa, en qué sistema o aplicación, quién lo gestiona y cuál es su vida útil esperada. La herramienta de análisis puede ir desde inspección manual de configuraciones hasta soluciones especializadas de crypto-discovery que escanean el tráfico de red y los repositorios de código.

  • Identificar todos los sistemas que usan PKI, TLS, SSH, firma digital o cifrado en reposo.
  • Catalogar algoritmos por tipo: clave asimétrica (RSA, ECC), simétrica (AES), hash (SHA), firma (ECDSA, RSA-PSS).
  • Mapear dependencias: qué aplicaciones dependen de qué certificados y qué HSM.
  • Identificar sistemas con criptografía embebida o hardcodeada (mayor riesgo de migración)
  • Clasificar proveedores Cloud y SaaS con acceso a datos cifrados.
  • Documentar ciclos de renovación de certificados y claves existentes

2. Priorización por riesgo  INICIAR
No todo migra al mismo tiempo · 3–9 meses

Una vez tienes el inventario, el siguiente error habitual es intentar migrarlo todo a la vez. No tiene sentido técnico ni presupuestario. La priorización correcta parte del riesgo HNDL: los datos que tienen valor a largo plazo son los que están en riesgo hoy, aunque el Q-Day esté a una década.

La regla práctica es sencilla: si la confidencialidad de un dato necesita mantenerse durante más tiempo del que tardará en existir un ordenador cuántico con capacidad de romper RSA-2048, estimado entre 5 y 15 años según la fuente, ese dato debería estar protegido con criptografía poscuántica lo antes posible.

  • Clasificar activos de datos por horizonte de confidencialidad requerido (<5 años / 5–15 años / >15 años).
  • Priorizar comunicaciones que contienen secretos comerciales, propiedad intelectual, datos de salud o información regulada.
  • Identificar claves de larga duración: certificados raíz, claves maestras de HSM, claves de firma de código.
  • Evaluar sistemas de comunicación con entidades reguladas (banca, sanidad, infraestructuras críticas)
  • Construir una matriz de priorización: criticidad del dato × vida útil × facilidad de migración

2. Arquitectura criptoágil  PLANIFICAR
Construir la capacidad de cambio · 6–18 meses

Esta es la fase más técnica y la más estratégica. El objetivo no es migrar un algoritmo concreto, sino rediseñar la forma en que tu empresa gestiona la criptografía para que los cambios futuros sean baratos y rápidos en lugar de traumáticos.

  • Introducir una capa de abstracción criptográfica (crypto abstraction layer) que desacople los algoritmos de las aplicaciones.
  • Exigir en nuevos desarrollos que las selecciones de algoritmos sean configurables, no hardcoded.
  • Desplegar PKI dual-stack capaz de emitir certificados clásicos y poscuánticos en paralelo.
  • Implementar hybrid key exchange en TLS para sistemas de alta criticidad (RSA/ECDH + ML-KEM).
  • Actualizar estándares de desarrollo seguro para incluir requisitos de crypto-agility.
  • Evaluar y seleccionar librerías PQC certificadas (liboqs, BouncyCastle PQC, OpenSSL 3.x con soporte PQC)

Migración progresiva  PLANIFICAR
Ejecutar por oleadas, no por revolución · 12–36 meses

Con la arquitectura criptoágil en marcha, la migración real de algoritmos puede ejecutarse de forma controlada. El modelo de tres oleadas permite gestionar el riesgo sin interrumpir operaciones y ajustar el ritmo según la madurez del ecosistema de proveedores y herramientas.

Oleada 1 Activos de alta prioridad HNDL (meses 12–18): comunicaciones externas con datos sensibles a largo plazo, firma digital de documentos con valor legal prolongado, claves maestras de PKI. Son los activos con mayor riesgo presente y, frecuentemente, los que tienen mejor soporte de herramientas PQC.

Oleada 2 Infraestructura crítica interna (meses 18–30): VPN corporativa, autenticación de sistemas, cifrado de bases de datos críticas, comunicaciones entre microservicios internos. Requieren coordinación mayor entre equipos de infraestructura y desarrollo.

Oleada 3 Sistemas legacy y periferia (meses 24–36+): sistemas OT/ICS, aplicaciones legacy difíciles de modificar, dispositivos IoT. Son frecuentemente los más complejos y pueden requerir estrategias específicas como gateways de traducción criptográfica.

  • Definir los criterios de entrada y salida para cada oleada.
  • Establecer entornos de test/staging con configuración PQC antes de producción.
  • Planificar la renovación de certificados raíz (operación de alto impacto, requiere ventana de mantenimiento).
  • Coordinar con proveedores cloud la activación de opciones PQC en servicios contratados.
  • Documentar cada migración para el registro de cumplimiento regulatorio.

Gobierno criptográfico continuo  ESTRUCTURAL
La migración no termina · Permanente

La criptografía poscuántica no es el destino final. Es el estándar actual. Habrá nuevos algoritmos, nuevas vulnerabilidades y nuevos requisitos regulatorios. El programa de gobierno criptográfico continuo es lo que hace que la empresa no tenga que volver a partir de cero en cada transición.

  • Revisar el inventario criptográfico al menos anualmente.
  • Suscribirse a alertas de NIST, ENISA y CCN-CERT sobre vulnerabilidades criptográficas.
  • Incluir criterios de cryptoagility en la gestión del ciclo de vida de sistemas (SDLC, procurement).
  • Mantener actualizados los contratos de proveedores con cláusulas de actualización criptográfica.
  • Formar al equipo de seguridad en PQC con periodicidad anual a medida que los estándares evolucionan.
  • Reportar al Consejo sobre el estado del programa con métricas de progreso claras.

Los errores más comunes y cómo evitarlos

  • X  Migrar sin inventario previo
    Empezar a desplegar PQC sin saber qué hay en producción garantiza migraciones incompletas y puntos ciegos de vulnerabilidad.

      Inventario primero, siempre
    Dedicar los primeros meses exclusivamente a visibilidad. El inventario es la única base desde la que se puede priorizar con rigor.
  • X  Tratar PQC como un proyecto de una sola vez
    La criptografía cambia. Un programa sin gobierno continuo quedará obsoleto antes de estar completamente desplegado.

      Diseñar para el cambio desde el inicio
    La arquitectura criptoágil es la inversión que reduce el coste de todas las migraciones futuras, no solo la actual.
  • X  Ignorar el rendimiento de PQC
    Algunos algoritmos PQC tienen firmas o claves más grandes que sus equivalentes clásicos. No considerarlo causa degradación de rendimiento en producción.

      Testear rendimiento en staging
    Validar el impacto de latencia y tamaño de mensaje antes de producción. ML-KEM tiene buen perfil de rendimiento; SLH-DSA es más costoso para firmas frecuentes.
  • X  Olvidar los sistemas legacy y heredados
    Los sistemas OT, IoT y aplicaciones antiguas son difíciles de migrar, pero frecuentemente acceden a datos sensibles. Ignorarlos crea flancos permanentes.

      Planificar gateways de traducción
    Para sistemas que no pueden migrarse directamente, los gateways PQC permiten proteger las comunicaciones sin tocar el sistema interno.

Las métricas que importan

Un programa de migración criptoágil sin métricas de progreso no sobrevive a los ciclos de revisión presupuestaria. Estas son las cuatro métricas que comunican el avance de forma comprensible para un Consejo de Administración:

  • Porcentaje del inventario criptográfico con algoritmos vulnerables, muestra la exposición actual y su reducción a lo largo del tiempo. Es la métrica de riesgo más directa.
  • Cobertura de activos de alta prioridad HNDL migrados, indica el progreso en el frente más urgente. Un Consejo entiende el 70% de nuestros datos más sensibles ya están protegidos con criptografía poscuántica.
  • Número de sistemas con arquitectura criptoágil, mide la capacidad estructural de respuesta futura. Es la métrica de resiliencia del programa.
  • Porcentaje de proveedores críticos con cláusulas de quantum-readiness. extiende la postura de seguridad más allá del perímetro propio, lo que el Consejo debería entender como responsabilidad fiduciaria.

______

Criptografía resistente y resiliente a la computación cuántica: retos y estrategias para la era cuántica