Criptografía poscuántica

Un ordenador cuántico calcula con cúbits, que pueden contener a la vez una combinación de 0 y 1 y enlazarse de modo que sus estados dependan unos de otros. En la mayoría de las tareas no es más rápido que un ordenador corriente. En unos pocos problemas con la estructura matemática adecuada, un algoritmo cuántico hace que las respuestas erróneas se anulen y la correcta destaque, y eso da una aceleración enorme. Las máquinas actuales tienen pocos cúbits y demasiados errores para amenazar el cifrado. Para romperlo haría falta una máquina grande y tolerante a fallos, que corrija sus propios errores, y nadie la ha construido todavía. Para su empresa, la conclusión práctica es concreta: una máquina así rompería la criptografía de clave pública que protege casi todas sus conexiones, por lo que su sustitución debe planificarse antes de que exista.

Porque un ordenador cuántico grande y tolerante a fallos que ejecute el algoritmo de Shor podría romper los métodos de clave pública que se usan hoy para acordar claves y firmar datos: RSA y la criptografía de curva elíptica (ECC). Esos dos protegen el intercambio de claves de casi todas las conexiones HTTPS, VPN y SSH, y las firmas de certificados, actualizaciones de software y documentos. Un atacante con una máquina así podría leer tráfico grabado antes y falsificar firmas. El cifrado simétrico como AES, que cifra los datos una vez acordada la clave, solo se debilita moderadamente con el algoritmo de Grover y sigue siendo útil con claves de 256 bits. Hoy no existe un ordenador así y nadie puede decir en qué año existirá. El riesgo es real para los datos que deben seguir siendo secretos durante muchos años: hay que planificarlo, no es una emergencia. La solución es software, no hardware: nuevos algoritmos que el NIST estandarizó en 2024 y que llegan con las actualizaciones.

Convierte en fáciles los problemas difíciles en los que se basan. RSA es seguro porque nadie sabe descomponer un número muy grande en sus dos factores primos en un tiempo razonable; la criptografía de curva elíptica es segura porque nadie sabe averiguar el número secreto detrás de un punto público de la curva. Peter Shor demostró en 1994 que un ordenador cuántico puede encontrar en ambos problemas un patrón repetitivo oculto, un periodo, y de ese periodo se deduce rápidamente el secreto. En una máquina lo bastante grande, el ataque tarda un tiempo práctico en lugar de uno imposible. Las claves más largas no salvan a RSA ni a ECC: solo hacen el ataque cuántico algo más lento. Por eso la respuesta es matemática nueva, como los problemas de retículos en los que se basan ML-KEM y ML-DSA, para los que no se conoce ningún algoritmo cuántico eficiente. Las estimaciones publicadas de la máquina necesaria siguen muy por encima de todo lo construido hasta ahora.

Mucho menos que el algoritmo de Shor para RSA: debilita el cifrado simétrico y las funciones hash, pero no los rompe. Lov Grover demostró en 1996 que un ordenador cuántico puede recorrer posibilidades en aproximadamente la raíz cuadrada del número habitual de pasos. Aplicado a adivinar una clave, eso reduce más o menos a la mitad su longitud en bits: en teoría, una clave AES de 128 bits se comporta más bien como una de 64. En la práctica, el ataque es una cadena de pasos muy larga que no se puede repartir con provecho entre muchas máquinas, así que incluso AES-128 sigue lejos de ser fácil de romper. El consejo habitual es sencillo: AES-256 para datos que deban seguir siendo secretos mucho tiempo, y SHA-256 o superior para hash. La mayoría de los sistemas modernos ya admiten ambos, por lo que esta parte del cambio suele ser una cuestión de configuración, no un proyecto de migración. El trabajo de verdad está en los métodos de clave pública.

Nadie lo sabe, y quien da un año está adivinando. Una máquina lo bastante grande y estable para ejecutar el algoritmo de Shor contra los tamaños de clave actuales necesita avances en calidad de cúbits, corrección de errores y escala que aún no se han demostrado. Las encuestas a expertos y las hojas de ruta de los fabricantes dan horquillas, no fechas, y las horquillas se mueven. Su planificación, sin embargo, no depende de esa fecha. Los reguladores han fijado sus propios plazos: la hoja de ruta coordinada de la UE del 23 de junio de 2025 pide migrar los casos de uso de alto riesgo antes de que acabe 2030, y la guía de transición del NIST (NIST IR 8547, borrador de noviembre de 2024, versión final de octubre de 2026) declara obsoletos después de 2030 los métodos de clave pública vulnerables a la computación cuántica, como RSA y la criptografía de curva elíptica, y los prohíbe en las normas del NIST después de 2035. Clientes, auditores y licitaciones preguntarán por esas fechas mucho antes de que exista un ordenador cuántico. Para datos que deban seguir siendo secretos una década o más, la desigualdad de Mosca muestra por qué esperar a esa fecha es una mala estrategia.

