Reglamento de Ciberresiliencia: obligaciones y plazos que las empresas deben comprobar

El Reglamento de Ciberresiliencia de la UE —conocido como CRA, por sus siglas en inglés— establece requisitos obligatorios de ciberseguridad para productos con elementos digitales. El marco abarca hardware y software: la Comisión Europea cita ejemplos cotidianos como relojes inteligentes, monitores para bebés, aplicaciones y programas informáticos. Su objetivo es que la seguridad se tenga en cuenta durante el diseño, el desarrollo y el mantenimiento del producto, no únicamente después de que llegue al mercado. [1]

Para una empresa, la pregunta inicial no es solo si vende tecnología, sino qué producto pone a disposición en el mercado europeo y qué función desempeña en su cadena de suministro. Fabricantes, importadores y distribuidores pueden tener responsabilidades distintas. La Comisión también identifica a los desarrolladores de aplicaciones como fabricantes cuando comercializan esas aplicaciones en la UE. Una etiqueta comercial, por sí sola, no resuelve la clasificación: conviene revisar el papel real de cada entidad y las características del producto. [2]

Una revisión útil empieza con un inventario de productos y componentes digitales, y continúa con una evaluación de su relación con servicios conectados. La guía publicada por la Comisión en julio de 2026 aborda, entre otros asuntos, el alcance, las modificaciones sustanciales, los periodos de soporte, la evaluación de riesgos y la notificación de vulnerabilidades. Es una ayuda para interpretar la aplicación práctica, pero no sustituye al reglamento ni determina automáticamente la situación de cada producto. [3]

No conviene asumir que una categoría completa está incluida o excluida sin analizar el caso concreto. Por ejemplo, un servicio en la nube puede tener una relación técnica con un producto cubierto; una fuente secundaria describe posibles supuestos de tratamiento remoto conectado al producto. Esa explicación puede servir como pista para formular preguntas, pero no es una base suficiente para cerrar una interpretación jurídica. La empresa debería contrastar su arquitectura y su papel con el texto legal y con asesoramiento especializado cuando haya dudas relevantes. [4]

La Comisión describe el CRA como un marco de requisitos de ciberseguridad para fabricantes que afecta a la planificación, el diseño, el desarrollo y el mantenimiento de productos con elementos digitales. También señala que los fabricantes deben gestionar vulnerabilidades durante el ciclo de vida. En términos operativos, esto implica conectar el trabajo de seguridad con procesos de ingeniería, mantenimiento y soporte, en vez de tratarlo como una comprobación aislada antes del lanzamiento. [1]

La aplicación concreta depende del producto y de las obligaciones que le correspondan. La guía de la Comisión de 2026 se ocupa de cuestiones como el análisis de riesgos y cómo entender los periodos de soporte. Por eso, las compañías deberían poder explicar qué producto han evaluado, qué riesgos han considerado y cómo organizan la atención de vulnerabilidades y actualizaciones. La documentación debe reflejar prácticas reales, no limitarse a una declaración genérica de que el producto es seguro. La información disponible aquí no permite fijar un periodo universal de soporte para todos los productos. [3]

Según la página de la Comisión dedicada a las obligaciones de notificación, desde el 11 de septiembre de 2026 los fabricantes deben notificar vulnerabilidades explotadas activamente e incidentes graves que afecten a la seguridad de sus productos con elementos digitales. La Comisión describe un aviso inicial en 24 horas desde que se tiene conocimiento, una notificación completa en 72 horas y un informe final sujeto a plazos que dependen del tipo de suceso. [5]

La página oficial señala que el informe final sobre una vulnerabilidad explotada activamente debe presentarse, como máximo, 14 días después de que haya una medida correctiva disponible. Para incidentes graves, indica un plazo de un mes desde la notificación de 72 horas. También explica que los fabricantes notifican a través de una plataforma única, con destino al equipo de respuesta a incidentes informáticos (CSIRT) correspondiente a su establecimiento principal. Los plazos breves hacen necesario preparar de antemano responsables, canales de escalado y criterios de activación, en lugar de improvisarlos ante un incidente. [5]

El mismo calendario oficial distingue a los gestores de software de código abierto: sus obligaciones de notificación, conforme a la disposición citada por la Comisión, comienzan el 11 de diciembre de 2027. Esta diferencia importa para organizaciones que mantienen software abierto y para las empresas que dependen de él; no debe confundirse con la fecha aplicable a fabricantes de productos. [5]

El CRA está en vigor desde diciembre de 2024, según la Comisión, pero eso no significa que todas sus obligaciones comenzaran simultáneamente. El hito de septiembre de 2026 activa las obligaciones de notificación descritas arriba. La Comisión indica que el reglamento será plenamente aplicable a partir del 11 de diciembre de 2027. Para planificar, las empresas deben distinguir entre la entrada en vigor, los hitos de obligaciones específicas y la fecha de aplicación general. [1][5]

Una tabla interna de seguimiento puede ayudar a evitar que un calendario simplificado o una publicación de terceros se conviertan en la única referencia:

La tabla resume fechas y colectivos tal como aparecen en la información oficial consultada; no sustituye la comprobación del artículo aplicable a cada organización. [1][5]

Un plan práctico puede empezar con cinco comprobaciones: identificar productos y mercados; asignar el rol de cada entidad; documentar componentes y dependencias; establecer un proceso para detectar, evaluar y escalar vulnerabilidades; y confirmar quién presenta las notificaciones y por qué canal. Después, conviene comparar esas medidas con el reglamento y con la guía oficial, prestando atención a la clasificación del producto, las modificaciones, el soporte y la evaluación de riesgos. [2][3][5]

La investigación disponible no incluye declaraciones directas de fabricantes afectados, ni permite atribuir a una empresa concreta una postura, un nivel de preparación o una interpretación. Tampoco aporta información suficiente para resolver todos los casos límite de alcance. Por tanto, no hay base aquí para afirmar que una compañía determinada cumple o incumple, ni para presentar una novedad regulatoria más allá de los hitos documentados. La conclusión verificable es más acotada: hay obligaciones de notificación con fecha de inicio confirmada y una fecha de aplicación general que las organizaciones deben incorporar a su análisis. [1][5]