No se puede proteger lo que no se ve: el argumento fundamental para el descubrimiento criptográfico.

Toda organización que utilice cifrado basado en RSA , ECC, TLS o AES posee un conjunto de datos criptográficos. La mayoría de las organizaciones desconocen su contenido.

Esto no es una crítica; es una realidad estructural. La criptografía nunca se diseñó para gestionarse como se gestionan los servidores o las aplicaciones. No tiene dirección IP. No genera ninguna alerta cuando llega al final de su vida útil. Se ejecuta silenciosamente en segundo plano en casi todos los sistemas que utilizas, hasta que algo falla, hasta que un organismo regulador solicita documentación que no puedes proporcionar, o hasta que un modelo de amenazas que descartaste como teórico se vuelve lo suficientemente real como para que alguien con recursos reales decida actuar en consecuencia.

El resultado es predecible. Las organizaciones acumulan deuda criptográfica durante años sin percatarse de su alcance total. SHA-1 persiste en sistemas que nadie ha tocado en años. Triple-DES sigue funcionando en terminales de pago configuradas en otra época. Las claves codificadas permanecen en repositorios que los desarrolladores dejaron de usar hace mucho tiempo. Los certificados operan en infraestructura que nadie posee formalmente. Y en algún lugar de su entorno en la nube, un microservicio se ejecuta con configuraciones de cifrado predeterminadas que nadie jamás definió deliberadamente.

Este es el problema del descubrimiento criptográfico, y subyace a todas las demás iniciativas criptográficas que su organización deberá implementar. La preparación para el cumplimiento normativo, la migración post-cuántica, la gestión del ciclo de vida de los certificados y la gobernanza de claves: todas ellas requieren saber qué información se posee antes de poder comenzar cualquier trabajo significativo.

La verdadera magnitud del problema 

Cuando las organizaciones intentan por primera vez realizar un inventario criptográfico , se sorprenden constantemente por lo que encuentran, no porque los hallazgos sean inesperados, sino porque hay muchísimos y muy pocos estaban registrados en algún sistema de registro existente.

Según el documento n.° 158 del BIS, entre el 70 y el 90 por ciento del software empresarial se compone de componentes de terceros. Cada uno de esos componentes conlleva decisiones criptográficas que la organización que los implementa nunca tomó directamente: versiones de bibliotecas vinculadas a dependencias obsoletas, configuraciones predeterminadas de conjuntos de cifrado establecidas en el momento en que se escribió la biblioteca, y decisiones de algoritmos integradas en el código que se distribuye dentro de un producto cuyo proveedor nunca ha publicado una divulgación criptográfica.

El marco de migración PQC de Applied Quantum estima más de 320 llamadas a funciones criptográficas en una sola aplicación de banca móvil. En el conjunto de sistemas de una empresa, el número total de activos criptográficos, algoritmos, claves, certificados, protocolos e implementaciones de bibliotecas asciende a cientos de miles. La mayoría de las organizaciones solo han documentado formalmente una pequeña fracción de esta cantidad.

La diferencia entre lo que las organizaciones creen que poseen en su infraestructura criptográfica y lo que realmente está en producción no es una discrepancia menor en el inventario. Es la causa principal de cada incumplimiento normativo, de cada retraso en la corrección de errores y de cada proyecto de migración que tarda el doble de lo previsto. 

¿Por qué su sistema de herramientas actual tiene puntos ciegos estructurales?

El instinto natural al iniciar un inventario criptográfico es recurrir a las herramientas existentes: ejecutar el escáner de vulnerabilidades, exportar el sistema de gestión de certificados, consultar la CMDB. Si bien cada una de estas herramientas captura información útil, todas presentan limitaciones estructurales que ninguna configuración puede superar.

Las plataformas de gestión de certificados administran los certificados que usted registró con ellas. No cuentan con ningún mecanismo para detectar certificados aprovisionados fuera de su flujo de trabajo administrado, como el certificado que un desarrollador solicitó directamente a una CA pública, el que una plataforma en la nube generó automáticamente o el que aún se ejecuta en un entorno de prueba que nunca se desactivó.

