Cyber Resilience Act desde el 11 de septiembre de 2026: La obligación de notificación de 24 horas, para la que los equipos de seguridad IT deben establecer procesos ahora

7 minutos de lectura

A partir del 11 de septiembre de 2026, la obligación de notificación del Cyber Resilience Act para vulnerabilidades activamente explotadas será efectiva: 24 horas para una alerta temprana, 72 horas para la notificación completa y 14 días para el informe final. Aquellos que hoy no tengan un proceso de respuesta a incidentes preparado para el CRA no cumplirán los plazos en caso de una crisis real. Para los fabricantes de productos con elementos digitales quedan cinco meses de margen – y son insuficientes.

Lo más importante en resumen

• El Cyber Resilience Act está en vigor desde el 11 de diciembre de 2024. La obligación de notificar vulnerabilidades activamente explotadas e incidentes graves se aplicará desde el 11 de septiembre de 2026 (EU Digital Strategy, 2026).
• La plena aplicabilidad del CRA, con todos los requisitos técnicos para productos con elementos digitales, comenzará el 11 de diciembre de 2027.
• La cadena de notificación es de tres niveles: Alerta Temprana en 24 horas, Notificación Completa en 72 horas, y Reporte Final en 14 días tras disponer de la medida de corrección.
• Las notificaciones se realizan a través de la Plataforma Única de Reporte del CRA al CSIRT competente en el país de sede principal. ENISA recibe la información paralelamente sin necesidad de notificación adicional.
• Las SBOM (Software Bill of Materials) no son una recomendación, sino un componente obligatorio de la gestión de vulnerabilidades. Sin transparencia de componentes, una notificación no puede fundamentarse adecuadamente.

Lo que exige concretamente la obligación de notificación del CRA desde septiembre de 2026

El Cyber Resilience Act es la primera regulación europea de seguridad cibernética para productos. Se dirige a fabricantes, importadores y distribuidores de productos con elementos digitales -es decir, prácticamente todo lo que contiene software o está conectado. Se ven afectados tanto los proveedores tradicionales de software como los fabricantes de hardware con sistemas embebidos, los proveedores de electrodomésticos conectados, sensores industriales, pasarelas IoT y productos con actualizaciones de firmware. La aplicación completa está 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.

Esta obligación de notificación es operativamente la parte más crítica del CRA. Vincula directamente a los equipos de seguridad IT con procesos regulatorios y crea una interfaz dura entre la gestión de vulnerabilidades y la comunicación con autoridades. Los productos que se comercializan después de la fecha límite quedan sujetos en su totalidad a la obligación de notificación. Para productos existentes se aplican disposiciones transitorias, pero cuando se lance una actualización, el fabricante debe poder cumplir con la cadena de notificación del CRA.

El BSI (Oficina Federal de Seguridad Informática de Alemania) ha dejado claro, dentro de su iniciativa de consulta sobre el CRA, que se trata de obligaciones de notificación operativas, no de documentación formal de cumplimiento. Los plazos son estrictos. Los destinatarios están definidos claramente. Los contenidos de las notificaciones son exigentes tanto técnica como sustancialmente. Un informe estándar impulsado por marketing no basta -se requieren datos precisos sobre productos afectados, exploits, estado de mitigación y disponibilidad de patches.

El cronograma 24-72-14: Cadena de notificación en detalle

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ón activa. Desde ese momento, hay 24 horas para emitir una alerta temprana, que contiene la información básica sobre la vulnerabilidad, el producto afectado y el estado de conocimiento. La alerta temprana no es una notificación completa, sino una señal de aviso preliminar para las autoridades.

Dentro de las 72 horas posteriores al mismo momento de conocimiento, debe seguir la notificación completa. Esta contiene detalles sobre el tipo de vulnerabilidad, las versiones del producto afectado, las primeras recomendaciones de mitigación y el estado actual del procesamiento del incidente. No cumplir con el plazo de 72 horas constituye una violación de una de las obligaciones centrales de cumplimiento de la CRA. La consecuencia práctica es que los procesos de respuesta a incidentes, dentro del primer día laborable después del descubrimiento, deben funcionar no solo técnicamente, sino también ser aptos para la notificación regulatoria.

