Qué es el Reglamento de Ciberresiliencia
El Reglamento de Ciberresiliencia, conocido como CRA por sus siglas en inglés, es el Reglamento (UE) 2024/2847. Establece requisitos horizontales de ciberseguridad para los productos con elementos digitales que se comercializan en la Unión Europea. Su objetivo es que la seguridad forme parte del producto desde su diseño y se mantenga durante el periodo de soporte, en lugar de depender solo de la diligencia de quien lo compra.
La norma responde a dos problemas conectados: productos que llegan al mercado con vulnerabilidades y fabricantes que no ofrecen actualizaciones o información clara durante un tiempo suficiente. Para abordar ambos, fija obligaciones a lo largo del ciclo de vida del producto y hace más visible el soporte de seguridad. No es una certificación general de empresas ni una ley que se limite a los datos personales: regula la ciberseguridad de productos, además de la cadena de operadores que los pone en el mercado.
El CRA está en vigor desde el 10 de diciembre de 2024, pero sus obligaciones se aplican por etapas. La entrada en vigor significa que el reglamento forma parte del ordenamiento jurídico; no equivale a que todos sus requisitos sean exigibles desde esa fecha. Las obligaciones generales de conformidad empiezan el 11 de diciembre de 2027, mientras que el deber de notificar determinados incidentes y vulnerabilidades se aplica desde el 11 de septiembre de 2026.
Qué productos abarca y quién responde
El concepto central es producto con elementos digitales: un producto de hardware o software cuya finalidad prevista o uso razonablemente previsible incluya una conexión de datos directa o indirecta, física o lógica, con otro dispositivo o una red. Puede incluir un router, una cámara conectada, un sistema operativo, una aplicación comercial o un componente digital vendido por separado. Lo determinante no es la etiqueta comercial, sino la funcionalidad y la conexión del producto.
La norma asigna responsabilidades a fabricantes, importadores y distribuidores, con el fabricante como responsable principal de diseñar y mantener un producto conforme. La categoría jurídica de fabricante puede alcanzar a una empresa que comercializa el producto bajo su propio nombre o marca, o que lo modifica sustancialmente. Por eso, una empresa que compra un dispositivo terminado y lo vende con marca propia no debe asumir automáticamente que solo actúa como distribuidor.
Los importadores deben comprobar, entre otros aspectos, que el fabricante haya seguido el procedimiento de evaluación de conformidad y que el producto cuente con la documentación y el marcado exigidos. Los distribuidores tienen deberes de diligencia antes de comercializarlo y deben actuar ante riesgos o incumplimientos que conozcan. En una cadena sencilla, las tareas pueden resumirse así, aunque los detalles dependen del papel legal de cada empresa:
Responsabilidades en la cadena de suministro
| Actor | Responsabilidad principal según el CRA | Qué significa en la práctica |
|---|---|---|
| Fabricante | Cumplir los requisitos esenciales, evaluar riesgos, documentar la conformidad y gestionar vulnerabilidades. | Mantener un proceso de seguridad desde el desarrollo hasta el fin del periodo de soporte. |
| Importador | Comprobar que el producto y el fabricante cumplen las obligaciones aplicables antes de introducirlo en el mercado de la UE. | Revisar marcado, documentación e información exigida, y actuar si detecta riesgos. |
| Distribuidor | Ejercer diligencia debida antes de comercializar y cooperar ante problemas de conformidad. | No seguir ofreciendo un producto cuando sepa o deba sospechar que presenta un incumplimiento relevante. |
| Consumidor | No es el operador obligado por estas obligaciones de comercialización. | Puede beneficiarse de información más clara sobre seguridad y soporte; la norma no sustituye sus decisiones de uso seguro. |
El alcance no significa que cualquier servicio digital quede automáticamente sometido al CRA. El reglamento se centra en productos con elementos digitales; ciertos servicios de procesamiento remoto pueden entrar en juego cuando forman parte de la funcionalidad de un producto cubierto. También hay exclusiones o regímenes particulares, por ejemplo para productos cubiertos por normativa sectorial específica y para software libre desarrollado fuera de una actividad comercial. No conviene presumir una exclusión solo porque el producto use código abierto o incluya un servicio en la nube: importan la función, la distribución y el contexto comercial.
Qué exige en diseño, mantenimiento y conformidad
El fabricante debe integrar la ciberseguridad en el diseño, el desarrollo y la producción, evaluar los riesgos pertinentes y adoptar medidas proporcionales a ellos. El anexo I del reglamento incluye requisitos relativos, entre otros, a configuraciones seguras por defecto, protección frente a accesos no autorizados y gestión de vulnerabilidades. La idea práctica es que la seguridad no se añada como un parche de última hora: debe influir en las decisiones de arquitectura, desarrollo y puesta en el mercado.
La gestión de vulnerabilidades continúa después de la venta. El fabricante debe identificar y corregir vulnerabilidades, proporcionar actualizaciones de seguridad y declarar un periodo de soporte. Ese periodo debe tener en cuenta la vida útil prevista del producto; el reglamento establece, como regla general, un mínimo de cinco años, salvo que se espere que el producto se use durante menos tiempo. Cinco años no son un plazo universal desconectado del producto: el periodo debe interpretarse junto con la vida útil prevista y las condiciones del reglamento.
Antes de comercializar un producto cubierto, el fabricante debe completar la evaluación de conformidad aplicable, preparar la documentación técnica y emitir la declaración correspondiente; cuando proceda, el producto llevará el marcado CE. El nivel de evaluación depende de la clasificación y de las vías de conformidad disponibles. En consecuencia, el marcado CE relacionado con el CRA comunica conformidad con los requisitos aplicables, no que el producto sea invulnerable ni que vaya a recibir soporte indefinidamente.
Para una empresa, esto convierte la conformidad en un trabajo coordinado entre desarrollo, seguridad, producto, compras y cumplimiento normativo. Un inventario de productos y componentes ayuda a identificar qué entra en el ámbito, quién ocupa cada papel y qué compromisos de soporte existen. Mantener registros de riesgos, cambios, actualizaciones y vulnerabilidades facilita responder tanto a incidentes como a evaluaciones de conformidad.
Notificación de vulnerabilidades e incidentes
Desde el 11 de septiembre de 2026, el artículo 14 exige a los fabricantes notificar dos tipos de situaciones: vulnerabilidades explotadas activamente en productos con elementos digitales e incidentes graves que afecten a su seguridad. No toda vulnerabilidad detectada se convierte por ello en una notificación de este tipo: debe alcanzarse el umbral definido por el reglamento. La obligación también alcanza a productos ya introducidos en el mercado, no solo a los lanzados después de esa fecha.
La notificación sigue varias etapas. El fabricante debe enviar una alerta temprana sin demora injustificada y, en todo caso, dentro de las 24 horas desde que tenga conocimiento del caso. La comunicación se completa dentro de las 72 horas. Después se presenta un informe final: para una vulnerabilidad, dentro de los 14 días posteriores a que esté disponible una medida correctora; para un incidente grave, dentro de un mes desde la notificación de 72 horas. Son plazos con puntos de inicio y entregables distintos, así que no deben reducirse a una sola fecha límite.
La notificación se canaliza mediante la plataforma única de la UE y se dirige al CSIRT coordinador correspondiente, con acceso simultáneo de ENISA según el mecanismo del reglamento. Operativamente, el reto consiste en reconocer pronto si el evento afecta a un producto cubierto, determinar cuándo la empresa adquiere conocimiento suficiente y activar a las personas autorizadas para informar. Un proceso interno que dependa de improvisar esas decisiones después de un incidente difícilmente encajará con una primera alerta de 24 horas.
La notificación regulatoria no reemplaza la respuesta técnica: investigar el alcance, contener el problema, preparar una actualización o mitigación e informar a los usuarios cuando corresponda siguen siendo tareas centrales. Tampoco todo aviso a un equipo nacional de respuesta a incidentes equivale automáticamente a una notificación CRA. El criterio es el tipo de evento y la obligación prevista en el artículo 14.
Calendario: entrada en vigor y aplicación
El calendario tiene tres hitos que conviene distinguir. El reglamento entró en vigor el 10 de diciembre de 2024. Las obligaciones de notificación de vulnerabilidades explotadas activamente e incidentes graves se aplican desde el 11 de septiembre de 2026. La aplicación general del resto de obligaciones principales está prevista para el 11 de diciembre de 2027.
| Fecha | Qué ocurre | Consecuencia práctica |
|---|---|---|
| 10 de diciembre de 2024 | Entrada en vigor del Reglamento (UE) 2024/2847. | La norma existe jurídicamente, pero la mayoría de las obligaciones aún tiene un periodo transitorio. |
| 11 de septiembre de 2026 | Se aplican las obligaciones de notificación del artículo 14. | Los fabricantes deben poder notificar los casos previstos, también si afectan a productos ya comercializados. |
| 11 de diciembre de 2027 | Aplicación general de las obligaciones principales. | Se aplican los requisitos de ciberseguridad, conformidad y documentación previstos para los productos cubiertos. |
El efecto de las fechas sobre un producto concreto depende de su situación y del régimen transitorio. Una empresa no debería interpretar 2027 como permiso para aplazar toda preparación: las notificaciones ya son exigibles desde septiembre de 2026, y los procesos de diseño, soporte y evaluación necesitan tiempo. A la vez, decir que el CRA se aplica plenamente desde 2024 sería incorrecto: el calendario es escalonado y cada obligación debe asociarse a su propio hito.
Para organizar el trabajo, una revisión inicial puede seguir este orden: identificar los productos que se venden en la UE; determinar si cada uno entra en el ámbito; asignar fabricante, importador o distribuidor; revisar vulnerabilidades y procesos de notificación; y planificar evaluación de conformidad, documentación y soporte para el hito general de 2027. La clasificación y las excepciones requieren análisis del caso, no una regla única para todas las categorías.
Diferencia entre el CRA y el RGPD
El CRA y el RGPD regulan problemas distintos. El CRA fija requisitos de ciberseguridad para productos con elementos digitales y obligaciones para operadores económicos que los comercializan. El RGPD regula el tratamiento de datos personales y las responsabilidades de quienes determinan o realizan ese tratamiento. Un dispositivo puede estar sujeto a ambos marcos si, además de ser un producto cubierto, procesa datos personales.
Por ejemplo, un fabricante de una cámara conectada debe considerar el diseño seguro, la gestión de vulnerabilidades y el periodo de soporte bajo el CRA. Si la empresa trata imágenes que identifican a personas, también debe analizar sus obligaciones de protección de datos bajo el RGPD, según su papel y las circunstancias del tratamiento. Cumplir una norma no sustituye cumplir la otra: una actualización de seguridad no resuelve por sí misma cuestiones como la base jurídica o la transparencia del tratamiento.
La diferencia también ayuda a los consumidores a interpretar qué pueden esperar. El CRA busca reforzar la seguridad del producto y la información sobre su soporte, pero no garantiza que nunca ocurra una intrusión, que un producto no tenga defectos ni que todo tratamiento de datos sea lícito. Para comparar dispositivos, resulta útil revisar quién ofrece las actualizaciones, durante cuánto tiempo se prevén y qué información proporciona el fabricante sobre el soporte. Esas señales no reemplazan la conformidad legal, pero ayudan a entender el mantenimiento que cabe esperar.