Descubrir no es proteger

Resumen ejecutivo

La pregunta que enfrentan las empresas sobre la criptografía poscuántica (PQC) ya no es si migrar, ni hacia qué algoritmos. NIST publicó sus tres primeros estándares poscuánticos en agosto de 2024 ^[1][2][3]. En octubre de 2026 publicó la versión final de su plan de transición: los algoritmos de clave pública vulnerables a la computación cuántica quedarán obsoletos después de 2030 y prohibidos después de 2035 bajo los estándares y las guías de NIST ^[4]. La pregunta abierta es cómo organizar una transformación que toca casi todos los sistemas que opera una organización.

Este documento plantea dos argumentos. El primero se refiere a dónde está el trabajo. Describimos el panorama de la transformación PQC empresarial (Enterprise PQC Transformation Landscape): cuatro dominios donde vive la criptografía, dos capas que los atraviesan a todos y las categorías de soluciones que atienden cada parte. Ningún proveedor ni producto cubre el mapa completo, y una gran parte de él solo cambia cuando la propia organización lo cambia.

El segundo argumento se refiere a cómo abordar el trabajo. La mayoría de los programas de PQC se organizan como una secuencia: descubrir, evaluar, planificar y luego transformar. El descubrimiento (discovery) es indispensable, y todos los planes de transición citados en este documento comienzan por ahí. Pero el descubrimiento no protege nada. Una organización puede identificar todos los activos vulnerables que posee y aun así dejarlos todos expuestos. Ante los ataques de tipo cosechar ahora, descifrar después (harvest now, decrypt later, HNDL), esa brecha tiene un costo, porque los datos capturados durante la fase de descubrimiento no pueden recuperarse cuando la protección mejore más adelante.

Usted puede descubrir el 100% de sus vulnerabilidades criptográficas y seguir teniendo el 100% de ellas expuestas.

De estos argumentos derivamos un modelo de ejecución con cinco elementos:

1. Mapear el panorama. Entender qué dominios, capas y responsables toca la transición, y qué partes modernizarán los proveedores frente a cuáles debe cambiar la propia organización.
2. Separar el conocimiento de la protección. Tratar el descubrimiento como fuente de conocimiento, no como evidencia de reducción del riesgo.
3. Descubrir y transformar en paralelo. Empezar a mitigar la exposición conocida y bien caracterizada mientras el descubrimiento continúa, de modo que cada motor alimente al otro.
4. Medir la protección. Reportar la exposición efectivamente eliminada, no solo los activos catalogados.
5. Construir para la criptoagilidad. Hacer que esta migración sea la última que deba ejecutarse como una crisis.

El panorama también revela una brecha. Ninguna de las categorías de soluciones, por sí sola, opera la criptografía para las aplicaciones como un único servicio gobernado que abarque claves, algoritmos y motores, ni vuelve a proteger lo que ya está cifrado. El capítulo 4 describe esa brecha; el capítulo 11 describe cómo la aborda ANKATech.

Este documento es complementario del whitepaper The Cryptographic Control Plane, que presenta el marco CAPA (Crypto Agility Posture Architecture) ^[5], y de Crypto agility beyond the quantum clock, que desarrolla el primer pilar de CAPA ^[6]. Mientras ese documento pregunta cuán costoso será el próximo cambio criptográfico, este plantea una pregunta más inmediata: cuánta de la exposición actual se está eliminando realmente.

Cómo leer la evidencia en este documento

Cada afirmación de este documento pertenece a una de cinco categorías, y el texto indica a cuál. Las citas entre corchetes remiten a las referencias al final del documento.

Las fuentes citadas están en inglés. Las citas textuales se presentan en traducción propia; el texto original puede consultarse en las referencias.

Nunca atribuimos nuestras interpretaciones a las instituciones que citamos. NIST, el NCSC y la UE recomiendan comenzar con un inventario criptográfico ^[4][7][8]. El NCSC describe sus fases como interrelacionadas y NIST menciona los despliegues tempranos junto al inventario, pero ninguno propone ejecutar el descubrimiento y la transformación como dos motores paralelos, ni reportar las métricas de protección por separado de las métricas de descubrimiento. Esas son nuestras conclusiones, y este documento explica por qué consideramos que la evidencia las respalda.

La conversación está fragmentada, el problema no

La PQC ha pasado de la investigación a la regulación más rápido de lo que la mayoría de las organizaciones han pasado de la concientización a la ejecución. Los estándares y el calendario ya están definidos. Lo que aún falta es una visión compartida del trabajo.

2.1 Los plazos están fijados

NIST publicó FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) en agosto de 2024 ^[1][2][3]. El 27 de octubre de 2026 publicó la versión final de NIST IR 8547, que establece que NIST declarará obsoleta toda la criptografía vulnerable a la computación cuántica después de 2030 y prohibirá su uso bajo sus estándares y guías después de 2035 ^[4]. El mismo informe registra que, en virtud de la Orden Ejecutiva 14412 y del Memorando M-26-15 de la OMB, las agencias federales de Estados Unidos deben migrar sus activos de alto valor y sus sistemas de alto impacto al establecimiento de claves poscuántico a más tardar el 31 de diciembre de 2030 y a las firmas poscuánticas a más tardar el 31 de diciembre de 2031 ^[4].

