No se puede migrar lo que no se enumera: el CBOM que la banca no tiene

TL;DR. El plazo de descubrimiento del NCSC para 2028 llega antes que cualquier migración. La banca no puede cumplirlo: el registro DORA no anota la criptografía.

Puntos clave

El plazo que nadie presupuestó. Léanse con atención los calendarios de migración publicados y la secuencia es inequívoca.
El registro DORA lo anota todo salvo la criptografía. Aquí está la parte que sorprende.
Qué contiene realmente un CBOM. Una Cryptography Bill of Materials es un inventario formal de los activos criptográficos de un sistema — los algoritmos, las claves, los certificados y los protocolos, y sus relaciones con los componentes de software…
El descubrimiento son cuatro problemas, no uno. Tratar el descubrimiento como un único flujo de trabajo es la forma más habitual de que estos programas fracasen.

Toda hoja de ruta poscuántica de la banca presume un inventario que no existe. Los planes están escritos, los comités de dirección se reúnen, los cuadros de mando están en ámbar. Debajo de todo ello late una suposición: que alguien, en algún sitio, puede producir la lista de todos los puntos en los que el banco ejecuta una operación criptográfica — qué algoritmo, qué longitud de clave, qué biblioteca, qué certificado y cuándo caduca. Casi ninguna entidad puede. El primer hito del NCSC no es un hito de migración: es un hito de descubrimiento, con fecha en 2028, y es el que nadie ha presupuestado.

Resumen ejecutivo

La secuencia es descubrimiento, después agilidad, después migración. La guía del NCSC fija un hito definido de descubrimiento en 2028, la migración de máxima prioridad en 2031 y la finalización para 2035. La entidad que empiece a migrar antes de haber enumerado migrará los sistemas que resulta que conoce.

El registro que tiene no responde a la pregunta que ahora afronta. El Article 8 de DORA exige a las entidades financieras identificar, clasificar y documentar los activos TIC y mapear sus interdependencias. No exige ni una sola propiedad criptográfica, de modo que un registro conforme al Article 8 puede estar completo y seguir siendo inútil para planificar la agilidad criptográfica.

La norma ya existe. Los activos criptográficos — algoritmos con longitud de clave, modo y curva; claves; certificados; protocolos — son representables en CycloneDX, publicada como ECMA-424. Es una cuestión de esquema, no de compras.

El cuartil más difícil no le corresponde escanearlo. Los módulos de seguridad hardware, los dispositivos de pago, las bibliotecas embebidas por proveedores y los proveedores SaaS no se enumeran apuntándoles con un escáner. Esa parte del inventario se construye con atestación contractual, y la cláusula tiene que existir antes de que pueda existir la hoja de ruta.

El plazo que nadie presupuestó

Léanse con atención los calendarios de migración publicados y la secuencia es inequívoca. La hoja de ruta del National Cyber Security Centre sitúa el descubrimiento — una imagen completa de qué sistemas y servicios dependen de la criptografía — en 2028, el trabajo de migración de máxima prioridad en 2031 y la finalización en todos los sistemas, servicios y productos en 2035. El informe de transición de NIST, IR 8547, corre por una vía compatible: los algoritmos de clave pública vulnerables a la computación cuántica, incluidos RSA y ECC, quedan obsoletos después de 2030 y prohibidos después de 2035.

La mayoría de los programas bancarios ha interiorizado 2035 como la fecha. Ese es el extremo equivocado del calendario desde el que planificar.

Hay dos fechas que importan mucho más. La primera es 2028, porque el descubrimiento es la entrada de todo lo que viene después: no se puede acotar, presupuestar ni secuenciar una migración contra un denominador desconocido. La segunda es 2030, porque «obsoleto» no es una palabra blanda en una entidad regulada: es el punto en el que seguir dependiendo de un algoritmo se convierte en una decisión que alguien tiene que firmar.

De aquí a 2028 quedan menos de treinta meses. Eso es uno, quizá dos, ciclos presupuestarios para construir una capacidad que la mayoría de las entidades no ha empezado.

El registro DORA lo anota todo salvo la criptografía

Aquí está la parte que sorprende. La mayoría de los grandes bancos europeos ya mantiene un inventario detallado y revisado con regularidad de sus activos TIC, porque DORA les obliga a ello.

El Article 8 del Regulation (EU) 2022/2554 exige a las entidades financieras identificar, clasificar y documentar adecuadamente todas las funciones de negocio soportadas por TIC, la información y los activos TIC que las soportan, y sus funciones y dependencias en relación con el riesgo TIC — así como mapear la configuración de esos activos y los vínculos entre ellos, manteniéndolo bajo revisión.

