Cyber Resilience Act: hay incidentes que deben notificarse en 24 horas, pero ¿afecta a tu empresa?

Desde el 11 de septiembre de 2026 se aplica una de las primeras obligaciones importantes del Cyber Resilience Act (CRA): determinados fabricantes de productos con elementos digitales deben comunicar las vulnerabilidades explotadas activamente y los incidentes graves que afecten a la seguridad de esos productos.

Y el primer aviso debe realizarse, cuando corresponda, en un máximo de 24 horas desde que el fabricante tiene conocimiento.

Pero antes de pensar que esto afecta a cualquier empresa que sufra un ciberataque, conviene aclarar algo importante:

No todas las empresas están obligadas a comunicar sus incidentes en 24 horas. Y utilizar ordenadores, aplicaciones, páginas web o servicios en la nube no significa estar sujeto al CRA.

Vamos a verlo sin complicarlo más de lo necesario.

¿Qué es el Cyber Resilience Act?

El Cyber Resilience Act, o Reglamento de Ciberresiliencia, es una normativa europea que establece requisitos de ciberseguridad para los denominados productos con elementos digitales.

La idea es relativamente sencilla: los productos digitales que se comercializan en la Unión Europea deben incorporar la seguridad desde su diseño y mantener un nivel adecuado de seguridad durante su ciclo de vida.

Hablamos, dependiendo del caso, de productos como:

• programas informáticos;
• aplicaciones;
• dispositivos conectados;
• equipos electrónicos;
• productos IoT;
• firmware;
• componentes de software;
• hardware conectado;
• soluciones que combinan dispositivos y elementos digitales.

La mayor parte de las obligaciones del CRA serán aplicables a partir del 11 de diciembre de 2027.

Sin embargo, las obligaciones de los fabricantes relacionadas con la notificación de vulnerabilidades explotadas activamente e incidentes graves se aplican desde el 11 de septiembre de 2026.

¿Qué cambia desde el 11 de septiembre de 2026?

Los fabricantes sujetos al CRA tienen que prestar especial atención a dos situaciones.

Vulnerabilidades explotadas activamente

No se trata de comunicar cualquier vulnerabilidad encontrada en un programa o dispositivo.

La obligación se refiere a las vulnerabilidades explotadas activamente, es decir, aquellas respecto de las que existen evidencias fiables de que un actor malicioso las ha explotado.

Cuando el fabricante tiene conocimiento de una de estas vulnerabilidades, el proceso de notificación comienza con un aviso temprano en un máximo de 24 horas.

Posteriormente debe realizar una notificación más completa, en un máximo de 72 horas desde que tuvo conocimiento de la vulnerabilidad.

Y el proceso no termina ahí: debe presentarse también un informe final, como máximo 14 días después de que esté disponible una medida correctora o de mitigación.

Incidentes graves de seguridad

También deben notificarse los incidentes graves que tengan un impacto sobre la seguridad de un producto con elementos digitales.

El CRA establece criterios concretos para determinar cuándo un incidente tiene esa consideración, por lo que no cualquier problema técnico o incidente de seguridad activa automáticamente esta obligación.

Cuando sí estamos ante uno de estos incidentes, los plazos vuelven a ser muy reducidos:

• 24 horas para el aviso temprano desde que el fabricante tiene conocimiento;
• 72 horas para la notificación del incidente con información adicional y una primera evaluación;
• un mes desde la notificación de 72 horas para presentar el informe final.

Las notificaciones se realizan a través de la Single Reporting Platform (SRP), la plataforma establecida por ENISA para centralizar estas comunicaciones.

Entonces… ¿todas las pymes tienen ahora 24 horas para comunicar un ciberataque?

No.

Y probablemente esta sea la aclaración más importante de todo el artículo.

Una empresa que utiliza Microsoft 365, un ERP, un antivirus, una página web, ordenadores, un NAS o cualquier otra herramienta tecnológica no se convierte por ello en fabricante de un producto con elementos digitales.

Pensemos en una pyme que utiliza tecnología simplemente para desarrollar su actividad.

