La aplicación plena del CRA comienza el 11 de diciembre de 2027. A partir de esa fecha, todo producto con elementos digitales introducido en el mercado de la UE deberá llevar marcado CE, y el marcado CE exige un SBOM conforme. El anexo I, parte II, punto 1, es la cláusula operativa: los fabricantes deben «identificarán y documentarán las vulnerabilidades y los componentes presentes en el producto con elementos digitales, también mediante la elaboración de una nomenclatura de materiales de los programas informáticos en un formato comúnmente utilizado y legible por máquina, que incluya, como mínimo, las dependencias de máximo nivel del producto». Esa frase determina el formato, el alcance y el lugar que debe ocupar el SBOM en tu expediente técnico. Esta página explica exactamente lo que la ley exige y lo que no.
Resumen
- Los SBOM son obligatorios bajo el anexo I, parte II, punto 1, para todo producto con elementos digitales
- El formato debe ser legible por máquina (CycloneDX o SPDX; los PDF y las hojas de cálculo no cumplen el requisito)
- Cobertura mínima: dependencias de máximo nivel del producto; la cobertura transitiva es una práctica recomendada, pero queda por encima del mínimo legal
- El SBOM forma parte de la documentación técnica del anexo VII (punto 2(b), con el punto 8 que regula las copias a petición de la vigilancia del mercado)
- La obligación es continua: los desencadenantes de actualización incluyen cada versión de firmware, cambio de componente y descubrimiento de vulnerabilidad
- Aplicación plena: 11 de diciembre de 2027; el plazo de notificación de vulnerabilidades comienza el 11 de septiembre de 2026
Las obligaciones de SBOM en el CRA
El CRA hace referencia a los SBOM en dos secciones clave:
Anexo I: requisitos esenciales
El texto oficial del anexo I, parte II, punto 1, establece:
«identificarán y documentarán las vulnerabilidades y los componentes presentes en el producto con elementos digitales, también mediante la elaboración de una nomenclatura de materiales de los programas informáticos en un formato comúnmente utilizado y legible por máquina, que incluya, como mínimo, las dependencias de máximo nivel del producto»
Esto significa que:
- Los SBOM son obligatorios, no opcionales
- Deben estar en formato legible por máquina (no PDF ni hojas de cálculo)
- Deben cubrir como mínimo las dependencias de máximo nivel del producto; la cobertura de dependencias transitivas es una práctica recomendada, pero va más allá del mínimo legal
Todo producto con elementos digitales introducido en el mercado de la UE debe tener un SBOM legible por máquina. No existe exención ni umbral de tamaño por debajo del cual desaparezca la obligación.
Anexo VII: documentación técnica
El expediente técnico del anexo VII incluye el SBOM en dos puntos:
- Punto 2(b): la descripción de los procesos de gestión de las vulnerabilidades «incluida la nomenclatura de materiales de los programas informáticos» debe formar parte de la documentación técnica conservada por el fabricante.
- Punto 8: «cuando proceda, la nomenclatura de materiales de los programas informáticos, previa solicitud motivada por parte de una autoridad de vigilancia del mercado, siempre que sea necesario para que dicha autoridad pueda comprobar el cumplimiento de los requisitos esenciales de ciberseguridad establecidos en el anexo I».
El SBOM no se presenta de forma proactiva. Debe existir en el momento en que el producto se introduce en el mercado de la UE y estar disponible para las autoridades a petición.
El SBOM incluido en el anexo VII debe permitir:
- Seguimiento de vulnerabilidades a nivel de componente
- Identificación del proveedor
- Verificación del cumplimiento de licencias
- Planificación del fin de vida útil
Qué debe incluir tu SBOM del anexo VII
La documentación técnica tiene tres dimensiones obligatorias para el SBOM: formato, contenido y alcance. La tabla siguiente refleja lo que comprobarán las autoridades de vigilancia del mercado.
| Categoría | Requisito | Fuente |
|---|---|---|
| Formato | Legible por máquina (CycloneDX o SPDX) | Anexo I, parte II, punto 1 |
| Formato | Resumen legible por personas | Práctica recomendada |
| Contenido | Todos los componentes de software listados | Anexo I |
| Contenido | Versiones de componentes especificadas | Anexo I |
| Contenido | Información del proveedor | Anexo I; TR-03183 |
| Contenido | Información de licencias | TR-03183 |
| Contenido | Vulnerabilidades conocidas en el momento de la evaluación | Anexo VII, punto 2(b) |
| Alcance | Dependencias directas (de máximo nivel) | Anexo I (mínimo legal) |
| Alcance | Dependencias transitivas | TR-03183 (práctica recomendada) |
| Alcance | Componentes del sistema operativo cuando proceda | TR-03183 |
| Alcance | Bibliotecas de terceros | Anexo I |
Para los requisitos de campo específicos que van más allá de esta lista (identificadores PURL, valores hash, metadatos del documento), consulta cómo BSI TR-03183 amplía el CRA. Para comparar las herramientas de CycloneDX y SPDX, consulta CycloneDX vs SPDX.
Cómo es una entrada de SBOM conforme
Una entrada correctamente estructurada en el expediente técnico del anexo VII hace referencia al archivo legible por máquina y registra el estado de vulnerabilidades en el momento de la evaluación:
SOFTWARE BILL OF MATERIALS
Product: SmartSense Pro (SSP-3000)
Firmware Version: 2.4.1
SBOM Format: CycloneDX 1.5
Generated: 2027-01-15
Tool: Trivy + syft
SBOM FILE:
sbom-ssp3000-v2.4.1.json (attached)
COMPONENT SUMMARY:
-------------------------------------------------------------
Total Components: 127
Direct Dependencies: 23
Transitive Dependencies: 104
By Type:
Libraries: 98
Frameworks: 12
Operating System: 1 (FreeRTOS)
Firmware Modules: 16
VULNERABILITY STATUS AT ASSESSMENT:
-------------------------------------------------------------
Scan Date: 2027-01-15
Scanner: Trivy v0.48.0
Critical: 0
High: 0
Medium: 2 (accepted - see below)
ACCEPTED VULNERABILITIES:
CVE-2026-XXXXX (Medium): Component xyz v1.2.3
Status: Not exploitable in our configuration
Justification: Feature not enabled, code path not reachable
Review Date: 2027-04-15
-------------------------------------------------------------
SBOM UPDATE COMMITMENT:
SBOM will be updated with each firmware release and made
available to customers upon request.
Cuándo actualizar tu SBOM
El SBOM no es un documento puntual. El expediente técnico debe mantenerse actualizado durante todo el ciclo de vida del producto.
Desencadenantes de actualización obligatorios:
| Desencadenante | Qué cambia | ¿Requiere actualización del SBOM? |
|---|---|---|
| Nueva versión de firmware o software | Nuevo artefacto de compilación | Sí, regeneración completa |
| Publicación de parche de seguridad | Versión del componente actualizada | Sí, componentes afectados |
| Vulnerabilidad descubierta y abordada | Estado VEX o de explotabilidad | Sí, campos VEX |
| Componente añadido, eliminado o sustituido | Grafo de dependencias | Sí, regeneración completa |
| Cambio de diseño que afecta a la seguridad | Componentes y arquitectura | Sí, regeneración completa |
| Cambio en la norma armonizada aplicada | Referencia a la norma | Sí, metadatos |
Revisiones periódicas:
| Cadencia | Alcance |
|---|---|
| Trimestral | SBOM y estado de vulnerabilidades |
| Anual | Revisión completa del expediente técnico |
| Antes del fin del período de soporte | Congelación final de la documentación |
La creación manual del SBOM es propensa a errores y no escala entre versiones de producto. Cada compilación debe producir un artefacto SBOM actualizado. Consulta los errores más comunes en el SBOM para ver qué sale mal cuando los equipos omiten la automatización.
Requisitos de conservación
El artículo 13(13) exige que los fabricantes mantengan la documentación técnica y la declaración UE de conformidad a disposición de las autoridades de vigilancia del mercado «durante un mínimo de diez años a partir de la introducción en el mercado del producto con elementos digitales, o durante el período de soporte si este plazo fuera más largo». El plazo comienza desde la última unidad introducida en el mercado, no desde la primera.
| Hito | Fecha de ejemplo |
|---|---|
| Producto introducido por primera vez en el mercado | Marzo de 2027 |
| Última unidad introducida en el mercado | Diciembre de 2030 |
| Conservación de la documentación hasta (mínimo 10 años) | Diciembre de 2040 |
Conserva el SBOM en un almacenamiento seguro y accesible con procedimientos de copia de seguridad, protección de integridad y capacidad de recuperar y suministrarlo ante una solicitud motivada de una autoridad de vigilancia del mercado. El punto 8 del anexo VII especifica que el SBOM se facilita «previa solicitud motivada» y no de forma proactiva.
Aplicación y sanciones
La aplicación plena del CRA comienza el 11 de diciembre de 2027. La obligación de notificación de vulnerabilidades del artículo 14 comienza antes, el 11 de septiembre de 2026. Los productos introducidos en el mercado de la UE después de diciembre de 2027 sin un SBOM conforme no podrán llevar marcado CE y no podrán venderse legalmente en la UE. Para el calendario completo y el desglose de sanciones, consulta plazos y sanciones del SBOM en el CRA.
Preguntas frecuentes
¿El CRA exige un SBOM legible por máquina o se acepta un PDF?
El anexo I exige explícitamente formato legible por máquina. Un PDF no es aceptable. CycloneDX o SPDX serializados como JSON o XML satisfacen el requisito. Una hoja de cálculo o un documento legible por personas no lo hacen.
¿El CRA exige un SBOM para los componentes de código abierto?
Sí. El anexo I establece que los fabricantes deben documentar los componentes en un SBOM legible por máquina sin ninguna excepción para el código abierto. Si una biblioteca de código abierto está en tu producto, debe aparecer en tu SBOM con información de versión e identificador.
¿Cuándo debe presentarse el SBOM: al introducir el producto en el mercado o a petición?
El SBOM no necesita presentarse de forma proactiva. Debe formar parte del expediente técnico (anexo VII), disponible para las autoridades de vigilancia del mercado a petición. Debe existir en el momento en que el producto se introduce en el mercado de la UE.
¿Cuáles son los elementos mínimos de la NTIA y satisfacen los requisitos del CRA?
Los elementos mínimos de la NTIA (nombre del proveedor, nombre del componente, versión, identificadores únicos, relaciones de dependencia, autor del SBOM y marca de tiempo) están ampliamente alineados con lo que el CRA y BSI TR-03183 exigen en el nivel básico. Son un punto de partida razonable, pero los campos obligatorios de TR-03183 van más lejos: los valores hash y los identificadores PURL son necesarios para el cumplimiento del CRA.
¿Puedo reutilizar los SBOM de mis proveedores para cumplir el CRA?
Parcialmente. Los SBOM de los proveedores son una entrada válida para los componentes que suministran, y el CRA espera que los fabricantes aprovechen la documentación de la cadena de suministro. Pero la obligación del anexo I recae sobre el fabricante del producto integrado: debes producir y mantener un SBOM para el producto tal como se comercializa, lo que significa consolidar los SBOM de los proveedores con tus propios componentes de primera parte y dependencias de compilación. Si al SBOM de un proveedor le faltan campos exigidos por BSI TR-03183 (PURL, hash, licencia), eres responsable de cubrir esas lagunas. Trata los SBOM de los proveedores como materia prima, no como un artefacto de cumplimiento terminado.