La criptografía poscuántica (PQC) es criptografía de clave pública diseñada para seguir siendo segura frente a un gran ordenador cuántico y que funciona en ordenadores normales. El NIST publicó las primeras normas el 13 de agosto de 2024: FIPS 203 (ML-KEM) para establecer claves, y FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) para firmas digitales. Se basan en problemas matemáticos, como encontrar vectores cortos en retículos de muchas dimensiones, o en la seguridad de las funciones hash, para los que no se conoce ningún ataque cuántico eficiente. Migrar significa actualizar software, bibliotecas, protocolos y certificados, no comprar hardware cuántico. Tampoco es lo mismo que la distribución cuántica de claves, que necesita equipos ópticos especiales. El precio del cambio es el tamaño: las claves y firmas poscuánticas son mayores que las actuales, los handshakes crecen y algunos equipos antiguos tienen problemas. La mayoría de las organizaciones se encuentra primero con la PQC en las actualizaciones de navegadores, sistemas operativos y software de VPN, y después tiene que ocuparse de sus propios servidores y aplicaciones.

Son las tres primeras normas poscuánticas del Instituto Nacional de Estándares y Tecnología de EE. UU. (NIST), publicadas el 13 de agosto de 2024 tras un concurso abierto e internacional que empezó en 2016. FIPS 203 especifica ML-KEM, un mecanismo de encapsulación de claves con el que dos partes acuerdan una clave secreta común; asume el papel que hoy tienen RSA y Diffie-Hellman de curva elíptica en el intercambio de claves. FIPS 204 especifica ML-DSA, el esquema principal de firma digital. FIPS 205 especifica SLH-DSA, un esquema de firma más lento y con firmas más grandes que solo se basa en funciones hash y se mantiene como alternativa conservadora. Aunque son normas federales estadounidenses, son la referencia en todo el mundo: agencias europeas como la BSI alemana y la ANSSI francesa recomiendan, entre otros, estos algoritmos, normalmente combinados con uno clásico. Para usted son los nombres que conviene buscar en la documentación de los proveedores, sus hojas de ruta y las respuestas a licitaciones.

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, FIPS 203) es el método poscuántico para acordar una clave secreta a través de una red abierta, y el primero con el que se encontrará. Procede de la propuesta CRYSTALS-Kyber. Una parte publica una clave pública; la otra la usa para envolver un secreto aleatorio nuevo que solo el titular de la clave privada puede desenvolver. Ese secreto sirve luego de clave para un cifrado simétrico rápido como AES. Hay tres tamaños, ML-KEM-512, ML-KEM-768 y ML-KEM-1024, y 768 es la opción habitual. Es rápido, a menudo comparable a las curvas elípticas, pero su clave pública y su texto cifrado ocupan alrededor de un kilobyte cada uno, frente a 32 bytes en X25519. Ese tamaño explica por qué algunos cortafuegos y dispositivos intermedios antiguos tienen problemas con los handshakes poscuánticos. En TLS, ML-KEM suele aparecer combinado con X25519 como el grupo híbrido X25519MLKEM768, que la mayoría de los navegadores ya ofrece.

Son las dos normas de firma poscuántica: ML-DSA (FIPS 204, de CRYSTALS-Dilithium) y SLH-DSA (FIPS 205, de SPHINCS+). Una firma digital demuestra quién produjo unos datos y que nadie los cambió; protege certificados, actualizaciones de software, firmware, documentos y código. ML-DSA es la opción de uso general: rápida, con firmas de unos pocos kilobytes en lugar de los 64 bytes de una firma ECDSA típica. SLH-DSA se basa solo en la seguridad de las funciones hash, lo que la hace muy conservadora, a costa de firmas más grandes y una firma más lenta; encaja en raíces de confianza de larga vida y en la firma de firmware. Las firmas importan menos para «harvest now, decrypt later», porque una firma falsificada solo ayuda a un atacante cuando ya existe un ordenador cuántico. Por eso la mayoría de las organizaciones cambia primero el intercambio de claves y después las firmas. El ecosistema de certificados con firma poscuántica aún se está construyendo, así que pregunte a sus proveedores por sus planes en lugar de esperar certificados poscuánticos hoy.

