Cómo cumplir con la obligación de reportar vulnerabilidades en 24 horas

Qué cambió a partir del 11 de septiembre de 2026 y por qué no es NIS2

El Reglamento (UE) 2024/2847 establece normas uniformes de ciberseguridad para productos con elementos digitales, es decir, tanto para hardware como para software. Se aplicará en su totalidad a partir del 11 de diciembre de 2027, pero el artículo 14 sobre notificación se aplicará ya desde el 11 de septiembre de 2026 (Reglamento (UE) 2024/2847, art. 71). Incluso antes, a partir del 11 de junio de 2026, se aplicará el capítulo sobre organismos de evaluación de la conformidad, aunque este solo afecta a los fabricantes de forma indirecta.

Para los fabricantes, la notificación en virtud del artículo 14 es una de las obligaciones clave que comenzó a aplicarse incluso antes de la plena aplicabilidad del reglamento. Por lo tanto, las empresas no pueden esperar hasta diciembre de 2027. Sin embargo, muchos fabricantes aún no disponen del proceso necesario. También es importante saber que esta obligación se refiere al producto en sí, no a cómo la empresa opera sus propias redes y sistemas.

Es precisamente aquí donde el régimen difiere de la Ley checa de Ciberseguridad. Esta regula los derechos y obligaciones de las personas en el ámbito de la garantía de la ciberseguridad, se aplica a las personas establecidas en la República Checa, incorpora la directiva correspondiente de la Unión Europea y da continuidad a los reglamentos de la Unión Europea de aplicación directa (§ 1 de la Ley de Ciberseguridad). La ley se basa en la prestación de un servicio regulado, mientras que el Reglamento de Ciberresiliencia impone obligaciones según el rol del sujeto en relación con el producto.

Sin embargo, esto no significa que las empresas de fabricación queden fuera de NIS2. Entre los sectores en los que el servicio puede estar regulado, la ley checa incluye expresamente la industria manufacturera (§ 4 de la Ley de Ciberseguridad). Así, un fabricante según el reglamento puede ser al mismo tiempo un proveedor de un servicio regulado. El texto sobre la nueva Ley de Ciberseguridad trata sobre esta nueva legislación. Una empresa bajo ambos regímenes debe separarlos, ya que tienen diferentes destinatarios, conceptos y plazos.

¿Soy fabricante si pongo mi nombre en un producto ajeno?

Según el reglamento, el fabricante no es solo quien desarrolla o fabrica el producto por sí mismo, sino también quien lo ha mandado diseñar, desarrollar o fabricar y lo ofrece bajo su nombre o marca comercial, ya sea a cambio de un pago, otra monetización o de forma gratuita (Reglamento (UE) 2024/2847, art. 3, punto 13). Por lo tanto, una empresa que vende un dispositivo ajeno bajo su propia marca asume las obligaciones del fabricante, aunque no haya escrito ni una sola línea de código.

El importador y el distribuidor se consideran fabricantes en dos situaciones específicas: si introducen el producto en el mercado bajo su nombre o marca comercial, o si realizan una modificación sustancial de un producto que ya está en el mercado. En ese caso, también están sujetos a la obligación de notificar según el artículo 14 (art. 21 del reglamento). Según el reglamento, las obligaciones del fabricante también se aplican a cualquier otra persona que realice una modificación sustancial y suministre el producto al mercado.

Por lo tanto, el contrato con el fabricante original debería determinar quién presentará la notificación y quién transmitirá a quién, sin demora, la información sobre el fallo explotado. Sin embargo, la obligación del fabricante se deriva directamente del reglamento, por lo que, por lo general, no puede considerarse cumplida por el mero hecho de hacer referencia a que el producto es fabricado en realidad por otra persona.

En la práctica, esto significa que la empresa debe aclarar primero en qué rol está actuando. Un comerciante de electrónica que coloca su logotipo en un dispositivo de un proveedor, una empresa de fabricación que integra una unidad de control con su propio software en su máquina, o un integrador que modifica un producto ajeno, pueden encontrarse en el lado del fabricante en dicho análisis, aunque no se sientan como tales en absoluto.

Qué es una vulnerabilidad explotada activamente y cuándo empieza a correr el reloj