Fuera de Estados Unidos, los hitos convergen. El NCSC del Reino Unido pide a las organizaciones, en particular a las grandes organizaciones y a los operadores de infraestructura nacional crítica, definir sus objetivos de migración, completar el descubrimiento y elaborar un plan inicial para 2028, ejecutar sus actividades de migración de mayor prioridad para 2031 y completar la migración para 2035 ^[7]. La hoja de ruta coordinada europea espera que cada Estado miembro haya implementado sus primeros pasos a finales de 2026, y que los casos de uso de alto riesgo se migren lo antes posible y a más tardar a finales de 2030 ^[8].

NIST también recuerda a las organizaciones cuánto tarda este tipo de cambio: el recorrido desde la estandarización de un algoritmo hasta su plena integración en los sistemas de información puede tomar de 10 a 20 años ^[4].

2.2 Cada proveedor plantea el problema según lo que vende

Buena parte de la conversación del mercado está moldeada por las capacidades que cada proveedor comercializa:

• Los proveedores de descubrimiento plantean la PQC como un problema de inventario: encontrar los algoritmos, construir la lista de materiales criptográficos (CBOM) y calificar el riesgo.
• Los proveedores de red la plantean como una actualización de protocolos: TLS híbrido, VPN resistentes a la computación cuántica, gateways actualizados.
• Los proveedores de HSM, KMS y nube la plantean como una capacidad de plataforma: nuevos algoritmos en el almacén de claves o en el servicio gestionado.
• Los proveedores de PKI la plantean como un problema del ciclo de vida de los certificados.

Cada uno de estos es una parte real del trabajo. Ninguno es la totalidad. Una organización que adopta el enfoque de un proveedor puede avanzar genuinamente en su parte del mapa mientras grandes áreas de exposición permanecen intactas, y mientras sus reportes sugieren que el programa va por buen camino.

El enfoque que la conversación deja por fuera es el control: ¿quién gobierna y opera la criptografía a través de todos ellos, y quién vuelve a proteger lo que ya está cifrado? El capítulo 4 retoma esta pregunta.

2.3 Dos preguntas: dónde y cómo

Este documento ofrece una respuesta neutral frente a los proveedores a dos preguntas. Los capítulos 3 y 4 responden dónde: dónde vive la criptografía en una empresa, qué debe cambiar en cada lugar y qué categorías de soluciones atienden cada parte. Los capítulos 5 a 9 responden cómo: cómo ejecutar la transformación para que reduzca la exposición desde temprano, en lugar de limitarse a describirla bien.

La PQC no es una única actualización tecnológica. Es una transformación empresarial que debe cambiar la criptografía en varios lugares a la vez, bajo distintos responsables.

El panorama: dónde vive la criptografía

El panorama de la transformación PQC empresarial organiza el trabajo en cuatro dominios de transformación y dos capas transversales. Los dominios son lugares donde se usa la criptografía. Las capas son capacidades de las que depende cada dominio. La distinción importa porque los responsables, las intervenciones y el ritmo del cambio son diferentes en cada caso.

3.1 Cuatro dominios de transformación

Red y transporte. TLS, VPN, IPsec, gateways, balanceadores de carga, proxies, enlaces entre servicios y mensajería empresarial. Aquí es donde los proveedores de red están incorporando intercambio de claves híbrido y poscuántico mediante actualizaciones de software, firmware y configuración, y donde NIST establece una prioridad temprana: TLS protege los datos en tránsito de casi todos los sistemas y servicios federales, y NIST recomienda ML-KEM-768 como conjunto de parámetros predeterminado para el establecimiento de claves ^[4]. El beneficio de las actualizaciones de los proveedores es real, pero la adopción depende de ambos extremos, de la interoperabilidad y de la configuración. Una organización se beneficia de la hoja de ruta de sus proveedores; no debe suponer que esa hoja de ruta moderniza toda su infraestructura.

Plataformas y almacenamiento. Bases de datos, sistemas de almacenamiento, servicios en la nube y plataformas empresariales. El cifrado simétrico, en gran medida, no es el problema: NIST no prevé tener que abandonar sus estándares simétricos aprobados como parte de la migración a PQC ^[4]. Lo que debe examinarse es todo lo que rodea a la clave simétrica: cómo se genera, envuelve, distribuye, protege y recupera, y qué mecanismos de clave pública usa la plataforma para el intercambio de claves, la autenticación y la replicación. Parte de esta transformación depende del proveedor de la plataforma, y parte de cómo la organización la ha configurado e integrado.

Datos y activos criptográficos. Archivos cifrados, archivos históricos, documentos, copias de respaldo, intercambios B2B y otros objetos protegidos que ya existen. Este es el dominio que con más frecuencia se pasa por alto, porque actualizar una red o una plataforma no cambia los datos que fueron protegidos antes de la actualización. Un archivo cuyo contenido está cifrado con AES y cuya clave de contenido está envuelta con RSA conserva una exposición cuántica a través de la envoltura RSA, aunque AES siga siendo adecuado. Eliminarla exige re-envolver o recifrar el propio activo.

Criptografía de aplicaciones. Criptografía embebida en aplicaciones, librerías, API, firmas digitales e integraciones. Una gran empresa puede operar cientos de aplicaciones que invocan directamente algoritmos clásicos. Cambiarlas puede implicar cambios de código, actualizaciones de librerías, pruebas de regresión y nuevos despliegues, aplicación por aplicación. No siempre tiene que ser así: centralizar los servicios criptográficos detrás de una interfaz estable puede sacar buena parte de ese cambio de las propias aplicaciones, un patrón relacionado con lo que NIST describe como una API criptográfica que separa las aplicaciones de la implementación de los algoritmos ^[9].

