[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:es:cuando-empieza-el-reloj-de-24-horas-del-cra-tener-conocimiento":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"es","cuando-empieza-el-reloj-de-24-horas-del-cra-tener-conocimiento","¿Cuándo empieza el reloj de 24 horas del CRA? «Tener conocimiento», según las orientaciones de la Comisión","Las 24 y las 72 horas corren desde el momento en que el fabricante «tiene conocimiento», y el Reglamento nunca dice qué significa eso. Las orientaciones de la Comisión del 27 de julio de 2026 sí lo dicen, en los apartados 211 a 218: un grado razonable de certeza, tras una evaluación inicial, tomado palabra por palabra del reglamento de ejecución de NIS2 y de las directrices sobre brechas de datos del RGPD. Qué convierte eso en un correo de un cliente, una alerta del escáner, una CVE listada en un componente, un zero-day de bug bounty y una vulnerabilidad que ya conocía antes del 11 de septiembre.","2026-09-11","\nEl artículo 14(2)(a) del Cyber Resilience Act, Reglamento (UE) 2024\u002F2847, da al fabricante 24 horas «desde que el fabricante tenga conocimiento de la vulnerabilidad explotada activamente» para presentar una alerta temprana, y el artículo 14(4)(a) dice lo mismo para un incidente grave. La notificación de 72 horas corre desde el mismo momento. Todo aquello por lo que se juzgará a un fabricante en los tres primeros días de un incidente depende de cuándo fue ese momento, y el Reglamento no lo define. Define aquello de lo que hay que tener conocimiento: el artículo 3(42) dice que una vulnerabilidad explotada activamente es aquella «respecto de la cual existen pruebas fiables de que un agente malintencionado la ha explotado en un sistema sin el permiso del propietario del sistema». No dice cuándo las pruebas fiables se convierten en conocimiento.\n\nLas orientaciones de la Comisión sobre la aplicación del Reglamento, C(2026) 5252 de 27 de julio de 2026, sí lo dicen, en la sección 9.1, apartados 211 a 218. Este artículo son esos ocho apartados, con los dos textos anteriores de los que están copiados, aplicados a las cinco maneras en que un fabricante se entera de verdad.\n\n## La prueba: un grado razonable de certeza, tras una evaluación inicial\n\nEl apartado 213 es la frase operativa. Un fabricante que detecta un suceso sospechoso, o al que «un particular, un cliente, una entidad, una autoridad, un medio de comunicación u otra fuente» se lo pone en conocimiento, «debe evaluar el suceso sospechoso inmediatamente para determinar si constituye una vulnerabilidad explotada activamente o un incidente grave», y:\n\n> Por tanto, debe considerarse que el fabricante ha tenido conocimiento cuando, tras esa evaluación inicial, tiene un grado razonable de certeza de que: (i) una vulnerabilidad contenida en su producto con elementos digitales está siendo explotada activamente; o (ii) se ha producido un incidente grave que ha dado lugar a que la seguridad de su producto con elementos digitales se vea comprometida.\n\nDe ahí se siguen tres cosas, y el apartado 214 explicita dos. El momento no es la primera señal: «el momento en que puede considerarse que un fabricante tiene conocimiento dependerá de las circunstancias», y «en otros casos, puede llevar algún tiempo establecer si un producto con elementos digitales está afectado por una vulnerabilidad y si esa vulnerabilidad está siendo explotada por un agente malintencionado». La evaluación no es opcional ni lenta: «el énfasis debe ponerse en actuar con prontitud para llevar a cabo la evaluación inicial y determinar si esas condiciones se cumplen efectivamente, en particular cuando la vulnerabilidad pueda plantear un riesgo significativo». Y, según el apartado 215, no se espera que lo sepa todo en la hora 24: la estructura en tres fases «exige a los fabricantes actualizar sus notificaciones progresivamente, a medida que avanzan sus investigaciones internas».\n\nAsí que el reloj no empieza ni cuando llega el correo ni cuando termina el análisis forense. Empieza cuando una evaluación inicial rápida alcanza una certeza razonable de que su producto está siendo explotado, o de que un incidente grave ha comprometido su seguridad. La palabra que hace el trabajo es «prontitud», y por eso la evaluación tiene que ser un procedimiento con hora de inicio y responsable, en vez de una reunión que alguien convocará.\n\n## De dónde vienen las palabras\n\nEl apartado 212 dice que las orientaciones «están alineadas con el considerando 31 del Reglamento de Ejecución (UE) 2024\u002F2690 de la Comisión y con la sección II(A) de las Directrices 9\u002F2022 sobre la notificación de violaciones de la seguridad de los datos personales en virtud del RGPD». Esa alineación no es laxa. El considerando 31 del reglamento de ejecución de NIS2 dice: cuando una entidad «haya detectado un suceso sospechoso, o después de que un tercero, como un particular, un cliente, una entidad, una autoridad, un medio de comunicación u otra fuente, haya puesto en su conocimiento un posible incidente, la entidad pertinente debe evaluar oportunamente el suceso sospechoso», y «por tanto debe considerarse que ha tenido \"conocimiento\" del incidente significativo cuando, tras esa evaluación inicial, tiene un grado razonable de certeza de que se ha producido un incidente significativo». Las directrices del CEPD sobre violaciones, en el apartado 31, dicen que debe considerarse que un responsable del tratamiento «ha tenido \"conocimiento\" cuando tiene un grado razonable de certeza de que se ha producido un incidente de seguridad que ha dado lugar a que los datos personales se vean comprometidos», y el apartado 34 permite «un breve periodo de investigación» durante el cual el responsable «puede no considerarse \"consciente\"», siempre que la investigación «comience lo antes posible».\n\nLa consecuencia práctica es grande para una empresa que ya tiene un procedimiento de brechas del RGPD, es decir, cualquier empresa con clientes. El desencadenante del CRA es el mismo, aplicado a la seguridad del producto en lugar de a los datos personales. El procedimiento, la evaluación, las dos marcas de tiempo y la persona que decide pueden ser los mismos, y una empresa que también notifica bajo NIS2 tiene tres obligaciones funcionando sobre una sola definición.\n\n## Cinco maneras de enterarse, y qué pone en marcha cada una\n\nLas FAQ de la Comisión sobre la aplicación, versión 1.4 de 4 de septiembre de 2026, sección 5.1, enumeran cómo puede tener conocimiento un fabricante sin obligarle a vigilar ninguno de esos canales: un cliente o socio que informa de actividad inusual, inteligencia de amenazas, la notificación de una agencia gubernamental, el informe de un hacker ético, la propia telemetría, los escaneos o los honeypots del fabricante. Leída junto con las orientaciones, cada señal es un «suceso sospechoso» que pone en marcha la evaluación, no el reloj.\n\n**Un correo de un cliente.** La evaluación empieza cuando se lee el correo, y tiene que ser inmediata. Si las pruebas del cliente son lo que la definición llama fiables, la evaluación puede llevar una hora, y el reloj empieza entonces. Un equipo que deja el correo hasta el lunes no mueve el reloj al lunes: la «prontitud» del apartado 214 es el criterio con el que una autoridad de vigilancia del mercado contrastará la cronología, y la única defensa es un registro que muestre cuándo empezó la evaluación, quién la hizo y qué concluyó.\n\n**Una alerta del escáner de que la CVE de un componente está en una lista de vulnerabilidades explotadas.** Es el caso con el que la mayoría de las empresas de software se encontrará primero, y el apartado 218 lo responde. Un fabricante notifica una vulnerabilidad explotada activamente «contenida en su producto». Si sabe que un componente de terceros contiene una vulnerabilidad que «o bien (i) no puede explotarse en su producto con elementos digitales (por ejemplo, porque el código vulnerable no es alcanzable) o bien (ii) no ha sido explotada en su producto con elementos digitales, esa vulnerabilidad no se considera una vulnerabilidad explotada activamente contenida en su producto con elementos digitales y, por tanto, no está sujeta a notificación obligatoria para ese fabricante». Así que una inclusión en una lista es un suceso sospechoso. La evaluación hace dos preguntas: ¿es alcanzable el código vulnerable en nuestro producto?, y ¿hay pruebas fiables de que se está explotando en nuestro producto, y no solo en el de otro? Una certeza razonable sobre ambas pone en marcha el reloj; una certeza razonable en contra de cualquiera de las dos cierra el asunto como notificación obligatoria, dejando la vía voluntaria del artículo 15 y el deber del artículo 13(6) de comunicar la vulnerabilidad aguas arriba al mantenedor del componente. La sección 5.4 de las FAQ añade que el fabricante del propio componente, si el componente se introdujo en el mercado por separado, también la notifica.\n\n**Un zero-day de un bug bounty o de un laboratorio de pruebas.** Ni vulnerabilidad explotada activamente ni notificación obligatoria. FAQ 5.2: un zero-day «descubierto por hackers éticos, del que no hay pruebas de explotación malintencionada previa y que se comunica al fabricante del producto en el marco de su programa de bug bounty» no está sujeto a notificación obligatoria, ni tampoco uno hallado por «un laboratorio de evaluación de ciberseguridad que realiza pruebas por cuenta del fabricante». El considerando 68 dice lo mismo de la investigación de buena fe. Las obligaciones de gestión de vulnerabilidades del anexo I, parte II, siguen aplicándose íntegramente; la notificación, no.\n\n**Una vulnerabilidad que ya conocía antes del 11 de septiembre de 2026.** El apartado 217 traza la línea en la explotación, no en la vulnerabilidad. Un fabricante «no está obligado a notificar vulnerabilidades de cuya explotación activa ya tenía conocimiento antes del 11 de septiembre de 2026». Pero «la obligación sí se aplica cuando el fabricante conocía una vulnerabilidad antes del 11 de septiembre de 2026 pero no tenía, en ese momento, conocimiento de ninguna explotación activa de la misma». Si la explotación se produce, o usted se entera, después de esa fecha, el reloj empieza el día en que se entera. Una vulnerabilidad antigua no es defensa; un conocimiento antiguo de su explotación, sí.\n\n**Un incidente grave.** El segundo inciso del apartado 213: certeza razonable de que «se ha producido un incidente grave que ha dado lugar a que la seguridad de su producto con elementos digitales se vea comprometida». Que un incidente sea grave lo decide el artículo 14(5): afecta o puede afectar a la capacidad del producto para proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes, o ha dado lugar o puede dar lugar a la introducción o ejecución de código malicioso en el producto o en los sistemas de un usuario. Una caída que no toca nada de eso es un incidente, pero no una notificación. La evaluación tiene, por tanto, una tercera pregunta para los incidentes: cuál de los dos incisos del artículo 14(5) se cumple, y la respuesta va en el campo de evaluación inicial de la notificación de 72 horas.\n\n## El alcance de la obligación es más amplio que el resto del Reglamento\n\nEl apartado 210 hace dos observaciones que sorprenden. El artículo 14 se aplica desde el 11 de septiembre de 2026 a todo producto con elementos digitales dentro del ámbito, «incluidos los productos con elementos digitales introducidos en el mercado antes del 11 de diciembre de 2027». Y la obligación de notificar sobrevive al periodo de soporte: «a diferencia de las obligaciones de gestión de vulnerabilidades, que solo se mantienen durante el periodo de soporte de un producto, las obligaciones de notificación siguen aplicándose después de que un producto con elementos digitales deje de recibir soporte». Para un producto introducido en el mercado antes de diciembre de 2027 o cuyo periodo de soporte ha terminado, el fabricante sigue teniendo que notificar, pero «no está obligado a cumplir las obligaciones de gestión de vulnerabilidades establecidas en la parte II del anexo I». Las FAQ, 5.3, reconocen que para productos antiguos el fabricante «puede no estar en condiciones de investigar esas vulnerabilidades» porque los entornos de compilación y el personal ya no existen, y dicen que la notificación sigue debiéndose.\n\n## Después de la notificación: los usuarios, y qué no publicar\n\nLos apartados 219 a 221 tratan del artículo 14(8), el deber de informar a los usuarios afectados «y, cuando proceda, a todos los usuarios». Las orientaciones lo leen de forma basada en el riesgo: informar a los usuarios «no implica que esa información deba hacerse pública o divulgarse indiscriminadamente», y los fabricantes «pueden limitar la divulgación de información detallada a los usuarios o clientes afectados», en particular en productos «utilizados en entornos sensibles o esenciales, donde la divulgación pública de detalles técnicos podría aumentar por sí misma los riesgos de ciberseguridad». Una divulgación más amplia «puede ser apropiada» una vez mitigada la vulnerabilidad, y el anexo I, parte II, punto 4, exige la divulgación pública de las vulnerabilidades corregidas una vez disponible la actualización de seguridad. El CSIRT que recibió la notificación puede informar a los usuarios por sí mismo si el fabricante no lo hace a tiempo.\n\n## Qué escribir antes de necesitarlo\n\nLas orientaciones convierten «tener conocimiento» en una constatación en vez de un hecho, y las constataciones necesitan un procedimiento. Basta una página.\n\n1. **Qué cuenta como suceso sospechoso.** La lista de las FAQ, más sus propios canales: la dirección de contacto de seguridad que exige el anexo I, el escáner, la cola de atención al cliente, las noticias.\n2. **Quién hace la evaluación inicial, y para cuándo.** Una persona con nombre y un suplente, y un tope para la evaluación medido en horas. «Inmediatamente» y «prontitud» son las palabras de la Comisión; un tope que usted fija y cumple es cómo demuestra que las respetó.\n3. **Las dos preguntas, en los términos de la Comisión.** Para una vulnerabilidad: ¿está en nuestro producto y es alcanzable?, y ¿hay pruebas fiables de explotación en nuestro producto? Para un incidente: ¿se ha producido?, ¿ha comprometido la seguridad del producto?, y ¿qué inciso del artículo 14(5) se aplica?\n4. **Dos marcas de tiempo, ambas en UTC.** Cuándo se detectó o recibió el suceso sospechoso, y cuándo la evaluación alcanzó certeza razonable. La segunda es «tener conocimiento» y pone en marcha el reloj; la primera, y la distancia entre ambas, es lo que demuestra que la evaluación fue rápida. La plataforma de notificación pide la segunda y, para una vulnerabilidad, solo tendrá el campo en una versión posterior, así que su propio registro es el único que existe ese día.\n5. **Quién firma la constatación, y dónde se archiva.** La persona que decide que se ha alcanzado la certeza razonable, y el registro que la autoridad de vigilancia del mercado leerá si alguna vez se cuestiona la cronología.\n\nEse registro es lo que es el evento de notificación CRA de StandardOS: una determinación del ámbito, el notificante y el suplente con nombre, el coordinador que seleccionar, una marca de tiempo del conocimiento con el razonamiento al lado, y los tres plazos calculados a partir de ella en los términos del Reglamento y no en los de la plataforma. [La página de plazos](\u002Fcyber-resilience-act\u002Freporting-deadlines) los calcula para cualquiera; [cómo recibe después la plataforma la notificación](\u002Farticles\u002Fhow-to-file-a-cra-notification-on-enisa-s-single-reporting-platform) es el artículo siguiente, y [qué coordinador la recibe](\u002Farticles\u002Fwhich-csirt-do-you-report-to-under-cra-article-14) el anterior.\n\n## Fuentes\n\n- Reglamento (UE) 2024\u002F2847, artículo 3(42), artículo 13(6), artículo 14(1) a (5) y (8), artículo 15, artículo 69(3), considerando 68.\n- Comisión Europea, orientaciones de la Comisión sobre la aplicación del Reglamento (UE) 2024\u002F2847, C(2026) 5252 final de 27 de julio de 2026, anexo, sección 9.1 apartados 209 a 221 y sección 9.2.\n- Comisión Europea, FAQ sobre el Cyber Resilience Act, versión 1.4 de 4 de septiembre de 2026, secciones 5.1 a 5.5.\n- Reglamento de Ejecución (UE) 2024\u002F2690 de la Comisión, considerando 31.\n- Comité Europeo de Protección de Datos, Directrices 9\u002F2022 sobre la notificación de violaciones de la seguridad de los datos personales en virtud del RGPD, versión 2.0, apartados 31 a 34.\n\nEsto no es asesoramiento jurídico. Los ocho apartados de las orientaciones se leen en diez minutos, y los números de artículo de arriba están ahí para que pueda hacerlo.\n",1789383977057]