El artículo 14 es el que pone en marcha el reloj

¿No sabes si el CRA se aplica a tu producto? Comprueba tu clase de riesgo en cuatro pasos.

1. Qué exige el artículo 14

El artículo 14 impone al fabricante de un producto con elementos digitales el deber de notificar dos tipos de sucesos: cualquier vulnerabilidad explotada activamente presente en el producto, y cualquier incidente grave que afecte a la seguridad de ese producto. El deber se dirige al CSIRT designado como coordinador y, en paralelo, a ENISA, a través de la plataforma única de notificación.

El obligado es el fabricante, no el revendedor ni el usuario final: quien desarrolla o fabrica el producto, o lo manda desarrollar o fabricar y lo comercializa con su nombre o marca, soporta el deber. El ámbito es el producto introducido en el mercado, con independencia de cuándo se vendiera por primera vez. Un producto en el mercado desde hace años entra plenamente en el ámbito.

2. Los tres plazos, en dos cadenas paralelas

Cada suceso notificable pasa por tres pasos: una alerta temprana, una notificación de vulnerabilidad y un informe final. Los dos primeros plazos son idénticos en ambas cadenas —24 horas para la alerta temprana, 72 horas para la notificación—, pero el informe final tiene dos plazos distintos según lo que se notifique. Confundirlos es el error más frecuente en los procedimientos internos que nos enseñan.

Cadena uno, vulnerabilidades explotadas activamente: alerta temprana en 24 horas desde el conocimiento; notificación de vulnerabilidad en 72 horas; informe final en 14 días desde que está disponible una medida correctora o de mitigación. El plazo final se ancla a la disponibilidad de la corrección, no al calendario.

Cadena dos, incidentes graves que afectan a la seguridad del producto: alerta temprana en 24 horas, notificación en 72 horas, y después un informe final en el plazo de un mes desde la notificación. Los dos primeros pasos son iguales, el anclaje del último es distinto. Como el cálculo del plazo final depende de cómo se calificó el suceso en el primer paso, la calificación debe registrarse junto con el artículo aplicado.

3. Explotada no es lo mismo que notificada

La cadena de las vulnerabilidades no arranca con cada vulnerabilidad. Arranca solo cuando existen pruebas fiables de que alguien ha explotado la vulnerabilidad en un sistema sin autorización del propietario. La divulgación responsable de un investigador, un artículo académico, un escáner que señala una biblioteca vieja: nada de esto, por sí solo, pone en marcha el reloj de 24 horas, porque nada de esto es prueba de una explotación no autorizada en la práctica.

Esta distinción corta en ambos sentidos. Notificar de menos te expone a una sanción; notificarlo todo quema credibilidad ante el CSIRT y consume el tiempo que necesitarás para los casos reales. La decisión de que una notificación no es —o todavía no es— una vulnerabilidad explotada activamente debe tomarse rápido y, sobre todo, por escrito: un «no» motivado es una defensa, un «no» implícito no deja rastro el día que un inspector pregunta por qué no presentaste.

4. El reloj arranca desde el conocimiento, no desde el lunes

Las 24 horas corren desde el momento en que la empresa tiene conocimiento del suceso. No desde que el responsable abre el correo, ni desde el lunes por la mañana, ni desde la reunión de coordinación. Si una notificación llega a la dirección pública a las 23:40 de un sábado, ese es el instante que tendrás que defender ante el CSIRT y, si llega el caso, ante la autoridad de vigilancia del mercado.

Esto traslada el problema del terreno técnico al organizativo. De ahí se derivan tres cosas: un único canal de entrada atendido, que alguien vigile de verdad; una regla de calificación por escrito que diga quién decide si el reloj ha arrancado y con qué criterios; y una cadena de guardia con umbrales horarios y sustitutos nombrados. Las empresas que hemos visto en apuros no tenían un problema de competencia — tenían un problema de disponibilidad.

5. Dos deberes que casi todos olvidan

El primero es el aviso a los usuarios. Tras notificar a las autoridades, y sin demora indebida, el fabricante informa a los usuarios del producto sobre el incidente o la vulnerabilidad y, cuando proceda, sobre las medidas correctoras o de mitigación que pueden adoptar. Debe conservarse copia de lo difundido y de cuándo: el aviso a los usuarios es una obligación por derecho propio, no una cortesía.

El segundo es la notificación aguas arriba. Si la vulnerabilidad está en un componente de terceros —incluido uno de código abierto—, el fabricante debe notificarla a la persona o entidad que mantiene el componente y cooperar con ella. Este deber, previsto en el art. 13(6), es materialmente imposible sin una lista de materiales de software actualizada: sin SBOM no sabes qué productos tuyos incorporan el componente ni a quién escribir.

6. Sanciones: cuánto, y qué las atenúa

Los incumplimientos de las obligaciones de los artículos 13 y 14 —entre las que están los deberes de notificación descritos— se sancionan con multas administrativas de hasta 15 millones de euros o, si el infractor es una empresa, hasta el 2,5 % de su volumen de negocios mundial total anual del ejercicio anterior, si esta cuantía fuese superior. Es el tramo más alto del régimen sancionador del reglamento, y se aplica a los deberes de notificación, no solo a la no conformidad del producto.

La cuantía no es automática. Al fijar la multa la autoridad pondera la naturaleza y la gravedad del incumplimiento, su duración, si fue intencionado o negligente, y el grado de cooperación con las autoridades. En la práctica es aquí donde la diligencia documentada rinde: una decisión de calificación por escrito, un registro de entrada con marcas de tiempo y pruebas de cooperación rápida cambian el desenlace de un mismo hecho.

7. Qué hacer antes del 11 de septiembre de 2026

Tres cosas operativas, por orden de urgencia. Un canal público de recepción de notificaciones, acompañado de una política de divulgación coordinada publicada donde los investigadores la buscan: un fichero security.txt en tu dominio. Una regla de calificación por escrito que diga quién decide si el reloj ha arrancado y con qué criterios. Una cadena de guardia con umbrales horarios y sustitutos nombrados, para que el caso del sábado por la noche tenga responsable.

Después dos requisitos administrativos que corren en calendarios ajenos: las credenciales EU Login necesarias para llegar a la plataforma de notificación, y la designación de tu punto de contacto ante el CSIRT nacional. Pedirlos el día de la emergencia significa llegar tarde por un motivo que no tiene nada de técnico. Identifica de antemano a las personas que puedan actuar como representante designado (Assigned Representative) en la plataforma, y completa el registro y la asociación a la plataforma única de notificación siguiendo las indicaciones de ENISA vigentes en el momento de notificar: el procedimiento puede evolucionar, no lo des por fijo. CRAnotify prepara la presentación pero no automatiza el envío final en la SRP: no existe una API automática de la SRP, y la presentación sigue siendo un acto del fabricante, hecho con sus propias credenciales. El cómo está en la página dedicada.

El resto —el registro de productos, la lista de materiales de software, las integraciones— se construye en los meses siguientes. Pero sin estas cinco cosas listas, la primera notificación real te pillará al descubierto, y esa primera notificación puede llegar el día después del 11 de septiembre de 2026.

Este artículo expone nuestra lectura del texto normativo y no constituye asesoramiento jurídico.