Según el reglamento, una vulnerabilidad explotada activamente es aquella sobre la cual existen pruebas fiables de que un actor malicioso la ha explotado en un sistema sin la autorización del propietario (art. 3, punto 42). Por lo tanto, no basta con la mera existencia de un fallo ni con que sea técnicamente explotable; debe existir una prueba fiable de su explotación maliciosa real. No es necesario que ya se haya producido una brecha de seguridad en los usuarios. Un incidente con impacto en la seguridad del producto es un concepto independiente en el reglamento y se notifica por separado.

Por el contrario, una vulnerabilidad detectada sin intención maliciosa durante pruebas autorizadas o investigaciones de seguridad de buena fe no cumple con la definición, ya que falta tanto el actor malicioso como la explotación no autorizada. Por lo tanto, el hallazgo habitual de un investigador de seguridad que nadie está explotando no activa la notificación en un plazo de 24 horas. No obstante, la empresa puede notificarlo de forma voluntaria.

Cuidado con la confusión de términos. La Ley checa de Ciberseguridad define la vulnerabilidad de manera más amplia, como un punto débil de un activo o de una medida de seguridad que puede ser explotado por una amenaza, y un incidente de ciberseguridad como una alteración de la seguridad de la información en el ciberespacio (§ 2, párr. 2 de la Ley de Ciberseguridad). El Reglamento de Ciberresiliencia solo exige notificar las vulnerabilidades explotadas activamente y los incidentes graves con impacto en la seguridad del producto, por lo que un mismo evento puede activar un régimen y el otro no.

El plazo comienza a correr desde el momento en que el fabricante tiene conocimiento de la vulnerabilidad, no desde el momento en que el atacante la explotó. Por lo tanto, la organización interna es decisiva: quién recibe el informe en la empresa, quién evalúa si se trata de una explotación activa y quién está autorizado para presentar la notificación. Si estos roles no están definidos de antemano, la empresa perderá las primeras horas decidiendo quién debe tomar las decisiones.

Tres notificaciones, tres plazos y dónde se notifican

El fabricante presentará una alerta temprana sin demora indebida y, en cualquier caso, en un plazo de 24 horas desde que tenga conocimiento de la vulnerabilidad, indicando, si procede, los Estados miembros donde el producto está disponible. A esto le sigue una notificación de la vulnerabilidad en un plazo de 72 horas y un informe final a más tardar 14 días después de que esté disponible una medida correctiva o de mitigación (Reglamento (UE) 2024/2847, art. 14, párr. 2).

Para los incidentes graves que tengan un impacto en la seguridad del producto, se aplica un procedimiento similar de 24 y 72 horas, pero el informe final se presenta en un plazo de un mes a partir de la presentación de la notificación de incidente de 72 horas (art. 14, párr. 4). El reglamento considera grave un incidente que afecte o pueda afectar negativamente a la capacidad del producto para proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes, o que haya provocado o pueda provocar la introducción o ejecución de código malicioso en el producto o en los sistemas del usuario. Un ejemplo sería una situación en la que un atacante introduce código malicioso en el canal a través del cual el fabricante distribuye las actualizaciones de seguridad.

La notificación se presenta simultáneamente al CSIRT designado como coordinador en el Estado miembro donde el fabricante tenga su establecimiento principal (art. 14, párr. 7) y a la agencia ENISA, a través de una plataforma única de notificación. Por lo tanto, el fabricante presenta la notificación una sola vez y la plataforma la reenvía. La información oficial checa sobre el registro y la presentación a través de esta plataforma es publicada por la Oficina Nacional de Seguridad Cibernética e Información en su portal, donde se indica, entre otras cosas, que se trabaja con una cuenta EU Login.

Además de la notificación obligatoria, el reglamento permite que los fabricantes y otras personas notifiquen voluntariamente cualquier vulnerabilidad del producto, las ciberamenazas que puedan afectar a su perfil de riesgo y los cuasiincidentes significativos. La notificación voluntaria puede utilizarse cuando la empresa no esté segura de si se trata de una explotación activa; sin embargo, esto no exime de la obligación de notificar tan pronto como se confirme la explotación.

