Checklist de preparación poscuántica para equipos de seguridad

Un checklist de preparación para la criptografía poscuántica (PQC) tiene una sola función: convertir una migración de varios años en elementos que un equipo puede terminar este trimestre, y que cada uno deje evidencias que otra persona pueda leer. El orden importa. El intercambio de claves va primero porque el tráfico grabado solo está protegido por el intercambio de claves; después vienen el inventario, los proveedores, las firmas y la supervisión. Cada elemento indica el artefacto que hay que producir, no solo la idea que conviene tener en cuenta.

Cómo usar este checklist

Avance por las fases en orden, pero ejecute el descubrimiento (fase 2) y las victorias rápidas (fase 3) en paralelo: esperar a tener un inventario completo antes de activar el intercambio de claves híbrido en un endpoint web público retrasa el único control que mitiga el tráfico grabado. Asigne a cada elemento un responsable, una fecha y un artefacto. El artefacto es lo esencial: PCI DSS, DORA y NIS2 exigen políticas, inventarios y revisiones documentados, y una migración sin documentar es indistinguible de una migración inexistente. Este artículo es información, no asesoramiento jurídico.

Cuatro términos que se usan a lo largo del texto. ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) es el intercambio de claves poscuántico estandarizado en NIST FIPS 203, publicado como estándar definitivo el 13 de agosto de 2024. Un KEM (mecanismo de encapsulación de claves) es la primitiva que establece un secreto compartido. HNDL (harvest now, decrypt later, «recolectar ahora, descifrar después») es la práctica de grabar hoy tráfico cifrado para descifrarlo cuando exista un ordenador cuántico capaz. Un CBOM (cryptographic bill of materials, lista de materiales criptográficos) es un inventario de activos criptográficos legible por máquina.

Fase 1: gobernanza y alcance

• Designe un único responsable y un grupo de trabajo que incluya arquitectura de seguridad, PKI, red, propietarios de aplicaciones y compras. Evidencia: un mandato de una página con nombres, alcance y periodicidad de reuniones.
• Elija el calendario que sirve de ancla a su plan (regulador sectorial, guías nacionales, contratos con clientes). Evidencia: una breve declaración de aplicabilidad que nombre los marcos que le obligan y los que trata como orientación. Nuestra síntesis de los plazos oficiales de migración poscuántica los recoge con sus fuentes.
• Incorpore la cripto-agilidad a la política de cifrado. Las normas técnicas de regulación de DORA, Reglamento Delegado (UE) 2024/1774 de la Comisión, Art. 6, exigen una política de cifrado y controles criptográficos que incluya disposiciones para actualizar o cambiar la tecnología criptográfica en función de la evolución del criptoanálisis. NIS2, Directiva (UE) 2022/2555, Art. 21(2)(h), exige políticas y procedimientos relativos a la utilización de la criptografía y, en su caso, del cifrado. Evidencia: la versión aprobada de la política, fechada, con la cláusula visible.
• Identifique los datos con horizontes de confidencialidad largos: secretos, historiales sanitarios y financieros, propiedad intelectual, todo aquello cuya exposición en 2040 seguiría causando daño. Evidencia: una lista de sistemas con la duración de secreto requerida por clase de datos.
• Registre HNDL en el registro de riesgos con su nombre y los sistemas afectados. Evidencia: la entrada de riesgo con responsable y fecha de revisión.

Fechas de referencia para la planificación

Fase 2: descubrimiento e inventario