Si se descubre una vulnerabilidad explotada activamente en uno de los productos que utiliza, la obligación de notificación del CRA corresponderá, cuando proceda, al fabricante de ese producto, no a la empresa simplemente por utilizarlo.

Otra cuestión diferente es que el mismo incidente pueda generar obligaciones para esa empresa por otras normativas. Por ejemplo, si se produce una brecha de seguridad que afecta a datos personales.

Por eso es importante no mezclar obligaciones.

¿Y si mi empresa desarrolla software?

Aquí ya tenemos que mirar el caso con más detalle.

El CRA puede afectar directamente a empresas que desarrollan y comercializan software bajo su nombre o marca.

Por ejemplo, merece la pena revisar especialmente situaciones relacionadas con:

• programas que se descargan e instalan;
• aplicaciones móviles;
• plugins y extensiones;
• componentes de software;
• firmware;
• aplicaciones instaladas en servidores del cliente;
• software integrado en maquinaria o dispositivos;
• productos IoT;
• soluciones que combinan hardware y elementos digitales.

Si tu empresa desarrolla este tipo de soluciones, conviene realizar una evaluación específica de aplicabilidad del CRA antes de dar por hecho que queda dentro o fuera.

¿Una página web está afectada por el CRA?

Una página web corporativa normal no está, por el simple hecho de ser una web, dentro del ámbito del CRA.

Tener una web con información de la empresa, formularios de contacto, un blog o funcionalidades similares no convierte automáticamente a la organización en fabricante de un producto con elementos digitales.

Por tanto, una empresa no debe interpretar que por tener una página web tiene ahora una nueva obligación de notificar incidentes en 24 horas derivada del CRA.

¿Y una aplicación web o un SaaS?

Este es uno de los puntos donde hay que tener más cuidado.

No podemos aplicar una regla tan sencilla como:

“Es software, por tanto le aplica el CRA”.

Los servicios cloud y los modelos SaaS (Software as a Service) tienen particularidades propias. Un servicio prestado exclusivamente a través de Internet no debe considerarse automáticamente un producto sujeto al CRA.

No es lo mismo, por ejemplo, una aplicación que el cliente descarga e instala que una solución a la que accede mediante navegador y que se ejecuta completamente en la infraestructura del proveedor.

Pero tampoco conviene concluir automáticamente que cualquier solución SaaS queda fuera.

Hay que analizar qué se ofrece realmente, cómo se pone a disposición del cliente y qué relación tiene ese servicio con otros productos o componentes digitales.

Especial atención al SaaS asociado a un producto

Aquí tenemos otro escenario.

Imaginemos un fabricante que comercializa un dispositivo conectado y ese dispositivo necesita una plataforma cloud del propio fabricante para realizar determinadas funciones.

No siempre podremos separar ambos elementos diciendo simplemente:

“El dispositivo está sujeto al CRA, pero la plataforma es SaaS y no”.

El Reglamento contempla las denominadas soluciones de procesamiento remoto cuando son necesarias para que un producto con elementos digitales realice sus funciones.

En estos casos hay que analizar el conjunto de la solución y no únicamente cada pieza por separado.

¿Y el software desarrollado exclusivamente para uso interno?

Si una empresa desarrolla una aplicación exclusivamente para utilizarla dentro de su propia organización y no la introduce en el mercado, la situación es diferente a la de un fabricante que comercializa un producto con elementos digitales.

Por tanto, desarrollar software internamente no convierte por sí solo a una empresa en fabricante sujeto al CRA.

Eso sí: como siempre, si existen circunstancias particulares, habrá que analizar el caso concreto.

¿Qué ocurre con el software desarrollado a medida para un cliente?

Aquí tampoco conviene sacar conclusiones automáticas.

Habrá que analizar cuestiones como:

• quién desarrolla el software;
• quién lo comercializa o pone a disposición;
• bajo qué nombre o marca se ofrece;
• quién asume el papel de fabricante;
• cómo se entrega o instala;
• si existe posteriormente explotación comercial;
• y cuál es la relación contractual entre las partes.

Dos soluciones técnicamente muy parecidas pueden tener un encaje diferente dependiendo de cómo se desarrollen, entreguen y comercialicen.

Un mismo incidente puede activar varias normativas

Este es otro punto importante.