Los proveedores modernizarán lo que les pertenece. Los datos que usted ya cifró, y la criptografía dentro de sus propias aplicaciones, solo cambian cuando usted los cambia.

3.2 Dos capas transversales

Algunas capacidades criptográficas no son un lugar sino una dependencia. Tratarlas como dominios adicionales ocultaría el hecho de que todos los dominios dependen de ellas.

Identidad y confianza. PKI, autoridades de certificación, certificados, firmas digitales, firma de código y almacenes de confianza. Los handshakes de red, la autenticación de plataformas, los documentos firmados y las versiones de software dependen todos de esta capa, y su exposición se comporta de manera diferente a la del cifrado, como explica el capítulo 6.

Gestión de claves. Generación, almacenamiento, envoltura, distribución, rotación, recuperación y destrucción de claves, mediante HSM, KMS y almacenes de claves a nivel de aplicación. Todos los dominios consumen claves, y la jerarquía de claves determina hasta dónde puede llegar un solo compromiso. La PQC cambia los algoritmos que envuelven e intercambian claves; no corrige, por sí misma, una jerarquía de claves mal diseñada.

3.3 Una condición presente en todos los dominios: los sistemas de larga vida

La tecnología operacional, el IoT, los dispositivos embebidos, las tarjetas inteligentes y otros sistemas con vidas útiles largas aparecen en más de un dominio. Es allí donde el supuesto de que el proveedor los actualizará es más débil, porque algunos no pueden actualizarse en campo en absoluto. El NCSC reconoce que habrá “un pequeño conjunto de tecnologías de uso menos frecuente para las cuales la migración antes de 2035 puede resultar más difícil” ^[7], y NIST establece que los sistemas que no puedan soportar criptografía poscuántica deben identificarse y priorizarse para su reemplazo o retiro ^[4]. Para estos sistemas, la decisión a menudo no es cómo migrar, sino qué aislar, reemplazar o retirar.

3.4 Qué cambia y quién lo cambia

La última columna es la razón por la que el panorama importa. La mayor parte de lo que entregarán los proveedores cae en las dos primeras filas. La mayor parte de lo que las organizaciones tendrán que entregar por sí mismas cae en las dos últimas.

El ecosistema de soluciones PQC

Ningún fabricante resuelve por sí solo toda la transformación PQC. Las soluciones se agrupan en categorías, y cada categoría es fuerte en algunas partes del panorama y no dice nada sobre otras. Este capítulo ubica a los fabricantes únicamente según las capacidades que documentan públicamente; no asume que un fabricante carezca de una capacidad que no hayamos encontrado.

4.1 Categorías de soluciones

Los ejemplos de fabricantes reflejan la documentación pública de cada uno a noviembre de 2026, según se cita, y no constituyen una evaluación exhaustiva. Otros fabricantes también ofrecen capacidades en estas categorías.

4.2 Las actualizaciones de los fabricantes son necesarias, y parciales

Cloudflare es un buen ejemplo de un fabricante que hace bien su parte. En febrero de 2026, Cloudflare informó que bastante más del 60% del tráfico TLS generado por personas hacia su red estaba protegido con ML-KEM híbrido ^[15]. Sin embargo, en la conexión entre Cloudflare y los servidores propios de sus clientes, el intercambio de claves poscuántico depende de que el origen lo admita, y Cloudflare informa que la proporción de orígenes que admiten intercambio de claves poscuántico ha crecido hasta el 12,8% ^[25].

El fabricante avanzó. La mayor parte del otro lado de la conexión, no.

El mismo patrón se repite en toda la tabla. Un HSM que admite ML-KEM protege las claves nuevas que se generan con él; no cambia el envoltorio de las claves creadas antes. Un certificado poscuántico asegura los nuevos handshakes; no vuelve a proteger un documento firmado el año pasado.

4.3 El estado importa: soporte, validación y certificación

La documentación de los fabricantes describe capacidades en distintas etapas, y las decisiones de compra deberían diferenciarlas. Entrust, por ejemplo, informa que los algoritmos poscuánticos de su firmware nShield obtuvieron la validación del Cryptographic Algorithm Validation Program del NIST, mientras que la validación FIPS 140-3 del módulo en sí había sido presentada pero no completada ^[21]. Thales reportó en julio de 2025 que la validación FIPS 140-3 Nivel 3 de Luna HSM v7.9 estaba en curso ^[20]. El soporte de un algoritmo, la validación del algoritmo y la certificación del módulo son tres hitos distintos.

4.4 Las plataformas de descubrimiento avanzan hacia la remediación

Varias plataformas de descubrimiento ya documentan flujos de remediación, aplicación de políticas o tareas de migración automatizadas ^[13][14]. Es un avance positivo, y el argumento del Capítulo 5 no es que estos productos solo hagan inventario. Es que el acto de descubrimiento, por completo que sea, no cambia ninguna protección; y que coordinar tareas de migración es distinto de volver a proteger datos que ya estaban cifrados y aplicaciones que invocan la criptografía directamente.