Es aconsejable gestionar el registro y el acceso a la plataforma con antelación, no en el momento en que se necesite presentar una notificación. En caso de un volumen elevado de solicitudes de registro, la verificación del usuario puede tardar un tiempo y, mientras tanto, el plazo sigue corriendo.

Esto también afecta a los productos que vendimos hace años

Sí. Las disposiciones transitorias del reglamento establecen expresamente que las obligaciones del artículo 14 se aplican a todos los productos con elementos digitales incluidos en el ámbito de aplicación del reglamento que hayan sido introducidos en el mercado antes del 11 de diciembre de 2027 (art. 69, párr. 3). Se trata de una excepción a la regla general, según la cual los demás requisitos del reglamento solo se aplican a los productos más antiguos si estos experimentan una modificación sustancial después de esa fecha. Por lo tanto, la antigüedad del producto no es motivo para no presentar la notificación.

Para la empresa, esto lleva a una conclusión incómoda: la lista de productos que deben vigilarse no incluye solo las nuevas gamas, sino también los dispositivos y el software que los clientes han estado utilizando durante años. Son especialmente sensibles los productos con una larga vida útil, como los sistemas de control industrial o los dispositivos de red, de los cuales el fabricante a menudo desconoce qué versión y dónde exactamente están implementados. Por lo tanto, el fabricante necesita un registro de qué vendió, cuándo, en qué versión y a quién, para saber dónde puede aparecer el fallo explotado y a quién informar.

Además, notificar a las autoridades no es la única obligación. Tras detectar una vulnerabilidad explotada activamente o un incidente grave, el fabricante debe informar a los usuarios afectados del producto, o a todos los usuarios si procede, y, si es necesario, sobre las medidas de mitigación y corrección que ellos mismos pueden adoptar (art. 14, párr. 8). Se trata de una obligación legal independiente, no solo de una buena práctica, y si el fabricante no la cumple a tiempo, el propio CSIRT competente puede informar a los usuarios. Por lo tanto, la comunicación con los clientes debe estar tan preparada como la parte técnica.

Cómo configurar el proceso antes de que suene el teléfono

El primer paso es designar a las personas responsables y a sus sustitutos. El plazo corre independientemente de vacaciones, fines de semana o días festivos, por lo que un único empleado designado no es suficiente. Conviene contar con un equipo de dos o tres personas, de las cuales al menos una pueda evaluar técnicamente si se trata de una explotación activa y otra tenga la autoridad para presentar la notificación.

El segundo paso es describir el procedimiento de toma de decisiones desde el primer aviso hasta la presentación de la notificación. Esto incluye las fuentes a través de las cuales la información sobre la vulnerabilidad puede llegar a la empresa, los criterios para evaluar las pruebas fiables de explotación, la forma de registrar el momento en que la empresa tuvo conocimiento de la vulnerabilidad y las plantillas para la alerta temprana y la notificación, de modo que no se tenga que redactar desde cero.

Los registros merecen especial atención. Si más adelante surge alguna duda sobre cuándo tuvo conocimiento la empresa de la vulnerabilidad, las marcas de tiempo serán decisivas: el correo electrónico con el primer aviso, el registro de la evaluación técnica, la confirmación de la presentación de la notificación. Una empresa que registra estos momentos de forma continua podrá demostrar más fácilmente que cumplió con el plazo, en comparación con una que intente reconstruirlos a posteriori a partir de la memoria de los implicados.

El tercer paso es regular los contratos con los proveedores de componentes y con los socios que distribuyen o integran el producto. El proveedor debería estar obligado a informar al fabricante sobre vulnerabilidades e incidentes de forma inmediata, ya que el fabricante no puede cumplir con el plazo de 24 horas si se entera de un fallo en un componente ajeno con una semana de retraso. La responsabilidad por el incumplimiento de dicha obligación se rige por las normas contractuales generales (§ 2913 del Código Civil checo).