El tercer paso es el informe final. Para vulnerabilidades explotadas activamente, existe un plazo de 14 días 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íodo se amplía a un mes. El informe final documenta la causa raíz, las medidas tomadas, el estado de la implementación del patch y las lecciones aprendidas para futuras versiones del producto. Es la base para las auditorías posteriores por parte de ENISA y las autoridades nacionales.

Quién informa en la empresa y a dónde

Las notificaciones de la CRA se gestionan centralmente mediante la Plataforma de Información Única de la CRA – un sistema de notificación operado por ENISA que prevé una única entrada. El fabricante dirige formalmente la notificación al Equipo de Respuesta a Incidentes de Seguridad Informática (CSIRT) en el estado miembro donde tiene su sede principal. En Alemania, la autoridad competente es el BSI (Oficina Federal de Seguridad Informática) o el CERT Bund. La información se transmite simultáneamente a ENISA, excepto en casos excepcionales claramente definidos con intereses de seguridad especiales.

Para empresas con múltiples centros de producción o filiales en distintos estados de la UE, la regla de la sede principal es determinante. Esta establece qué CSIRT es competente, qué directrices nacionales se aplican y a quién contactar en caso de consultas. Las corporaciones con estructuras mixtas deben documentar claramente esta asignación y definir internamente quién activará la notificación en caso de emergencia. Un responsable de producto sin autorización para la comunicación con autoridades no cumple con los requisitos de la CRA.

Internamente en la empresa, la notificación de la CRA requiere una responsabilidad definida. Normalmente reside en el Equipo de Respuesta a Incidentes de Seguridad de Producto (PSIRT), con conexión directa a la oficina del CISO (Director de Seguridad Informática). Aquellas empresas que actualmente no tienen un PSIRT deben establecer esta función antes de la fecha límite. La alternativa sería obligar a los equipos de desarrollo a participar ad hoc en el proceso de notificación – esto no es escalable y no cumple con los plazos de 24 horas. La cuestión de los recursos humanos es al menos tan importante como la preparación técnica.

Lo que un proceso de respuesta a incidentes conforme al CRA debe lograr

Un proceso conforme al CRA se basa en tres pilares: Detección, Evaluación y Notificación. La Detección significa que el fabricante identifica la explotación activa de forma temprana – mediante el monitoreo de sus productos, el análisis de fuentes de inteligencia sobre amenazas (Threat Intelligence Feeds), los canales de divulgación coordinada de vulnerabilidades (Coordinated Vulnerability Disclosure) y la integración en estructuras de ISAC (Centros de Análisis e Intercambio de Información sobre Seguridad). Un fabricante que solo actúa tras las quejas de los clientes está en una posición deficiente, porque alcanza el umbral de conocimiento tarde y el reloj de 24 horas comienza a correr simultáneamente con la evaluación del incidente.

La Evaluación implica poder determinar la relevancia de una notificación en pocas horas. ¿La vulnerabilidad reportada está siendo explotada activamente o es solo teóricamente explotable? ¿Qué versiones del producto están afectadas? ¿Existen ya medidas de mitigación o se necesita desarrollar un hotfix? Esta capacidad de evaluación requiere un SBOM (Lista de Materiales de Software) actualizado, entornos de reproducción testados y una matriz de escalada clara. Los equipos que hoy tardan varios días en completar la evaluación necesitan inversiones en procesos y herramientas.

La Notificación es el último pilar y simultáneamente el punto donde confluyen la obligación de cumplimiento normativo y la realidad técnica. Los contenidos de la notificación deben ser estructurados, precisos y jurídicamente sólidos. El CSIRT (Equipo de Respuesta a Incidentes de Seguridad Informática) no espera comunicación de marketing, sino datos técnicos al nivel de un CVE (Identificador de Vulnerabilidad Común), marcas de tiempo claras y pasos de mitigación verificables. Quien en una situación crítica tenga que traducir entre desarrollo, departamento legal y comunicación, pierde tiempo. Textos modelo y plantillas consensuadas son una preparación obligatoria.

SBOM como requisito técnico

La Ley de Resiliencia Cibernética (CRA) exige explícitamente la creación y mantenimiento de una Software Bill of Materials (SBOM) como base para la gestión de vulnerabilidades. Una SBOM es una lista legible por máquina 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ápidamente qué productos están afectados. Los plazos de notificación se vuelven prácticamente imposibles de cumplir entonces.