En la documentación pública revisada para este documento, no encontramos una descripción explícita, por parte de los fabricantes de descubrimiento y remediación citados, de recifrar datos existentes en reposo ni de re-envolver las claves de contenido de archivos y archivos históricos. SandboxAQ incluye la “encryption remediation” (remediación de cifrado) entre las capacidades en versión preliminar de AQtive Guard, sin especificar si se extiende a los datos almacenados ^[14]. Esta observación se limita a la documentación citada y no constituye una afirmación sobre sus hojas de ruta.

4.5 Lo que ninguno de ellos hace por sí solo

Si se lee la última columna de la tabla, aparece un patrón. Cada categoría moderniza su propia pieza del panorama. Ninguna de ellas, por sí sola, opera la criptografía para las aplicaciones de la organización como un único servicio gobernado que abarque claves, algoritmos y motores, ni vuelve a proteger lo que ya está cifrado.

Cada categoría moderniza su propia pieza. Nadie le está sirviendo la criptografía a las aplicaciones como un todo.

Ese rol faltante es lo que aporta un plano de control criptográfico: una capa que gobierna y opera la criptografía a través de las demás categorías, mientras la raíz de confianza permanece en el HSM o KMS de la organización. El concepto está publicado como un estándar abierto ^[26]. El Capítulo 11 describe la implementación de ANKATech.

El término “plano de control” (control plane) también se utiliza en categorías adyacentes. Keyfactor, por ejemplo, describe un Trust Control Plane para la gestión de identidades de máquina y criptografía, construido en torno a observar, analizar, aprovisionar, orquestar y gobernar certificados, claves, anclas de confianza e identidades de máquina ^[27]. La página menciona la coordinación de operaciones criptográficas sin detallarlas; en la documentación revisada para este documento, no describe la ejecución de cifrado o firma para las aplicaciones, ni la reprotección de datos almacenados. Los dos alcances son distintos y pueden coexistir.

Descubrir no es proteger

Este capítulo enuncia la distinción central del documento. Es deliberadamente directo, porque la confusión que aborda es común y costosa.

El descubrimiento no protege nada. Punto.

5.1 Por qué todos los marcos comienzan con el inventario

Esto no es una crítica al descubrimiento. NIST describe la transición como un proceso que comienza “con inventarios criptográficos, planificación de la migración y despliegues tempranos” de productos y servicios habilitados para PQC ^[4]. La hoja de ruta europea califica la creación y el mantenimiento de inventarios de activos criptográficos como “un primer paso esencial y una medida ‘sin arrepentimiento’ para toda entidad” ^[8]. CISA, NSA y NIST pidieron a las organizaciones, ya en 2023, crear un inventario criptográfico que ofrezca visibilidad sobre cómo usan la criptografía ^[28], y el NCSC incluye un ejercicio completo de descubrimiento entre sus hitos para 2028 ^[7].

Estamos de acuerdo con todos ellos. Sin saber dónde está la criptografía, una organización no puede priorizar, planificar ni verificar nada. Pero conocer una exposición y eliminarla son resultados distintos, y es fácil confundirlos.

5.2 Un millón de archivos

Considere una organización con un millón de archivos cuyas claves de contenido están protegidas por mecanismos vulnerables a la computación cuántica. Tras doce meses de descubrimiento, ha encontrado y catalogado el millón completo. El inventario está completo y es preciso. El número de archivos cuya protección ha cambiado es cero.

El cero es preciso, no retórico. Se refiere a la protección que aporta directamente el acto de inventariar, no al valor estratégico del conocimiento adquirido. Ese valor es real. Simplemente es otra cosa.

Usted puede descubrir el 100% de sus vulnerabilidades criptográficas y seguir teniendo el 100% de ellas expuestas.

5.3 Avance en conocimiento frente a avance en protección

Los programas de PQC generan dos tipos de avance. Ambos son legítimos. Solo uno reduce el riesgo.

El riesgo está en reportar la columna izquierda como si fuera la derecha. Una junta directiva que ve un inventario completo, un CBOM y una hoja de ruta puede creer razonablemente que la organización está más segura. Está mejor informada. Todavía no está más segura.

Trabajar en PQC y reducir el riesgo de PQC no son la misma afirmación, y los programas no deberían permitir que se lean como una sola.

Cosechar ahora, descifrar después: el costo de esperar

Si el descubrimiento y la protección estuvieran separados solo por un problema de reporte, la distinción sería un asunto de buen gobierno. Los ataques HNDL la convierten en un asunto de exposición.

6.1 La captura no necesita un computador cuántico

En 2023, CISA, NSA y NIST advirtieron que “los actores de ciberamenazas podrían estar apuntando hoy a datos que seguirían requiriendo protección en el futuro”, una operación que describieron como capturar ahora, romper después, o cosechar ahora, descifrar después ^[28]. El plan de transición final de NIST enuncia el mismo riesgo: los datos cifrados siguen en riesgo debido a la amenaza HNDL ^[4].

De ello se derivan dos consecuencias. Primero, la exposición se acumula durante el descubrimiento: si una organización dedica uno o dos años solo a descubrir y documentar, los datos protegidos por mecanismos vulnerables pueden seguir siendo capturados durante todo ese periodo. Segundo, modernizar más tarde no recupera lo que ya se tomó. Recifrar un archivo o actualizar un protocolo mañana protege frente a capturas futuras; no hace nada respecto a las copias que un adversario ya tiene.

La amenaza HNDL no espera a que usted termine su inventario.

6.2 La inecuación de Mosca