Los escáneres de vulnerabilidades informan sobre qué es accesible y qué servicios están en funcionamiento. No revelan qué conjuntos de cifrado se están negociando activamente en el tráfico este-oeste entre las capas de su aplicación, las conexiones internas de servicio a servicio que son invisibles en el perímetro y que casi nunca se rigen por las mismas políticas TLS que el tráfico externo entrante.

Las CMDB registran la infraestructura aprovisionada oficialmente. No incluyen los recursos en la nube implementados fuera de los flujos de trabajo estándar, los dispositivos OT que la administración de instalaciones aprovisionó de forma independiente, los sistemas de empresas adquiridas que se integraron en las operaciones pero nunca en el registro de activos, ni ningún sistema cuyo propietario abandonó la organización sin documentarlo.

No se trata de fallos en las herramientas, sino de limitaciones de diseño. Cada herramienta se creó con un propósito específico, y ese propósito no era el descubrimiento criptográfico . Para subsanar estas deficiencias, es necesario abordar el descubrimiento como una disciplina multicapa, no como un simple escaneo que se realiza una sola vez y luego se olvida.

Las cinco capas de descubrimiento y lo que revela cada una.

Un inventario criptográfico completo requiere cinco capas de descubrimiento distintas. No son intercambiables ni redundantes. Cada una revela lo que las demás, por su estructura, no pueden.

Método de capas	Lo que encuentra de forma única
Análisis pasivo del tráfico de red	Negociación de protocolos en vivo en producción, lo que realmente se está utilizando, no solo lo que está configurado.
Análisis de código estático	Claves codificadas, importaciones de bibliotecas obsoletas y opciones de algoritmos fijas en la lógica de la aplicación.
Configuración y escaneo de certificados	Políticas de conjuntos de cifrado en infraestructura administrada; certificados espejo a través de registros CT.
Análisis binario y de tiempo de ejecución	Postura criptográfica de los dispositivos del proveedor, sistemas OT y firmware que no se puede leer directamente.
Investigación manual	Protocolos personalizados, esquemas propietarios, integraciones no documentadas y contexto organizacional.

Capa 1: Análisis pasivo del tráfico de red

El análisis pasivo de redes es el único método de descubrimiento que revela qué protocolos criptográficos se negocian realmente en producción, en contraposición a lo que las configuraciones indican que debería ser negociable. Esta distinción es más importante de lo que la mayoría de los equipos creen. 

Un servidor configurado para admitir TLS 1.3 aún puede negociar TLS 1.1 con terminales heredados que no pueden ofrecer un mejor rendimiento. Un balanceador de carga que aplica conjuntos de cifrado modernos en el perímetro no tiene control sobre las conexiones de backend entre los servidores de aplicaciones y las bases de datos, que ejecutan el protocolo de cifrado con el que se programó originalmente la aplicación. Implementado en derivaciones de red o puertos SPAN en puntos de agregación clave, el análisis pasivo captura metadatos de establecimiento de conexión TLS en tiempo real desde esas conexiones sin descifrar el tráfico ni sobrecargar los sistemas de producción.

El programa de inventario criptográfico de Santander, presentado por Jaime Gómez García en la Conferencia PQC 2025 del Consorcio PKI, logró visibilidad en 9,000 instancias de Apache a nivel mundial mediante el uso de herramientas existentes adaptadas, en lugar de plataformas de descubrimiento diseñadas específicamente para este fin. La capa 1 es donde suelen surgir las sorpresas más significativas desde el punto de vista operativo.

Capa 2: Análisis de código estático 

El análisis estático examina los repositorios de código fuente en busca de material criptográfico integrado directamente en la lógica de la aplicación, como valores de clave codificados, importaciones de bibliotecas obsoletas y parámetros explícitos de tamaño de clave en las llamadas de generación de claves. Estas representan decisiones criptográficas fijas a nivel de código que no se pueden modificar sin una redistribución completa.

Una llamada a hashlib.sha1() en una aplicación de producción no es solo una advertencia sobre un algoritmo obsoleto. Es una tarea de corrección que requiere un cambio de código, un ciclo de compilación, un ciclo de pruebas y un despliegue. En una base de código empresarial que contiene cientos de miles de llamadas a funciones criptográficas, la capa 2 es donde se hace visible por primera vez el verdadero alcance del esfuerzo de migración a nivel de aplicación. 

