Reglamento de Ciberresiliencia (CRA): guía para fabricantes
El Reglamento de Ciberresiliencia, conocido por sus siglas en inglés CRA (Cyber Resilience Act, Reglamento (UE) 2024/2847), convierte la ciberseguridad en una condición para vender productos conectados en la Unión Europea. Quien fabrique, importe o distribuya electrónica con conexión tendrá que demostrar que sus productos son seguros, y llevar el marcado CE que lo acredite.
No es una norma lejana: desde el 11 de septiembre de 2026 ya es obligatorio notificar las vulnerabilidades explotadas y los incidentes graves, y el 11 de diciembre de 2027 empieza a aplicarse todo lo demás. Esta guía resume lo esencial desde el punto de vista de la ingeniería del producto.
A qué productos afecta
El CRA se aplica a los productos con elementos digitales: hardware y software cuyo uso previsto, o razonablemente previsible, incluye una conexión de datos, directa o indirecta, con un dispositivo o una red. En electrónica, eso abarca:
- Dispositivos IoT, wearables y electrónica de consumo conectada.
- Controladores industriales, sensores, pasarelas (gateways) y equipos de red.
- El firmware, los sistemas operativos y las aplicaciones asociadas, incluido el procesamiento remoto de datos que forme parte del producto.
Quedan fuera los productos regulados por otras normas europeas específicas, como los productos sanitarios, los vehículos de motor homologados, los productos de aviación civil certificados y los equipos marinos, además del software libre sin actividad comercial. Ojo: que un producto esté sujeto a otra normativa no significa siempre que quede fuera del CRA, y conviene comprobarlo caso por caso.
Calendario de aplicación
La fecha que más preocupa es el 11 de diciembre de 2027, pero hay otra que ya ha pasado: desde el 11 de septiembre de 2026 los fabricantes deben notificar a las autoridades las vulnerabilidades explotadas activamente y los incidentes graves de sus productos. Esta obligación alcanza también a los productos que ya estaban en el mercado antes de la aplicación plena.
¿Ya tienes productos en el mercado?Revisión y rescate de diseños
No todos los productos tienen las mismas obligaciones
El CRA distingue cuatro niveles según el riesgo. La mayoría de los productos son de la categoría por defecto y el fabricante puede evaluarlos por sí mismo. Los productos importantes (clases I y II) y los críticos figuran en los anexos III y IV del Reglamento, y exigen más: normas armonizadas, un organismo notificado o, en el futuro, un esquema europeo de certificación.
Dos matices que importan en la práctica:
- La categoría depende de la funcionalidad principal del producto, y el Reglamento de Ejecución (UE) 2025/2392 detalla qué productos entran en cada una.
- Las normas armonizadas que permitirán la autoevaluación en la clase I todavía están en elaboración. Mientras no se publiquen en el Diario Oficial de la UE, un producto de clase I puede necesitar la evaluación de un tercero.
Llegar preparado a la evaluación:Test y validación
Qué exige el CRA al producto
El anexo I del Reglamento reúne los requisitos esenciales en dos bloques. El primero se refiere al producto:
- Diseñarlo con un nivel de ciberseguridad adecuado a los riesgos.
- Que no tenga vulnerabilidades explotables conocidas cuando se comercializa.
- Configuración segura por defecto.
- Actualizaciones de seguridad durante el ciclo de vida del producto.
- Protección frente al acceso no autorizado, con autenticación y control de acceso.
- Protección de la confidencialidad y la integridad de los datos, tratando solo los necesarios.
- Superficie de ataque reducida al mínimo.
Se resuelve en el diseño:Diseño de hardwareFirmware embebido
El segundo bloque es la gestión de vulnerabilidades durante todo el periodo de soporte:
- Una lista de componentes de software (SBOM) que identifique, como mínimo, las dependencias de primer nivel.
- Pruebas y revisiones de seguridad periódicas.
- Una política de divulgación coordinada de vulnerabilidades y un punto de contacto para recibirlas.
- Corregir las vulnerabilidades con actualizaciones de seguridad gratuitas y distribuidas sin demora.
El periodo de soporte no puede ser inferior a cinco años, salvo que se espere que el producto se use durante menos tiempo, y el fabricante debe documentar cómo lo ha determinado. Todo ello se recoge en la documentación técnica, la declaración UE de conformidad y el marcado CE.
Mecanismo de actualización y SBOM:Firmware embebido
La notificación: lo que ya es obligatorio
Desde septiembre de 2026, el fabricante debe notificar a través de la plataforma única de notificación de ENISA, que reparte la información entre las autoridades correspondientes (el CSIRT del país donde tiene su sede y la propia ENISA):
- Alerta temprana: en las primeras 24 horas desde que se tiene conocimiento.
- Notificación: en un plazo de 72 horas.
- Informe final: a los 14 días de disponer de una medida correctiva, si se trata de una vulnerabilidad explotada, o en el plazo de un mes desde la notificación, si se trata de un incidente grave.
Por eso conviene tener definido de antemano quién vigila las vulnerabilidades, quién decide y quién notifica, porque 24 horas es muy poco tiempo para improvisar.
¿Sin equipo para vigilarlo?Seguimiento de vulnerabilidades
Sanciones
Incumplir los requisitos esenciales puede costar hasta 15 millones de euros o el 2,5 % de la facturación anual mundial, lo que sea mayor. Otras infracciones se sancionan con hasta 10 millones o el 2 %, y dar información incorrecta a las autoridades, con hasta 5 millones o el 1 %. Además, las autoridades pueden ordenar retirar un producto del mercado.
Cómo podemos ayudarte
Cumplir el CRA no es solo una cuestión documental: la mayor parte de los requisitos se resuelve en el diseño del producto, y ahí es donde la ingeniería marca la diferencia. Trabajamos contigo desde el análisis de riesgos hasta la verificación en hardware real, para que tu producto llegue a la evaluación de conformidad, que realizan los organismos notificados cuando procede, con las bases técnicas resueltas y la documentación preparada.
- Del análisis de riesgos a la arquitectura: partimos de un análisis de amenazas y lo traducimos en decisiones de hardware y firmware, como el arranque seguro, las actualizaciones firmadas o el almacenamiento seguro de claves.
- Verificación en hardware real, con evidencias que se integran en el expediente técnico.
- Productos existentes: analizamos las brechas frente al anexo I y los adaptamos sin necesidad de rediseñarlo todo.
Seguimiento de vulnerabilidades
El CRA no termina el día del lanzamiento: durante todo el periodo de soporte hay que vigilar los componentes, valorar si una vulnerabilidad afecta al producto y, si es así, preparar la corrección y notificarla a tiempo. Es un trabajo continuo, y no todas las empresas tienen un equipo dedicado a ello.
Por eso también ofrecemos un servicio de seguimiento de vulnerabilidades: vigilamos las dependencias de tu SBOM, evaluamos el impacto en tu producto y preparamos la actualización de firmware cuando hace falta. Se contrata como un servicio continuo, con una licencia periódica, para que tu equipo siga centrado en el producto.
Por dónde empezar
- Inventaría tus productos y define tu papel en cada uno: fabricante, importador o distribuidor.
- Clasifica cada producto: por defecto, importante o crítico.
- Prepara el proceso de notificación, que ya es exigible.
- Haz un análisis de brechas frente al anexo I.
- Define el periodo de soporte y cómo vas a distribuir las actualizaciones.
- Prepara la SBOM y la documentación técnica.
- Planifica la vía de evaluación de conformidad y el calendario hasta diciembre de 2027.
Si quieres ver cómo se aplica a un producto concreto, cuéntanos tu proyecto y lo repasamos contigo.
Fuentes
- Comisión Europea: Cyber Resilience Act.
- Comisión Europea: obligaciones de notificación.
- Comisión Europea: evaluación de conformidad.
- ENISA: plataforma única de notificación del CRA.
- Reglamento (UE) 2024/2847 en EUR-Lex.