Ese es un inventario serio. También tiene la forma equivocada para este problema.

Tabla 1: el registro que tiene y el registro que exige el hito de 2028

Pregunta	Registro de activos TIC (DORA Article 8)	Inventario criptográfico (CBOM)
¿Qué es este activo y quién es su propietario?	Sí — es el núcleo del registro	No es su cometido
¿Qué criticidad tiene y de qué depende?	Sí — clasificación y mapeo de interdependencias	Heredado del registro de activos
¿Qué algoritmos usa y dónde?	No	Sí — por componente, con longitud de clave, modo y curva
¿Qué biblioteca los implementa y en qué versión?	Parcialmente, vía el SBOM si existe	Sí, como relación explícita
¿Qué certificados presenta y cuándo caducan?	Rara vez, y normalmente en una herramienta PKI aparte	Sí
¿Dónde residen las claves y cómo se protegen?	No	Sí — incluyendo si hay un HSM en la ruta
¿Es este activo vulnerable a la computación cuántica?	No se puede deducir	Se responde directamente

La última fila es todo el argumento. Una entidad puede cumplir plenamente el Article 8, superar su examen y seguir siendo incapaz de responder «cuántos de nuestros sistemas se romperán en 2030» sin encargar un proyecto de descubrimiento desde cero.

Esto no es una crítica a DORA. El Article 8 se escribió para responder a preguntas de resiliencia y concentración, y las responde bien. Sencillamente no se escribió para responder a una pregunta de agilidad criptográfica, y los dos registros hay que unirlos en lugar de operarlos como hojas de cálculo separadas en manos de equipos separados.

Qué contiene realmente un CBOM

Una Cryptography Bill of Materials es un inventario formal de los activos criptográficos de un sistema — los algoritmos, las claves, los certificados y los protocolos, y sus relaciones con los componentes de software que los usan.

El punto estructural importante es que no es un formato de fichero nuevo. El soporte de activos criptográficos se aportó a CycloneDX, la especificación de lista de materiales respaldada por OWASP, publicada como norma de Ecma International, ECMA-424. Un CBOM es, por tanto, un documento CycloneDX con los campos de criptografía poblados. Valida con el mismo esquema, circula por las mismas cadenas de construcción y aterriza en el mismo repositorio de artefactos que los SBOM que una entidad ya produce para la cadena de suministro.

Eso importa más de lo que parece. La diferencia entre una norma que se despliega y una norma que se atasca suele ser si exige fontanería nueva. Esta no la exige.

Tabla 2: clases de activo del CBOM y la pregunta de migración que responde cada una

Clase de activo	Qué se anota	La pregunta que responde
Algoritmo	Primitiva, longitud de clave, modo, curva, relleno y la función que desempeña	¿Cuáles de nuestras operaciones son vulnerables a la computación cuántica, y con qué robustez de parámetros?
Clave	Tipo, tamaño, formato, estado y dónde reside el material	¿Qué claves protege un HSM y cuáles residen en la memoria de la aplicación?
Certificado	Sujeto, emisor, algoritmo de firma, ventana de validez	¿Qué caduca antes de la ventana de migración y qué está firmado con un algoritmo obsoleto?
Protocolo	Protocolo y versión, con los conjuntos de cifrado ofrecidos	¿Qué se negocia realmente en el cable, frente a lo que afirma el fichero de configuración?
Componente relacionado	La biblioteca, la versión y la ubicación en el código que implementan lo anterior	Si se sustituye esta biblioteca, ¿qué más se mueve con ella?

La última fila es la que convierte un inventario en un plan. Una lista de algoritmos indica el tamaño del problema. Una lista de algoritmos unida a los componentes que los implementan indica la forma del trabajo — que es de lo que se construye realmente una secuencia de migración.

El descubrimiento son cuatro problemas, no uno

Tratar el descubrimiento como un único flujo de trabajo es la forma más habitual de que estos programas fracasen. Son cuatro problemas distintos con cuatro herramientas distintas, cuatro propietarios distintos y niveles de confianza muy diferentes.

1. Código fuente — lo que el código pide. El análisis estático sobre los repositorios propios encuentra llamadas criptográficas, parámetros codificados a fuego y las bibliotecas invocadas. Hay instrumental abierto: el proyecto CBOMkit y su complemento para SonarQube detectan activos criptográficos en el fuente y emiten CycloneDX. Máxima confianza, cobertura más estrecha — solo ve el código que usted escribió y sigue construyendo.

2. Binarios y contenedores — lo que realmente se despliega. El análisis de fuente se pierde todo lo que entra como dependencia compilada o va horneado en una imagen base. El escaneo de contenedores y sistemas de ficheros cierra parte de esa brecha. Cuente con que las dos visiones discrepen; la discrepancia es en sí misma un hallazgo.

3. La red — lo que de verdad se negocia. La configuración es una intención, no una observación. La observación pasiva de la negociación TLS en vivo por todo el parque es la única manera de descubrir que un servicio que documenta TLS 1.3 sigue aceptando algo más antiguo con una contraparte interna que nunca actualizó. En un parque de pagos, esa contraparte suele ser la que importa.

4. El parque de proveedores y hardware — lo que no se puede escanear en absoluto. Módulos de seguridad hardware, terminales de pago, dispositivos de red, subsistemas de mainframe y todos los proveedores SaaS de la cadena. Ningún escáner llega hasta ahí. Este cuartil se enumera preguntando, por contrato, y es donde se concentra la exposición genuina de la banca mayorista, porque los sistemas que compensan y liquidan son desproporcionadamente de proveedor.

El cuarto es el que hay que empezar ahora, porque tiene el plazo de entrega más largo y no es una tarea de ingeniería. Es una tarea de compras: meter una cláusula de divulgación criptográfica y agilidad criptográfica en el contrato, y en la plantilla de renovación, de modo que para 2028 la respuesta llegue como obligación del proveedor y no como favor. Cada trimestre que esa cláusula no está en la plantilla es un trimestre de renovaciones que habrá que reabrir después.

Convertirlo en un control y no en un proyecto

El modo de fallo por el que yo apostaría no es que los bancos se salten el inventario. Es que lo encarguen de una sola vez, entreguen una instantánea defendible en 2028 y dejen que se degrade — porque se financió como entregable de un proyecto poscuántico en lugar de construirse como un control mantenido.

Un inventario criptográfico se degrada más deprisa que un registro de activos. Los certificados rotan. Las bibliotecas suben de versión por automatización de dependencias. Cambia una imagen base y un servicio entero adquiere en silencio una pila TLS distinta. Una instantánea tomada en 2028 será materialmente errónea en 2029, que es precisamente cuando el trabajo de priorización de 2031 depende de ella.

Tres compromisos lo evitan.

Generarlo en el pipeline, no en una encuesta. Un CBOM debe emitirlo la construcción, junto al SBOM, y almacenarse como artefacto versionado contra la release. Un inventario montado enviando un cuestionario por correo a los propietarios de aplicaciones nace caducado y no se puede comparar.

Compararlo y alertar sobre la diferencia. La señal valiosa no es el inventario; es el cambio en el inventario. Un servicio que adquirió una nueva dependencia criptográfica, un certificado que acortó su vigencia, un algoritmo que apareció donde antes no estaba — esos son los eventos que merecen un control. Es el mismo razonamiento que hace que comparar SBOM sea más útil que archivarlos.

Unirlo al registro que ya mantiene. El CBOM responde «qué criptografía»; el registro del Article 8 responde «qué criticidad, de quién y qué depende de ello». Ninguno es una priorización por sí solo. Unidos, producen la única clasificación que importa: operaciones vulnerables a la computación cuántica ordenadas por la criticidad de la función de negocio que se apoya encima. Esa unión es el entregable real de un programa de descubrimiento, y merece nombrarse así en el plan.

El manual operativo

Replantear el hito de 2028 como una capacidad, no como un informe. El entregable es un inventario mantenido y legible por máquina que se regenera solo, no un documento producido una vez para un supervisor.
Emitir CBOM desde la construcción ya, empezando por los servicios nuevos. No intentar el parque entero de una pasada. Cablearlo en el pipeline para todo lo que se construya o cambie de forma material este año, para que la cobertura se acumule en vez de exigir una campaña.
Meter la cláusula contractual en la plantilla de renovación este trimestre. Divulgación criptográfica y compromiso de agilidad criptográfica. Tiene el plazo de entrega más largo de toda la lista y no depende de ninguna decisión de herramienta.
Ejecutar la observación de red primero contra las rutas de pago y liquidación. Es donde la brecha entre configuración y realidad hace más daño y donde se concentran las contrapartes heredadas.
Unir el CBOM al registro del Article 8 y ordenar sobre la unión. Publicar la lista ordenada. Es el artefacto que convierte un inventario de ingeniería en una conversación de consejo sobre secuenciación y dinero.
Comparar cada regeneración y alertar sobre nuevas dependencias vulnerables a la computación cuántica. Un inventario sin comparación es un archivo.

