Cyber Resilience Act (UE) 2024/2847 — obligaciones del fabricante desde el 11 de septiembre de 2026

Durante veinte años, la ciberseguridad de los productos se reguló en la UE a fragmentos: en parte mediante la Directiva de equipos radioeléctricos, en parte mediante normas sectoriales y, en su mayoría, de ninguna manera. El Reglamento (UE) 2024/2847 — el Cyber Resilience Act — pone fin a esa situación. Abarca todo producto con elementos digitales comercializado en el mercado de la Unión, desde un router hasta una biblioteca de software vendida como producto, y lo vincula al marcado CE.

El plazo más cercano no está lejos. El 11 de septiembre de 2026 entran en vigor las obligaciones de notificación: las vulnerabilidades explotadas activamente y los incidentes graves deben comunicarse en un plazo de 24 horas. Esto afecta también a los productos que ya están en el mercado. La aplicación plena llega el 11 de diciembre de 2027. Para los fabricantes esto no supone solo trabajo técnico nuevo, sino un conjunto de datos que debe llegar al usuario y seguir siendo cierto durante años — el mismo problema que el pasaporte digital de producto resuelve en otros ámbitos de cumplimiento.

Qué es realmente el Cyber Resilience Act

El CRA es un acto horizontal: no describe un sector, sino una propiedad común de los productos. Esa propiedad es la presencia de un elemento digital y la capacidad de intercambiar datos. Estructuralmente pertenece a la familia del derecho de productos que se conoce por el marcado CE: requisitos esenciales en un anexo, evaluación de la conformidad, documentación técnica, declaración y marcado.

La novedad está en otro sitio. El derecho de productos evaluaba hasta ahora la mercancía en el momento de la introducción en el mercado; después, el interés del regulador terminaba en la práctica. El CRA no acepta esa premisa. La obligación de tratar las vulnerabilidades, publicar actualizaciones y notificar incidentes se extiende a todo el periodo de soporte declarado. Un producto conforme el día de la venta puede dejar de serlo dos años después si el fabricante deja de corregir vulnerabilidades conocidas.

Conviene señalar también el orden que el CRA introduce en el derecho vigente. El Reglamento Delegado (UE) 2022/30, que desde 2025 aplicaba requisitos de ciberseguridad a través de la Directiva de equipos radioeléctricos, queda derogado el día de la aplicación plena del CRA, el 11 de diciembre de 2027. Los requisitos esenciales del anexo I cubren todo lo que cubrían las normas de equipos radioeléctricos, de modo que desaparece el doble régimen.

Qué es un «producto con elementos digitales»

La definición es amplia, y lo es a propósito. Se refiere a un producto de hardware o software cuyo uso previsto o razonablemente previsible incluye una conexión de datos directa o indirecta con un dispositivo o una red. Alcanza también a las soluciones de tratamiento remoto de datos cuando son necesarias para que el producto funcione.

En la práctica resulta más fácil señalar qué queda fuera del ámbito, porque la lista de exclusiones es cerrada y concreta:

Productos sanitarios y productos sanitarios para diagnóstico in vitro — Reglamentos (UE) 2017/745 y (UE) 2017/746.
Vehículos de motor — Reglamento (UE) 2019/2144.
Aviación civil — Reglamento (UE) 2018/1139.
Equipos marinos — Directiva 2014/90/UE.
Productos desarrollados exclusivamente para fines de seguridad nacional o defensa y productos no suministrados en el marco de una actividad comercial.

Fuera de esas exclusiones el ámbito es muy amplio. El software vendido como producto queda cubierto igual que un dispositivo. El software libre y de código abierto desarrollado sin fines comerciales no lo está, pero el artículo 24 crea una figura propia y más ligera, la del administrador de software de código abierto, para las entidades que apoyan de forma sostenida el desarrollo de ese software destinado a usos comerciales.

Tres niveles de riesgo y tres vías de evaluación

El reglamento gradúa su rigor según el impacto que podría tener una brecha de seguridad en cada producto.

