El 11 de septiembre de 2026 el Cyber Resilience Act (Reglamento (UE) 2024/2847) enciende su régimen de notificación. Desde esa fecha, cualquier fabricante de un producto con elementos digitales vendido en la Unión Europea dispone de 24 horas para dar una alerta temprana en cuanto detecta que una de sus vulnerabilidades se está explotando de forma activa, o que ha sufrido un incidente grave que afecta a la seguridad del producto.
El detalle que se pasa por alto es quién queda obligado. La notificación de incidentes que casi todo el mundo asocia a NIS2 recae sobre las entidades esenciales e importantes; la del CRA recae sobre quien fabrica el producto y lo pone en el mercado. Son sujetos distintos, y muchas empresas de software y hardware en España dan por hecho que, si no son entidad esencial, esto no va con ellas. Va con ellas.
El reglamento ya está en vigor. Lo que arranca en septiembre es la parte que más disciplina operativa exige: notificar rápido, con un procedimiento escrito y alguien que decida bajo presión. Merece la pena repasar qué exige exactamente, a quién obliga y qué hace falta tener preparado.
Lo principal
Lo que un comité de dirección necesita saber antes de entrar en el detalle:
- Desde el 11 de septiembre de 2026 aplica el régimen de notificación del CRA (artículo 14).
- La cascada es de tres fases: alerta temprana en 24 horas, notificación más completa en 72 horas e informe final en 14 días una vez que hay corrección (un mes para incidentes graves).
- Los avisos van al CSIRT nacional y a ENISA a través de la Plataforma Única de Notificación.
- Obliga al fabricante de productos con elementos digitales —hardware y software—, incluidos los que ya están comercializados.
- El grueso del reglamento (requisitos esenciales, marcado CE) es plenamente aplicable el 11 de diciembre de 2027.
- Las sanciones alcanzan los 15 millones de euros o el 2,5 % de la facturación mundial (artículo 64).
Qué arranca el 11 de septiembre
El CRA introduce una obligación de notificación para dos supuestos concretos: una vulnerabilidad que se está explotando de forma activa, y un incidente grave que afecte a la seguridad del producto. No es cualquier fallo ni cualquier incidencia: el detonante es la explotación activa o el impacto grave, y ahí está la primera decisión operativa que hay que tener resuelta de antemano.
Las tres fases del plazo
Según recogen los análisis de Crowell & Moring y Hogan Lovells sobre el artículo 14, la notificación se escalona: una alerta temprana dentro de las 24 horas siguientes a tener constancia del hecho; una notificación más detallada dentro de las 72 horas; y un informe final a los 14 días, una vez existe una corrección o medida de mitigación disponible. Para los incidentes graves, el informe final se amplía a un mes. Los envíos se dirigen al CSIRT nacional y a ENISA a través de la Plataforma Única de Notificación, que el reglamento exige tener operativa para esa fecha.
El plazo corto no premia el informe perfecto, sino el aviso a tiempo: la alerta de las 24 horas comunica lo que se sabe, y el detalle llega después. Lo que no admite la mecánica es descubrir, en mitad de un incidente, que nadie sabe quién redacta ni quién aprueba ese primer aviso.
A qué productos afecta
El perímetro es amplio. Según el resumen oficial del reglamento de la Comisión Europea, el CRA es la primera norma europea que fija requisitos obligatorios de ciberseguridad para los productos con elementos digitales —hardware y software— a lo largo de todo su ciclo de vida. La obligación de notificación no se limita a los lanzamientos nuevos: cubre también los productos que ya estaban en el mercado. Los requisitos completos de seguridad desde el diseño y el marcado CE se aplican por entero el 11 de diciembre de 2027, pero la parte de notificación se adelanta a septiembre de 2026.
«Esto es cosa de las grandes»: por qué medio sector cree que no le toca
Sobre el papel la obligación es clara; en la práctica choca con cuatro creencias muy extendidas entre fabricantes españoles:
- «Somos una pyme, esto es para multinacionales».
- «Vendemos un servicio en la nube, no un producto».
- «Integramos código abierto; la responsabilidad es de la comunidad».
- «Ya pasamos la ISO 27001 y nos estamos preparando para NIS2; con eso vamos servidos».
Ninguna de las cuatro resiste el texto del reglamento. Cada una esconde un malentendido distinto sobre qué regula el CRA, y hay que verlas por separado.
Por qué sí te obliga
El tamaño no te exime
A diferencia de NIS2, que fija umbrales por tamaño y sector para decidir quién es entidad esencial o importante, la obligación de notificar del CRA se ata al producto puesto en el mercado, no a la plantilla ni a la facturación. Una pyme que fabrica un dispositivo conectado o distribuye una aplicación queda dentro por lo que vende, no por lo que factura.
La frontera SaaS/producto es justo donde hay que mirar
El argumento del «servicio, no producto» es el que más matiz exige. El CRA cubre los productos con elementos digitales y las soluciones de procesamiento remoto de datos que forman parte del producto. Un servicio en la nube puramente autónomo puede caer bajo NIS2 en su lugar; pero los componentes remotos que son parte integral de un producto entran en el alcance del CRA. El criterio no es la etiqueta comercial, sino si ese componente forma parte del producto que se pone en el mercado, y eso se analiza caso a caso, no se despacha con un «nosotros hacemos SaaS».
El código abierto no traslada tu responsabilidad
Como explica el análisis de Hogan Lovells, el fabricante debe ejercer diligencia sobre el software de código abierto que integra en su producto y gestionar y notificar sus vulnerabilidades. El reglamento crea la figura del «administrador de software libre», con deberes propios y más ligeros; pero quien toma componentes abiertos y comercializa con ellos un producto sigue siendo el fabricante a efectos del CRA. Aquí un SBOM deja de ser una buena práctica y pasa a ser la base para saber qué te afecta cuando aparece un fallo en un componente de terceros.
NIS2 e ISO 27001 no cubren esta obligación
Es el malentendido más costoso. NIS2 regula cómo operas como organización; el CRA regula lo que vendes. La ISO 27001 es un sistema de gestión que ordena tus controles, pero no sustituye una obligación legal de notificar en 24 horas al regulador. Regulan cosas distintas, y por eso separar ciberseguridad y cumplimiento como si fueran compartimentos deja huecos precisamente aquí: la empresa cumple sus marcos y aun así no tiene resuelto quién da la voz de alarma del CRA.
Qué hace falta tener listo
El reglamento no pide un plan a plazos; pide capacidad de detectar, decidir y notificar, con la evidencia que lo respalde. Eso se traduce en cinco piezas que hace falta tener en pie antes de septiembre, no como proyecto eterno sino como músculo que se pueda ejercitar:
Un proceso de gestión y divulgación coordinada de vulnerabilidades —un PSIRT o su equivalente— con un canal de recepción, responsables definidos y un flujo claro desde que entra un aviso hasta que se decide qué hacer. Es la base de la que sale, si hace falta, la notificación al regulador. Aquí encaja el servicio de gestión de vulnerabilidades que muchas organizaciones ya tienen a medias.
Un inventario del software que compone cada producto, mantenido y no un PDF de hace dos años, para saber en minutos a qué productos afecta un fallo publicado en una biblioteca de terceros.
Capacidad de distinguir «explotación activa» de una vulnerabilidad más. Sin telemetría, inteligencia de amenazas y un umbral acordado, el plazo de 24 horas se convierte en una discusión improvisada justo cuando no hay tiempo para tenerla.
Un procedimiento de notificación escrito y ensayado: quién redacta la alerta temprana, quién la aprueba, cómo se envía a ENISA y al CSIRT y cómo se documenta todo para el informe posterior. Un simulacro vale más que un manual sin estrenar.
Encaje con lo que ya tienes. Los controles de ISO 27001 y la preparación de NIS2 dan base, pero el disparador y el plazo del CRA son propios: hay que mapearlos sobre tus procesos existentes y no suponer que ya están cubiertos.
Lo que cuesta ignorarlo
El régimen sancionador tiene tres tramos. Según el resumen del artículo 64 de Taylor Wessing, el incumplimiento de los requisitos esenciales (Anexo I) y de las obligaciones nucleares del fabricante —los artículos 13 y 14, que incluyen precisamente la notificación— se sanciona con hasta 15 millones de euros o el 2,5 % de la facturación mundial anual, la cifra que sea mayor. Otras obligaciones, incluidas las de importadores y distribuidores y las de evaluación de conformidad, llegan a 10 millones o el 2 %. Facilitar información incorrecta o engañosa a las autoridades se sanciona con hasta 5 millones o el 1 %.
Importadores y distribuidores no quedan al margen: asumen deberes secundarios de verificación y comunicación. Para quien monta su oferta sobre productos de terceros, esto conecta con la gestión de riesgo de terceros y con las lecciones recientes sobre la cadena de suministro digital.
La decisión no es solo del equipo de producto
El plazo de 24 horas fuerza una decisión de gobierno antes de que ocurra el incidente: quién da la voz de alarma, quién firma la alerta temprana y cómo se coordinan producto, seguridad y asesoría legal cuando solo quedan horas para actuar. La seguridad del producto deja de ser un asunto solo de ingeniería y pasa a ser uno de gobierno, igual que NIS2 puso la responsabilidad del incidente sobre la mesa de la dirección.
El 11 de septiembre no cambia lo que hay que construir; cambia el margen. La empresa que hoy no sabe quién enviaría esa alerta temprana, ni con qué datos, lo descubrirá en mitad de un incidente y con el plazo corriendo. El trabajo previo no es redactar el aviso ideal, sino ensayar las primeras 24 horas hasta que dejen de resolverse sobre la marcha.
Este artículo es divulgación técnica y no constituye asesoramiento jurídico. Las obligaciones, plazos y fechas del Cyber Resilience Act deben verificarse contra el texto oficial del Reglamento (UE) 2024/2847 y las guías de ENISA y de la autoridad competente; la información recogida corresponde a la fecha de publicación. Para evaluar cómo aplica a un producto concreto, consulta con tu asesoría legal y tu responsable de cumplimiento.