El roadmap de criptografía post-cuántica para DevOps empresarial

NIST ha cerrado los primeros estándares de criptografía post-cuántica y la pregunta que tenían aparcada los equipos de infraestructura ya no puede esperar: ¿cuándo empezamos la migración? La respuesta corta es que si no has empezado a inventariar, ya vas tarde.

Los tres algoritmos estandarizados —ML-KEM (antes Kyber), ML-DSA (antes Dilithium) y SLH-DSA (antes SPHINCS+)— tienen implementaciones maduras en todas las plataformas principales. El problema no es técnico. Es de escala y de planificación.

Por qué la urgencia

El argumento para actuar ahora, incluso cuando los ordenadores cuánticos capaces de romper RSA-2048 están todavía a años vista, es la amenaza "harvest now, decrypt later". Actores adversariales con suficientes recursos ya están almacenando tráfico cifrado hoy con la intención de descifrarlo cuando tengan la capacidad cuántica para hacerlo.

Para datos con vida útil larga —registros médicos, secretos comerciales, comunicaciones diplomáticas— eso significa que la ventana de riesgo ya está abierta.

El inventario como primer paso

Antes de migrar nada, el paso obligatorio es saber qué tienes. En organizaciones de tamaño mediano, el número de lugares donde se usa criptografía asimétrica es sorprendentemente alto:

• Certificados TLS en APIs, webs y microservicios
• Claves SSH para acceso a infraestructura
• Firmas de código y artefactos de CI/CD
• Tokens JWT y cookies de sesión
• Comunicación entre servicios (mTLS)
• Almacenamiento de secretos (Vault, AWS KMS, etc.)

# Auditar certificados TLS en tu infraestructura
openssl s_client -connect tu-servicio.com:443 2>/dev/null   | openssl x509 -noout -text   | grep "Public Key Algorithm"

El roadmap práctico

La estrategia que está funcionando en empresas que ya están en proceso es la hibridación: usar algoritmos clásicos y post-cuánticos en paralelo durante un período de transición. TLS 1.3 ya soporta cipher suites híbridas como X25519Kyber768.

Para DevOps, el roadmap realista es de tres a cinco años, con las APIs públicas y los certificados de mayor visibilidad como primera prioridad, seguidos de la infraestructura interna y finalmente los sistemas legacy que requieren más esfuerzo de integración.