Productos por defecto: la gran mayoría del mercado. El fabricante realiza un control interno (módulo A) y elabora él mismo la documentación técnica y la declaración. No se necesita organismo notificado.

Productos importantes, anexo III clase I: entre otros, gestores de contraseñas, antivirus, sistemas de gestión de identidades y de acceso privilegiado, VPN, sistemas operativos, routers y conmutadores, microprocesadores con funciones relacionadas con la seguridad, asistentes virtuales domésticos, juguetes conectados a internet y dispositivos ponibles. La autoevaluación sigue siendo posible, pero solo si se han aplicado plenamente normas armonizadas o especificaciones comunes. Sin ellas interviene un organismo notificado.

Productos importantes, anexo III clase II: por ejemplo cortafuegos, sistemas de detección y prevención de intrusiones, hipervisores y microprocesadores resistentes a la manipulación. Aquí el organismo notificado o un esquema europeo de certificación de ciberseguridad es obligatorio.

Productos críticos, anexo IV: el nivel más estricto, con organismo notificado o certificación obligatorios. Las descripciones técnicas de las categorías se precisan en el Reglamento de Ejecución (UE) 2025/2392.

La conclusión práctica es la misma que en cualquier regulación con organismos notificados: clasificar pronto. Si un producto cae en la clase II o en el anexo IV, el plazo del organismo notificado pasa a formar parte del plan de lanzamiento y deja de ser un trámite final.

Obligaciones del fabricante — qué hay que hacer realmente

Requisitos esenciales, parte primera: propiedades del producto

El anexo I parte I describe cómo debe ser el producto. Los puntos clave: introducirse en el mercado sin vulnerabilidades explotables conocidas, entregarse con una configuración predeterminada segura y con la posibilidad de restablecer el estado de fábrica, proteger la confidencialidad, la integridad y la disponibilidad de los datos, minimizar la superficie de ataque, limitar la recogida de datos a lo necesario y permitir la instalación de actualizaciones de seguridad, en la medida de lo posible de forma automática y con aviso claro al usuario.

Requisitos esenciales, parte segunda: tratamiento de vulnerabilidades

El anexo I parte II describe un proceso que debe funcionar durante todo el periodo de soporte:

Un SBOM en formato legible por máquina que cubra al menos las dependencias de primer nivel y se mantenga actualizado. No hay obligación de publicarlo a los usuarios, pero sí de presentarlo a las autoridades de vigilancia del mercado cuando lo pidan.
Subsanar las vulnerabilidades sin demora, también mediante actualizaciones de seguridad.
Pruebas y revisiones de seguridad periódicas.
Divulgación pública de información sobre las vulnerabilidades corregidas una vez disponible la actualización.
Una política de divulgación coordinada de vulnerabilidades y un punto de contacto único para comunicarlas.
Distribución gratuita de las actualizaciones de seguridad sin demora.

El periodo de soporte, un campo de datos con consecuencias comerciales

Es la obligación que más sorprende. El fabricante fija el periodo durante el cual trata eficazmente las vulnerabilidades del producto, pero no puede ser inferior a cinco años, salvo que la vida útil prevista del producto sea menor. La fecha de finalización, con precisión de mes y año, debe indicarse claramente en el momento de la compra.

Sobre eso se superpone un segundo horizonte. Una actualización de seguridad, una vez publicada, debe seguir disponible al menos diez años desde su publicación o hasta el final del periodo de soporte si este termina más tarde. Es un compromiso de infraestructura: alguien tiene que mantener archivos e información accesibles durante una década, a través de cambios de sistemas y de dominios.

Notificación de vulnerabilidades e incidentes: la fecha del 11 de septiembre de 2026

El artículo 14 introduce las obligaciones que llegan antes y que alcanzan también a los productos ya comercializados. Deben notificarse las vulnerabilidades explotadas activamente y los incidentes graves que afecten a la seguridad del producto, al CSIRT del Estado miembro del establecimiento principal del fabricante y a ENISA, a través de una plataforma única de notificación.

Fase	Plazo
Alerta temprana	24 horas
Notificación principal	72 horas
Informe final — vulnerabilidad	14 días desde que hay medida correctora
Informe final — incidente grave	1 mes

Las 24 horas de alerta temprana son un plazo operativo, no una abstracción jurídica. Significan que la guardia, la vía de escalado y el acceso a la plataforma deben existir de antemano. Las microempresas y las pequeñas empresas no son multadas por incumplir el plazo de 24 horas, pero la obligación de notificar sí les alcanza.

Información para el usuario: anexo II

El anexo II enumera la información que debe acompañar al producto: identificación del tipo, lote o número de serie, datos del fabricante con dirección y punto de contacto, un punto de contacto único para comunicar vulnerabilidades y la indicación de dónde encontrar la política de divulgación, la finalidad prevista, instrucciones de instalación y uso seguros, cómo obtener las actualizaciones de seguridad y la fecha de finalización del periodo de soporte.

Calendario

Fecha	Qué ocurre
10 de diciembre de 2024	Entrada en vigor del Reglamento (UE) 2024/2847
11 de junio de 2026	Aplicación de las disposiciones sobre organismos notificados (capítulo IV)
11 de septiembre de 2026	Aplicación de las obligaciones de notificación (art. 14), también para productos ya comercializados
11 de diciembre de 2027	Aplicación plena: requisitos esenciales, evaluación de la conformidad, CE, documentación
11 de junio de 2028	Expiración de los certificados de examen UE de tipo emitidos en el periodo transitorio

Los productos introducidos en el mercado antes del 11 de diciembre de 2027 quedan sujetos a los requisitos plenos solo si se modifican sustancialmente después de esa fecha. Las obligaciones de notificación, en cambio, los alcanzan igualmente.

Conviene leer estas fechas junto al Reglamento de máquinas (UE) 2023/1230, aplicable desde el 20 de enero de 2027. Una máquina con elementos digitales entra en ambos regímenes en menos de once meses: el Reglamento de máquinas trata la ciberseguridad como requisito de seguridad funcional, mientras que el CRA impone obligaciones horizontales al software, los controladores y la conectividad. Son dos regímenes complementarios, no alternativos.

Qué significa esto para los datos de producto

Digámoslo con claridad, porque suele confundirse: el Cyber Resilience Act no establece un pasaporte digital de producto. No contiene obligación de pasaporte, ni soporte de datos, ni registro. La obligación de pasaporte procede del ESPR y de los actos sectoriales que la imponen expresamente.

Pero el conjunto de deberes de información que crea el CRA es un problema de gestión de datos en un grado difícil de pasar por alto:

Identidad a nivel de versión. El SBOM cambia con cada publicación de software. Una lista de materiales que no dice a qué versión se refiere no sirve como prueba. Es el mismo principio de versionar en lugar de sobrescribir sobre el que se apoya el pasaporte.
La fecha de fin de soporte como campo, no como frase en un folleto. Debe darse en la compra, ser coherente en todos los canales de venta y poder verificarse años después. Una discrepancia entre la ficha de producto de la tienda propia y la del distribuidor deja de ser cosmética.
Un soporte de datos resoluble. El punto de contacto para vulnerabilidades, la política de divulgación y la información sobre actualizaciones deben ser accesibles durante todo el periodo de soporte. Un código que resuelve al registro actual lo consigue mejor que una dirección impresa en un manual hace seis años. Las variantes se tratan en nuestro artículo sobre código QR y GS1 Digital Link.
Multilingüismo. La información del anexo II debe ser comprensible para los usuarios de los países donde el producto se comercializa. Con documentación digital eso no es un proyecto de traducción, sino un campo con versiones lingüísticas.
Continuidad durante una década. Diez años de disponibilidad de actualizaciones e información son un compromiso de servicio que sobrevive a migraciones, cambios de marca y cambios de proveedor.

Para la electrónica hay un argumento práctico adicional. La misma categoría de producto está simultáneamente en el punto de mira del ESPR, de la Directiva RoHS y de las normas sobre residuos electrónicos. Una empresa que lleva por un lado los datos de sustancias, por otro los de reparabilidad y por otro los de soporte de software mantiene tres registros sobre el mismo producto. Ordenar los datos de producto una sola vez sirve a todas esas direcciones — el punto de partida es nuestro artículo sobre por qué los datos de producto son el fundamento del DPP.

