La conversación poscuántica suele comenzar con una pregunta imposible: “¿cuándo llegará una computadora capaz de romper la criptografía actual?”. Para una empresa, la pregunta útil es otra: ¿cuánto tardaríamos en encontrar y cambiar toda la criptografía que protege nuestros datos?
RSA y la criptografía de curva elíptica sostienen conexiones TLS, VPN, firmas, certificados, actualizaciones de software y muchas integraciones. Una computadora cuántica criptográficamente relevante podría comprometer esos mecanismos de clave pública. El momento exacto es incierto; la complejidad de migrar sistemas reales, en cambio, ya es observable y puede tomar años.
Qué cambió: ya existen estándares finales
En agosto de 2024, NIST finalizó FIPS 203, 204 y 205. Esto movió el tema de investigación a planificación tecnológica:
ML-KEM: establecimiento de claves
Sirve para acordar secretos que después protegen comunicaciones y datos. NIST mantiene ML-KEM como elección recomendada para uso general.
ML-DSA: firmas digitales
Permite verificar autenticidad e integridad de documentos, software y mensajes mediante firmas resistentes a ataques cuánticos conocidos.
SLH-DSA: firma basada en hash
Ofrece una alternativa construida sobre supuestos criptográficos distintos, con características de tamaño y rendimiento que deben evaluarse.
En 2025, NIST seleccionó HQC como mecanismo de respaldo basado en matemáticas diferentes a ML-KEM y señaló que su estandarización final se espera para 2027. Esto no es una razón para esperar: la recomendación oficial fue continuar migrando hacia los estándares ya finalizados.
El riesgo empieza antes de la computadora cuántica
Información cifrada hoy puede ser capturada y almacenada para intentar descifrarla en el futuro. Esta estrategia, conocida como harvest now, decrypt later, importa cuando la confidencialidad debe durar muchos años: expedientes, propiedad intelectual, secretos comerciales, contratos, datos biométricos o diseños de infraestructura.
La prioridad no depende solo de la probabilidad tecnológica. Depende de la combinación de vida secreta del dato + tiempo de migración + impacto de exposición. Una base que debe permanecer confidencial por quince años merece atención antes que información pública con un certificado que vencerá pronto.
Fase 1: construir el inventario criptográfico
No basta con buscar certificados visibles. La criptografía vive dentro de bibliotecas, dispositivos y servicios contratados. El inventario debe registrar al menos:
- Aplicación, dueño, criticidad y ambiente.
- Algoritmo, longitud de clave, biblioteca, proveedor y versión.
- Uso: intercambio de claves, firma, identidad, cifrado de datos o actualización.
- Ubicación de certificados, llaves y módulos de seguridad.
- Protocolos externos: TLS, VPN, SSH, correo, APIs, intercambio de archivos y conexiones B2B.
- Datos protegidos, periodo de retención y periodo durante el cual deben conservar confidencialidad.
- Contrato, hoja de ruta poscuántica y fecha de soporte del proveedor.
Las fuentes incluyen escáneres de red y código, inventarios de activos, gestores de certificados, configuraciones de nube, software bills of materials y entrevistas con responsables. Ninguna fuente descubre todo por sí sola.
Entregable útil
El inventario no debe ser una hoja estática. Conviértelo en un registro con dueño, evidencia, fecha de escaneo y estado de migración. Así puede actualizarse desde CI/CD y gestión de activos.
Fase 2: priorizar con contexto de negocio
Asigna una prioridad considerando cuatro ejes:
- Longevidad del secreto: cuánto tiempo conserva valor la información.
- Exposición: si cruza redes públicas, terceros o ubicaciones fuera de control.
- Dependencia: cuántos consumidores, dispositivos y socios deben cambiar al mismo tiempo.
- Capacidad de sustitución: si el algoritmo está parametrizado o incrustado en código, hardware o formatos históricos.
Los sistemas con datos de larga duración y ciclos lentos —dispositivos, firmware, PKI, respaldos, integraciones con terceros— suelen quedar primero. Una aplicación que se despliega cada semana puede adaptarse después con menos riesgo que un equipo instalado por diez años.
Fase 3: diseñar agilidad criptográfica
La migración poscuántica no será el último cambio de algoritmos. La arquitectura debe permitir sustituirlos sin reescribir reglas de negocio. Algunas decisiones prácticas:
- Centralizar políticas criptográficas y evitar nombres de algoritmo dispersos en el código.
- Versionar formatos de mensajes, firmas y llaves.
- Negociar capacidades entre clientes y servidores sin aceptar degradaciones inseguras.
- Separar gestión de llaves, identidad y lógica de aplicación.
- Probar tamaños mayores de llaves, firmas y mensajes en límites reales.
- Registrar qué algoritmo protegió cada objeto para conservar capacidad de validación histórica.
Fase 4: pilotear sin confundir “híbrido” con “seguro”
Durante la transición, algunos protocolos combinan un algoritmo clásico y uno poscuántico. El objetivo es conservar seguridad si al menos uno resiste. Pero una construcción híbrida exige especificación e implementación maduras; concatenar secretos por cuenta propia puede crear nuevas fallas.
El piloto debe ejecutarse en un flujo acotado y medir latencia, uso de CPU, tamaño de handshake, compatibilidad de proxies, HSM, balanceadores, clientes móviles y observabilidad. También debe probar renovación, revocación, respaldo y recuperación: la criptografía no termina cuando una conexión funciona.
Preguntas obligatorias para proveedores
- ¿Qué estándares NIST soportan hoy y en qué componentes?
- ¿Cuál es la hoja de ruta para TLS, VPN, firmas, PKI y datos almacenados?
- ¿El cambio requiere hardware, licencia o actualización mayor?
- ¿Cómo se inventarían algoritmos y certificados usados por el producto?
- ¿Qué compatibilidad existe con versiones anteriores y cuánto durará?
- ¿Qué pruebas de interoperabilidad y validación están disponibles?
Evita promesas genéricas de “quantum safe”. Solicita nombres de estándares, versiones, alcances, limitaciones y evidencia. Un solo componente preparado no vuelve poscuántica a toda una cadena.
Plan de acción para los próximos seis meses
- Nombrar un responsable y acordar una definición común de alcance.
- Identificar los diez sistemas con datos de mayor vida útil o dependencia.
- Crear el esquema del inventario y automatizar una primera fuente.
- Pedir hojas de ruta a proveedores críticos y registrar dependencias contractuales.
- Elegir un piloto reversible con soporte estándar, no criptografía casera.
- Incluir agilidad criptográfica en nuevas arquitecturas y compras.
- Revisar trimestralmente estándares, compatibilidad y cronograma de migración.
Conclusión
La preparación poscuántica es un programa de gestión tecnológica, no una compra puntual. Las organizaciones que primero entiendan sus dependencias podrán adoptar estándares maduros con menos interrupciones. Empieza por visibilidad, prioriza según el valor temporal del dato y diseña capacidad de cambio: esa agilidad protege tanto frente al futuro cuántico como frente a la próxima transición criptográfica.
Fuentes y lectura adicional
- NIST CSRC — Publicaciones y estándares de criptografía poscuántica.
- NIST — Selección de HQC como algoritmo de respaldo.
- NIST IR 8547 — Transition to Post-Quantum Cryptography Standards (borrador).
- NIST NCCoE — Migración PQC y marcos de riesgo.
Última revisión editorial y técnica: 31 de julio de 2026. Verifica siempre el estado vigente de estándares, bibliotecas y certificaciones antes de desplegar.