A partir del 11 de diciembre de 2027, al integrar componentes de terceros, el fabricante debe prestar la debida diligencia para garantizar que no comprometan la ciberseguridad del producto y, si detecta una vulnerabilidad en un componente, debe informar a quien lo fabrique o lo mantenga (art. 13, párrs. 5 y 6 del reglamento). Según los considerandos del reglamento, debe supervisar, por ejemplo, si el componente recibe actualizaciones de seguridad periódicas y no tiene vulnerabilidades registradas. Para los contratos, esto significa que el proveedor del componente debe compartir información en ambas direcciones y el fabricante debe mantener un registro de qué componentes contiene su producto, ya que sin él no es posible determinar rápidamente si un fallo explotado afecta a su producto.

El cuarto paso es involucrar a la dirección de la empresa. Quien acepta un cargo como miembro de un órgano de administración se compromete a desempeñarlo con la lealtad necesaria y con los conocimientos y la diligencia debidos (§ 159, párr. 1 del Código Civil checo). La forma exacta en que este deber de diligencia debida se refleje en los riesgos cibernéticos del producto dependerá de las circunstancias, pero una dirección que no haya tratado en absoluto la obligación de notificación podría tener dificultades para defenderse en un litigio posterior.

Esto también se relaciona con los daños tras un incidente, que se analizan en el texto sobre la responsabilidad por incidentes cibernéticos. La dirección debe saber quién aprueba las notificaciones, qué información sobre los incidentes llega a la alta dirección y quién es responsable de la comunicación con los clientes.

El quinto paso es ensayar todo el procedimiento. Un simulacro de notificación un viernes por la tarde mostrará dónde se atasca la comunicación, quién no tiene acceso a la plataforma y a quién le faltan autorizaciones. Conviene repetir el simulacro con cada cambio en el equipo o en la cartera de productos, ya que un proceso que solo funciona sobre el papel fallará ante un incidente real.

Parte de la preparación consiste también en aclarar si la empresa, además de la notificación según el reglamento, está sujeta a la Ley de Ciberseguridad o al régimen de infraestructuras críticas, ya que cada uno de ellos tiene sus propios destinatarios de notificaciones y sus propios plazos. Cómo evaluar prácticamente la situación de la empresa en ambos regímenes se describe en el texto ¿Infraestructura crítica o NIS2?

Además, la notificación es solo uno de los componentes del conjunto más amplio de herramientas del fabricante. El reglamento impone a los fabricantes (Anexo I, Parte II, puntos 1 y 5) la obligación de implantar una política de divulgación coordinada de vulnerabilidades, que determine cómo pueden las personas o entidades notificarles las vulnerabilidades, y de documentar los componentes contenidos en los productos, entre otras cosas mediante una lista de materiales de software (SBOM). Estas obligaciones se aplicarán a partir del 11 de diciembre de 2027, pero la empresa que las tenga en cuenta ya al diseñar el proceso de notificación se ahorrará tener que reestructurarlo más adelante.

La forma exacta de configurar el proceso para un producto específico depende del rol en el que actúe la empresa y de la complejidad de su cadena de suministro; por ello, los abogados de la firma ARROWS advokátní kancelář lo evalúan siempre en función del fabricante concreto y no mediante un modelo de procedimiento universal.

Riesgos de no gestionar la obligación de notificación

Resumen final

A partir del 11 de septiembre de 2026, el fabricante de un producto con elementos digitales debe notificar cualquier vulnerabilidad explotada activamente en un plazo de 24 horas desde que tenga conocimiento de ella. El fabricante también puede ser una empresa que vende un producto ajeno bajo su propia marca, la obligación afecta expresamente también a los productos introducidos previamente en el mercado y se trata de un régimen diferente al de la Ley de Ciberseguridad, aunque una misma empresa pueda estar sujeta a ambos regímenes simultáneamente.

Para la dirección de la empresa, esto se traduce en una tarea clara: determinar si la empresa es fabricante, designar a personas concretas para la notificación y ensayar el procedimiento antes de que sea necesario utilizarlo en una situación real. El plazo de 24 horas no deja margen para la improvisación y las primeras horas deciden si la empresa lo cumplirá.

Los abogados de la firma ARROWS advokátní kancelář evalúan la posición de las empresas según el Reglamento de Ciberresiliencia, configuran los procesos internos de notificación y adaptan los contratos con proveedores y socios. Escríbanos a consultas@arws.cz o consulte nuestra práctica de contratos y negociación.