Los dos formatos SBOM más comunes son SPDX y CycloneDX. Ambos son legibles por máquina, compatibles con herramientas y conformes con la ENISA (la Agencia de la Unión Europea para la Ciberseguridad). Para su implementación, se recomienda la generación durante el proceso de compilación -las SBOMs generadas únicamente desde el repositorio suelen ser incompletas, porque no reflejan adecuadamente las dependencias binarias y las librerías 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ón DACH (Alemania, Austria, Suiza) y proporcionan resultados válidos.

El mantenimiento continuo es crucial. Una SBOM creada solo en el momento del lanzamiento queda obsoleta en días si se actualizan las dependencias. Las organizaciones maduras para el CRA gestionan las SBOMs como artefactos vivos, versionados con cada compilación y disponibles en un repositorio central. En caso de incidente grave, se puede entonces determinar en minutos mediante consulta qué versiones de producto contienen una librería afectada -el requisito previo para una notificación rápida.

Calendario: Qué debe aplicarse y en qué momento

Fuentes: EU Digital Strategy, Portal CRA del BSI, Hogan Lovells Insights 2026

Análisis de brechas: seis preguntas para evaluar los procesos internos

Antes de implementar medidas, se recomienda realizar un análisis de brechas estructurado basado en seis preguntas operativas. Estas pueden responderse en medio día con el equipo del CISO y proporcionarán un plan de acción claro:

1. Nivel de conocimiento: ¿Cómo se informa actualmente la empresa sobre vulnerabilidades activamente explotadas en sus productos? ¿Existe una política de divulgación coordinada de vulnerabilidades con tiempos de respuesta cortos? ¿Se evalúa la inteligencia sobre amenazas filtrada específicamente para los productos propios?
2. Capacidad de triaje: ¿Puede el departamento de seguridad evaluar, en un plazo de tres a cuatro horas, si una vulnerabilidad reportada representa una explotación activa? ¿Existen entornos de reproducción para todas las versiones de software en producción?
3. Actualidad de la SBOM: ¿Se genera y mantiene una SBOM actualizada para cada producto entregado? ¿Son las SBOM legibles y consultables por máquinas, o se exportan como PDF en un wiki?
4. Responsabilidad de notificación: ¿Quién en la empresa está autorizado para enviar una notificación CRA al BSI (la Oficina Federal de Seguridad de la Información de Alemania)? ¿Existe una disponibilidad 24/7 para esta función? ¿Cómo se coordina con el departamento legal y la comunicación?
5. Textos modelo: ¿Existen plantillas previamente coordinadas para la alerta temprana, la notificación completa y el informe final? ¿Están aprobadas por el departamento legal y completadas técnicamente?
6. Estado de los ejercicios: ¿Se ha probado ya la cadena de notificación CRA en condiciones simuladas? Los ejercicios de mesa con escalonamiento cronometrado revelan lagunas en los procesos antes que resulten costosas en una situación real.

Quien pueda responder todas las seis preguntas con un «sí» sólido, está preparado para la CRA. Quien tenga que pasar en dos o más preguntas, necesita inmediatamente una hoja de ruta concreta con calendario hasta agosto de 2026 – un mes de margen antes de la fecha límite es el mínimo.

Conclusion

La CRA establece una fecha límite regulatoria muy exigente, el 11 de septiembre de 2026, que hasta ahora no formaba parte del derecho de productos alemán. La obligación de notificar vulnerabilidades activamente explotadas no es un documento de cumplimiento, sino un proceso operativo que debe funcionar en 24 horas. Los equipos de seguridad IT necesitan una responsabilidad clara, caminos de escalada definidos, SBOMs actualizadas y textos de notificación preparados. La construcción técnica es viable en cinco meses, pero solo si se comienza ahora con el análisis de deficiencias.

La parte que se subestima es la organizativa: quién notifica, bajo qué autorización, en base a qué fundamento legal. Sin una responsabilidad clarificada, las preparaciones técnicas se diluyen en caso de emergencia. Para la mayoría de fabricantes de la región DACH (Alemania, Austria, Suiza), la creación de un Equipo de Respuesta a Incidentes de Seguridad del Producto es el paso crucial – y este no debería empezar solo el 1 de septiembre.

Preguntas frecuentes

Cada pregunta está bloqueada. Un toque desbloquea la respuesta.