El argumento no depende de predecir la fecha de llegada de un computador cuántico criptográficamente relevante. Depende de tres magnitudes que Michele Mosca formalizó en 2015. Sea x la vida útil de seguridad, es decir, cuánto tiempo deben permanecer seguras las claves y la información que protegen; y el tiempo de migración; y z el tiempo de colapso, hasta que la criptografía de clave pública actual sea quebrada. “Si x + y > z, tenemos un problema serio hoy” ^[29]. NIST usa el mismo razonamiento, al que llama teorema de Mosca, para explicar la urgencia de la transición ^[4].

Nuestra interpretación se deriva directamente. Una organización no controla z. Controla y. Cada mes dedicado solo a descubrir es un mes que se suma a y para exposiciones que ya comprende. La hoja de ruta europea aplica la misma lógica cuando, entre sus criterios, clasifica un caso de uso como de alto riesgo si comprometer la confidencialidad después de 10 años o más todavía causaría un daño significativo ^[8].

6.3 La confidencialidad y la autenticidad tienen relojes distintos

Aquí la precisión importa, porque no todas las exposiciones corren con el mismo reloj. HNDL es una amenaza para la confidencialidad: el intercambio de claves, la envoltura de claves y los datos cifrados. NIST establece explícitamente que las firmas no son vulnerables a ella, y que un sistema de autenticación sigue siendo seguro mientras sus algoritmos y claves sean seguros en el momento en que se realiza la autenticación ^[4]. Aun así, NIST considera urgente la migración a firmas poscuánticas, porque esa transición es más larga y compleja ^[4].

Por lo tanto, la exposición de la autenticidad está determinada por la vida útil de la confianza y no por la vida útil de los datos: el riesgo es que se siga confiando en una clave o en un objeto firmado cuando la falsificación ya sea posible. El ejemplo de NIST es la firma de código para dispositivos cuyo código de verificación no puede actualizarse, que debería diseñarse para exigir firmas resistentes a la computación cuántica si dichos dispositivos pueden seguir en uso cuando existan esos computadores ^[4].

La tabla es nuestra síntesis de los criterios de NIST y de la UE citados arriba. Separar los dos relojes hace más precisa la priorización y evita tratar todos los activos vulnerables a la computación cuántica como igualmente urgentes.

Descubrir y transformar en paralelo

Este es el punto en el que el documento deja de diagnosticar el problema y propone una alternativa.

No espere a terminar de descubrir para empezar a proteger.

7.1 Los límites de una secuencia estricta

En nuestra experiencia, la secuencia que siguen la mayoría de los programas es descubrir, evaluar, planificar y transformar. Leída de forma estricta, significa que la transformación comienza solo cuando el inventario empresarial está completo. En una organización grande eso puede tomar años, y cada uno de esos años prolonga la exposición de activos que ya se comprendían bien en el tercer mes.

Las propias guías no exigen una lectura estricta. El NCSC presenta sus actividades en tres periodos, pero advierte que, “aunque se presentan de forma secuencial, en la práctica están interrelacionadas” ^[7]. NIST describe la transición como un proceso que comienza “con inventarios criptográficos, planificación de la migración y despliegues tempranos” de productos y servicios habilitados para PQC ^[4]. La hoja de ruta europea califica el inventario como “un primer paso esencial” y lo agrupa con los demás primeros pasos previstos para finales de 2026 ^[8]. Ninguna de ellas propone el modelo que sigue; este va más allá de las guías, y lo presentamos como nuestra interpretación.

7.2 Dos motores

Proponemos ejecutar dos motores al mismo tiempo:

• El motor de descubrimiento identifica, inventaría, evalúa y prioriza la exposición a lo largo del panorama. En realidad nunca termina, porque los sistemas cambian continuamente.
• El motor de transformación toma las exposiciones conocidas y suficientemente caracterizadas, interviene sobre ellas, verifica el resultado y registra la reducción de la exposición.

Los motores se alimentan mutuamente. El descubrimiento entrega a la transformación una cola creciente de candidatos listos. La transformación devuelve al descubrimiento lo que aprende durante la ejecución: dependencias ocultas, responsables, resultados de pruebas y activos que ningún escaneo encontró.

De ello se sigue una consecuencia práctica. El motor de transformación necesita algo que ejecute, no solo algo que decida. Recifrar un archivo histórico o cambiar el algoritmo detrás de una aplicación requiere una capacidad operativa, con claves, políticas y evidencia, y no solo un plan. El capítulo 11 retoma este punto.

No se trata de una propuesta para cambiar activos a ciegas. Es una propuesta para dejar de mantener la exposición bien comprendida como rehén de la finalización de un inventario de toda la empresa.

7.3 Qué exposiciones van primero

Una exposición está lista para el motor de transformación cuando cumple la mayoría de estas condiciones:

1. La exposición está caracterizada. Se conocen el algoritmo, la clave, el mecanismo y los datos que protege.
2. El valor de actuar temprano es alto. Larga vida útil de la confidencialidad, alto riesgo de captura o un ancla de confianza de larga vida, como se describe en el capítulo 6.
3. Las dependencias están mapeadas. Se conocen los sistemas que leen, escriben o verifican el activo, y ninguno fallará de forma silenciosa.
4. El cambio es comprobable y reversible. Existe una forma de validar el resultado y de revertirlo si es necesario.
5. Hay un responsable y un mecanismo. Alguien rinde cuentas, y existe una herramienta para ejecutar el cambio a la escala del activo.