Son los siguientes algoritmos poscuánticos en el camino del NIST, todavía no normas definitivas. HQC (Hamming Quasi-Cyclic) es un método de encapsulación de claves que el NIST seleccionó en marzo de 2025 como respaldo de ML-KEM. Se basa en códigos correctores de errores en lugar de retículos, de modo que si algún día se encontrara una debilidad en los problemas de retículos, habría preparado un algoritmo de otra familia matemática. El NIST anunció entonces un borrador de norma aproximadamente un año después y la norma definitiva en 2027. FN-DSA, basado en la propuesta FALCON, es un esquema de firma previsto como FIPS 206; sus firmas son mucho más pequeñas que las de ML-DSA, lo que ayuda donde falta espacio, pero es más difícil de implementar de forma segura. La lección para su planificación: no apueste para siempre por un solo algoritmo. Elija productos que puedan cambiar de algoritmo mediante configuración o actualizaciones. Esa capacidad, llamada agilidad criptográfica, le protege si una norma cambia o aparece un fallo de implementación.

El intercambio de claves híbrido combina en el mismo handshake TLS un método clásico (X25519, un intercambio de curva elíptica) con uno poscuántico (ML-KEM-768) y deriva la clave de sesión de ambos. La clave sigue siendo secreta mientras uno de los dos resista: si se encontrara un fallo en el todavía joven ML-KEM, X25519 seguiría frenando a los atacantes de hoy; frente a un futuro ordenador cuántico, lo haría ML-KEM. Por eso la mayoría de las guías, también las de agencias europeas como BSI y ANSSI, prefieren el modo híbrido durante la transición. X25519MLKEM768 es el nombre de esta combinación en TLS. Los principales navegadores ya la ofrecen por defecto y grandes redes de distribución de contenidos y muchos servicios en la nube la aceptan, así que parte de su tráfico web puede estar usándola ya sin que usted haya cambiado nada. Una conexión que la usa hace que el tráfico grabado sea mucho más difícil de descifrar después. Las que hay que planificar son las conexiones que siguen usando solo intercambio de claves clásico: servidores antiguos, appliances, VPN y aplicaciones internas.

Para casi cualquier empresa, no. La distribución cuántica de claves (QKD) usa la física de fotones individuales, enviados por fibra dedicada o por enlaces en espacio libre, para acordar una clave de un modo que revela las escuchas. Necesita hardware especial en ambos extremos, funciona a distancias limitadas salvo que se añadan estaciones repetidoras de confianza y no autentica por sí misma a las dos partes, así que sigue necesitando firmas clásicas o poscuánticas. La criptografía poscuántica, en cambio, es software que funciona en las redes y los equipos que ya tiene. Agencias europeas de seguridad, entre ellas la BSI alemana, la ANSSI francesa y la NLNCSA neerlandesa, han publicado una posición conjunta que considera la criptografía poscuántica la vía principal y la QKD, como mucho, adecuada para usos de nicho. La infraestructura europea de comunicación cuántica, EuroQCI, atiende necesidades gubernamentales concretas y es un asunto distinto de lo que debería comprar una mediana empresa. Si un proveedor le ofrece QKD como respuesta a «harvest now, decrypt later» para una red de oficina normal, pregunte qué hace que no haga una configuración TLS o VPN híbrida.

Significa que un atacante graba hoy tráfico cifrado y lo guarda para descifrarlo cuando exista un ordenador cuántico capaz. Grabar es barato e invisible para usted: puede ocurrir en un punto de intercambio de internet, en un router comprometido o en un proveedor, lejos de su red. Solo corre riesgo el tráfico cuyo intercambio de claves es vulnerable a la computación cuántica, y solo los datos que sigan importando cuando se descifren. Historias clínicas, diseños, código fuente, contratos a largo plazo, expedientes jurídicos y datos personales que se conservan muchos años son ejemplos típicos; el calendario de entregas de esta semana no lo es. Una forma habitual de valorarlo es la desigualdad de Mosca: si los años que los datos deben seguir siendo secretos más los años que dura su migración superan los años que faltan para un ordenador así, el momento de empezar es ahora. La respuesta práctica es llevar primero a métodos poscuánticos híbridos el intercambio de claves que protege los datos de larga vida, porque ahí es donde las grabaciones de hoy se convertirían en las filtraciones de mañana. Las firmas pueden venir después.

