Lo m\u00e1s importante en resumen<\/h2>\n\n- El Cyber Resilience Act est\u00e1 en vigor desde el 11 de diciembre de 2024. La obligaci\u00f3n de notificar vulnerabilidades activamente explotadas e incidentes graves se aplicar\u00e1 desde el 11 de septiembre de 2026 (EU Digital Strategy, 2026).<\/li>\n
- La plena aplicabilidad del CRA, con todos los requisitos t\u00e9cnicos para productos con elementos digitales, comenzar\u00e1 el 11 de diciembre de 2027.<\/li>\n
- La cadena de notificaci\u00f3n es de tres niveles: Alerta Temprana en 24 horas, Notificaci\u00f3n Completa en 72 horas, y Reporte Final en 14 d\u00edas tras disponer de la medida de correcci\u00f3n.<\/li>\n
- Las notificaciones se realizan a trav\u00e9s de la Plataforma \u00danica de Reporte del CRA al CSIRT competente en el pa\u00eds de sede principal. ENISA recibe la informaci\u00f3n paralelamente sin necesidad de notificaci\u00f3n adicional.<\/li>\n
- Las SBOM (Software Bill of Materials) no son una recomendaci\u00f3n, sino un componente obligatorio de la gesti\u00f3n de vulnerabilidades. Sin transparencia de componentes, una notificaci\u00f3n no puede fundamentarse adecuadamente.<\/li>\n<\/ul>\n
Lo que exige concretamente la obligaci\u00f3n de notificaci\u00f3n del CRA desde septiembre de 2026<\/h2>\n
El Cyber Resilience Act es la primera regulaci\u00f3n europea de seguridad cibern\u00e9tica para productos. Se dirige a fabricantes, importadores y distribuidores de productos con elementos digitales -es decir, pr\u00e1cticamente todo lo que contiene software o est\u00e1 conectado. Se ven afectados tanto los proveedores tradicionales de software como los fabricantes de hardware con sistemas embebidos, los proveedores de electrodom\u00e9sticos conectados, sensores industriales, pasarelas IoT y productos con actualizaciones de firmware. La aplicaci\u00f3n completa est\u00e1 programada para el 11 de diciembre de 2027, pero un bloque esencial de obligaciones entra en vigor antes: desde el 11 de septiembre de 2026, los fabricantes deben notificar vulnerabilidades activamente explotadas y incidentes graves de seguridad.<\/p>\n
Esta obligaci\u00f3n de notificaci\u00f3n es operativamente la parte m\u00e1s cr\u00edtica del CRA. Vincula directamente a los equipos de seguridad IT con procesos regulatorios y crea una interfaz dura entre la gesti\u00f3n de vulnerabilidades y la comunicaci\u00f3n con autoridades. Los productos que se comercializan despu\u00e9s de la fecha l\u00edmite quedan sujetos en su totalidad a la obligaci\u00f3n de notificaci\u00f3n. Para productos existentes se aplican disposiciones transitorias, pero cuando se lance una actualizaci\u00f3n, el fabricante debe poder cumplir con la cadena de notificaci\u00f3n del CRA.<\/p>\n
El BSI (Oficina Federal de Seguridad Inform\u00e1tica de Alemania) ha dejado claro, dentro de su iniciativa de consulta sobre el CRA, que se trata de obligaciones de notificaci\u00f3n operativas, no de documentaci\u00f3n formal de cumplimiento. Los plazos son estrictos. Los destinatarios est\u00e1n definidos claramente. Los contenidos de las notificaciones son exigentes tanto t\u00e9cnica como sustancialmente. Un informe est\u00e1ndar impulsado por marketing no basta -se requieren datos precisos sobre productos afectados, exploits, estado de mitigaci\u00f3n y disponibilidad de patches.<\/p>\n
\nDefinici\u00f3n<\/p>\n
Vulnerabilidad activamente explotada<\/strong> en el sentido del CRA es una vulnerabilidad para la cual existen evidencias documentadas de explotaci\u00f3n real -independientemente de si provienen de inteligencia sobre amenazas, un incidente en la propia base de clientes o una notificaci\u00f3n externa verificada. La simple existencia de un proof-of-concept no basta; lo decisivo es la prueba de uso contra un sistema productivo.<\/p>\n<\/div>\nEl cronograma 24-72-14: Cadena de notificaci\u00f3n en detalle<\/h2>\n
Los tres plazos de la CRA para vulnerabilidades explotadas activamente se superponen y obligan a los equipos de seguridad a seguir una rutina de escalada claramente cronometrada. El cronograma comienza cuando el fabricante tiene conocimiento de la explotaci\u00f3n activa. Desde ese momento, hay 24 horas para emitir una alerta temprana, que contiene la informaci\u00f3n b\u00e1sica sobre la vulnerabilidad, el producto afectado y el estado de conocimiento. La alerta temprana no es una notificaci\u00f3n completa, sino una se\u00f1al de aviso preliminar para las autoridades.<\/p>\n
Dentro de las 72 horas posteriores al mismo momento de conocimiento, debe seguir la notificaci\u00f3n completa. Esta contiene detalles sobre el tipo de vulnerabilidad, las versiones del producto afectado, las primeras recomendaciones de mitigaci\u00f3n y el estado actual del procesamiento del incidente. No cumplir con el plazo de 72 horas constituye una violaci\u00f3n de una de las obligaciones centrales de cumplimiento de la CRA. La consecuencia pr\u00e1ctica es que los procesos de respuesta a incidentes, dentro del primer d\u00eda laborable despu\u00e9s del descubrimiento, deben funcionar no solo t\u00e9cnicamente, sino tambi\u00e9n ser aptos para la notificaci\u00f3n regulatoria.<\/p>\n
El tercer paso es el informe final. Para vulnerabilidades explotadas activamente, existe un plazo de 14 d\u00edas desde la disponibilidad de una medida correctiva -es decir, desde el momento en que se puede implementar el patch. Para incidentes de seguridad graves, este per\u00edodo se ampl\u00eda a un mes. El informe final documenta la causa ra\u00edz, las medidas tomadas, el estado de la implementaci\u00f3n del patch y las lecciones aprendidas para futuras versiones del producto. Es la base para las auditor\u00edas posteriores por parte de ENISA y las autoridades nacionales.<\/p>\n
\n24 \/ 72 \/ 14<\/div>\nHoras para la alerta temprana, horas para la notificaci\u00f3n completa, d\u00edas para el informe final – el ritmo de notificaci\u00f3n de la CRA desde el 11 de septiembre de 2026<\/div>\nFuente: EU Digital Strategy, CRA Reporting Obligations 2026<\/div>\n<\/div>\nQui\u00e9n informa en la empresa y a d\u00f3nde<\/h2>\n
Las notificaciones de la CRA se gestionan centralmente mediante la Plataforma de Informaci\u00f3n \u00danica de la CRA – un sistema de notificaci\u00f3n operado por ENISA que prev\u00e9 una \u00fanica entrada. El fabricante dirige formalmente la notificaci\u00f3n al Equipo de Respuesta a Incidentes de Seguridad Inform\u00e1tica (CSIRT) en el estado miembro donde tiene su sede principal. En Alemania, la autoridad competente es el BSI (Oficina Federal de Seguridad Inform\u00e1tica) o el CERT Bund. La informaci\u00f3n se transmite simult\u00e1neamente a ENISA, excepto en casos excepcionales claramente definidos con intereses de seguridad especiales.<\/p>\n
Para empresas con m\u00faltiples centros de producci\u00f3n o filiales en distintos estados de la UE, la regla de la sede principal es determinante. Esta establece qu\u00e9 CSIRT es competente, qu\u00e9 directrices nacionales se aplican y a qui\u00e9n contactar en caso de consultas. Las corporaciones con estructuras mixtas deben documentar claramente esta asignaci\u00f3n y definir internamente qui\u00e9n activar\u00e1 la notificaci\u00f3n en caso de emergencia. Un responsable de producto sin autorizaci\u00f3n para la comunicaci\u00f3n con autoridades no cumple con los requisitos de la CRA.<\/p>\n
Internamente en la empresa, la notificaci\u00f3n de la CRA requiere una responsabilidad definida. Normalmente reside en el Equipo de Respuesta a Incidentes de Seguridad de Producto (PSIRT), con conexi\u00f3n directa a la oficina del CISO (Director de Seguridad Inform\u00e1tica). Aquellas empresas que actualmente no tienen un PSIRT deben establecer esta funci\u00f3n antes de la fecha l\u00edmite. La alternativa ser\u00eda obligar a los equipos de desarrollo a participar ad hoc en el proceso de notificaci\u00f3n – esto no es escalable y no cumple con los plazos de 24 horas. La cuesti\u00f3n de los recursos humanos es al menos tan importante como la preparaci\u00f3n t\u00e9cnica.<\/p>\n
Lo que un proceso de respuesta a incidentes conforme al CRA debe lograr<\/h2>\n
Un proceso conforme al CRA se basa en tres pilares: Detecci\u00f3n, Evaluaci\u00f3n y Notificaci\u00f3n. La Detecci\u00f3n significa que el fabricante identifica la explotaci\u00f3n activa de forma temprana – mediante el monitoreo de sus productos, el an\u00e1lisis de fuentes de inteligencia sobre amenazas (Threat Intelligence Feeds), los canales de divulgaci\u00f3n coordinada de vulnerabilidades (Coordinated Vulnerability Disclosure) y la integraci\u00f3n en estructuras de ISAC (Centros de An\u00e1lisis e Intercambio de Informaci\u00f3n sobre Seguridad). Un fabricante que solo act\u00faa tras las quejas de los clientes est\u00e1 en una posici\u00f3n deficiente, porque alcanza el umbral de conocimiento tarde y el reloj de 24 horas comienza a correr simult\u00e1neamente con la evaluaci\u00f3n del incidente.<\/p>\n
La Evaluaci\u00f3n implica poder determinar la relevancia de una notificaci\u00f3n en pocas horas. \u00bfLa vulnerabilidad reportada est\u00e1 siendo explotada activamente o es solo te\u00f3ricamente explotable? \u00bfQu\u00e9 versiones del producto est\u00e1n afectadas? \u00bfExisten ya medidas de mitigaci\u00f3n o se necesita desarrollar un hotfix? Esta capacidad de evaluaci\u00f3n requiere un SBOM (Lista de Materiales de Software) actualizado, entornos de reproducci\u00f3n testados y una matriz de escalada clara. Los equipos que hoy tardan varios d\u00edas en completar la evaluaci\u00f3n necesitan inversiones en procesos y herramientas.<\/p>\n
La Notificaci\u00f3n es el \u00faltimo pilar y simult\u00e1neamente el punto donde confluyen la obligaci\u00f3n de cumplimiento normativo y la realidad t\u00e9cnica. Los contenidos de la notificaci\u00f3n deben ser estructurados, precisos y jur\u00eddicamente s\u00f3lidos. El CSIRT (Equipo de Respuesta a Incidentes de Seguridad Inform\u00e1tica) no espera comunicaci\u00f3n de marketing, sino datos t\u00e9cnicos al nivel de un CVE (Identificador de Vulnerabilidad Com\u00fan), marcas de tiempo claras y pasos de mitigaci\u00f3n verificables. Quien en una situaci\u00f3n cr\u00edtica tenga que traducir entre desarrollo, departamento legal y comunicaci\u00f3n, pierde tiempo. Textos modelo y plantillas consensuadas son una preparaci\u00f3n obligatoria.<\/p>\n
SBOM como requisito t\u00e9cnico<\/h2>\n
La Ley de Resiliencia Cibern\u00e9tica (CRA) exige expl\u00edcitamente la creaci\u00f3n y mantenimiento de una Software Bill of Materials (SBOM) como base para la gesti\u00f3n de vulnerabilidades. Una SBOM es una lista legible por m\u00e1quina de todos los componentes software de un producto -incluyendo versiones, licencias y dependencias. Sin una SBOM, en caso de vulnerabilidad, no se puede determinar r\u00e1pidamente qu\u00e9 productos est\u00e1n afectados. Los plazos de notificaci\u00f3n se vuelven pr\u00e1cticamente imposibles de cumplir entonces.<\/p>\n
Los dos formatos SBOM m\u00e1s comunes son SPDX y CycloneDX. Ambos son legibles por m\u00e1quina, compatibles con herramientas y conformes con la ENISA (la Agencia de la Uni\u00f3n Europea para la Ciberseguridad). Para su implementaci\u00f3n, se recomienda la generaci\u00f3n durante el proceso de compilaci\u00f3n -las SBOMs generadas \u00fanicamente desde el repositorio suelen ser incompletas, porque no reflejan adecuadamente las dependencias binarias y las librer\u00edas transitivas. Herramientas como Syft, Trivy o las integraciones SBOM de los grandes gestores de paquetes se han establecido en los entornos de desarrollo de la regi\u00f3n DACH (Alemania, Austria, Suiza) y proporcionan resultados v\u00e1lidos.<\/p>\n
El mantenimiento continuo es crucial. Una SBOM creada solo en el momento del lanzamiento queda obsoleta en d\u00edas si se actualizan las dependencias. Las organizaciones maduras para el CRA gestionan las SBOMs como artefactos vivos, versionados con cada compilaci\u00f3n y disponibles en un repositorio central. En caso de incidente grave, se puede entonces determinar en minutos mediante consulta qu\u00e9 versiones de producto contienen una librer\u00eda afectada -el requisito previo para una notificaci\u00f3n r\u00e1pida.<\/p>\n
Calendario: Qu\u00e9 debe aplicarse y en qu\u00e9 momento<\/h2>\n\n
Lo que exige concretamente la obligaci\u00f3n de notificaci\u00f3n del CRA desde septiembre de 2026<\/h2>\n
El Cyber Resilience Act es la primera regulaci\u00f3n europea de seguridad cibern\u00e9tica para productos. Se dirige a fabricantes, importadores y distribuidores de productos con elementos digitales -es decir, pr\u00e1cticamente todo lo que contiene software o est\u00e1 conectado. Se ven afectados tanto los proveedores tradicionales de software como los fabricantes de hardware con sistemas embebidos, los proveedores de electrodom\u00e9sticos conectados, sensores industriales, pasarelas IoT y productos con actualizaciones de firmware. La aplicaci\u00f3n completa est\u00e1 programada para el 11 de diciembre de 2027, pero un bloque esencial de obligaciones entra en vigor antes: desde el 11 de septiembre de 2026, los fabricantes deben notificar vulnerabilidades activamente explotadas y incidentes graves de seguridad.<\/p>\n
Esta obligaci\u00f3n de notificaci\u00f3n es operativamente la parte m\u00e1s cr\u00edtica del CRA. Vincula directamente a los equipos de seguridad IT con procesos regulatorios y crea una interfaz dura entre la gesti\u00f3n de vulnerabilidades y la comunicaci\u00f3n con autoridades. Los productos que se comercializan despu\u00e9s de la fecha l\u00edmite quedan sujetos en su totalidad a la obligaci\u00f3n de notificaci\u00f3n. Para productos existentes se aplican disposiciones transitorias, pero cuando se lance una actualizaci\u00f3n, el fabricante debe poder cumplir con la cadena de notificaci\u00f3n del CRA.<\/p>\n
El BSI (Oficina Federal de Seguridad Inform\u00e1tica de Alemania) ha dejado claro, dentro de su iniciativa de consulta sobre el CRA, que se trata de obligaciones de notificaci\u00f3n operativas, no de documentaci\u00f3n formal de cumplimiento. Los plazos son estrictos. Los destinatarios est\u00e1n definidos claramente. Los contenidos de las notificaciones son exigentes tanto t\u00e9cnica como sustancialmente. Un informe est\u00e1ndar impulsado por marketing no basta -se requieren datos precisos sobre productos afectados, exploits, estado de mitigaci\u00f3n y disponibilidad de patches.<\/p>\n
Definici\u00f3n<\/p>\n
Vulnerabilidad activamente explotada<\/strong> en el sentido del CRA es una vulnerabilidad para la cual existen evidencias documentadas de explotaci\u00f3n real -independientemente de si provienen de inteligencia sobre amenazas, un incidente en la propia base de clientes o una notificaci\u00f3n externa verificada. La simple existencia de un proof-of-concept no basta; lo decisivo es la prueba de uso contra un sistema productivo.<\/p>\n<\/div>\n Los tres plazos de la CRA para vulnerabilidades explotadas activamente se superponen y obligan a los equipos de seguridad a seguir una rutina de escalada claramente cronometrada. El cronograma comienza cuando el fabricante tiene conocimiento de la explotaci\u00f3n activa. Desde ese momento, hay 24 horas para emitir una alerta temprana, que contiene la informaci\u00f3n b\u00e1sica sobre la vulnerabilidad, el producto afectado y el estado de conocimiento. La alerta temprana no es una notificaci\u00f3n completa, sino una se\u00f1al de aviso preliminar para las autoridades.<\/p>\n Dentro de las 72 horas posteriores al mismo momento de conocimiento, debe seguir la notificaci\u00f3n completa. Esta contiene detalles sobre el tipo de vulnerabilidad, las versiones del producto afectado, las primeras recomendaciones de mitigaci\u00f3n y el estado actual del procesamiento del incidente. No cumplir con el plazo de 72 horas constituye una violaci\u00f3n de una de las obligaciones centrales de cumplimiento de la CRA. La consecuencia pr\u00e1ctica es que los procesos de respuesta a incidentes, dentro del primer d\u00eda laborable despu\u00e9s del descubrimiento, deben funcionar no solo t\u00e9cnicamente, sino tambi\u00e9n ser aptos para la notificaci\u00f3n regulatoria.<\/p>\n El tercer paso es el informe final. Para vulnerabilidades explotadas activamente, existe un plazo de 14 d\u00edas desde la disponibilidad de una medida correctiva -es decir, desde el momento en que se puede implementar el patch. Para incidentes de seguridad graves, este per\u00edodo se ampl\u00eda a un mes. El informe final documenta la causa ra\u00edz, las medidas tomadas, el estado de la implementaci\u00f3n del patch y las lecciones aprendidas para futuras versiones del producto. Es la base para las auditor\u00edas posteriores por parte de ENISA y las autoridades nacionales.<\/p>\n Las notificaciones de la CRA se gestionan centralmente mediante la Plataforma de Informaci\u00f3n \u00danica de la CRA – un sistema de notificaci\u00f3n operado por ENISA que prev\u00e9 una \u00fanica entrada. El fabricante dirige formalmente la notificaci\u00f3n al Equipo de Respuesta a Incidentes de Seguridad Inform\u00e1tica (CSIRT) en el estado miembro donde tiene su sede principal. En Alemania, la autoridad competente es el BSI (Oficina Federal de Seguridad Inform\u00e1tica) o el CERT Bund. La informaci\u00f3n se transmite simult\u00e1neamente a ENISA, excepto en casos excepcionales claramente definidos con intereses de seguridad especiales.<\/p>\n Para empresas con m\u00faltiples centros de producci\u00f3n o filiales en distintos estados de la UE, la regla de la sede principal es determinante. Esta establece qu\u00e9 CSIRT es competente, qu\u00e9 directrices nacionales se aplican y a qui\u00e9n contactar en caso de consultas. Las corporaciones con estructuras mixtas deben documentar claramente esta asignaci\u00f3n y definir internamente qui\u00e9n activar\u00e1 la notificaci\u00f3n en caso de emergencia. Un responsable de producto sin autorizaci\u00f3n para la comunicaci\u00f3n con autoridades no cumple con los requisitos de la CRA.<\/p>\n Internamente en la empresa, la notificaci\u00f3n de la CRA requiere una responsabilidad definida. Normalmente reside en el Equipo de Respuesta a Incidentes de Seguridad de Producto (PSIRT), con conexi\u00f3n directa a la oficina del CISO (Director de Seguridad Inform\u00e1tica). Aquellas empresas que actualmente no tienen un PSIRT deben establecer esta funci\u00f3n antes de la fecha l\u00edmite. La alternativa ser\u00eda obligar a los equipos de desarrollo a participar ad hoc en el proceso de notificaci\u00f3n – esto no es escalable y no cumple con los plazos de 24 horas. La cuesti\u00f3n de los recursos humanos es al menos tan importante como la preparaci\u00f3n t\u00e9cnica.<\/p>\n Un proceso conforme al CRA se basa en tres pilares: Detecci\u00f3n, Evaluaci\u00f3n y Notificaci\u00f3n. La Detecci\u00f3n significa que el fabricante identifica la explotaci\u00f3n activa de forma temprana – mediante el monitoreo de sus productos, el an\u00e1lisis de fuentes de inteligencia sobre amenazas (Threat Intelligence Feeds), los canales de divulgaci\u00f3n coordinada de vulnerabilidades (Coordinated Vulnerability Disclosure) y la integraci\u00f3n en estructuras de ISAC (Centros de An\u00e1lisis e Intercambio de Informaci\u00f3n sobre Seguridad). Un fabricante que solo act\u00faa tras las quejas de los clientes est\u00e1 en una posici\u00f3n deficiente, porque alcanza el umbral de conocimiento tarde y el reloj de 24 horas comienza a correr simult\u00e1neamente con la evaluaci\u00f3n del incidente.<\/p>\n La Evaluaci\u00f3n implica poder determinar la relevancia de una notificaci\u00f3n en pocas horas. \u00bfLa vulnerabilidad reportada est\u00e1 siendo explotada activamente o es solo te\u00f3ricamente explotable? \u00bfQu\u00e9 versiones del producto est\u00e1n afectadas? \u00bfExisten ya medidas de mitigaci\u00f3n o se necesita desarrollar un hotfix? Esta capacidad de evaluaci\u00f3n requiere un SBOM (Lista de Materiales de Software) actualizado, entornos de reproducci\u00f3n testados y una matriz de escalada clara. Los equipos que hoy tardan varios d\u00edas en completar la evaluaci\u00f3n necesitan inversiones en procesos y herramientas.<\/p>\n La Notificaci\u00f3n es el \u00faltimo pilar y simult\u00e1neamente el punto donde confluyen la obligaci\u00f3n de cumplimiento normativo y la realidad t\u00e9cnica. Los contenidos de la notificaci\u00f3n deben ser estructurados, precisos y jur\u00eddicamente s\u00f3lidos. El CSIRT (Equipo de Respuesta a Incidentes de Seguridad Inform\u00e1tica) no espera comunicaci\u00f3n de marketing, sino datos t\u00e9cnicos al nivel de un CVE (Identificador de Vulnerabilidad Com\u00fan), marcas de tiempo claras y pasos de mitigaci\u00f3n verificables. Quien en una situaci\u00f3n cr\u00edtica tenga que traducir entre desarrollo, departamento legal y comunicaci\u00f3n, pierde tiempo. Textos modelo y plantillas consensuadas son una preparaci\u00f3n obligatoria.<\/p>\n La Ley de Resiliencia Cibern\u00e9tica (CRA) exige expl\u00edcitamente la creaci\u00f3n y mantenimiento de una Software Bill of Materials (SBOM) como base para la gesti\u00f3n de vulnerabilidades. Una SBOM es una lista legible por m\u00e1quina de todos los componentes software de un producto -incluyendo versiones, licencias y dependencias. Sin una SBOM, en caso de vulnerabilidad, no se puede determinar r\u00e1pidamente qu\u00e9 productos est\u00e1n afectados. Los plazos de notificaci\u00f3n se vuelven pr\u00e1cticamente imposibles de cumplir entonces.<\/p>\n Los dos formatos SBOM m\u00e1s comunes son SPDX y CycloneDX. Ambos son legibles por m\u00e1quina, compatibles con herramientas y conformes con la ENISA (la Agencia de la Uni\u00f3n Europea para la Ciberseguridad). Para su implementaci\u00f3n, se recomienda la generaci\u00f3n durante el proceso de compilaci\u00f3n -las SBOMs generadas \u00fanicamente desde el repositorio suelen ser incompletas, porque no reflejan adecuadamente las dependencias binarias y las librer\u00edas transitivas. Herramientas como Syft, Trivy o las integraciones SBOM de los grandes gestores de paquetes se han establecido en los entornos de desarrollo de la regi\u00f3n DACH (Alemania, Austria, Suiza) y proporcionan resultados v\u00e1lidos.<\/p>\n El mantenimiento continuo es crucial. Una SBOM creada solo en el momento del lanzamiento queda obsoleta en d\u00edas si se actualizan las dependencias. Las organizaciones maduras para el CRA gestionan las SBOMs como artefactos vivos, versionados con cada compilaci\u00f3n y disponibles en un repositorio central. En caso de incidente grave, se puede entonces determinar en minutos mediante consulta qu\u00e9 versiones de producto contienen una librer\u00eda afectada -el requisito previo para una notificaci\u00f3n r\u00e1pida.<\/p>\nEl cronograma 24-72-14: Cadena de notificaci\u00f3n en detalle<\/h2>\n
Qui\u00e9n informa en la empresa y a d\u00f3nde<\/h2>\n
Lo que un proceso de respuesta a incidentes conforme al CRA debe lograr<\/h2>\n
SBOM como requisito t\u00e9cnico<\/h2>\n
Calendario: Qu\u00e9 debe aplicarse y en qu\u00e9 momento<\/h2>\n
![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/03\/pexels-30965500-cisco-fmc-zero-day-250x167.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/03\/supply-chain-glassworm-2026-250x167.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/03\/pexels-279810-privileged-access-management-250x167.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/net-data-act-durchfuehrungsgesetz-iot-herste-60577565-250x141.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/net-valkey-9-redis-fork-18-monate-cloud-cach-69791755.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/net-ki-governance-2026-nur-14-prozent-haben-18715512-250x167.jpg\")
<\/span>