• Enumere primero la superficie externa: cada nombre de host público, sus versiones de TLS, los grupos de intercambio de claves ofrecidos, las suites de cifrado y la cadena de certificados. Evidencia: una exportación de escaneo fechada por nombre de host, conservada como imagen del estado inicial.
• Extienda el trabajo al interior: terminadores TLS y balanceadores de carga, concentradores VPN, parques SSH, TLS mutuo entre servicios, conexiones a bases de datos y colas de mensajes, HSM, cifrado de copias de seguridad, cadenas de firma de firmware y software. Evidencia: un inventario con finalidad, ubicación y responsable por entrada, que es también lo que el requisito 12.3.3 de PCI DSS v4.0.1 espera para las suites de cifrado y protocolos en uso.
• Haga que el descubrimiento sea repetible, no una hoja de cálculo puntual. OMB M-26-15 pide a las agencias de EE. UU. un inventario criptográfico automatizado y actualizado de forma continua; ese listón es un objetivo razonable en otros contextos, incluso donde no es aplicable.
• Produzca un CBOM. Esta es nuestra interpretación, no un requisito literal de los textos anteriores: un CBOM es una forma práctica de acreditar un inventario y de compararlo entre versiones. Consulte qué contiene un CBOM para conocer su estructura.
• Señale lo obsoleto y lo vulnerable a la computación cuántica: RSA, ECDSA, EdDSA, ECDH, DH sobre cuerpos finitos y DSA quedan rotos por el algoritmo de Shor en un ordenador cuántico suficientemente grande, sea cual sea el tamaño de clave. RC4 está prohibido en TLS (RFC 7465), MD5 y SHA-1 están obsoletos para firmas, y el grupo TLS preestándar de Kyber X25519Kyber768Draft00 (codepoint 0x6399) debería eliminarse.

openssl version
openssl s_client -connect example.com:443 -tls1_3 -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i "Negotiated TLS1.3 group"
ssh -Q kex | grep mlkem
ssh -v user@example.com 2>&1 | grep "kex: algorithm"

Se necesita OpenSSL 3.5 o posterior para los grupos ML-KEM. Si openssl s_client rechaza el nombre del grupo, el cliente es demasiado antiguo y el resultado no dice nada sobre el servidor.

Fase 3: victorias rápidas en el intercambio de claves

• Active el intercambio de claves híbrido en los endpoints TLS públicos. Ofrezca X25519MLKEM768 (codepoint IANA 0x11EC) en primer lugar y mantenga X25519 clásico detrás como alternativa. SecP256r1MLKEM768 (0x11EB) y SecP384r1MLKEM1024 (0x11ED) son las alternativas registradas. Las versiones actuales de Chrome, Edge y Firefox ya ofrecen X25519MLKEM768 por defecto, por lo que la adopción es inmediata para el tráfico de navegador. Evidencia: el diff de configuración más un escaneo antes y después.
• Pruebe primero en preproducción y vigile los equipos intermedios que toleran mal mensajes ClientHello más grandes. Evidencia: el registro de pruebas en preproducción y cualquier hallazgo relativo a MTU o fragmentación.
• Actualice SSH. OpenSSH 9.9 (19/09/2024) añadió mlkem768x25519-sha256, OpenSSH 10.0 (09/04/2025) lo convirtió en el acuerdo de claves por defecto y OpenSSH 10.1 (06/10/2025) emite un aviso cuando una conexión negocia un acuerdo de claves no poscuántico. Evidencia: informe de versiones del parque e intercambio de claves negociado por cada host de salto.
• Prefiera AES-256 para los datos en reposo de larga duración. Los algoritmos simétricos y las funciones hash no quedan rotos por Shor; el algoritmo de Grover es la razón por la que se prefiere AES-256 para la protección a largo plazo.

# nginx built against OpenSSL 3.5 or later: hybrid first, classical kept as fallback
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

La sintaxis y la compilación necesaria varían según el servidor y la distribución; nuestra guía para activar ML-KEM en nginx, Apache, HAProxy y Caddy detalla las directivas de cada servidor. RFC 10024 (agosto de 2026) especifica el acuerdo de claves híbrido poscuántico y tradicional para TLS 1.3.

Fase 4: proveedores y compras

La mayor parte del parque pertenece a terceros. Envíe las mismas cinco preguntas a cada proveedor crítico y archive las respuestas junto con el contrato.

1. ¿Qué grupos de intercambio de claves TLS ofrece hoy su servicio y podemos verificarlo desde fuera?
2. ¿Cuál es su hoja de ruta fechada para el soporte de ML-KEM y qué notas de versión lo anunciarán?
3. ¿Qué implementaciones de FIPS 203, 204 o 205 utilizan y en qué componentes?
4. ¿Pueden proporcionar un CBOM o un inventario criptográfico equivalente del producto entregado?
5. ¿Cómo trata el contrato un cambio de algoritmo forzado si el criptoanálisis avanza?