Los datos que hoy cruzan una red y deben seguir siendo confidenciales después de la llegada de un gran ordenador cuántico. Hágase dos preguntas sobre cada conjunto de datos: ¿viaja por una conexión con un intercambio de claves vulnerable a la computación cuántica?, ¿y durante cuántos años seguiría haciendo daño su divulgación? Ejemplos típicos de larga vida son historias clínicas y expedientes de RR. HH., diseños de producto y código fuente, documentación de fusiones y asuntos legales, contratos con el sector público, datos biométricos y credenciales que nunca se cambian. Los datos de vida corta, como un código de un solo uso o los precios de este mes, no merecen preocupación. Los datos almacenados son otra cuestión: suelen estar protegidos con cifrado simétrico como AES, que un ordenador cuántico no rompe, salvo que sus claves se intercambien o envuelvan con RSA. Ponga la lista por escrito con un responsable y un plazo de conservación por elemento: se convierte en el orden de prioridad de su migración y en la base del cálculo de Mosca. Un sensor de red no puede clasificar sus datos; esa lista sale del negocio.

Ponga tres números uno al lado del otro para cada conjunto de datos o sistema importante. X es cuántos años deben seguir siendo secretos los datos. Y es cuántos años le llevará pasar ese sistema a criptografía poscuántica, incluidos proveedores, pruebas y ciclos presupuestarios. Z es cuántos años faltan para que un ordenador cuántico pueda romper la criptografía de clave pública actual. Si X más Y es mayor que Z, los datos enviados hoy ya están expuestos a «harvest now, decrypt later». Michele Mosca describió la desigualdad en 2015, en un trabajo publicado como IACR ePrint 2015/1075. Z es desconocido, así que no finja conocerlo: pruebe un valor prudente y otro relajado y vea qué sistemas fallan incluso con el relajado. Por ejemplo, unos contratos que deben ser confidenciales 10 años, en un sistema cuya migración requiere 5 años, fallan con cualquier Z inferior a 15 años. El resultado es una lista de prioridades, no un pronóstico, y un razonamiento que un auditor o un consejo pueden seguir.

La amenaza no lo es, pero buena parte del marketing que la rodea sí. Los hechos son sólidos: el NIST publicó normas definitivas en agosto de 2024, los navegadores y los grandes proveedores de nube ya usan intercambio de claves poscuántico híbrido y la UE tiene una hoja de ruta coordinada con fechas. Lo incierto es cuándo existirá un ordenador cuántico capaz, y esa incertidumbre es justo la razón por la que planificar es mejor que esperar: cambiar la criptografía de toda una empresa lleva años. La moda está en productos que prometen inmunidad frente a ataques cuánticos, en relojes de cuenta atrás y en la presión para comprar hardware que no necesita. Una postura sensata para la mayoría de las medianas empresas: ningún gasto de urgencia, pero un inventario este año, preguntas poscuánticas en cada compra nueva, actualizaciones que activen el intercambio híbrido donde los proveedores lo ofrezcan y prioridad para los datos que deben seguir siendo secretos mucho tiempo. Cuesta poco y evita una migración precipitada y cara más adelante.

Sí, como asunto de planificación y riesgo, no como crisis. Tiene sitio en el orden del día de la dirección por tres razones. Es un cambio largo y transversal que afecta durante varios años a proveedores, productos y presupuestos, y solo la dirección puede ordenarlo. Afecta a datos que la empresa se ha comprometido a proteger durante muchos años, como los de clientes, pacientes o diseños. Y clientes, aseguradoras y licitaciones públicas empiezan a preguntar por ello, así que la respuesta se convierte en un asunto comercial. Según NIS2, los órganos de dirección de las entidades afectadas deben aprobar las medidas de gestión de riesgos de ciberseguridad y supervisar su aplicación, y una política de criptografía es una de ellas. Lo que la dirección necesita es breve: un inventario de dónde se usa criptografía vulnerable a la computación cuántica, una lista de prioridades según cuánto tiempo deben seguir secretos los datos, un responsable designado y un calendario alineado con los hitos europeos de 2030 y 2035. No necesita una charla técnica sobre cúbits.