Los archivos históricos cifrados, las copias de respaldo y los intercambios B2B suelen cumplir las cinco condiciones desde temprano. Su exposición es fácil de describir, su vida útil de confidencialidad es larga, y volver a protegerlos no requiere cambiar las aplicaciones que los produjeron.

7.4 Verificar la mitigación

Toda transformación debe cerrarse con evidencia de que la exposición fue efectivamente eliminada: el activo ahora está protegido por un mecanismo aprobado, la envoltura o la clave anterior está retirada, sus consumidores siguen funcionando y el cambio se refleja de vuelta en el inventario. Sin este paso, el motor de transformación produce actividad en lugar de protección, que es el mismo error contra el que advierte este documento, un nivel más abajo.

Medir la protección, no el descubrimiento

Lo que un programa mide es lo que optimizará. Si los únicos indicadores son de cobertura del inventario, el programa se volverá muy bueno haciendo inventarios.

8.1 Dos familias de métricas

Recomendamos que los programas de PQC reporten dos familias de métricas, por separado y una junto a la otra.

8.2 El indicador que la mayoría de los programas omite

El indicador individual más útil es el que la mayoría de los programas no sigue: el tiempo desde el descubrimiento hasta la mitigación verificada. Mide exactamente la brecha de la que trata este documento. Un programa con un inventario perfecto y un tiempo largo entre descubrimiento y mitigación está bien informado y, aun así, expuesto.

Para las juntas directivas, una medida ponderada de la exposición residual dice más que un conteo. Mil registros de sesión de corta duración y mil archivos históricos que deben permanecer confidenciales durante veinte años no representan el mismo riesgo. Ponderar la exposición residual por la vida útil de los datos y la vida útil de la confianza, como sugiere la inecuación de Mosca, alinea la métrica con el riesgo real.

Deje de medir lo que ha descubierto. Empiece a medir lo que ha protegido.

Esto no significa que deba dejar de medirse el descubrimiento. Significa que el resultado de un programa de PQC es la protección efectiva, no la vulnerabilidad documentada.

Construir para la criptoagilidad

Una organización que está por invertir años de esfuerzo en modernizar su criptografía debería hacerse una pregunta más: ¿cómo evitamos ejecutar el mismo proyecto otra vez la próxima vez que cambie un algoritmo, una amenaza o un estándar?

9.1 La PQC no es el destino

NIST define la criptoagilidad como “las capacidades necesarias para reemplazar y adaptar algoritmos criptográficos en protocolos, aplicaciones, software, hardware, firmware e infraestructuras, preservando la seguridad y la continuidad de las operaciones” ^[9]. Nuestro documento complementario muestra, con cinco casos recientes, que la evaluación de los mecanismos criptográficos cambia por razones que incluyen la computación cuántica pero no se limitan a ella ^[6]. Por lo tanto, la PQC no debe tratarse como el destino de la arquitectura criptográfica. El destino debe ser la capacidad de seguir evolucionando.

Haga de la transformación PQC el comienzo de la criptoagilidad, no otra migración de una sola vez.

9.2 Cuatro capacidades

9.3 El ejemplo del radio de impacto

Una aplicación cifra 500.000 archivos con AES-256-GCM. El algoritmo es robusto, y NIST no prevé reemplazarlo en la migración a PQC ^[4]. Pero si todos los archivos están cifrados con la misma clave y esa clave se ve comprometida, los 500.000 quedan expuestos.

Una arquitectura que asigna a cada archivo o grupo de archivos su propia clave de datos, envuelta por una clave de cifrado de claves, limita muchos escenarios de compromiso a un solo archivo o grupo. Las claves de envoltura se convierten entonces en el punto crítico: su compromiso vuelve a ampliar el impacto, razón por la cual necesitan la protección más fuerte, su propia política de rotación y, en una transición a PQC, un mecanismo de envoltura resistente a la computación cuántica.

La lección es que una arquitectura criptográfica sólida no depende solo de elegir algoritmos resistentes. Depende de cómo se gestionan en el tiempo las claves, los activos y las dependencias, que es el objeto del marco CAPA ^[5].

Preguntas para el comité de dirección de PQC

Las siguientes preguntas están diseñadas para revelar, antes de que lo haga un plazo, si un programa de PQC está produciendo protección o solo conocimiento:

1. De los activos vulnerables a la computación cuántica que ya identificamos, ¿cuántos hemos vuelto a proteger efectivamente?
2. ¿Cuál es nuestro tiempo mediano desde el descubrimiento hasta la mitigación verificada, y qué dominios definen su límite superior?
3. ¿Cuáles de nuestros datos deben permanecer confidenciales por más de diez años, y alguno de ellos sigue protegido por un intercambio o una envoltura de claves vulnerable a la computación cuántica?
4. ¿En cuáles de nuestras claves y objetos firmados se seguirá confiando dentro de cinco años, y alguno de ellos es clásico?
5. ¿Qué partes de nuestro panorama modernizarán nuestros proveedores, y cuáles no cambiarán a menos que nosotros las cambiemos?
6. Cuando terminemos esta migración, ¿cuántas aplicaciones tendríamos que modificar para ejecutar la siguiente?

Las organizaciones que pueden responder estas preguntas con evidencia están ejecutando una transformación. Las organizaciones que solo pueden responder la primera mitad de cada pregunta están ejecutando un inventario.

ANKASecure© en el panorama

