El Cyber Resilience Act es el reglamento europeo que impone requisitos obligatorios de ciberseguridad a los productos con elementos digitales. Se aplica a todo producto comercializado en la Unión Europea. Se aprobó como Reglamento (UE) 2024/2847 y entró en vigor el 10 de diciembre de 2024. Obliga a fabricantes, importadores y distribuidores, y alcanza tanto al hardware como al software, desde un router hasta una aplicación móvil. Sus obligaciones llegan escalonadas. Las de notificación son exigibles desde el 11 de septiembre de 2026. El grueso del reglamento se aplica desde el 11 de diciembre de 2027. El incumplimiento se sanciona con hasta 15 millones de euros o el 2,5% del volumen de negocio mundial.
Si necesitas abogados para adaptarte al Cyber Resilience Act, solicita una valoración inicial gratuita.
Entra cualquier producto de software o hardware con una conexión de datos, lógica o física, directa o indirecta, a un dispositivo o a una red. La definición incluye las soluciones de tratamiento de datos a distancia asociadas al producto y los componentes que se comercializan por separado. El criterio es la conectividad, no el sector ni el tamaño de la empresa que lo fabrica.
Esa amplitud sorprende a muchas empresas que no se ven como fabricantes de tecnología. Una empresa de maquinaria industrial que vende equipos con panel táctil conectado está dentro. Una asesoría que comercializa su propio software de gestión está dentro. Un fabricante de juguetes con conexión a internet está dentro.
El artículo 2 deja fuera siete supuestos, casi todos porque ya tienen su propia regulación sectorial de ciberseguridad.
Queda fuera también el software libre desarrollado sin ánimo comercial. Esa exclusión tiene un matiz. Cuando el software libre se destina a un uso comercial aparece una figura intermedia con obligaciones propias, que se desarrolla más adelante.
El reglamento obliga a cuatro figuras con intensidad decreciente. El fabricante soporta el peso principal, incluidos los requisitos esenciales del anexo I y la notificación del artículo 14. El importador verifica que el producto que introduce en el mercado europeo cumple. El distribuidor comprueba el marcado CE y que fabricante e importador han hecho lo suyo. El representante autorizado actúa por cuenta de un fabricante sin establecimiento en la Unión.
Fabricante, a efectos del reglamento, no es quien ensambla físicamente. Es quien desarrolla o hace desarrollar un producto y lo comercializa bajo su nombre o marca. Una empresa que encarga el desarrollo de su aplicación y la publica con su marca es fabricante. Da igual que no haya escrito una línea de código.
Cuando el fabricante está fuera de la Unión, la responsabilidad sigue una cadena. Primero responde el representante autorizado. A falta de este, el importador. Después el distribuidor. Y en último término se atiende al Estado miembro donde se concentre el mayor número de usuarios.
Un importador o distribuidor pasa a ser considerado fabricante en dos supuestos del artículo 21. El primero es comercializar el producto bajo su propio nombre o marca. El segundo es introducir una modificación sustancial en un producto ya comercializado. En ambos casos queda sujeto a los artículos 13 y 14. Asume las obligaciones completas del fabricante y el deber de notificar vulnerabilidades en 24 horas.
Es la trampa jurídica más silenciosa del reglamento, porque no depende de lo que la empresa hace sino de cómo etiqueta lo que vende. El modelo de marca blanca, habitual en electrónica de consumo y en distribución industrial, convierte al distribuidor en fabricante sin que este lo perciba. Lo mismo ocurre con el integrador que reempaqueta software de terceros bajo su propia marca.
La consecuencia práctica es que un distribuidor sin capacidad técnica de desarrollo asume la obligación de gestionar vulnerabilidades de un producto que no controla. La única salida razonable es contractual. Antes de poner la marca propia sobre un producto ajeno conviene cerrar tres cosas con el proveedor original. El acceso a la información técnica, el compromiso de parcheo y unos plazos internos compatibles con las 24 horas.
El artículo 24 crea la figura del responsable de software libre. Es la persona jurídica que presta apoyo sostenido a un programa de código abierto destinado a un uso comercial. No es un fabricante y no soporta sus obligaciones. Debe adoptar una política de ciberseguridad documentada, gestionar las vulnerabilidades de forma efectiva y cooperar con las autoridades de vigilancia del mercado.
El artículo 64 va más lejos y excluye por completo de multas administrativas a estos responsables. Es una de las pocas exenciones subjetivas del reglamento. Responde a la preocupación del legislador por no asfixiar al ecosistema de código abierto europeo.
La clasificación determina cómo se demuestra el cumplimiento, no si el producto está obligado. Hay cuatro niveles. Los productos por defecto, que son todos los no listados, permiten autoevaluación. Los importantes de clase I y II figuran en el anexo III. Los críticos figuran en el anexo IV. Cuanto más sensible es la función, más peso tiene la intervención de un tercero independiente.
| Categoría | Dónde figura | Cómo se evalúa la conformidad | Ejemplos |
|---|---|---|---|
| Por defecto | No listado | Autoevaluación con control interno, expediente técnico y declaración UE de conformidad | La mayoría del software de gestión y de los dispositivos conectados de consumo |
| Importante clase I | Anexo III | Autoevaluación si se aplican normas armonizadas. En su defecto, intervención de un tercero | Navegadores, gestores de contraseñas, antivirus, VPN, sistemas operativos, routers, domótica con funciones de seguridad, juguetes conectados con seguimiento |
| Importante clase II | Anexo III | Evaluación por organismo notificado | Cortafuegos, hipervisores y entornos de contenedores, sistemas de detección y prevención de intrusiones, microprocesadores resistentes a manipulación |
| Crítico | Anexo IV | Puede exigirse certificación europea de ciberseguridad | Módulos de seguridad hardware, pasarelas de contadores inteligentes, tarjetas inteligentes y elementos seguros |
La clasificación depende de la funcionalidad principal del producto, no de sus funciones accesorias. Un programa de contabilidad con un gestor de contraseñas para su propio acceso no se convierte por eso en producto importante de clase I.
Durante casi un año la clasificación fue una fuente de inseguridad, porque los anexos describían las categorías en términos genéricos. El Reglamento de Ejecución (UE) 2025/2392, de 28 de noviembre de 2025, publicó las descripciones técnicas de cada categoría de producto importante y crítico. Ese texto es hoy el punto de partida de cualquier análisis de encaje. Las 26 categorías y sus descripciones técnicas están en la guía de clasificación de productos del Cyber Resilience Act.
El fabricante debe diseñar, desarrollar y producir el producto conforme a los requisitos esenciales del anexo I. Y debe mantener esa conformidad durante todo el período de soporte. No es un trámite de certificación puntual, es una obligación continuada que sobrevive a la venta.
Las obligaciones se agrupan en cinco bloques.
El período de soporte es la pieza que más planificación exige. El artículo 13, apartado 8, fija un mínimo de cinco años. Solo cabe un período inferior cuando la vida útil esperada del producto sea menor, como ocurre con una aplicación diseñada para un evento concreto. El fabricante debe determinar ese período, informarlo al usuario y respetarlo, aunque el producto deje de venderse.
Cinco años de compromiso de parcheo obligan a decisiones que no son jurídicas. Un fabricante que integra una biblioteca de terceros sin soporte a largo plazo está asumiendo una obligación que no podrá cumplir con sus propios medios.
Desde el 11 de septiembre de 2026, el fabricante notifica las vulnerabilidades explotadas activamente y los incidentes graves que afecten a la seguridad del producto. El régimen se articula en tres comunicaciones sucesivas sobre el mismo hecho. Los plazos son de 24 horas, 72 horas y 14 días o un mes según el caso.
Las notificaciones se presentan por la plataforma única que gestiona ENISA y se dirigen al CSIRT designado coordinador en el Estado miembro del establecimiento principal. Desde el 4 de septiembre de 2026, España encamina sus notificaciones a través de INCIBE-CERT.
Esta obligación es la única del reglamento que ya se aplica a los productos antiguos. El artículo 69, apartado 3, la extiende a todos los productos comercializados antes del 11 de diciembre de 2027, sin límite de antigüedad. Los plazos, los sujetos y el contenido mínimo de cada comunicación están en nuestro análisis de la notificación de vulnerabilidades del Cyber Resilience Act.
El producto conforme lleva marcado CE y va acompañado de una declaración UE de conformidad en la que el fabricante asume la responsabilidad. Es el mismo mecanismo que ya se aplica a la seguridad eléctrica o a la compatibilidad electromagnética, ahora extendido a la ciberseguridad. Sin marcado CE, el producto no puede comercializarse en la Unión a partir del 11 de diciembre de 2027.
La ruta hasta ese marcado depende de la categoría. Un producto por defecto se evalúa internamente con el módulo A. Un producto importante de clase I puede seguir esa misma vía si el fabricante aplica normas armonizadas que cubran los requisitos aplicables. Si no las aplica, o si el producto es de clase II, interviene un organismo notificado. Los productos críticos del anexo IV pueden quedar sujetos a un esquema europeo de certificación.
Los organismos notificados son la pieza que hace posible todo lo anterior. Sus procedimientos de notificación se aplican desde el 11 de junio de 2026. La red tenía que existir antes de que el marcado fuese exigible. El procedimiento completo, la documentación técnica y la declaración están en la guía del marcado CE del Cyber Resilience Act.
El reglamento no entra en vigor de golpe. Distribuye sus obligaciones en cuatro hitos a lo largo de tres años, y tres ya se han cumplido.
| Fecha | Qué ocurre | Situación |
|---|---|---|
| 10 de diciembre de 2024 | Entrada en vigor del reglamento | Cumplido |
| 11 de junio de 2026 | Se aplican los procedimientos de notificación de los organismos de evaluación de la conformidad | Cumplido |
| 11 de septiembre de 2026 | Son exigibles las obligaciones de notificación del artículo 14 | Cumplido |
| 11 de diciembre de 2027 | Aplicación plena. Requisitos esenciales, marcado CE y declaración de conformidad | Pendiente |
Quince meses separan septiembre de 2026 de diciembre de 2027. En ese tramo convive un deber de notificar plenamente exigible con unos requisitos técnicos aún inaplicables. Un fabricante puede estar obligado a comunicar una vulnerabilidad de un producto que aún no tiene que cumplir el anexo I.
El 27 de julio de 2026 la Comisión aprobó la Comunicación C(2026) 5252, que contiene la guía de aplicación del reglamento prevista en su artículo 26. Está pensada sobre todo para microempresas y pymes, e incluye 67 ejemplos prácticos. No es vinculante, porque la interpretación auténtica del reglamento corresponde al Tribunal de Justicia de la Unión Europea. Pero expresa el criterio oficial de la Comisión y sirve también para orientar a las autoridades de vigilancia del mercado y a los organismos notificados. El texto está publicado en la biblioteca de la Comisión Europea. Estas son las aclaraciones que más cambian el trabajo de una empresa.
Muchos fabricantes seguirán vendiendo después del 11 de diciembre de 2027 unidades de modelos diseñados antes. La guía aclara que cumplir no obliga necesariamente a rediseñarlos. El fabricante tiene que hacer la evaluación de riesgos del artículo 13, apartado 2, y si demuestra que el producto ya incorpora medidas de seguridad adecuadas puede apoyarse en ellas.
Lo que no desaparece es el procedimiento. Esas unidades necesitan su evaluación de la conformidad, su declaración UE de conformidad y su marcado CE. La guía sí rebaja la carga documental. No hace falta reconstruir la documentación de diseño ni los ensayos de la fase original, y los ensayos que sean necesarios pueden agruparse por familias de productos.
Para el reglamento, solo es software libre el que tiene una licencia libre con todos los derechos de uso, modificación y redistribución y además publica su código fuente. Un programa con licencia libre cuyo código solo reciben los clientes que pagan no cuenta como tal. Tampoco responde quien se limita a aportar código a un proyecto ajeno. La responsabilidad es de quien publica el programa y decide sus versiones.
La guía fija cuándo el software libre se suministra en el marco de una actividad comercial y pasa a estar sujeto al reglamento.
No basta, en cambio, con ofrecer por separado formación o consultoría sobre un programa que cualquiera puede descargar gratis. Tampoco con aceptar donaciones, salvo que en la práctica funcionen como un precio porque condicionan el acceso al programa o a sus actualizaciones.
La guía dedica un apartado entero al software que se actualiza de forma continua. El criterio no es el tamaño del cambio, sino si altera el riesgo de ciberseguridad y si ese riesgo no estaba ya contemplado en la evaluación de riesgos del fabricante. Una función nueva que cambia la finalidad del producto será normalmente una modificación sustancial. Una función prevista y evaluada desde el diseño no lo es. Una función aparentemente menor sí puede serlo. El ejemplo de la guía es la opción de mantener la sesión iniciada, que guarda los tokens de autenticación en el dispositivo.
Las actualizaciones de seguridad, por regla general, no son modificaciones sustanciales. Dejan de estar exentas cuando cambian la finalidad del producto o añaden riesgos no previstos, por ejemplo interfaces accesibles desde fuera o dependencias de servicios de terceros. Para decidirlo, la guía propone cuatro preguntas.
La consecuencia importa. Un producto modificado sustancialmente se trata como un producto nuevo que se introduce en el mercado. Si lo modifica alguien distinto del fabricante, esa persona pasa a ser fabricante, aunque sus obligaciones pueden limitarse a la parte modificada cuando el cambio no afecta a la seguridad del producto en su conjunto. La misma proporcionalidad vale para el fabricante original que modifica después de diciembre de 2027 un producto comercializado antes.
La guía corrige una lectura muy extendida. Los cinco años del artículo 13, apartado 8, son un suelo. Un producto que se espera usar durante más tiempo debe tener un período de soporte más largo. El fabricante tiene que indicar en el momento de la compra la fecha final del soporte, al menos con mes y año. Y, cuando sea técnicamente posible, avisar al usuario cuando el soporte termine.
En el software con versiones sucesivas, cada versión modificada sustancialmente necesita su propio período de soporte declarado. El artículo 13, apartado 10, permite corregir vulnerabilidades solo en la última versión si los usuarios pueden actualizar gratis y sin costes adicionales. Según la guía, esos costes adicionales son comprar hardware nuevo o sustituir infraestructura, no el tiempo de pruebas o de configuración propio de cualquier actualización. Y una modificación sustancial no reinicia automáticamente el período de soporte, que solo se recalcula si cambia la vida útil esperada del producto.
El reglamento incluye en el producto sus soluciones de tratamiento de datos a distancia. La guía aclara que una solución remota forma parte del producto cuando se cumplen dos condiciones a la vez.
Da igual dónde se ejecute. Un servidor propio en las instalaciones del fabricante cuenta igual que una nube pública. Quedan fuera los sistemas internos de la empresa, como recursos humanos, CRM o los entornos de integración y despliegue, la telemetría con fines puramente estadísticos y las webs que solo informan sobre el producto. Una aplicación SaaS de un tercero tampoco forma parte del producto, pero el fabricante debe tratarla como un componente, evaluar sus riesgos y ejercer la diligencia debida. La guía propone incluir garantías de seguridad en los acuerdos de nivel de servicio con esos proveedores.
El plazo corre desde que el fabricante tiene conocimiento del hecho. La guía lo sitúa en el momento en que, tras una primera evaluación, tiene un grado razonable de certeza de que una vulnerabilidad de su producto se está explotando activamente o de que un incidente grave ha comprometido su seguridad. Esa evaluación debe hacerse de inmediato.
La guía añade tres precisiones. La obligación no es retroactiva, así que no hay que notificar explotaciones conocidas antes del 11 de septiembre de 2026. La vulnerabilidad de un componente de terceros que no puede explotarse, o no se ha explotado, en el propio producto no es de notificación obligatoria, aunque sí hay que comunicarla a quien mantiene el componente. Y el deber de notificar continúa después de que termine el período de soporte del producto.
España no ha designado formalmente todavía a sus autoridades del reglamento. El proyecto de real decreto que debe hacerlo atribuye la vigilancia del mercado a la Secretaría de Estado de Telecomunicaciones e Infraestructuras Digitales. Reserva la condición de autoridad notificante al Centro Criptológico Nacional. La CNMC emitió su informe IPN/CNMC/007/26 el 13 de mayo de 2026 y el texto continúa en tramitación.
Conviene separar dos cosas que se confunden con frecuencia. Que INCIBE-CERT figure desde el 4 de septiembre de 2026 en la lista de ENISA como CSIRT coordinador resuelve a quién se notifica. No resuelve quién supervisa el mercado ni quién instruye un expediente sancionador. El canal europeo entra en servicio antes que el brazo ejecutor nacional.
La ausencia de designación no suspende ninguna obligación. El reglamento es directamente aplicable y no necesita norma nacional de desarrollo para obligar. Lo que queda en el aire es la maquinaria sancionadora española, no la existencia del deber. Es el mismo patrón que ya se vio con el marco regulatorio digital europeo en otras normas recientes.
El artículo 64 fija tres tramos de multa administrativa. En todos ellos se aplica el importe mayor entre la cifra fija y el porcentaje del volumen de negocio anual mundial del ejercicio anterior.
Hay dos exenciones que apenas se mencionan y que cambian el cálculo de riesgo de muchas empresas. Las microempresas y las pequeñas empresas no pueden ser multadas por incumplir el plazo de la alerta temprana de 24 horas. Los responsables de software libre no pueden ser multados por ninguna infracción del reglamento.
Esa exención de las pymes es limitada y conviene leerla bien. Alcanza al plazo de las 24 horas, no al deber de notificar. Una pequeña empresa que notifique tarde no será sancionada por el retraso. Una que no notifique en absoluto sigue expuesta al tramo más alto. Qué infracción cae en cada tramo y qué falta en España para sancionar se explica en el análisis de las sanciones del Cyber Resilience Act.
El CRA regula el producto. La Directiva NIS2 regula la organización que presta un servicio esencial o importante. Una misma empresa puede estar sujeta a las dos por títulos distintos, y los deberes de notificación no se sustituyen entre sí. Un fabricante de software que además opera una infraestructura crítica notifica dos veces, por vías distintas y con plazos propios.
Con el Reglamento de Inteligencia Artificial la relación es de acumulación. Un sistema de IA de alto riesgo que se comercialice como producto con elementos digitales debe cumplir los requisitos de ciberseguridad de ambos textos. Los dos textos están enlazados expresamente: según el artículo 12 del CRA, un sistema de IA de alto riesgo que cumple los requisitos esenciales del CRA se presume conforme con los requisitos de ciberseguridad del artículo 15 del AI Act.
Queda un tercer frente del que casi nadie habla. La Directiva (UE) 2024/2853 sobre responsabilidad por productos defectuosos incluye el software dentro del concepto de producto. Y admite que un producto sea defectuoso por falta de actualizaciones de seguridad. El expediente técnico que el CRA obliga a mantener será la prueba de diligencia en una reclamación civil por daños. Es la lectura que menos aparece en los análisis técnicos y la que más pesa cuando hay un perjuicio real.
Una empresa gallega importa cámaras de videovigilancia de un fabricante asiático y las vende bajo su propia marca en grandes superficies. No desarrolla firmware ni tiene departamento técnico. Se considera distribuidora y asume que sus obligaciones se limitan a comprobar el marcado CE.
El artículo 21 dice otra cosa. Al comercializar el producto bajo su nombre, esa empresa es fabricante a efectos del reglamento. Le corresponden los requisitos esenciales del anexo I, el expediente técnico y la declaración UE de conformidad. También un período de soporte de al menos cinco años y la notificación en 24 horas de toda vulnerabilidad explotada.
El anexo III incluye entre los productos importantes de clase I los productos domóticos con funciones de seguridad, y menciona expresamente las cámaras de seguridad. Si el modelo se comercializa para uso doméstico, la evaluación de la conformidad deja de ser una autoevaluación libre. La calificación no es automática y hay que analizarla producto a producto. Las unidades vendidas en 2025 siguen en el mercado, así que el deber de notificar ya le alcanza. El marcado CE, en cambio, no le será exigible hasta diciembre de 2027.
La solución no pasa por dejar de vender. Pasa por renegociar el contrato con el fabricante asiático. Acceso al SBOM, compromiso de parcheo compatible con las 24 horas y reparto del coste de las actualizaciones durante el período de soporte. Es trabajo contractual, no técnico.
El reglamento entró en vigor el 10 de diciembre de 2024 y sus obligaciones llegan escalonadas. Desde el 11 de septiembre de 2026 es obligatorio notificar las vulnerabilidades explotadas activamente y los incidentes graves. El resto del reglamento, incluidos los requisitos esenciales del anexo I y el marcado CE, se aplica desde el 11 de diciembre de 2027.
Sí. El reglamento no distingue entre hardware y software. Alcanza a cualquier producto con una conexión de datos directa o indirecta a un dispositivo o a una red, incluidas las aplicaciones móviles, el software de gestión y las soluciones de tratamiento de datos a distancia asociadas al producto. La mayoría de este software encaja en la categoría por defecto, que permite autoevaluación.
Sí. El artículo 21 considera fabricante al importador o distribuidor que comercializa un producto bajo su propio nombre o marca, y también al que introduce una modificación sustancial en un producto ya comercializado. Queda sujeto a los artículos 13 y 14, con las obligaciones completas del fabricante y el deber de notificar en 24 horas.
Depende de la categoría del producto. Los productos por defecto se autoevalúan con control interno. Los importantes de clase I del anexo III permiten autoevaluación si el fabricante aplica normas armonizadas que cubran los requisitos aplicables. Los importantes de clase II exigen la intervención de un organismo notificado y los críticos del anexo IV pueden requerir certificación europea de ciberseguridad.
El artículo 13, apartado 8, fija un período de soporte de al menos cinco años. Solo cabe un período menor cuando la vida útil esperada del producto sea inferior a cinco años. El fabricante debe determinar ese período, comunicarlo al usuario y mantenerlo aunque el producto deje de venderse.
El reglamento es directamente aplicable y obliga sin necesidad de norma nacional de desarrollo. Lo que está pendiente en España es la designación formal de las autoridades de vigilancia del mercado y del procedimiento sancionador, no la existencia del deber. Un retraso en la designación no suspende la obligación. Si podrán sancionarse después incumplimientos anteriores al régimen sancionador español es una cuestión abierta, pero las medidas sobre el producto y la responsabilidad civil no dependen de él.
El Cyber Resilience Act redistribuye responsabilidad a lo largo de toda la cadena de suministro, y la reparte con criterios que no coinciden con la intuición comercial de las empresas. Si vendes productos conectados o software, el análisis de encaje conviene hacerlo antes de diciembre de 2027, no después. En Innovatech revisamos la calificación de tus productos, el reparto contractual del riesgo con tus proveedores y el circuito interno de notificación. Escríbenos y te damos una valoración inicial gratuita.
Marta Suárez-Mansilla, Socia Directora de Innovatech y abogada que ejerce en derecho tecnológico. Formada en Copyright por Harvard Law School y en Blockchain por BerkeleyX, acumula más de 8 años de experiencia asesorando a empresas tecnológicas.