La Recomendación (UE) 2024/1101 de la Comisión, de 11 de abril de 2024, pidió a los Estados miembros que coordinaran la transición, y el Grupo de Cooperación NIS publicó el 23 de junio de 2025 una hoja de ruta coordinada: iniciar la transición, proteger los casos de uso de alto riesgo antes de que termine 2030 y migrar tantos sistemas como sea factible antes de 2035. Es una hoja de ruta para los Estados miembros, no una ley que obligue directamente a su empresa; las autoridades nacionales pueden convertirla en guías o normas. Su primer paso práctico es saber dónde usa criptografía.

Que la transición haya empezado en todas partes. La hoja de ruta coordinada que publicó el Grupo de Cooperación NIS el 23 de junio de 2025, tras la Recomendación (UE) 2024/1101 de la Comisión, fija tres etapas: primeros pasos antes de que acabe 2026, migración de los casos de uso de alto riesgo antes de que acabe 2030 y de tantos sistemas como sea posible para 2035. La primera etapa trata de preparación: los Estados miembros fijan planes nacionales de transición, las organizaciones empiezan a inventariar dónde usan criptografía vulnerable a la computación cuántica y se evalúa el riesgo de cada uso para poder pilotar pronto los casos de alto riesgo. La hoja de ruta se dirige a los Estados miembros y a sus sectores público y crítico, no directamente a su empresa, y las autoridades nacionales la traducirán en sus propias guías. Aun así, su lógica sirve para cualquier organización: para finales de 2026, sepa dónde está su criptografía, quién es responsable de cada sistema y cuáles deben migrar primero. Siga lo que publique su autoridad nacional de ciberseguridad.

No por su nombre, pero ambas apuntan en esa dirección. NIS2, la Directiva (UE) 2022/2555, exige a las entidades afectadas políticas y procedimientos sobre el uso de la criptografía y, en su caso, del cifrado, dentro de las medidas de gestión de riesgos de ciberseguridad del artículo 21. El Reglamento de Ciberresiliencia (CRA), Reglamento (UE) 2024/2847, exige que los productos con elementos digitales protejan la confidencialidad de los datos con mecanismos acordes con el estado de la técnica, entre los requisitos esenciales de su anexo I. Ninguno nombra un algoritmo. Pero el estado de la técnica avanza: cuando las normas del NIST, las guías de las agencias europeas y la hoja de ruta de la UE tratan el intercambio de claves poscuántico híbrido como lo normal, un producto o una política que lo ignora es más difícil de defender en una auditoría o una licitación. La propia hoja de ruta de la UE presenta la transición poscuántica como un paso sin arrepentimiento que apoya NIS2 y la CRA. Consulte la transposición nacional de NIS2 y las guías de su autoridad nacional, porque los detalles pueden variar según el país.

Sobre todo cosas corrientes y baratas. Primero, mantenga al día navegadores, sistemas operativos, clientes VPN, servidores y bibliotecas: gran parte del cambio poscuántico llega con las actualizaciones, y los navegadores modernos ya usan por defecto el intercambio de claves híbrido. Segundo, haga una lista de dónde usa criptografía que controla usted: su web y su alojamiento, el acceso remoto, el correo, el intercambio de ficheros con clientes y cualquier equipo con certificados propios. Tercero, marque los datos que deben seguir siendo secretos muchos años. Cuarto, añada una pregunta a cada compra o renovación de contrato: ¿admite el producto intercambio de claves poscuántico híbrido y, si no, cuándo? Quinto, prefiera proveedores que puedan cambiar de algoritmo mediante actualizaciones. Comprar productos cuánticos especiales no está en la lista. NetSenX puede ayudar en el segundo paso: NQCI, en versión preview, es visible en todos los planes y está activo desde el plan Pro, y necesita el sensor de captura de paquetes, desactivado por defecto, activado en un agente Linux o como sensor SPAN/TAP; el modo básico en macOS no ve los handshakes.