Un plano de control criptográfico gobierna, opera y hace evolucionar la criptografía de una organización como un único servicio, mientras la raíz de confianza permanece en su HSM o KMS. El Cryptographic Control Plane (plano de control criptográfico) se publica como estándar abierto ^[26] y se describe en el whitepaper complementario de ANKATech ^[5]; ANKASecure© es la implementación de ANKATech. Es un participante del ecosistema descrito en el capítulo 4 y no reemplaza ninguna de las demás categorías: gobierna y opera la criptografía a través de ellas, y actúa directamente donde solo la organización puede actuar.

11.1 Cuatro capacidades

La raíz de confianza permanece en el HSM o KMS que la organización elija, y puede ser más de uno al mismo tiempo. Como las claves siguen protegidas por esa raíz de confianza mientras las operaciones pueden ejecutarse en el plano de control, adoptar un nuevo algoritmo no tiene que esperar a que todos los HSM o KMS de la organización lo soporten.

El plano de control gobierna y opera la criptografía a través del ecosistema. No reemplaza ninguna parte de él.

11.2 Dónde encaja y dónde no

11.3 Volver a proteger los activos existentes

Las operaciones dedicadas de recifrado y refirmado, incluidas las operaciones en streaming para objetos de datos de gran tamaño, permiten trasladar la información protegida bajo un mecanismo antiguo a uno nuevo sin exigir que las aplicaciones que la crearon recreen los datos. Es el motor de transformación del capítulo 7 aplicado al dominio que las actualizaciones de los proveedores dejan intacto.

11.4 La criptografía como servicio gobernado para las aplicaciones

Las aplicaciones invocan capacidades criptográficas estables, como cifrar, descifrar, firmar y verificar, sobre identificadores de clave estables. El mecanismo detrás de cada capacidad, incluidas las construcciones híbridas y los mecanismos poscuánticos basados en FIPS 203, 204 y 205, se gobierna mediante políticas en lugar de estar embebido en el código de la aplicación. Cada operación se registra con su contexto, incluidos el algoritmo y la clave utilizados, de modo que el avance en protección pueda demostrarse y no solo afirmarse.

11.5 Cómo empezar

1. Clasificación de exposiciones: a partir del inventario existente de la organización, identificar las exposiciones que cumplen los criterios de preparación del capítulo 7.
2. Demostración: ANKASecure© volviendo a proteger un conjunto de activos análogos a los de la organización, de extremo a extremo, con evidencia.
3. Piloto acotado: un conjunto de datos de alto valor o un flujo crítico de aplicación transformado bajo políticas, con las claves ancladas en el HSM o KMS elegido por la organización.

Conclusión

La criptografía poscuántica no es una única actualización tecnológica. Requiere una transformación coordinada en redes, plataformas, datos y aplicaciones, apoyada en las capas de identidad y de gestión de claves que los atraviesan a todos. Los proveedores entregarán parte de esa transformación. Las organizaciones tendrán que entregar el resto por sí mismas, en especial para los datos que ya están cifrados y para la criptografía dentro de sus propias aplicaciones.

El descubrimiento es esencial para comprender la exposición criptográfica, pero el descubrimiento no protege nada. Con los ataques HNDL, esperar tiene un costo: los datos capturados hoy pueden seguir siendo vulnerables incluso después de que los sistemas se modernicen. Por lo tanto, las organizaciones deberían ir más allá de los programas guiados por el descubrimiento hacia una ejecución coordinada, en la que el descubrimiento, la priorización, la transformación y la validación avancen en paralelo y se midan por la exposición que eliminan. Y como la PQC no será el último cambio criptográfico, la inversión que se haga ahora debería dejar como legado una criptoagilidad duradera.

El resultado de un programa de PQC no es un inventario completo. Es una exposición que ya no existe.

Referencias