Capa 3: Configuración y escaneo de certificados 

Esta capa abarca las políticas de conjuntos de cifrado configuradas en balanceadores de carga, cortafuegos y concentradores VPN, así como el inventario de certificados en todo su entorno PKI e infraestructura en la nube.

Los registros de Transparencia de Certificados (CT) son la fuente menos utilizada en esta capa. Toda Autoridad de Certificación (CA) de confianza pública debe enviar cada certificado que emite a los registros CT, los cuales son de acceso público. Una consulta a los registros CT de sus dominios devuelve todos los certificados emitidos para ellos, incluidos aquellos que nunca se registraron en su sistema de gestión de certificados. Estos son sus certificados sombra, y están sujetos a la normativa, independientemente de si aparecen o no en su inventario gestionado.

Capa 4: Análisis binario y en tiempo de ejecución 

Para dispositivos de proveedores, firmware integrado y sistemas OT donde no se dispone del código fuente, el análisis binario y en tiempo de ejecución es el único método viable para evaluar la seguridad criptográfica real. Esto se aplica a cajeros automáticos y terminales de punto de venta, dispositivos de red, sistemas de control industrial y cualquier dispositivo cuya implementación criptográfica resida en un firmware que su organización no haya desarrollado y que no pueda inspeccionar directamente.

El documento NIST CSWP 39 indica que el ciclo promedio de actualización de un sistema de tecnología operativa (OT) es de 20 años. En la práctica, esto significa que los algoritmos criptográficos obsoletos pueden permanecer arraigados en entornos de tecnología operativa durante una década o más, sin ningún mecanismo de actualización ni proceso de gobernanza que los haya intervenido.

Capa 5: Investigación manual

La revisión de la documentación de arquitectura, el examen de los registros de auditoría de HSM y KMS , el análisis de la documentación de seguridad del proveedor y las entrevistas estructuradas con los responsables de la plataforma y el sistema completan el panorama del descubrimiento. La investigación manual revela los protocolos personalizados, los esquemas de cifrado propietarios y las integraciones no documentadas que cualquier capa automatizada pasaría por alto, y proporciona el contexto organizacional que transforma los hallazgos técnicos brutos en inteligencia verdaderamente útil.

Cada capa descubre lo que las demás no pueden. Omitir cualquiera de ellas implica heredar permanentemente sus puntos ciegos.

Las obligaciones de cumplimiento ya están en vigor. 

Para las organizaciones sujetas a DORA , PCI DSS 4.0 o NIS2 , un inventario criptográfico no es una recomendación de buenas prácticas, sino una obligación legal vigente y de obligado cumplimiento.

El artículo 9.2 de la DORA exige a las entidades financieras mantener un registro actualizado de todos los activos de información, incluidos explícitamente los activos criptográficos, para todos los sistemas de TIC que dan soporte a funciones críticas o importantes. El artículo 7.4 de la DORA exige además que este registro incluya todos los certificados digitales y los dispositivos en los que se almacenan. Ambas disposiciones son de obligado cumplimiento desde el 17 de enero de 2025.

El requisito 12.3.3 de PCI DSS exige un inventario documentado y actualizado continuamente de todos los conjuntos de cifrado y protocolos criptográficos en uso, con una justificación comercial para cada entrada, un monitoreo activo de su viabilidad y una estrategia de respuesta documentada para cualquier vulnerabilidad criptográfica identificada. Este requisito es de cumplimiento obligatorio desde el 31 de marzo de 2025.

Ninguna de estas fechas límite es futura. Ambas son obligaciones vigentes hoy. Una organización que no puede presentar la documentación requerida durante una revisión de supervisión no tiene una laguna en su plan estratégico; tiene una laguna en un requisito exigible que está en vigor desde principios de este año.

La justificación comercial para crear un inventario criptográfico no requiere una evaluación de amenazas cuánticas ni un mandato formal para una migración post-cuántica. El mero cumplimiento normativo ha sido una justificación más que suficiente desde enero de 2025.

Cómo la consultoría en cifrado puede ayudarle a crear su inventario criptográfico.

Comprender el problema del descubrimiento es el primer paso. Contar con la plataforma adecuada para abordarlo es el segundo, y ahí es donde entra en juego CBOM Secure.

