El CRA en cinco ideas
- El Cyber Resilience Act (CRA) es el Reglamento (UE) 2024/2847 sobre ciberseguridad de productos con elementos digitales durante su ciclo de vida.
- Desde el 11 de septiembre de 2026 se aplican las obligaciones de notificación del artículo 14.
- Notifica el fabricante cuando conoce una vulnerabilidad explotada activamente contenida en su producto o un incidente grave que afecta a su seguridad.
- Hay una alerta temprana en un máximo de 24 horas y una notificación ampliada en un máximo de 72 horas, ambas desde que se tiene conocimiento y sin demora indebida. Después llega el informe final.
- La aplicación general llega el 11 de diciembre de 2027. Notificar ya es una obligación; preparar el resto requiere trabajar desde ahora.
Contenido revisado en septiembre de 2026 · .
Son las cinco de la tarde de un viernes. Un cliente envía registros que muestran cómo un atacante ha aprovechado un fallo de tu appliance (un equipo con software integrado) para ejecutar código. Producto empieza a investigar. Seguridad pide las versiones afectadas. La persona que suele hablar con dirección ya se ha marchado.
Desde el 11 de septiembre de 2026, si el producto está dentro del CRA y el fabricante tiene conocimiento de una vulnerabilidad explotada activamente, hay además una obligación de notificación con plazos concretos. El fin de semana no los convierte en días hábiles.
El CRA todavía no se aplica plenamente, pero desde septiembre de 2026 ha dejado de ser únicamente una regulación futura.
En el calendario de ciberseguridad para la recta final de 2026 situamos este hito junto a otras normas. Aquí vamos a una decisión más concreta: qué debe poder hacer hoy un fabricante cuando aparece un problema de seguridad en su producto.
¿Qué es el Cyber Resilience Act?
El Cyber Resilience Act es un reglamento europeo que establece requisitos de ciberseguridad para productos con elementos digitales comercializados en la Unión Europea. Abarca hardware y software, incluidos componentes comercializados por separado, cuando su finalidad prevista o uso razonablemente previsible implica una conexión lógica o física, directa o indirecta, a un dispositivo o una red.
Su planteamiento cubre el diseño, el desarrollo y la gestión de vulnerabilidades durante el periodo de soporte. Reparte obligaciones entre fabricantes y otros actores de la cadena. También puede incluir determinadas soluciones de tratamiento remoto de datos asociadas al producto. Hay exclusiones y reglas sectoriales: conviene revisar el producto concreto, no decidir solo por la etiqueta «empresa tecnológica».
La base para delimitarlo está en los artículos 2 y 3 del Reglamento y en la explicación de la Comisión Europea.
¿Qué cambió el 11 de septiembre de 2026?
Empezó a aplicarse el artículo 14, dedicado a las notificaciones de los fabricantes. Ese adelanto no activa en bloque todas las obligaciones de diseño, documentación, soporte y evaluación de conformidad.
Entrada en vigor
El CRA entra en el ordenamiento europeo.
Organismos de evaluación
Se aplica el capítulo IV, artículos 35 a 51.
Notificación
El artículo 14 ya es aplicable a fabricantes.
Aplicación general
Llegan las principales obligaciones de producto.
Fechas verificadas en el artículo 71 y la Comunicación C(2026) 5252 de la Comisión.
El artículo 69.3 extiende el reporting del artículo 14 a los productos dentro del alcance introducidos en el mercado antes del 11 de diciembre de 2027. Haber vendido el producto antes no lo exime de estas notificaciones.
Eso no obliga a notificar retrospectivamente una explotación activa de la que ya se tenía conocimiento antes del 11 de septiembre de 2026, según las FAQ de ENISA. Hay que separar la fecha de introducción del producto, la del evento y la del conocimiento del fabricante.
¿Qué hay que notificar?
Explotada activamente
Existe evidencia fiable de que un actor malicioso ha aprovechado una vulnerabilidad en un sistema sin permiso de su propietario. El artículo 14 se refiere a una vulnerabilidad contenida en el producto del fabricante.
Una puntuación alta de gravedad o una prueba de concepto publicada no demuestran, por sí solas, explotación activa.
Ejemplo orientativo: registros y análisis confirman que un atacante está usando un fallo de autenticación del appliance comercializado por la empresa.
Grave y con impacto en la seguridad del producto
El incidente perjudica o puede perjudicar la capacidad del producto para proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes; o ha provocado o puede provocar la introducción o ejecución de código malicioso en el producto o en los sistemas de un usuario.
Ejemplo orientativo: un compromiso del sistema de actualizaciones permite distribuir código malicioso a los usuarios del producto.
Son dos supuestos distintos, que pueden coincidir. Un problema en el correo corporativo no activa automáticamente el reporting de producto del CRA. Debe valorarse el encaje en los artículos 3.42 y 14.5. Los ejemplos ayudan a entender la decisión, pero no sustituyen el análisis del caso.
Los plazos: 24 horas, 72 horas y después
La información se completa por fases. No se espera disponer de toda la causa raíz en la alerta temprana. Tampoco se permite retrasarla hasta que termine la investigación.
Advertir del evento
Identificar la situación e indicar, cuando corresponda, los Estados miembros donde se sabe que se ha comercializado el producto. En incidentes graves, incluir si se sospecha un origen ilícito o malicioso.
Aportar lo conocido
Para vulnerabilidades: producto, naturaleza de la explotación y del fallo. Para incidentes: naturaleza y evaluación inicial. En ambos casos, medidas tomadas, medidas que pueden adoptar los usuarios y sensibilidad de la información, según proceda.
Completar el análisis
Vulnerabilidad: hasta 14 días después de disponer de una medida correctora o de mitigación.
Incidente grave: dentro del mes siguiente a presentar la notificación de 72 horas.
El informe final de vulnerabilidad recoge su descripción, gravedad e impacto, información disponible sobre el actor malicioso y detalles de las medidas. El de incidente incluye descripción, gravedad e impacto, amenaza o causa raíz probable y mitigaciones aplicadas o en curso. El CSIRT puede solicitar informes intermedios. Artículo 14.2, 14.4 y 14.6.
Las 24 y las 72 horas parten del conocimiento del evento notificable. No son 24 horas más otras 72. Son máximos y rige la obligación de actuar sin demora indebida. Registrar cuándo y con qué evidencias se alcanza ese conocimiento forma parte del trabajo.
Según las orientaciones publicadas por la Comisión, apartado 9.1, puede ser necesario un análisis inicial para determinar si el aviso encaja en un supuesto notificable. No es una autorización para prolongar el triage —la evaluación inicial— ni para esperar una aprobación interna cuando ya se conoce el evento.
¿Dónde se notifica? La Single Reporting Platform de ENISA
La Single Reporting Platform (SRP) es la plataforma única de notificación que desarrolla, opera y mantiene ENISA, la Agencia de la Unión Europea para la Ciberseguridad. Está operativa desde el 11 de septiembre de 2026. Permite presentar la notificación al equipo de respuesta a incidentes de seguridad informática (CSIRT) designado como coordinador y a ENISA mediante un único canal, con las excepciones de difusión previstas en el Reglamento. Confirmación de la Comisión.
El acceso está en el portal oficial de la SRP. ENISA documenta el uso de EU Login y el rol Assigned Representative (representante asignado). Conviene definir usuarios, suplencias y quién mantiene esos accesos, además de seleccionar el CSIRT coordinador conforme a las reglas del artículo 14.7.
Antes de necesitarlos, revisa los manuales de registro y uso. El representante asignado en la plataforma no debe confundirse automáticamente con el representante autorizado del artículo 18.
Esperar al incidente para descubrir cómo se accede a la plataforma añade una dependencia evitable a un proceso que ya tiene poco margen.
Un detalle operativo de las FAQ de ENISA, actualizadas el 12 de septiembre: el contador inicial de 72 horas de la plataforma se calcula como 48 horas desde el envío de la alerta. ENISA advierte de que puede mostrar un vencimiento anticipado. Conserva tu propio cálculo desde el conocimiento del evento; el contador no cambia el plazo legal.
El verdadero problema: poder notificar en 24 horas
¿Podrías identificar en 24 horas qué versiones están afectadas? Para responder necesitas algo más que un inventario comercial. Hace falta conectar producto, versión, componentes, responsable técnico y clientes o mercados afectados cuando corresponda.
También necesitas un proceso de vulnerability management, o gestión de vulnerabilidades, que reciba avisos de clientes, investigadores, proveedores y monitorización interna. Alguien debe evaluar la fiabilidad de la información, distinguir un fallo de una explotación activa y conservar las evidencias.
Cumplir un plazo de 24 horas no consiste en redactar más rápido. Consiste en haber decidido antes qué detectar, quién evalúa, quién escala, quién decide y quién notifica.
- DetectarRecibir el aviso y registrar su hora y origen.
- ValidarContrastar evidencias y relación con el producto.
- ClasificarValorar explotación activa o incidente grave.
- EscalarReunir a producto, seguridad, legal y dirección.
- DecidirDocumentar el criterio y activar al responsable.
- NotificarEnviar la información disponible y conservar el justificante.
- Investigar / corregirProfundizar en alcance, versiones y medidas.
- Actualizar la notificaciónCompletar información y preparar el informe final.
Trabajo en paralelo: la investigación, la contención y la mitigación empiezan desde las primeras horas. El orden representa la coordinación del reporting, no una espera para corregir.
En una pyme, una persona puede asumir varios papeles. Lo relevante es que cada decisión tenga responsable y suplente. Una cadena de aprobaciones que solo funciona de lunes a viernes debe revisarse antes del primer aviso.
La relación con los componentes de terceros también importa. La evaluación de proveedores ayuda a concretar contactos, avisos y evidencias que vas a necesitar cuando un fallo de una dependencia llegue a tu producto.
Caso práctico: un fabricante de appliances para empresas
Un fallo de autenticación en una versión distribuida
Un fabricante europeo vende un appliance de gestión de archivos a empresas de varios Estados miembros. Un viernes a las 17:00 recibe un aviso; a las 18:00 cuenta con evidencia fiable de explotación maliciosa de una vulnerabilidad contenida en su producto. En este ejemplo, esa segunda hora marca el conocimiento del evento notificable.
- Primeras horas
- El equipo realiza el triage, conserva registros y muestras, identifica al responsable del producto y contrasta versiones. Seguridad coordina la investigación y la contención. Se documenta el momento del conocimiento.
- Sin demora indebida; como máximo, sábado a las 18:00
- El fabricante presenta la alerta temprana mediante su usuario asignado. Incluye la información exigible disponible y los Estados miembros pertinentes. No espera a tener el parche ni a que vuelva el equipo el lunes.
- Sin demora indebida; como máximo, lunes a las 18:00
- Completa la notificación con el producto y versiones identificadas, la naturaleza del fallo y de la explotación, las medidas adoptadas y las que pueden aplicar los usuarios. Señala las incertidumbres que siguen abiertas.
- Después
- Continúa corrigiendo y verificando. Informa a los usuarios afectados y, cuando proceda, a todos los usuarios, sin demora indebida, con medidas que puedan adoptar, conforme al artículo 14.8. Esa comunicación puede ser necesaria mucho antes del informe final.
Si una mitigación está disponible el domingo a las 12:00, el plazo máximo del informe final de vulnerabilidad vence 14 días después de ese momento. No se reinicia al publicar posteriormente un parche. El equipo conserva justificantes y revisa qué falló en la detección, el inventario o el escalado.
¿A quién afecta el CRA?
El punto de partida es el producto, su comercialización y el papel de la empresa. Esta tabla orienta la revisión; no declara automáticamente incluido cada negocio.
| Organización | ¿Revisar el CRA? | Por qué |
|---|---|---|
| Fabricante de software B2B | Sí | El software comercializado en la UE puede ser un producto con elementos digitales. Revisar conectividad, finalidad y exclusiones. |
| Fabricante de hardware conectado | Sí | Revisar el equipo, su software y las funciones remotas asociadas. |
| Fabricante de IoT | Sí | Los dispositivos del internet de las cosas pueden entrar en el alcance, salvo exclusiones aplicables. |
| Integrador de componentes digitales | Sí | Puede ser fabricante del producto final. Importan la marca bajo la que lo comercializa y las modificaciones realizadas. |
| Empresa SaaS | Depende | El software como servicio no entra automáticamente. Hay que distinguir el servicio cloud de un producto y de su tratamiento remoto de datos. |
| Importador o distribuidor | Sí, por su rol | Tiene obligaciones propias en el calendario general. No asume automáticamente el reporting del fabricante; revisar si pasa a actuar como fabricante. |
| Empresa que solo usa software de terceros | Revisar compras y dependencias | Usarlo no la convierte en fabricante obligado por el artículo 14. Puede tener otras obligaciones y necesitar información de sus proveedores. |
SaaS y cloud: hay que mirar la arquitectura
Una solución de tratamiento remoto de datos entra en esta definición cuando el software se diseña y desarrolla por el fabricante, o por su cuenta, y su ausencia impediría al producto realizar una de sus funciones. Un servicio remoto que permite controlar un dispositivo puede encajar. No basta con que una empresa facture una suscripción o use servidores cloud.
Hay que identificar quién es responsable del software remoto, qué función del producto sostiene y dónde termina esa dependencia. Los considerandos 11 y 12 y el artículo 3.2, junto con las orientaciones de la Comisión, ayudan a analizarlo. También deben revisarse las modificaciones sustanciales y los supuestos en que otro actor pasa a ser fabricante.
¿Qué pasa si utilizo componentes open source?
Utilizar código abierto no excluye automáticamente al producto final. El CRA da un tratamiento específico al software libre y de código abierto desarrollado o suministrado fuera de una actividad comercial. Esa condición no se traslada sin más al producto comercial que lo incorpora.
Un open-source software steward, denominado «administrador de programas informáticos de código abierto» en el Reglamento, tiene un papel específico de apoyo sostenido al desarrollo y viabilidad de determinados proyectos. No equivale a cualquier colaborador ni al fabricante que integra una biblioteca.
Sus obligaciones de notificación del artículo 24.3 se aplican desde el 11 de diciembre de 2027. El fabricante no puede esperar a esa fecha para cumplir el artículo 14 por incorporar open source. Fuentes: artículos 2.3, 3.14 y 24 y Comisión Europea.
¿Y las pymes?
Ser una pequeña o mediana empresa no supone una exclusión general. El Reglamento contempla apoyo y medidas de proporcionalidad, como asistencia de los CSIRT para el reporting y documentación técnica simplificada para microempresas y pequeñas empresas en los términos previstos.
Existe además una particularidad concreta en el artículo 64.10.a: la exclusión de las multas administrativas allí reguladas para fabricantes microempresa o pequeña empresa por incumplir el plazo de alerta temprana. No elimina la obligación de notificar ni crea una exención general para todas las pymes. Artículos 17.6, 33 y 64.
El 27 de julio de 2026, la Comisión publicó orientaciones con 67 ejemplos prácticos, casos de uso, diagramas de flujo y gráficos, con atención específica a microempresas y pymes. Son útiles para revisar alcance, modificaciones y soporte. Publicación oficial.
Conviene precisar su estado: la Comunicación C(2026) 5252 aprueba el contenido del proyecto y prevé su adopción formal cuando estén disponibles todas las versiones lingüísticas. Aquí se utiliza ese material publicado como orientación no vinculante; el Reglamento es la referencia normativa.
Qué debería hacer una empresa ahora
Esta checklist propone preparación operativa. No convierte cada práctica en una obligación formal ya exigible ni requiere haber resuelto antes la vía de evaluación de conformidad. Puedes marcarla durante la lectura; las marcas no se guardan ni se envían.
Si faltan inventarios o responsables, una evaluación de madurez y brechas puede ordenar el punto de partida. El Plan Director de Ciberseguridad sirve para convertir las brechas en prioridades, recursos y seguimiento.
¿Qué cambia en diciembre de 2027?
Desde el 11 de diciembre de 2027 se aplican con carácter general los requisitos de ciberseguridad de producto y los procesos de gestión de vulnerabilidades, junto con evaluación de riesgos, documentación técnica, evaluación de conformidad, declaración UE y marcado CE según corresponda.
El fabricante deberá integrar esas exigencias en el desarrollo y en el soporte. La vía de evaluación depende del producto y su categoría; no todo exige certificación por un tercero. Para productos anteriores, la regla de transición del artículo 69.2 se vincula a modificaciones sustanciales posteriores a esa fecha, con la excepción ya explicada para el reporting.
El trabajo de ahora debe alimentar esa preparación: inventario reutilizable, decisiones documentadas y evidencias que el equipo pueda mantener. Reporting ahora; preparación integral en marcha. Artículos 13, 32, 69 y anexo I.
CRA y NIS2: ¿cómo se relacionan?
El CRA se centra en la seguridad de productos con elementos digitales. La NIS2, Directiva (UE) 2022/2555, aborda la gestión de riesgos y la resiliencia de determinadas entidades. Un fabricante puede tener que analizar ambas.
Ni una sustituye a la otra ni enviar una notificación CRA demuestra haber cumplido cualquier otro deber de comunicación. Conviene coordinar el análisis de eventos y comprobar destinatarios, criterios y plazos de cada régimen. Puedes ampliar el contexto en la guía de NIS2 de ACBSEC y en la página oficial de la Comisión sobre NIS2.
Preguntas frecuentes sobre el CRA
¿Qué es el CRA?
El Cyber Resilience Act es el Reglamento (UE) 2024/2847 sobre ciberseguridad de productos con elementos digitales comercializados en la Unión Europea.
¿Cuándo se aplica el Cyber Resilience Act?
Entró en vigor el 10 de diciembre de 2024. El capítulo IV se aplica desde el 11 de junio de 2026; el artículo 14, desde el 11 de septiembre de 2026. La aplicación general llega el 11 de diciembre de 2027.
¿Qué cambió el 11 de septiembre de 2026?
Se hicieron aplicables las obligaciones de notificación de fabricantes del artículo 14. No se adelantaron todas las obligaciones de producto previstas para 2027.
¿Qué debe notificarse en 24 horas?
La alerta temprana sobre una vulnerabilidad explotada activamente contenida en el producto o un incidente grave que afecta a su seguridad, sin demora indebida y como máximo en 24 horas desde su conocimiento.
¿Qué debe notificarse en 72 horas?
La notificación ampliada del evento con la información disponible y las medidas pertinentes, salvo que ya se haya facilitado. Las 72 horas se cuentan desde el conocimiento del evento, no desde la alerta temprana.
¿Dónde se notifican los incidentes del CRA?
Los fabricantes presentan las notificaciones obligatorias mediante la Single Reporting Platform de ENISA, operativa desde el 11 de septiembre de 2026, seleccionando el CSIRT coordinador correspondiente.
¿Afecta el CRA a las pymes?
Sí, si sus productos y su papel entran en el alcance. Hay apoyo y particularidades para empresas pequeñas, pero no una exclusión general por ser pyme.
¿Afecta el CRA al software?
Sí. Puede incluir software comercializado por separado y componentes. Deben revisarse conectividad, finalidad, actividad comercial y exclusiones aplicables.
¿Afecta al SaaS?
No automáticamente. Hay que distinguir el servicio cloud del producto con elementos digitales y comprobar si existe una solución de tratamiento remoto de datos que cumpla la definición del CRA.
¿Afecta al open source?
Depende de la actividad y el rol. Incorporar código abierto no excluye un producto comercial. Los administradores de software de código abierto tienen obligaciones específicas de reporting desde el 11 de diciembre de 2027.
¿Qué ocurre el 11 de diciembre de 2027?
Llega la aplicación general del CRA, con requisitos de producto, gestión de vulnerabilidades, documentación y evaluación de conformidad según corresponda, teniendo en cuenta las disposiciones transitorias.
¿Qué relación existe entre CRA y NIS2?
El CRA se centra en seguridad de producto; NIS2, en gestión de riesgos y resiliencia de determinadas entidades. Pueden coexistir y sus obligaciones deben analizarse por separado.
Lo que conviene comprobar hoy
El primer hito operativo del CRA ya ha llegado. Un fabricante necesita preparar diciembre de 2027 y comprobar si hoy puede reconocer un evento notificable, reunir la información disponible y hacer que llegue a quien debe actuar.
Una prueba útil para esta semana: escoger un producto, plantear una explotación activa y recorrer el proceso con las personas que tendrían que responder. Los huecos que aparezcan ya tienen una prioridad concreta.
Fuentes oficiales
Comisión Europea · Cyber Resilience Act
Comisión Europea · obligaciones de reporting
ENISA · Single Reporting Platform y manuales
ENISA · FAQ de la plataforma, 12 de septiembre de 2026
Comisión · publicación de orientaciones, 27 de julio de 2026
Comunicación C(2026) 5252 · estado del proyecto
Anexo · orientaciones publicadas, apartado 9.1 sobre reporting
Contenido revisado el 15 de septiembre de 2026. Los ejemplos y las recomendaciones operativas deben adaptarse al producto y al papel de la empresa.