1. [1] NIST. Module-Lattice-Based Key-Encapsulation Mechanism Standard. FIPS 203, August 13, 2024. https\://doi.org/10.6028/NIST.FIPS.203
2. [2] NIST. Module-Lattice-Based Digital Signature Standard. FIPS 204, August 13, 2024. https\://doi.org/10.6028/NIST.FIPS.204
3. [3] NIST. Stateless Hash-Based Digital Signature Standard. FIPS 205, August 13, 2024. https\://doi.org/10.6028/NIST.FIPS.205
4. [4] D. Moody, R. Perlner, A. Regenscheid, A. Robinson, D. Cooper. Transition to Post-Quantum Cryptography Standards. NIST IR 8547, October 2026. https\://doi.org/10.6028/NIST.IR.8547
5. [5] ANKATech Solutions INC. The Cryptographic Control Plane: Introducing CAPA, Crypto Agility Posture Architecture. Whitepaper V2, September 2026.
6. [6] ANKATech Solutions INC. Crypto agility beyond the quantum clock: why post-quantum migration is necessary, and why it is not enough. Whitepaper V1, October 2026.
7. [7] UK National Cyber Security Centre. Timelines for migration to post-quantum cryptography, March 20, 2025. https\://www.ncsc.gov.uk/guidance/pqc-migration-timelines
8. [8] NIS Cooperation Group, EU PQC Workstream. A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, Part 1, Version 1.1, June 11, 2025 (published by the European Commission June 23, 2025). https\://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography
9. [9] E. Barker, L. Chen, D. Cooper, D. Moody, A. Regenscheid, M. Souppaya, W. Newhouse, R. Housley, S. Turner, W. C. Barker, K. Kent. Considerations for Achieving Crypto Agility: Strategies and Practices. NIST CSWP 39-upd1, December 2025, updated June 29, 2026. https\://doi.org/10.6028/NIST.CSWP.39-upd1
10. [10] IBM. IBM Quantum Safe. Product page, accessed November 2026. https\://www.ibm.com/quantum/quantum-safe
11. [11] K. Patil. AppViewX PQC Assessment Tool – Kickstart Your PQC Readiness Journey with Complete Cryptographic Visibility. AppViewX blog, May 16, 2025. https\://www.appviewx.com/blogs/appviewx-avx-one-pqc-assessment-tool-kickstart-your-pqc-readiness-journey-with-complete-cryptographic-visibility/
12. [12] SandboxAQ. SandboxAQ Redefines Cybersecurity with Unified Cryptography Management. March 27, 2024. https\://sandboxaq.com/post/sandboxaq-redefines-cybersecurity-with-unified-cryptography-management
13. [13] IBM. IBM Quantum Safe (IBM Guardium Cryptography Manager). Product page, accessed November 2026. https\://www.ibm.com/products/guardium-quantum-safe
14. [14] SandboxAQ. AQtive Guard: Remediate. Product page, accessed November 2026. https\://www.sandboxaq.com/solutions/security/remediate
15. [15] S. Goldberg, A. Paul, D. Gauch. Cloudflare One is the first SASE offering modern post-quantum encryption across the full platform. Cloudflare blog, February 23, 2026. https\://blog.cloudflare.com/post-quantum-sase
16. [16] F5. Integrating PQC. BIG-IP System: SSL Administration, version 21.1.0. Technical documentation, accessed November 2026. https\://techdocs.f5.com/en-us/bigip-21-1-0/big-ip-system-ssl-administration/integrating-pqc-on-the-client-side.html
17. [17] Palo Alto Networks. PAN-OS 12.1 IKE and Web Certificate Cipher Suites. Technical documentation, updated October 23, 2026. https\://docs.paloaltonetworks.com/compatibility-matrix/reference/supported-cipher-suites/cipher-suites-supported-in-pan-os-12-1/cipher-suites-supported-in-pan-os-12-1-ike-web-certs
18. [18] Amazon Web Services. AWS KMS adds support for post-quantum ML-DSA digital signatures. What's New, June 13, 2025. https\://aws.amazon.com/about-aws/whats-new/2025/06/aws-kms-post-quantum-ml-dsa-digital-signatures
19. [19] Oracle. JDK 24 Release Notes. March 18, 2025. https\://www.oracle.com/java/technologies/javase/24-relnote-issues.html
20. [20] B. Canavan. How to Become Quantum-Ready Today: Luna HSM v7.9 Delivers Real-World PQC, Validated by Thales PKI Technology Partners. Thales blog, July 29, 2025. https\://cpl.thalesgroup.com/blog/encryption/luna-hsm-pqc-quantum-safe-encryption
21. [21] Entrust. Entrust nShield HSMs Post-Quantum Cryptography Algorithms Achieve Validation from the NIST Cryptographic Algorithm Validation Program. Press release, September 10, 2025. https\://www.entrust.com/company/newsroom/entrust-nshield-hsms-achieve-validation-from-nist-cryptographic-algorithm-validation-program
22. [22] Utimaco. Utimaco launches Quantum Protect solution and free PQC simulator. Press release, April 2, 2025. https\://utimaco.com/news/press-releases/utimaco-launches-quantum-protect-solution-and-free-pqc-simulator
23. [23] AppViewX. Private PKI Ready for AI and Quantum. Product page, accessed November 2026. https\://www.appviewx.com/products/pki/
24. [24] DigiCert. Post-quantum cryptography (PQC). Trust Lifecycle Manager documentation, June 26, 2026. https\://docs.digicert.com/en/trust-lifecycle-manager/post-quantum-cryptography-pqc.html
25. [25] S. Ahmad, Y. Jamal, A. Krivit. Automatic Key Exchange: faster, post-quantum secure origin handshakes for 45 billion daily connections (and counting). Cloudflare blog, September 8, 2026. https\://blog.cloudflare.com/automatic-key-exchange-for-origins/
26. [26] Cryptographic Control Plane. Open standard, CC BY 4.0. https\://cryptographiccontrolplane.org
27. [27] E. Boehm. The vision behind the Keyfactor Trust Control Plane. Keyfactor blog, May 7, 2026. https\://www.keyfactor.com/blog/the-vision-behind-the-keyfactor-trust-control-plane/
28. [28] CISA, NSA, NIST. Quantum-Readiness: Migration to Post-Quantum Cryptography. Factsheet, August 2023. https\://www.nccoe.nist.gov/sites/default/files/2023-08/quantum-readiness-fact-sheet.pdf
29. [29] M. Mosca. Cybersecurity in an era with quantum computers: will we be ready? IACR Cryptology ePrint Archive, Paper 2015/1075, November 2015. https\://eprint.iacr.org/2015/1075

ANKATech Solutions INC. ANKASecure© es un producto de ANKATech Solutions INC. Las capacidades de los proveedores se describen a partir de la documentación pública de cada proveedor, según se cita, y no constituyen una evaluación exhaustiva. Este documento se proporciona con fines informativos y refleja el estado de las fuentes citadas al 2 de noviembre de 2026.