Años en la mayoría de las organizaciones, y por eso empezar pronto importa más que la fecha exacta. El cambio afecta a todos los puntos donde se acuerdan claves o se firman datos: webs, VPN, SSH, correo, aplicaciones internas, certificados, módulos de seguridad hardware (HSM), tarjetas inteligentes, máquinas y su firmware. Mucho depende de cuándo entreguen los proveedores soporte poscuántico y de sus propios ciclos de renovación: un cortafuegos comprado este año puede seguir funcionando la próxima década, y un controlador industrial mucho más. Los cambios anteriores dan una idea de la escala: retirar SHA-1 y las versiones antiguas de TLS le costó al sector muchos años desde los primeros avisos hasta el apagado definitivo. Una pequeña empresa que usa sobre todo servicios en la nube y software actualizado puede recorrer buena parte del camino con actualizaciones normales, dentro de un ciclo de renovación habitual. Una empresa con software propio, equipos de larga vida o su propia autoridad de certificación debe esperar un programa repartido en varios años. La Y de la desigualdad de Mosca es su propia estimación, así que anótela con sus motivos.

Protege el tráfico de hoy frente al descifrado de mañana y obtiene varias ventajas que no dependen en absoluto de los ordenadores cuánticos. Los datos de larga vida dejan de estar expuestos a «harvest now, decrypt later» en cuanto su intercambio de claves pasa a un método híbrido. El inventario que construye por el camino descubre versiones antiguas de TLS, cifrados débiles, certificados caducados u olvidados y servidores sin gestionar, que ya son riesgos hoy. La agilidad criptográfica, la capacidad de cambiar de algoritmo mediante configuración, abarata el siguiente cambio forzoso, sea cual sea su causa. Comercialmente, puede responder a licitaciones y clientes con hechos y fechas en lugar de un hueco, y estará preparado cuando las autoridades nacionales conviertan la hoja de ruta de la UE en guías. Hecha dentro de los ciclos normales de renovación, la migración cuesta mucho menos que una hecha con prisas. Lo que no gana es inmunidad: la criptografía poscuántica protege el intercambio de claves y las firmas, no las contraseñas robadas, el phishing ni los sistemas sin parchear.

Sobre todo la compatibilidad y el rendimiento, rara vez las matemáticas. Las claves poscuánticas son más grandes, así que un ClientHello de TLS con X25519MLKEM768 ya no cabe en un solo paquete de red; algunos cortafuegos, balanceadores de carga y sistemas de prevención de intrusiones antiguos lo gestionan mal y descartan o reinician la conexión. Los módulos de seguridad hardware, las tarjetas inteligentes y los dispositivos embebidos pueden no tener memoria o firmware para los nuevos algoritmos. Las firmas de varios kilobytes agrandan las cadenas de certificados y ralentizan los enlaces limitados. Las implementaciones jóvenes pueden tener errores, una razón más para usar métodos híbridos y bibliotecas bien mantenidas. Los proxies de interceptación que descifran TLS pueden no admitir los nuevos grupos y devolver en silencio las conexiones al intercambio de claves clásico. Planifíquelo: pruebe con tráfico real en un segmento de pruebas, mantenga la alternativa clásica durante la transición, compruebe que los equipos intermedios estén actualizados y mida después qué conexiones usan de verdad el intercambio híbrido. Ver los handshakes en la red revela regresiones que los ficheros de configuración no muestran.

La agilidad criptográfica es la capacidad de cambiar los algoritmos criptográficos que usa un sistema sin reescribirlo ni sustituirlo. En la práctica significa que los algoritmos se eligen por configuración y no están fijados en el código; el software usa bibliotecas mantenidas que reciben nuevos algoritmos con las actualizaciones; certificados y claves se gestionan de forma centralizada, con responsables y fechas de caducidad conocidos; y usted sabe dónde se usa cada algoritmo. Importa ahora porque la transición poscuántica no será la última: HQC y FN-DSA aún están por llegar, los parámetros pueden revisarse y puede aparecer un fallo en una implementación joven. Una organización que hace una migración manual y dolorosa sufrirá lo mismo la próxima vez; la que construye agilidad convierte el siguiente cambio en una publicación de configuración. Pregúntelo en cada compra: ¿puede el producto cambiar sus algoritmos de intercambio de claves y de firma mediante actualización o ajuste, y se compromete el proveedor a hacerlo? Un producto que no puede es un problema de migración que está comprando hoy.