Las entidades que llegarán a 2031 con holgura no son las que tienen la visión más avanzada de ML-KEM. Son las que pueden responder, cualquier mañana y sin encargar un proyecto, a la pregunta de dónde está realmente su criptografía.

Preguntas frecuentes

¿Es un CBOM algo distinto de un SBOM?
Es el mismo tipo de documento con campos distintos poblados. El soporte de activos criptográficos se incorporó a CycloneDX, publicada como ECMA-424, de modo que un CBOM valida contra el mismo esquema y circula por el mismo instrumental que un SBOM. Las entidades que ya generan SBOM están más cerca de esto de lo que suelen suponer.

¿Exige DORA un inventario criptográfico?
No en esos términos. El Article 8 del Regulation (EU) 2022/2554 exige la identificación, clasificación y documentación de los activos TIC y el mapeo de su configuración e interdependencias. Las propiedades criptográficas no están entre los atributos que obliga a anotar, y por eso un registro conforme al Article 8 no puede responder a una pregunta de vulnerabilidad cuántica sin ser ampliado.

¿Por qué el descubrimiento tiene que terminar tan por delante de la migración?
Porque es la entrada de la priorización. La guía del NCSC fija el descubrimiento en 2028 y la migración de máxima prioridad en 2031 precisamente para que haya un intervalo definido en el que ordenar el parque y secuenciar el trabajo. Comprimir ambos significa migrar lo que mejor se entiende en lugar de lo que más importa.

¿Cómo inventariamos la criptografía dentro del hardware de proveedor y del SaaS?
No se escanea; se exige divulgación. Los módulos de seguridad hardware, los dispositivos de pago y los proveedores de servicio deben quedar cubiertos por una obligación contractual de divulgación criptográfica y agilidad criptográfica. Como esto depende de los ciclos de renovación y no del esfuerzo de ingeniería, tiene el plazo de entrega más largo de todo el programa y debe empezar primero.

¿Deberíamos esperar a que el instrumental madure antes de empezar?
No, y el argumento del instrumental suele ser un sustituto del argumento presupuestario. Ya hay implementaciones abiertas que emiten inventarios criptográficos CycloneDX desde el fuente y desde imágenes de contenedor, y la especificación es una norma ratificada. La restricción del hito de 2028 es la cobertura y el alcance contractual, no la disponibilidad de herramientas.

Referencias

Parlamento Europeo y Consejo de la Unión Europea, 2022. Regulation (EU) 2022/2554 sobre la resiliencia operativa digital del sector financiero (DORA). Bruselas: Diario Oficial de la Unión Europea. Disponible en: Parlamento Europeo y Consejo de la Unión Europea, 2022..
National Cyber Security Centre, 2025. Calendarios para la migración a la criptografía poscuántica. Londres: NCSC. Disponible en: National Cyber Security Centre, 2025..
National Institute of Standards and Technology, 2024. NIST IR 8547 (borrador público inicial), Transición a las normas de criptografía poscuántica. Gaithersburg: Departamento de Comercio de EE. UU. Disponible en: National Institute of Standards and Technology, 2024..
National Institute of Standards and Technology, 2024. FIPS 203, norma de mecanismo de encapsulación de claves basado en retículos modulares. Gaithersburg: Departamento de Comercio de EE. UU. Disponible en: National Institute of Standards and Technology, 2024..
OWASP Foundation, 2026. Especificación de lista de materiales CycloneDX (ECMA-424). Wakefield: OWASP Foundation. Disponible en: OWASP Foundation, 2026..
OWASP CycloneDX, 2026. Cryptography Bill of Materials (CBOM). Wakefield: OWASP Foundation. Disponible en: OWASP CycloneDX, 2026..
IBM Research, 2026. CBOM: Cryptography Bill of Materials. Armonk: IBM. Disponible en: IBM Research, 2026..

Última revisión 2026-08-05.

Volver a publicar este artículo

No se puede migrar lo que no se enumera: el CBOM que la banca no tiene — Sebastien Rousseau

El plazo de descubrimiento del NCSC para 2028 llega antes que cualquier migración. La banca no puede cumplirlo: el registro DORA no anota la criptografía.

Este artículo se publica bajo Creative Commons Attribution 4.0 International. La republicación requiere atribución a la URL canónica.

No se puede migrar lo que no se enumera: el CBOM que la banca no tiene — Sebastien Rousseau

El plazo de descubrimiento del NCSC para 2028 llega antes que cualquier migración. La banca no puede cumplirlo: el registro DORA no anota la criptografía.

Originally published at https://sebastienrousseau.com/es/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER