Gemelos digitales y ciberseguridad: el nuevo activo que también necesita seguridad

Cyber Resilience Act (CRA): marco europeo de ciberseguridad para productos digitales

3 de septiembre de 2026

El 11 de septiembre de 2026, cualquier fabricante con un producto conectado en el mercado europeo pasa a tener 24 horas para notificar una vulnerabilidad explotada activamente a ENISA y al CSIRT nacional competente. Ese plazo no es una recomendación de buenas prácticas: es una obligación del Reglamento (UE) 2024/2847, el Cyber Resilience Act (CRA), y afecta también a productos que ya están vendidos y en funcionamiento, sin excepción por antigüedad.

Para un fabricante, ese dato cambia una pregunta de diseño que hasta ahora era opcional: ¿cuántos sistemas distintos tendría que revisar mi equipo para saber, en menos de un día, si una vulnerabilidad afecta a un activo crítico? Cuantas más piezas heterogéneas (VPN, RDP, agentes de endpoint, credenciales dispersas) compongan el acceso a ese activo, más difícil es responder a tiempo. Es el problema técnico real que el CRA pone encima de la mesa, y del que partimos en este artículo.

¿Qué es el Cyber Resilience Act (CRA)?

El CRA es el primer reglamento horizontal de la Unión Europea que fija requisitos de ciberseguridad obligatorios para cualquier “producto con elementos digitales” (hardware o software) comercializado en la UE, durante todo su ciclo de vida. Entró en vigor el 10 de diciembre de 2024, pero su aplicación es escalonada:

10 de diciembre de 2024 — entrada en vigor del Reglamento.
11 de junio de 2026 — empieza a aplicarse lo relativo a la notificación de los organismos de evaluación de la conformidad.
11 de septiembre de 2026 — arrancan las obligaciones de notificación: vulnerabilidades explotadas activamente e incidentes graves deben comunicarse a ENISA y al CSIRT nacional competente.
11 de diciembre de 2027 — aplicación completa: ningún producto con elementos digitales podrá comercializarse en la UE sin cumplir el CRA y llevar el marcado CE correspondiente.

Según INCIBE, los fabricantes disponen de un plazo de hasta 36 meses desde la entrada en vigor de la norma para adaptarse a su cumplimiento, lo que explica este calendario escalonado en lugar de una entrada en vigor única.

A diferencia de NIS2 (que regula a los operadores de servicios esenciales) o de ENS (que regula al sector público español), el CRA regula al fabricante del producto: quien lo diseña, lo integra y lo pone en el mercado bajo su marca (incluida la venta bajo marca propia, que a efectos del CRA cuenta como fabricación). Es un cambio de paradigma deliberado: traslada la responsabilidad de la seguridad al que pone el producto en el mercado, no a quien lo usa.

Fabricante vs. empresa que usa la solución: quién hace qué

Es el punto que más confusión genera, así que conviene separarlo con claridad:

El fabricante (quien diseña, desarrolla o encarga el desarrollo del producto y lo comercializa bajo su marca) es el obligado directo: debe integrar seguridad por diseño, mantener el SBOM, sostener el producto con actualizaciones durante el periodo de soporte, y es quien notifica a ENISA y al CSIRT nacional en los plazos de 24h/72h/14 días cuando detecta una vulnerabilidad explotada activamente o un incidente grave en su producto. Es también quien responde ante sanciones y ante una eventual retirada del producto del mercado.

La empresa que usa el producto (el banco, el hospital, la administración pública que despliega una solución de terceros) no es la obligada a notificar a ENISA bajo el CRA, esa carga es del fabricante. Su papel es aplicar las actualizaciones de seguridad que el fabricante publique, y reportarle al fabricante, a través del canal de divulgación coordinada de vulnerabilidades (CVD) que este debe mantener, cualquier vulnerabilidad que detecte. Si además es una entidad esencial o importante bajo NIS2, o está dentro del ámbito del ENS, mantiene sus propias obligaciones de notificación de incidentes como operador, pero son obligaciones de esas normas, no del CRA del fabricante. Una matización: si esa empresa revende el producto bajo su propia marca o lo modifica sustancialmente, pasa a ser considerada fabricante de esa versión, con las obligaciones que eso implica.

El proceso de comunicación, paso a paso

El artículo 14 del CRA establece tres plazos, todos a cargo del fabricante:

Plazo	Qué debe comunicarse	Quién lo hace
24 horas	Aviso temprano desde que se tiene conocimiento de la vulnerabilidad explotada o el incidente grave	El fabricante, a ENISA y al CSIRT nacional competente, vía la plataforma única de notificación
72 horas	Notificación completa, con descripción, métodos de explotación y medidas correctoras adoptadas	El fabricante
14 días	Informe final una vez corregida la vulnerabilidad o gestionado el incidente	El fabricante

En paralelo a esta notificación a las autoridades, el fabricante debe informar a los usuarios y clientes afectados, junto con las acciones de mitigación recomendadas. Ese es el punto en el que la empresa que implanta el producto entra en el proceso: recibe la alerta y aplica la actualización o la mitigación, no genera ni tramita la notificación regulatoria.

La Comisión Europea publicó el 27 de julio de 2026 su guía oficial sobre el ámbito de aplicación del Reglamento, y ha propuesto retrasar dos meses el calendario de normalización técnica: las normas horizontales de gestión de vulnerabilidades se esperan para finales de octubre de 2026, y las normas verticales por producto a lo largo de diciembre de 2026. Conviene revisar el estado de las normas armonizadas antes de cerrar cualquier plan de conformidad, porque el calendario todavía se está moviendo.

Las obligaciones núcleo para el fabricante

Más allá de la notificación, el CRA exige:

Seguridad por diseño y por defecto, no como capa añadida al final del desarrollo.
SBOM (Software Bill of Materials) actualizado, al menos a nivel de paquete, disponible para las autoridades competentes previa solicitud.
Gestión de vulnerabilidades durante todo el periodo de soporte del producto, no solo en el lanzamiento.
Documentación de evaluación de riesgos, conservada un mínimo de 10 años.
Actualizaciones de seguridad disponibles durante el ciclo de vida declarado del producto.

El incumplimiento se sanciona con hasta 15 millones de euros o el 2,5% de la facturación mundial del ejercicio anterior, lo que resulte mayor.

Clasificación del producto según su riesgo

No todos los productos afrontan el mismo nivel de exigencia. Según INCIBE, el CRA distingue cuatro categorías:

No clasificados: productos sin vulnerabilidades críticas identificadas, sujetos a autoevaluación periódica.
Importantes — Clase I y Clase II (Anexo III): requieren un nivel de seguridad robusto, con exigencias crecientes según el riesgo.
Críticos (Anexo IV): el nivel de exigencia más alto, generalmente con intervención de un organismo notificado.

El periodo de soporte de seguridad, salvo justificación distinta, tiene un mínimo general de 5 años o la vida útil esperada del producto si es menor, un dato relevante a la hora de valorar con qué fabricante trabajar a largo plazo.

¿Por qué la arquitectura importa?

La mayoría de contenido sobre el CRA se queda en el listado de obligaciones del fabricante. Pero el CRA no libera al cliente de responsabilidad: le cambia la naturaleza. En vez de tener que detectar y notificar él mismo una vulnerabilidad, su papel pasa a recibir la alerta del fabricante y actuar rápido. Aplicar la actualización, valorar si el activo crítico está expuesto, y si es una entidad bajo NIS2 o ENS, gestionar su propia obligación de notificación como operador. Cuantos más sistemas heterogéneos (VPN, RDP, agentes de endpoint, credenciales dispersas) compongan el acceso a ese activo, más lento y más difícil es responder a esa alerta a tiempo, sea cual sea el plazo que le marque su propia normativa.

Cosmikal, fabricante de tecnología española, aplica ya esta filosofía de seguridad por diseño en sus propios procesos de desarrollo, lo que sitúa a Cosmikal como compañía plenamente adaptada a la aplicación práctica de los principios que el Cyber Resilience Act.

En síntesis

El Cyber Resilience Act consolida un principio que irá marcando la próxima década regulatoria europea: la seguridad de un producto conectado ya no se presume, se demuestra con documentación, con trazabilidad y con capacidad de respuesta verificable. Para el fabricante, supone incorporar la seguridad al propio proceso de diseño, como una condición de acceso al mercado y no como un requisito posterior. Para la organización que adopta tecnología conectada, supone revisar con qué rigor sus proveedores sostienen esa responsabilidad en el tiempo, y con qué agilidad su propia estructura le permite actuar cuando llega una alerta.

El horizonte de diciembre de 2027 puede parecer lejano. La experiencia con otros marcos normativos europeos indica lo contrario: las organizaciones que aborden esta transición con antelación son las que llegan a cada nuevo hito regulatorio con la seguridad como ventaja, no como contingencia.

Preguntas frecuentes sobre el CRA

¿A quién obliga el Cyber Resilience Act?

A fabricantes, importadores y distribuidores de productos con elementos digitales —hardware y software— que se comercialicen en la UE. Quedan exclusiones limitadas para sectores con legislación equivalente ya vigente.

¿Cuándo empiezan a aplicarse las obligaciones del CRA?

Las obligaciones de notificación de vulnerabilidades entran en vigor el 11 de septiembre de 2026. El resto de obligaciones, incluido el marcado CE, se aplican desde el 11 de diciembre de 2027.

¿El CRA afecta a productos que ya están en el mercado?

Sí. La obligación de notificar en 24 horas se aplica también a productos ya comercializados, sin periodo transitorio ni excepción por antigüedad, siempre que sigan recibiendo soporte del fabricante.

¿Qué diferencia hay entre el CRA y NIS2?

NIS2 regula a los operadores de servicios esenciales e importantes; el CRA regula al fabricante del producto digital que esos operadores utilizan. Son complementarios, no equivalentes.

¿Qué es un SBOM y por qué lo exige el CRA?

Un SBOM (Software Bill of Materials) es el inventario de componentes de software de un producto. Permite identificar librerías y dependencias para reaccionar con rapidez cuando una vulnerabilidad afecta a un componente de terceros, algo que el propio CRA convierte en obligación documental.

Fuentes oficiales consultadas: