Consultoría Cyber Resilience Act (CRA): adecuación para fabricantes y proveedores de software y hardware
El Reglamento (UE) 2024/2847 Cyber Resilience Act entró en vigor el 10 de diciembre de 2024, obliga desde el 11 de septiembre de 2026 a notificar a ENISA las vulnerabilidades explotadas y será plenamente aplicable el 11 de diciembre de 2027. Afecta a todos los fabricantes y distribuidores de productos con elementos digitales vendidos en la UE: desde aplicaciones de escritorio hasta dispositivos IoT, routers y software empresarial. Las sanciones alcanzan los 15 millones de euros o el 2,5% de la facturación global anual.
Dimensiona tu proyecto · Evaluar mi adecuación al CRA
¿Prefieres hablarlo? Llámanos al +34 960 730 013
- 11-09-2026 — notificar a ENISA ya es obligatorio, para todo el catálogo
- 24 h · 72 h · 14 días — aviso temprano, notificación e informe final
- 11-12-2027 — aplicación plena: Anexo I, conformidad y marcado CE
- 15 M€ o 2,5% — sanción máxima, también por fallar en el artículo 14
¿Tu empresa fabrica o distribuye productos digitales en la UE?
Si desarrollas software que incluye componentes instalables en el lado del cliente, fabricas dispositivos con conectividad de red —cámaras IP, routers, dispositivos IoT, wearables, sistemas industriales—, distribuyes en la UE productos digitales fabricados fuera de ella, o tus componentes se integran en los productos de otros fabricantes, el CRA te afecta directamente. El reglamento aplica a toda la cadena: fabricante, importador y distribuidor. Muchas empresas asumen erróneamente que solo aplica a los fabricantes de hardware, pero el CRA abarca también a los desarrolladores de software con componentes de red, aplicaciones de escritorio con conectividad remota y sistemas embebidos.
El plazo de adecuación plena es diciembre de 2027, pero una parte ya obliga: desde el 11 de septiembre de 2026 hay que notificar a ENISA las vulnerabilidades activamente explotadas y los incidentes graves. Y por el artículo 69.3 esa obligación alcanza a todo el catálogo, también a los productos que llevan años en el mercado. Lo que casi nadie ha asimilado es el otro lado: hoy no hay normas armonizadas del CRA citadas en el Diario Oficial ni organismos notificados designados, así que muchos productos de clase I no tienen todavía una vía de autoevaluación abierta.
Una vulnerabilidad explotada en tu producto, bajo el artículo 14
Desde el 11 de septiembre de 2026 este es el reloj que corre cuando alguien explota un fallo de algo que vendes. Lo que decide si llegas no es el parche: es tener preparado de antemano quién notifica, con qué cuenta y con qué datos.
- Tienes conocimiento (Hora 0): Un investigador, un cliente o un feed de amenazas te avisa de que una vulnerabilidad de tu firmware se está explotando. El plazo empieza a contar desde que lo sabes, no desde que lo confirmas del todo. Sin canal de reporte ni responsable, el aviso se pierde en un buzón genérico
- Aviso temprano (≤ 24 h): Por la plataforma única de ENISA, que lo hace llegar a la vez al CSIRT coordinador —INCIBE en España— y a ENISA. La plataforma funciona solo por navegador y sin API: las cuentas EU Login con doble factor tienen que existir antes. El primer plazo que se incumple cuando nadie sabe quién notifica
- Notificación de la vulnerabilidad (≤ 72 h): Información general del producto afectado, naturaleza del aprovechamiento y de la vulnerabilidad, y las medidas correctoras o mitigaciones disponibles, también las que pueden aplicar los usuarios.
- Corrección y aviso a usuarios (Anexo I · parte II): Actualización de seguridad gratuita, distribuida de forma segura, e información a los usuarios afectados sobre la vulnerabilidad y cómo mitigarla, en un formato estructurado. Con SBOM al día se sabe en minutos qué versiones y clientes están afectados
- Informe final (≤ 14 días tras el parche): Descripción de la vulnerabilidad y su gravedad, impacto, información sobre el actor malicioso si se conoce y detalle de la actualización publicada.
Por qué importa: Fallar en el artículo 14 está en el tramo sancionador más alto del reglamento: hasta 15 millones de euros o el 2,5% de la facturación mundial, el mismo que incumplir los requisitos esenciales.
Ejemplo ilustrativo. Los plazos son los del artículo 14 del Reglamento (UE) 2024/2847; para un incidente grave, el informe final se presenta en el plazo de un mes.
En qué consiste nuestra consultoría CRA
- Análisis de aplicabilidad: determinamos si tus productos entran en el ámbito del CRA y en qué categoría (por defecto, importante de clase I, importante de clase II o crítico), según su funcionalidad principal
- Puesta en marcha del artículo 14: responsable de notificación, cuentas en la plataforma única de ENISA, plantillas de aviso a 24 h, 72 h y 14 días, y simulacro
- Gap analysis técnico: evaluamos el producto y su ciclo de desarrollo seguro (SDLC) frente a los requisitos esenciales del Anexo I, parte I
- Gap analysis de gestión de vulnerabilidades (Anexo I, parte II): SBOM, divulgación coordinada, actualizaciones gratuitas y período de soporte
- Pruebas técnicas del producto: pentesting de hardware, firmware y aplicaciones, y auditoría de código fuente, para demostrar que no hay vulnerabilidades explotables conocidas
- Plan de adecuación priorizado: qué cubrir ya y qué preparar para diciembre de 2027, con la ruta de evaluación de la conformidad que te corresponde hoy
- Documentación técnica: expediente, declaración de conformidad UE, marcado CE e instrucciones de seguridad para usuarios
- Política de divulgación coordinada de vulnerabilidades (CVD), canal de reporte y security.txt
Proceso de adecuación al CRA
- Clasificación de productos: Determinamos el nivel de cada producto —por defecto, importante de clase I, importante de clase II o crítico— a partir de su funcionalidad principal y las listas cerradas de los Anexos III y IV. El nivel no cambia los requisitos: decide quién puede firmar que se cumplen.
- Artículo 14 operativo: Antes que nada, lo que ya es exigible: quién detecta, quién decide y quién notifica, con las cuentas de la plataforma única de ENISA creadas y un simulacro de aviso a 24 horas sobre un producto real de tu catálogo.
- Gap analysis técnico y pruebas: Evaluamos el producto frente a los requisitos esenciales del Anexo I: seguridad por defecto, superficie de ataque mínima, ausencia de credenciales comunes, cifrado, actualizaciones seguras y registro de eventos. Lo comprobamos con pruebas, no con cuestionarios.
- Gap analysis de procesos: Analizamos la gestión de vulnerabilidades: SBOM, vigilancia de dependencias, canal de divulgación, período de soporte declarado y capacidad de publicar parches gratuitos de forma segura.
- Plan de adecuación: Plan de acción con dos horizontes —lo exigible hoy y la aplicación plena de diciembre de 2027—, con responsables, esfuerzo estimado y la ruta de conformidad que admite tu categoría con el estado actual de normas y organismos.
- Implementación y documentación: Apoyamos la implementación de controles en el SDLC y redactamos la documentación obligatoria: expediente técnico, declaración de conformidad UE, instrucciones al usuario e historial de vulnerabilidades.
Entregables
- Informe de clasificación de productos con justificación en base al CRA y sus Anexos III y IV
- Procedimiento de notificación del artículo 14, con plantillas y acta del simulacro
- Gap analysis técnico frente a los requisitos esenciales del Anexo I (partes I y II)
- Informe de pruebas técnicas del producto con hallazgos reproducibles y re-test
- Plan de adecuación priorizado con dos hitos: la notificación a ENISA, ya vigente, y la aplicación plena en diciembre de 2027
- Borrador de declaración de conformidad UE y documentación técnica de seguridad
- Política de divulgación coordinada de vulnerabilidades (CVD policy) y security.txt
¿A quién afecta el CRA?
- Fabricantes de software con componentes instalables y conectividad de red (SaaS con agentes de escritorio, aplicaciones empresariales, firmware)
- Fabricantes de hardware con conectividad: dispositivos IoT, cámaras IP, routers domésticos y profesionales, wearables, juguetes conectados
- Proveedores de componentes de software que se integran en los productos de otros fabricantes (librerías, SDKs, módulos), que son productos con su propia declaración
- Importadores y distribuidores en la UE de productos digitales fabricados fuera de la Unión Europea
- Empresas de automatización industrial y fabricantes de sistemas de control (OT/ICS/SCADA) con componentes en red
- Fabricantes de equipos radioeléctricos que ya pasaron por la RED y la EN 18031: ese régimen se deroga el 11 de diciembre de 2027 y el CRA lo sustituye
CRA y NIS2: dos reglamentos que se confunden
Los dos hablan de ciberseguridad y de notificar en 24 horas, pero regulan cosas distintas. Un fabricante que además presta un servicio esencial tiene que cumplir los dos.
| Cyber Resilience Act | NIS2 | |
|---|---|---|
| Qué regula | La seguridad del producto con elementos digitales durante todo su ciclo de vida | La gestión de riesgos de ciberseguridad de la organización |
| A quién obliga | Fabricantes, importadores y distribuidores de productos que se venden en la UE | Entidades esenciales e importantes de los sectores que enumera |
| Qué se notifica | Vulnerabilidades explotadas e incidentes graves que afectan al producto | Incidentes significativos que afectan a los servicios de la entidad |
| Plazos | 24 h aviso · 72 h notificación · 14 días informe final tras el parche | 24 h alerta · 72 h notificación · 1 mes informe final |
| A quién | Plataforma única de ENISA (CSIRT coordinador: INCIBE) | CSIRT o autoridad nacional competente |
| Desde cuándo | Artículo 14: 11-09-2026 · todo lo demás: 11-12-2027 | Directiva aplicable desde 2024; en España, pendiente de transposición |
| Cómo se demuestra | Evaluación de la conformidad, declaración UE y marcado CE | Medidas de gestión de riesgos, supervisión y auditorías |
| Sanción máxima | 15 M€ o 2,5% de la facturación mundial | 10 M€ o 2% (esenciales) · 7 M€ o 1,4% (importantes) |
Compara con
Lo que más encontramos al revisar productos frente al Anexo I
La misma contraseña en todas las unidades
Credenciales de administración por defecto, idénticas en toda la flota y escritas en el firmware. Es de los primeros puntos que mira cualquier revisión del Anexo I, y de los más fáciles de explotar a escala.
Nadie sabe qué lleva el producto
Sin SBOM, o con uno que se generó una vez y no se actualiza. Cuando sale una CVE en una librería, el fabricante tarda días en saber si le afecta, y el artículo 14 da 24 horas.
Actualizaciones que no se verifican
Firmware descargado sin firma o por un canal sin cifrar. Cualquiera en la red puede sustituir el parche por otra cosa.
Ningún sitio donde reportar
Ni política de divulgación ni security.txt ni un buzón vigilado. El investigador que encuentra el fallo no tiene a quién decírselo, y el reloj empieza igual.
Puertos de depuración abiertos en serie
Consolas UART o JTAG accesibles en las unidades de producción, que dan una shell de root con un adaptador de pocos euros.
Un período de soporte que nadie ha decidido
El CRA exige declarar durante cuánto tiempo se darán parches gratuitos, como mínimo cinco años salvo que el uso previsto sea más corto. En muchos fabricantes es una decisión que nadie ha tomado.
Preguntas frecuentes sobre el CRA
¿Cuándo entra en vigor el Cyber Resilience Act?
El CRA entró en vigor el 10 de diciembre de 2024. La aplicación plena de los requisitos técnicos y de conformidad es el 11 de diciembre de 2027. Hay dos hitos intermedios: desde el 11 de junio de 2026 los Estados miembros pueden designar organismos notificados para la evaluación por terceros, y desde el 11 de septiembre de 2026 es obligatorio notificar a ENISA las vulnerabilidades activamente explotadas y los incidentes graves.
¿La obligación de notificar alcanza a productos que ya estaban en el mercado?
Sí. Por el artículo 69.3, el artículo 14 se aplica a todos los productos con elementos digitales, también a los introducidos en el mercado antes del 11 de diciembre de 2027. No hay excepción por antigüedad ni por producto descatalogado: si alguien explota una vulnerabilidad de un modelo que vendiste hace años, el plazo de 24 horas corre igual.
¿Y los requisitos del Anexo I también se aplican a lo que ya vendo?
No, con un matiz importante. Por el artículo 69.2, los productos introducidos en el mercado antes del 11 de diciembre de 2027 solo quedan sujetos a los requisitos del CRA si después sufren una modificación sustancial. El corte es la fecha de introducción en el mercado de cada unidad, así que conviene documentarla con precisión.
¿El CRA aplica a todo el software o solo al hardware conectado?
El CRA aplica a todos los "productos con elementos digitales": hardware y software con conectividad de red directa o indirecta. Están excluidos el software publicado como open source sin finalidad comercial, los servicios SaaS puros sin componentes instalables en el cliente, los productos médicos regulados por el MDR, los productos de aviación civil y el equipo de defensa. Si tu SaaS incluye un agente de escritorio o un plugin instalable, ese componente sí entra en el ámbito del CRA.
¿Qué diferencia hay entre productos por defecto, de clase I, de clase II y críticos?
Los productos por defecto son la mayoría y pueden usar la autoevaluación. Los importantes de clase I (gestores de identidad, navegadores, gestores de contraseñas, software antimalware, VPN, routers domésticos…) necesitan un tercero salvo que apliquen íntegramente una norma armonizada. Los de clase II (hipervisores, cortafuegos, sistemas de detección de intrusiones, microprocesadores resistentes a manipulaciones…) requieren siempre un organismo notificado o certificación europea, y los críticos del Anexo IV, certificación cuando la Comisión la exija. El nivel no cambia los requisitos, solo quién puede firmar que se cumplen.
¿Puedo hacer hoy la autoevaluación de un producto de clase I?
Hoy es difícil. En la última revisión de nuestra guía (septiembre de 2026) no había ninguna norma armonizada del CRA citada en el Diario Oficial ni organismos notificados designados bajo el reglamento. Sin norma armonizada aplicada al completo, la clase I necesita un tercero, y sin organismos designados esa vía tampoco está abierta todavía. Lo sensato es preparar el expediente como si fuera a auditoría externa y seguir los hitos de normalización.
¿A quién se notifica en España?
Todo se envía por la plataforma única de notificación de ENISA, que lo hace llegar a la vez a ENISA y al CSIRT coordinador del Estado donde el fabricante tiene su establecimiento principal. En España, ese CSIRT coordinador es INCIBE. La plataforma funciona por navegador, así que las cuentas EU Login con doble factor de quien vaya a notificar tienen que estar creadas antes del primer aviso.
¿Es obligatorio tener un SBOM?
Sí. El Anexo I, parte II, exige identificar y documentar los componentes del producto elaborando una lista de materiales de software (SBOM) en un formato de uso común y legible por máquina, que cubra al menos las dependencias de primer nivel. Forma parte de la documentación técnica; no es obligatorio publicarlo. Sin un SBOM al día es casi imposible saber en 24 horas si una vulnerabilidad nueva te afecta.
Ya tengo marcado CE por la Directiva de equipos radioeléctricos y la EN 18031, ¿me sirve?
Sirve como trabajo previo, pero no como cumplimiento del CRA. El marcado CE se otorga por acto legislativo y no hay reconocimiento cruzado. Además, el Reglamento Delegado (UE) 2026/339 deroga el 2022/30, el de ciberseguridad de la RED, con efecto el 11 de diciembre de 2027: desde ese día, la ciberseguridad de esos equipos se rige por el CRA.
¿Cuáles son las sanciones por incumplimiento del CRA?
El CRA establece tres niveles de sanción: hasta 15 millones de euros o el 2,5% de la facturación anual global por incumplir los requisitos esenciales de ciberseguridad o las obligaciones de los artículos 13 y 14, incluida la notificación; hasta 10 millones o el 2% por incumplir otras obligaciones; y hasta 5 millones o el 1% por facilitar información incorrecta a las autoridades.
¿El CRA se solapa con NIS2 o con otras normativas?
Sí. NIS2 regula la ciberseguridad de las entidades que prestan servicios esenciales e importantes, mientras que el CRA regula la seguridad de los productos digitales que se ponen en el mercado. Si eres fabricante de software y además prestas un servicio esencial, te aplican ambas. También hay solapamientos con el MDR para dispositivos médicos conectados (el MDR prevalece) y con la Directiva de equipos radioeléctricos hasta diciembre de 2027.
¿Cuánto tiempo lleva adecuarse al CRA?
Depende del punto de partida y de la categoría de productos. Lo del artículo 14 se puede tener operativo en semanas. Para el resto, empresas con un SDLC seguro y una gestión de vulnerabilidades madura pueden completar el proceso en 6-9 meses; las que parten de cero necesitarán 12-24 meses para llegar a diciembre de 2027.
Entender el reglamento
- Guía del CRA para fabricantes
- ¿Qué es el Cyber Resilience Act?
- Requisitos del CRA
- Plazos del CRA
- Multas y sanciones del CRA
Lo que ya es obligatorio
- La notificación del CRA ya es obligatoria
- CRA y divulgación de vulnerabilidades
- Divulgación coordinada de vulnerabilidades
- Cómo crear un programa de divulgación
Herramientas
Pruebas técnicas para demostrarlo
- Pentesting IoT y de hardware
- Auditoría de código fuente
- Gestión de programas de divulgación
- CRA vs NIS2
Fuentes
- Reglamento (UE) 2024/2847 (Cyber Resilience Act) — texto oficial en EUR-Lex
- Comisión Europea — Cyber Resilience Act
¿Listo para proteger tu empresa?
Responde la ficha de alcance a tu ritmo y la usaremos para preparar tu propuesta. Si prefieres hablarlo antes, reserva una llamada gratuita de 30 minutos.