Evidencia: respuestas escritas y fechadas por proveedor, además de una cláusula de cripto-agilidad en las renovaciones. Para los productos comercializados en la UE, el Reglamento de Ciberresiliencia (Cyber Resilience Act), Reglamento (UE) 2024/2847, anexo I, parte I (2)(e), exige proteger la confidencialidad, por ejemplo cifrando los datos pertinentes en reposo o en tránsito mediante mecanismos de vanguardia; no menciona algoritmos poscuánticos. Sus obligaciones de notificación se aplican a partir del 11/09/2026 y se aplica plenamente a partir del 11/12/2027.

Fase 5: firmas, certificados y PKI

• Inventaríe los algoritmos de firma y los periodos de validez. Enumere cada certificado y clave de firma cuya validez se extienda más allá de sus fechas de referencia. Evidencia: un registro de certificados, que el Art. 7 de las RTS de DORA exige para los activos TIC que soportan funciones críticas o importantes, junto con la gestión de claves durante todo su ciclo de vida.
• Acorte las vigencias y automatice la renovación para que un cambio de algoritmo sea un cambio de configuración y no un proyecto. Evidencia: cobertura de la emisión automatizada, en porcentaje de certificados bajo automatización.
• Planifique por separado la firma de código y de firmware. ML-DSA (FIPS 204) y SLH-DSA (FIPS 205) son los estándares definitivos; LMS y XMSS se especifican en NIST SP 800-208 y tienen estado, por lo que la gestión del estado es el verdadero problema de ingeniería. Para los National Security Systems de EE. UU., CNSA 2.0 exige el uso exclusivo de sus algoritmos antes de finales de 2030 para la firma de software y firmware y los equipos de red tradicionales, y antes de finales de 2033 para navegadores y servidores web, servicios en la nube, sistemas operativos y equipos especializados.
• No imponga todavía certificados poscuánticos en la web pública. Mantenga el intercambio de claves híbrido como prioridad: el tráfico grabado está protegido por el intercambio de claves, de modo que las firmas y los certificados pueden migrar más adelante, según un calendario planificado.
• Pruebe ya la tolerancia al tamaño: las claves públicas y firmas más grandes ponen a prueba los almacenes de certificados, los dispositivos embebidos y los búferes de negociación. Evidencia: un informe de laboratorio por familia de dispositivos.

openssl x509 -in cert.pem -noout -subject -issuer -enddate
openssl x509 -in cert.pem -noout -text | grep -i -E "Signature Algorithm|Public-Key"

Fase 6: supervisión y revisión

• Vuelva a escanear la superficie externa de forma periódica y genere alertas ante cualquier regresión. La sustitución de un balanceador de carga o un cambio de configuración en una CDN pueden eliminar silenciosamente el grupo híbrido. Evidencia: un historial mensual de escaneos por nombre de host.
• Revise las suites de cifrado y los protocolos al menos cada 12 meses. Esa periodicidad es el texto literal del requisito 12.3.3 de PCI DSS v4.0.1, obligatorio desde el 31/03/2025, junto con la supervisión de su viabilidad continuada y una estrategia documentada ante los cambios previstos en las vulnerabilidades criptográficas. Evidencia: el registro firmado de la revisión anual.
• Siga la evolución de los estándares. NIST seleccionó HQC como quinto algoritmo y KEM de respaldo el 11/03/2025, previsto como FIPS 207, sin borrador publicado a septiembre de 2026. NIST IR 8547 y SP 800-131A Rev. 3 siguen siendo borradores públicos iniciales.
• Reporte una sola cifra a la dirección: la proporción de endpoints críticos que negocian un intercambio de claves híbrido. Evidencia: una tendencia trimestral, no una instantánea puntual.

Convierta el checklist en una primera medición

Las fases 2 y 6 necesitan el mismo punto de partida: una visión externa de lo que sus servidores negocian realmente. Puede escanear su dominio con PQC Status de forma gratuita para ver las versiones de TLS, los grupos de intercambio de claves ofrecidos y la cadena de certificados, y conservar la exportación como referencia fechada para el elemento de inventario. Un escaneo describe únicamente la configuración TLS visible desde el exterior: no es una certificación ni una atestación de cumplimiento. El siguiente paso concreto es ejecutarlo sobre sus tres nombres de host más expuestos, archivar los resultados y abrir un ticket por cada nombre de host que todavía no ofrezca un grupo híbrido.