CBOM Secure es la plataforma de descubrimiento e inventario criptográfico automatizado (ACDI) de Encryption Consulting, diseñada específicamente para ejecutar las cinco capas de descubrimiento como una única capacidad integrada. Los sensores de red pasivos capturan la negociación de protocolos en tiempo real en el tráfico de producción. El análisis estático se integra directamente con los sistemas de control de versiones para escanear el código propio y los árboles de dependencias de terceros. La enumeración de certificados se ejecuta continuamente en los registros CT y los sistemas de gestión de certificados. Las consultas a la API en la nube abarcan el cifrado en reposo y las configuraciones de gestión de claves en todas las cuentas en la nube conectadas. Los flujos de trabajo de investigación manual se integran directamente en CBOM, lo que garantiza que nada descubierto fuera de las herramientas automatizadas pase desapercibido.

Cada entrada de CBOM se enriquece automáticamente con el estado de vulnerabilidad cuántica, el enrutamiento de propiedad y el etiquetado de brechas de cumplimiento normativo según DORA, PCI DSS 4.0 y NIS2, de modo que su equipo siempre trabaja a partir de una imagen priorizada y contextualizada del entorno, no de una recopilación de hallazgos sin procesar.

CBOM Secure no genera una lista de hallazgos y deja que su equipo determine cómo abordarlos. Crea un sistema de registro controlado y mantenido continuamente que transforma los hallazgos en acciones, desde el primer análisis hasta cada cambio posterior en su entorno.

Donde empezar 

El alcance total de un inventario criptográfico puede resultar abrumador. No es necesario abordarlo todo de una vez.

• Comience con las capas 1 y 3: Sus balanceadores de carga, concentradores VPN y proxies inversos ya están en su CMDB, tienen propietarios identificables y sus configuraciones criptográficas se pueden descubrir con las herramientas que la mayoría de las organizaciones ya tienen.
• Construye el inventario gradualmente, no todo a la vez: El marco de migración de Applied Quantum PQC recomienda lograr primero una cobertura integral de las capas 1 y 2, con un plazo de semanas a meses según el tamaño del sistema, y ​​comenzar la evaluación de riesgos de esas entradas de inmediato, en lugar de esperar a tener un inventario completo antes de iniciar cualquier corrección. Puede comenzar a secuenciar las correcciones en lo que ya conoce mientras continúa mejorando la visibilidad del resto.
• Contacta ya con tus proveedores estratégicos: Si algún componente de su entorno, suministrado por un proveedor, depende de una biblioteca criptográfica o un módulo de seguridad de hardware (HSM) cuya actualización posterior a la computación cuántica no se ha comunicado, es necesario iniciar esa conversación hoy mismo. Los plazos de los proveedores están completamente fuera de su control. La única variable que puede influir es el momento en que inicie la comunicación.

Conclusión

El problema del descubrimiento criptográfico no es un desafío futuro, sino una realidad actual. La mayoría de las organizaciones operan con importantes discrepancias entre lo que creen que contiene su infraestructura criptográfica y lo que realmente está en producción. Estas discrepancias no son inofensivas. Son la razón por la que los proyectos de migración se estancan, las auditorías de cumplimiento revelan hallazgos inesperados y los plazos de remediación se extienden mucho más allá de las estimaciones iniciales.

Se estimaba que la migración de SHA-1 a SHA-256 tardaría cinco años. Tardó más de diez. La transición poscuántica es más compleja en todos los sentidos, y las obligaciones de cumplimiento de DORA y PCI DSS 4.0 ya están en vigor. Cada mes sin un inventario completo y controlado supone un mes de riesgo creciente.

Saber con qué se cuenta no es la meta final, sino el punto de partida. Pero es el primer paso que deben superar todas las demás iniciativas, procesos de cumplimiento, migración y gobernanza. Las organizaciones que logren esa visibilidad ahora estarán preparadas cuando sea necesario.

La segunda parte de esta serie trata sobre qué hacer con los datos encontrados: cómo una lista de materiales criptográficos transforma los datos de descubrimiento en un sistema de registro controlado y cómo utilizarlos para impulsar la evidencia de cumplimiento, la priorización de riesgos y la planificación de la migración a PQC.