No elija un algoritmo poscuántico hasta saber dónde vive la criptografía de clave pública en su infraestructura. NIST publicó FIPS 203, 204 y 205 en agosto de 2024 y afirma que las organizaciones deberían empezar a migrar ya. Los estándares dicen a qué migrar. No dicen nada sobre lo que usted ejecuta hoy, y averiguarlo es la parte lenta.
Qué le piden los plazos
La página del proyecto de NIST indica que, según el calendario de transición de NIST IR 8547, los algoritmos vulnerables a la computación cuántica quedarán obsoletos y se eliminarán definitivamente de sus estándares en 2035, y que los sistemas de alto riesgo tendrán que migrar mucho antes. La página del borrador de IR 8547 recoge que la versión final lo sustituyó el 27 de octubre de 2026. Nuestras fuentes no enumeran los estándares vulnerables ni las fechas anteriores para sistemas de alto riesgo, así que consulte esos datos en el texto de NIST.
El NCSC británico convierte el calendario en hitos con los que un equipo de TI puede elaborar un presupuesto, en su guía sobre los plazos de migración a criptografía poscuántica:
| Para | Qué espera el NCSC |
|---|---|
| 2028 | Definir los objetivos de migración, completar un ejercicio de descubrimiento exhaustivo y elaborar un plan inicial |
| 2031 | Llevar a cabo la migración temprana de máxima prioridad y refinar el plan hasta convertirlo en una hoja de ruta completa |
| 2035 | Completar la migración de todos los sistemas, servicios y productos |
El inventario alimenta las tres tareas de 2028. Si es escaso, las otras dos son meras conjeturas.
Qué debe figurar en la lista
El objetivo es todo aquello que dependa de criptografía asimétrica de clave pública, que según el NCSC los ordenadores cuánticos podrán romper. La sección de descubrimiento del NCSC cubre estos ámbitos:
- sistemas y servicios que usted opera, para usuarios internos y para terceros;
- productos que usted fabrica o utiliza y que cumplen una función de criptografía, seguridad, comunicaciones o procesamiento de datos;
- aplicaciones de software y equipamiento de red como routers, switches, pasarelas, VPN y estaciones base;
- dispositivos móviles, servidores y estaciones de trabajo;
- dispositivos IoT e ICS con función de comunicaciones, tokens emitidos a usuarios, y dispositivos y sensores instalados sobre el terreno;
- los datos que custodia, su vida útil prevista y su valor para un adversario, y cómo se protegen en tránsito y en reposo.
Los certificados no se mencionan en esa lista, aunque el NCSC dedica una sección aparte a la PKI corporativa. Añada como filas independientes los certificados web públicos, las CA internas, los certificados de cliente y las claves de firma de código; es criterio nuestro, no del NCSC. Añada también a los proveedores gestionados.
No se trata de un registro formal de activos. Anote de cada sistema su naturaleza, escala, versión, nivel de parcheado y dependencias; basta con una fila por sistema.
Dónde fallan los inventarios
Hay tres puntos que requieren una revisión deliberada, porque ninguno aparece en una exportación de certificados ni en una lista de paquetes: las claves incrustadas en el código de las aplicaciones o en la configuración, las claves de firma custodiadas en un HSM y el firmware de los dispositivos embebidos y de campo, que no puede actualizarse como un servidor. El NCSC señala como limitación el hardware de larga vida y los ciclos de sustitución poco frecuentes, y es en esos dispositivos donde más se nota.
Cómo listarlo en una semana
Empiece de arriba abajo, por los servicios principales y sus interdependencias, y vaya después de abajo arriba allí donde esa visión se quede corta. Un reparto viable para un equipo pequeño:
- Día uno. Liste los servicios clave y los datos que maneja cada uno, y marque los datos que deben seguir siendo secretos durante años. Envíe ese mismo día el correo a proveedores que figura más abajo, ya que las respuestas son lo que más tarda.
- Días dos y tres. Exporte las listas de certificados de todas las CA que gestione y pida las suyas a cada equipo que compre certificados. Añada las configuraciones de VPN y de acceso remoto. Recopile SBOM, archivos de bloqueo de dependencias (lockfiles) o listas de paquetes del software que desarrolla y ejecuta, y busque en ellos librerías criptográficas y sus versiones. Busque en repositorios y directorios de configuración claves privadas y certificados incluidos en el código; cada coincidencia es una fila, y una clave privada en un repositorio hay que corregirla de todos modos.
- Día cuatro. Ejecute un escáner de TLS contra los endpoints externos e internos, y compruebe las claves de host SSH y las propuestas de VPN o IPsec que ofrecen sus pasarelas. Compare los resultados con sus filas; la salida del escáner es una verificación cruzada, no un sustituto.
- Día cinco. Fusione los datos, señale las lagunas y escriba «desconocido» donde no haya podido confirmar algo.
Preguntas a proveedores que caben en un solo correo:
- ¿Cuáles de sus productos o servicios que utilizamos dependen de criptografía de clave pública, y qué librerías y versiones contienen?
- ¿Cuál es su plan de migración a criptografía poscuántica, con fechas?
El NCSC indica que debe asegurarse de que los proveedores gestionados realicen estas evaluaciones para los servicios que operan para usted. Preguntar por escrito es nuestra recomendación para lograrlo.
Convertir la lista en un plan
Para cada fila, elija una de las estrategias del NCSC: migración in situ, replataformado, retirada del servicio, uso hasta el fin de su vida útil o aceptación del riesgo. Los sistemas sin criptografía de clave pública no requieren ninguna acción.
Ordene las filas por la vida útil y el valor de los datos que protegen y, a continuación, por su dependencia de hardware de larga vida.
Cuente con que lo antiguo y lo nuevo convivirán durante un tiempo. Prefiera productos con agilidad criptográfica, es decir, que admitan con facilidad conjuntos de algoritmos alternativos, y decida de antemano cuándo dejará de dar soporte a lo tradicional.
Solo entonces elija los algoritmos. NIST espera que ML-KEM (FIPS 203) para el establecimiento de claves, y ML-DSA (FIPS 204) y SLH-DSA (FIPS 205) para las firmas, sean la base de la mayoría de los despliegues. FIPS 203 incluye una nota de planificación sobre una cuestión que se corregirá en una revisión futura, así que consulte la fe de erratas antes de implementar a partir de él. NIST sigue estandarizando Falcon y HQC; su página del proyecto de PQC es donde conviene vigilar los cambios.
Si necesita ayuda con el descubrimiento, nuestro equipo de consultoría realiza evaluaciones.
Por dónde empezar
- Nombre a un responsable, reserve una semana y envíe el correo a proveedores el primer día.
- Cree una fila por sistema: responsable, finalidad, dónde se usa criptografía de clave pública, versiones, dependencias, vida útil de los datos, proveedor, estrategia elegida y fecha objetivo.
- Recopile certificados, configuraciones de VPN y SBOM, y ejecute después las búsquedas de TLS, SSH y repositorios.
- Revise a mano las claves incrustadas, la firma respaldada por HSM y el firmware embebido, y marque como «desconocido» todo lo que no haya podido confirmar.
- Ordene las filas por vida útil de los datos y dependencia del hardware, y asigne a cada una una estrategia del NCSC y una fecha objetivo, de modo que la hoja se convierta en su plan de 2028.
- Lea la versión final de IR 8547 para conocer las fechas de obsolescencia de los sistemas de alto riesgo y fije fechas internas anteriores a 2035 donde así se exija.