Una advertencia honesta sobre los límites del papel del proveedor: myDPP no realiza pruebas de seguridad, no genera ni valida SBOM, no gestiona el proceso de tratamiento de vulnerabilidades, no evalúa la conformidad con el CRA, no es organismo notificado y no presenta notificaciones del artículo 14. Almacena, versiona y publica datos de producto verificados y mantiene el soporte que los abre. La responsabilidad del cumplimiento sigue siendo del fabricante.

Preparación: cinco pasos

Clasifique la cartera. Determine qué productos son productos con elementos digitales y cuáles caen en el anexo III clase I o II, o en el anexo IV. De ello depende si hace falta organismo notificado y cuánto durará la evaluación.
Ponga en marcha la notificación antes del 11 de septiembre de 2026. Designe responsables, escriba la vía de escalado para la alerta temprana de 24 horas, registre el acceso a la plataforma y ensáyelo con un caso de prueba. Ese plazo no espera a que el resto del proyecto esté listo.
Fije los periodos de soporte y regístrelos como datos. Para cada familia de productos, establezca una fecha de fin de soporte, justifíquela con la vida útil prevista e introdúzcala en el sistema que alimenta la tienda, los distribuidores y la documentación, no solo en una presentación comercial.
Integre la generación del SBOM en el proceso de publicación. Una lista de materiales elaborada a mano una vez por trimestre se desviará de la realidad en la primera versión correctora. Vincular el SBOM a la versión y a la unidad es trabajo del lado de los datos, no del lado jurídico.
Ordene la información del anexo II. El punto de contacto, la política de divulgación, las instrucciones de configuración segura y la fecha de fin de soporte deben ser coherentes en todos los idiomas y canales y accesibles durante años.

El programa de datos más amplio se recoge en nuestra checklist de implantación del DPP.

Preguntas frecuentes

¿Se aplica el CRA a los productos que vendí antes de 2027?

En parte. Los requisitos plenos — esenciales, evaluación de la conformidad, CE — alcanzan a un producto introducido en el mercado antes del 11 de diciembre de 2027 solo si se modifica sustancialmente después de esa fecha. En cambio, las obligaciones de notificación del artículo 14 cubren los productos ya comercializados desde el 11 de septiembre de 2026, con independencia de cuándo se vendieran.

¿Tengo que publicar el SBOM para mis clientes?

No. El anexo I exige elaborar y mantener una lista de materiales legible por máquina que cubra al menos las dependencias de primer nivel y ponerla a disposición de las autoridades de vigilancia del mercado cuando lo soliciten. Publicar el SBOM a los usuarios es una decisión comercial, no una obligación legal.

¿Puedo fijar un periodo de soporte inferior a cinco años?

Solo si la vida útil prevista del producto es inferior a cinco años, y hay que poder justificarlo. En los demás casos cinco años son el mínimo y, si el producto se usa realmente durante más tiempo, el periodo de soporte debería corresponder a la vida útil real.

¿Introduce el Cyber Resilience Act un pasaporte digital de producto?

No. El CRA no contiene obligación de pasaporte ni exigencia de soporte de datos. Sí impone deberes de información asociados al producto y a la versión que deben seguir disponibles durante el periodo de soporte y una década después de publicar una actualización. Los requisitos de datos convergen con los del pasaporte, de modo que un solo ordenamiento sirve a ambas direcciones.

Seguir leyendo

Fuentes

Reglamento (UE) 2024/2847 — Cyber Resilience Act — EUR-Lex
Cyber Resilience Act — resumen del texto legislativo — Comisión Europea
Reglamento (UE) 2023/1230 — máquinas — EUR-Lex
Reglamento (UE) 2024/1781 (ESPR) — EUR-Lex
Reglamento Delegado (UE) 2022/30 — ciberseguridad en la Directiva de equipos radioeléctricos — EUR-Lex