Cada vez más, sí, pero hay que comprobar cada producto. OpenSSH convirtió un intercambio de claves poscuántico híbrido en su opción por defecto en la versión 9.0, en 2022, y la versión 10.0, de 2025, puso por defecto el híbrido basado en ML-KEM, mlkem768x25519-sha256; si ambos extremos usan versiones actuales, sus sesiones SSH probablemente ya lo emplean. En las VPN el panorama varía. El intercambio de claves de IPsec, IKEv2, obtuvo con la RFC 9370 una forma estándar de añadir intercambios adicionales, como ML-KEM; algunos fabricantes y proyectos de código abierto lo admiten y otros solo lo han anunciado. WireGuard puede añadir una clave simétrica precompartida como capa de protección poscuántica, pero su handshake sigue siendo clásico. Revise las notas de versión del firmware de su cortafuegos o pasarela VPN y las versiones de cliente que se usan de verdad, y recuerde que un servidor antiguo en un extremo mantiene clásica toda la conexión. Las VPN de acceso remoto y entre sedes transportan muchos datos de larga vida, así que merecen un puesto alto en su orden de migración.

Empiece por un inventario: certificados, VPN, TLS en sus servidores, SSH, firma de código y las bibliotecas que usan sus aplicaciones. El tráfico de red muestra gran parte, porque el intercambio de claves de cada conexión TLS es visible sin descifrar. NQCI, el inventario criptográfico de NetSenX (en versión preview), es visible en todos los planes y está activo desde el plan Pro: muestra qué conexiones usan un intercambio de claves vulnerable a la computación cuántica y cuáles un intercambio híbrido poscuántico. Necesita el sensor de captura de paquetes, desactivado por defecto: activado en un agente Linux o como sensor en un puerto SPAN o TAP. El modo básico del agente, el que se usa en macOS, no ve los handshakes TLS. Aporta visibilidad; la migración en sí sigue siendo cosa suya y de sus proveedores.

Una gran parte, sí, pero no todo. Cada conexión TLS anuncia, antes de que empiece el cifrado, qué grupos de intercambio de claves ofrece el cliente y cuál elige el servidor, además de la versión de TLS; SSH funciona de forma parecida. Un sensor que ve esos handshakes puede listar, por servidor y por cliente, dónde se sigue usando intercambio de claves vulnerable a la computación cuántica y dónde ya se usa intercambio poscuántico híbrido, para cada equipo del segmento, incluidas impresoras, appliances y máquinas que no admiten agente. Lo que no ve: la criptografía dentro de aplicaciones y bases de datos, claves y certificados guardados en disco, la firma de código, las copias de seguridad cifradas, los segmentos no supervisados y las conexiones cuyo handshake nunca pasa por el sensor. NQCI, el inventario criptográfico de NetSenX (en versión preview), es visible en todos los planes y está activo desde el plan Pro; necesita el sensor de captura de paquetes, desactivado por defecto, activado en un agente Linux o como sensor en un puerto SPAN o TAP. El modo básico en macOS no ve los handshakes. Combínelo con un inventario de certificados y cuestionarios a proveedores.

Mire el grupo de intercambio de claves elegido en cada handshake TLS: X25519MLKEM768 significa híbrido poscuántico; X25519, secp256r1 o un intercambio de claves RSA significan solo clásico. Un servidor concreto puede probarlo desde fuera: OpenSSL 3.5 y posteriores, y herramientas basadas en él como curl, pueden ofrecer el grupo híbrido y mostrar lo que elige el servidor, y algunos comprobadores TLS en línea lo indican. Las herramientas de desarrollo del navegador también muestran el grupo negociado con un sitio que visita. Para toda la red, una prueba puntual no basta, porque lo que cuenta es lo que pasa de verdad cada día entre sus clientes y servidores: clientes antiguos, appliances y aplicaciones internas vuelven a menudo a grupos clásicos. NQCI, en versión preview, lo muestra por conexión en el tráfico supervisado. Es visible en todos los planes y está activo desde el plan Pro, con el sensor de captura de paquetes activado en un agente Linux o como sensor SPAN o TAP, porque el modo básico en macOS no ve los handshakes. El resultado muestra dónde las actualizaciones ya hicieron la migración y dónde falta hacerla.

Para cada lugar donde la criptografía protege algo, anote qué se protege, cómo y quién puede cambiarlo. Campos prácticos: el sistema o servicio y su responsable; qué protege, con el tipo de datos y cuántos años deben seguir siendo secretos; el protocolo, como TLS, SSH, IPsec, S/MIME, firma de código o cifrado de discos y bases de datos; los algoritmos de intercambio de claves, firma y cifrado, con tamaños de clave; los certificados, su emisor y su caducidad; la versión de la biblioteca o del producto y si el proveedor tiene un plan poscuántico; y si el algoritmo puede cambiarse mediante configuración. Añada una prioridad derivada de la desigualdad de Mosca. Las fuentes varían según la capa: observación de la red para lo que pasa por el cable, gestión de certificados y escáneres para los certificados, análisis de composición de software y cuestionarios a proveedores para lo que hay dentro de las aplicaciones. Un inventario que solo lista certificados se olvida del intercambio de claves, y uno construido solo desde la red se olvida de los datos almacenados. Manténgalo al día, porque cada actualización puede cambiar la respuesta, y feche cada entrada: auditores y licitaciones preguntan cuándo se revisó por última vez.

No, y ningún producto de supervisión de red puede hacerlo. La protección frente a un futuro ordenador cuántico llega cambiando la criptografía de sus propios sistemas y de los de sus proveedores: primero el intercambio de claves híbrido, después las firmas poscuánticas. NetSenX no es un producto de cifrado y no cambia, actualiza ni migra nada. Lo que le da es visibilidad, que es donde empieza toda migración. NQCI, el inventario criptográfico de NetSenX, está en versión preview: visible en todos los planes y activo desde el plan Pro. Muestra qué conexiones del tráfico supervisado siguen usando intercambio de claves vulnerable a la computación cuántica y cuáles ya usan intercambio poscuántico híbrido, de modo que ve dónde las actualizaciones ya han hecho el trabajo y dónde no, y detecta después las regresiones. Necesita el sensor de captura de paquetes, desactivado por defecto: activado en un agente Linux o como sensor en un puerto SPAN o TAP; el modo básico en macOS no ve los handshakes. No ve la criptografía dentro de las aplicaciones, en los discos ni en segmentos que ningún sensor vigila.

Con hechos sobre su plan, no con eslóganes. Los evaluadores suelen buscar cuatro cosas: que sabe dónde usa criptografía vulnerable a la computación cuántica, que ha fijado prioridades, que tiene un calendario y que alguien es responsable. Una respuesta sólida menciona el inventario y su fecha; el método de priorización, por ejemplo la desigualdad de Mosca aplicada a los plazos de conservación; los pasos ya dados, como el intercambio de claves híbrido activado en los servicios públicos y las versiones de VPN y SSH revisadas; las dependencias de proveedores, con sus planes declarados; e hitos alineados con la hoja de ruta coordinada de la UE: primeros pasos antes de finales de 2026 y casos de uso de alto riesgo antes de finales de 2030. Cite por su nombre las normas del NIST FIPS 203, 204 y 205. No afirme que su servicio es inmune a los ataques cuánticos; un evaluador informado le restará puntos. Si su inventario procede en parte de la observación de la red, dígalo y diga qué no cubre. Una respuesta honesta y parcial con fechas puntúa mejor que un hueco lleno de aplomo.

Haga preguntas con respuestas verificables. ¿Qué algoritmos poscuánticos o híbridos admite hoy el producto, por su nombre, como X25519MLKEM768 para TLS o ML-DSA para firmas, y desde qué versión? Si todavía ninguno, ¿en qué versión y para cuándo? ¿Se pueden cambiar los algoritmos mediante configuración o actualización, sin sustituir hardware? ¿Qué biblioteca criptográfica usa el producto y quién la mantiene? ¿Tiene el hardware, como un cortafuegos, un módulo de seguridad hardware o un controlador, capacidad para claves más grandes, o habrá que sustituirlo? ¿Cómo firmará el proveedor sus propias actualizaciones cuando cambien los algoritmos de firma? ¿Seguirá funcionando el producto durante la transición con clientes que solo admiten algoritmos clásicos? Pida las respuestas por escrito y con fechas. Desconfíe de las respuestas que prometen inmunidad frente a ataques cuánticos o que solo hablan de cifrado simétrico: esquivan la pregunta de verdad. Un proveedor que no sabe responder es una dependencia que hay que tener en cuenta en el plan, y su respuesta va a su inventario.