Un mismo incidente de ciberseguridad puede tener implicaciones bajo diferentes normas.

Por ejemplo:

CRA: si afecta a un producto con elementos digitales sujeto al Reglamento y se cumplen los requisitos correspondientes.

RGPD: si se produce una brecha de seguridad de datos personales y concurren las circunstancias que generan obligaciones de notificación o comunicación.

NIS2: cuando afecta a una entidad incluida en su ámbito y se cumplen los requisitos establecidos.

DORA: en determinadas entidades del sector financiero sujetas a esta normativa.

Esto significa que, ante un incidente, ya no basta con preguntarnos:

“¿Tenemos que comunicarlo?”

La pregunta debería ser:

“¿Qué normativas pueden haberse activado y qué tenemos que hacer en cada una?”

Porque los plazos no tienen por qué ser los mismos y algunos pueden empezar a contar desde las primeras horas.

¿Cómo saber si el CRA afecta a mi empresa?

Antes de preparar procedimientos, formularios y sistemas de notificación hay que resolver una cuestión mucho más básica:

¿Estamos realmente dentro del ámbito del CRA?

Como primera aproximación, podemos hacernos estas preguntas:

• ¿La empresa fabrica o desarrolla un producto digital?
• ¿Es hardware, software o una combinación de ambos?
• ¿Se comercializa o pone a disposición de terceros?
• ¿Se ofrece bajo nuestra propia marca?
• ¿El software se descarga, instala o distribuye?
• ¿Se trata exclusivamente de un servicio web o SaaS?
• ¿Existe una aplicación móvil, plugin, firmware o componente distribuido?
• ¿El producto se conecta directa o indirectamente a un dispositivo o una red?
• ¿Existe un servicio cloud necesario para que el producto realice sus funciones?
• ¿Qué papel tenemos: fabricante, importador, distribuidor u otro?

Con estas respuestas podemos hacer una primera evaluación de aplicabilidad del Cyber Resilience Act.

Y merece la pena empezar precisamente por ahí.

Porque no tiene sentido implantar procedimientos y documentación pensados para el CRA si nuestra empresa realmente no está dentro de su ámbito.

¿Qué deberían hacer ahora las empresas a las que sí puede afectar?

Sin alarmismos por el plazo de 24 horas, sí hay una realidad: cuando llegue un incidente no habrá mucho tiempo para empezar a estudiar qué hacer.

Por eso, las empresas potencialmente afectadas deberían trabajar al menos en estos puntos:

1. Identificar qué productos pueden estar sujetos al CRA.
2. Determinar qué papel desempeña la empresa respecto de cada producto.
3. Revisar cómo se detectan y gestionan actualmente las vulnerabilidades e incidentes.
4. Establecer quién debe valorar el incidente y tomar decisiones.
5. Preparar un procedimiento interno de notificación.
6. Tener identificados los plazos y canales de comunicación.
7. Coordinar el CRA con los procedimientos existentes relacionados con RGPD, NIS2 u otras normativas aplicables.
8. Documentar las decisiones adoptadas y conservar las evidencias necesarias.

Con un primer plazo de 24 horas, empezar a buscar qué dice el Reglamento cuando el incidente ya está encima no parece la mejor estrategia.

No todo es CRA, pero merece la pena comprobarlo

Desde el 11 de septiembre no todas las empresas europeas tienen que comunicar sus incidentes de ciberseguridad en 24 horas.

Pero sí existe una nueva obligación que puede ser muy relevante para fabricantes y desarrolladores de determinados productos digitales.

Y hay una consecuencia práctica que va más allá del CRA.

Gestionar bien un incidente de ciberseguridad ya no consiste únicamente en solucionar el problema técnico.

Hay que saber qué ha ocurrido, valorar sus consecuencias, identificar qué obligaciones pueden haberse activado, tomar decisiones y, cuando corresponda, notificar dentro del plazo establecido.

La normativa bien aplicada no consiste en comunicar todo “por si acaso”. Consiste en tener claro qué te aplica, qué tienes que hacer y quién debe hacerlo cuando llega el problema.

Y eso, con plazos de 24 horas, es mejor tenerlo preparado antes.