El Reglamento (UE) 2024/2847, conocido como Cyber Resilience Act (CRA), entró en vigor el 10 de diciembre de 2024. No exige nada de golpe: despliega sus obligaciones en fases, y la más urgente para cualquier equipo que desarrolle o comercialice software con elementos digitales llega el 11 de septiembre de 2026, cuando empieza a exigirse la notificación de vulnerabilidades explotadas activamente. Quien fabrica, integra o distribuye software con capacidad de conexión a una red o a otro dispositivo debería tener resuelto antes de esa fecha quién es su interlocutor (CSIRT/ENISA) y cómo dispara un aviso en 24 horas.
Qué es el Cyber Resilience Act y a quién obliga
El CRA regula los requisitos de ciberseguridad de los "productos con elementos digitales": hardware y software que se conecta, directa o indirectamente, a otro dispositivo o a una red. El Reglamento define tres roles con obligaciones distintas:
- Fabricante: la persona física o jurídica que desarrolla o fabrica el producto, lo comercialice de forma pagada, monetizada o gratuita. Es el rol con más obligaciones: evaluación de conformidad, gestión de vulnerabilidades durante todo el ciclo de soporte y notificación a las autoridades.
- Importador: quien introduce en el mercado de la UE un producto de un fabricante de fuera de la Unión. Debe verificar que el fabricante ha cumplido sus obligaciones antes de comercializarlo.
- Distribuidor: quien pone el producto a disposición en el mercado sin ser fabricante ni importador. Su obligación principal es comprobar el marcado CE y la documentación antes de distribuir.
Para una empresa de software, lo habitual es actuar como fabricante: quien escribe el código y lo pone en el mercado —también como SaaS empaquetado, app móvil o componente que se integra en otro producto— asume las obligaciones más exigentes del Reglamento, con independencia de si cobra por la licencia o la distribuye gratis con un modelo de monetización indirecta.
El calendario real: cuatro fechas, no una
El error más habitual es tratar el CRA como una obligación que "empieza en 2027". En realidad despliega sus exigencias en cuatro momentos distintos, y la segunda ya está prácticamente encima:
| Fecha | Qué entra en vigor |
|---|---|
| 10 de diciembre de 2024 | Entrada en vigor del Reglamento (UE) 2024/2847 |
| 11 de junio de 2026 | Obligaciones sobre notificación de organismos de evaluación de la conformidad |
| 11 de septiembre de 2026 | Obligaciones de información de los fabricantes: notificación de vulnerabilidades explotadas activamente e incidentes graves |
| 11 de diciembre de 2027 | Aplicación plena del Reglamento: requisitos esenciales del anexo I y marcado CE |
Estas cuatro fechas están confirmadas de forma coincidente en el resumen oficial de la Comisión Europea y en la nota informativa de INCIBE sobre la versión en castellano del Reglamento. La misma cronología es la que usa la ficha de servicio de Summum Consultoría sobre el CRA, así que un equipo puede cruzar cualquiera de las dos fuentes sin encontrar discrepancias.
La fecha que debe marcar la agenda de cualquier equipo de desarrollo no es la de aplicación plena (2027), sino la del 11 de septiembre de 2026: a partir de ese día, un fabricante que detecte que una vulnerabilidad de su producto está siendo explotada activamente tiene 24 horas para un aviso temprano y 72 horas para una notificación completa al CSIRT nacional (en España, INCIBE-CERT) y a ENISA, según el artículo 14 del Reglamento.
Qué debe tener preparado un fabricante de software antes de septiembre de 2026
La obligación de notificar en 24 horas no se improvisa el día que aparece la vulnerabilidad. Exige tener resuelto de antemano:
- Canal de notificación identificado: quién es el CSIRT competente (INCIBE-CERT para España) y cómo se le contacta fuera de horario laboral.
- Proceso interno de triaje: quién decide si una vulnerabilidad reportada está siendo explotada activamente y quién autoriza la notificación.
- Inventario de componentes (SBOM): sin un listado actualizado de las dependencias de terceros que usa el producto, es difícil saber si una vulnerabilidad publicada en una librería afecta realmente al software propio.
- Política de gestión de vulnerabilidades documentada: cómo se reciben reportes externos, cómo se corrigen y en qué plazo se publican actualizaciones de seguridad.
- Trazabilidad del ciclo de soporte: el Reglamento exige mantener la gestión de vulnerabilidades durante todo el periodo de soporte declarado del producto, no solo en el momento de la venta.
Nada de esto exige el marcado CE ni la evaluación de conformidad completa —eso llega en 2027—, pero sin este proceso mínimo montado, la primera vulnerabilidad crítica que se reciba después del 11 de septiembre de 2026 se gestionará contrarreloj y sin procedimiento.
No todos los productos se tratan igual: clases de riesgo
El Reglamento no aplica el mismo rigor a todos los productos con elementos digitales. El anexo III distingue dos clases de "productos importantes" con obligaciones reforzadas frente al resto del mercado:
- Clase I (autoevaluación posible): gestores de identidad, navegadores, gestores de contraseñas, VPN, sistemas de gestión de red, SIEM, sistemas operativos, routers y switches domésticos, entre otras 19 categorías listadas en el anexo.
- Clase II (requiere intervención de un organismo externo en algunos casos): hipervisores y sistemas de contenedores, cortafuegos, sistemas de detección y prevención de intrusiones, microprocesadores y microcontroladores resistentes a manipulación.
Por encima de ambas clases, el anexo IV recoge un grupo reducido de productos considerados críticos —módulos de seguridad hardware (HSM), pasarelas de contador inteligente, tarjetas inteligentes— para los que puede exigirse un certificado europeo de ciberseguridad o la intervención de un organismo notificado, sin posibilidad de autoevaluación.
La mayoría del software de gestión empresarial, ERP, CRM o herramientas verticales no aparece en estos listados y sigue el régimen general del anexo I, con autoevaluación de conformidad. Pero si el producto incorpora funciones que se solapan con estas categorías —por ejemplo, un módulo propio de gestión de identidad o un SIEM integrado—, conviene revisar el encaje concreto antes de asumir el régimen general por defecto.
Software libre: una exención real, pero con matices
El Reglamento excluye de la consideración de "actividad comercial" el suministro de software libre y de código abierto que el fabricante no monetiza. Así lo confirma la propia Comisión Europea: la provisión de productos que cualifican como software libre y de código abierto y que no son monetizados por sus fabricantes no debe considerarse una actividad comercial a efectos del Reglamento.
Esto no significa que un proyecto de software libre quede completamente al margen. Los "stewards" de software libre —entidades que dan soporte estructural a un proyecto de código abierto— tienen obligaciones más ligeras (artículo 24): deben mantener una política de ciberseguridad, cooperar con las autoridades y notificar vulnerabilidades desde el 11 de septiembre de 2026, pero no están sujetos a las sanciones económicas del artículo 64.10. El matiz que conviene no perder de vista es el de un steward que mantiene soporte comercial sostenido a terceros: ahí el encaje deja de ser automático y requiere revisión caso por caso, algo que la propia norma no cuantifica con un umbral preciso.
Errores frecuentes al leer el CRA
- Pensar que 2027 es la única fecha relevante y descuidar la obligación de notificación de vulnerabilidades de septiembre de 2026.
- Asumir que "gratuito" equivale automáticamente a exento, sin comprobar si existe monetización indirecta (soporte de pago, publicidad, versión premium).
- No distinguir el rol de fabricante, importador o distribuidor cuando la empresa integra software de terceros en su propio producto.
- No tener identificado el CSIRT de contacto ni un proceso de triaje antes de que aparezca la primera vulnerabilidad crítica.
- Ignorar si el producto encaja en alguna categoría del anexo III o IV, que exige un tratamiento distinto al régimen general.
Hay situaciones que el Reglamento no resuelve con una regla simple: un producto a caballo entre dos categorías del anexo III, un modelo de negocio mixto entre código abierto y soporte comercial, o un componente que se integra en el producto de otro fabricante bajo marca blanca. En esos casos, la respuesta correcta no es forzar una clasificación, sino tratarlos como casos que requieren análisis individual con asesoramiento técnico y legal específico.
Cómo saber en qué situación está tu producto
Antes de encargar una auditoría completa de conformidad, tiene sentido resolver primero tres preguntas: qué rol ocupa tu empresa (fabricante, importador o distribuidor), si tu producto encaja en el régimen general o en alguna categoría reforzada del anexo III/IV, y si te beneficia la exención de software libre no comercial. El checker CRA para fabricantes de software de Summum Sistemas responde a estas tres preguntas en menos de dos minutos y devuelve las fechas y obligaciones que aplican a tu caso concreto, marcando como "requiere análisis individual" los supuestos que la norma no resuelve de forma automática.
Preguntas frecuentes
¿El Cyber Resilience Act aplica a cualquier empresa que desarrolle software?
Aplica a quien fabrica, importa o distribuye productos con elementos digitales que se comercializan en la Unión Europea, entendiendo "comercializar" en sentido amplio (pago, monetización indirecta o distribución gratuita con modelo comercial). El software libre no monetizado por su fabricante queda excluido de la consideración de actividad comercial.
¿Qué pasa si mi empresa no cumple el 11 de septiembre de 2026?
Esa fecha activa la obligación de notificar vulnerabilidades explotadas activamente en 24 horas y notificaciones completas en 72 horas. No tener el canal y el proceso interno resueltos antes de esa fecha expone a la empresa a gestionar el primer incidente sin procedimiento, con el riesgo reputacional y de cumplimiento que eso implica.
¿Es lo mismo el Cyber Resilience Act que el AI Act o el ENS?
No. El CRA regula la ciberseguridad de productos con elementos digitales que se comercializan en el mercado único; el ENS regula la seguridad de los sistemas de las administraciones públicas y de quienes prestan servicios a ellas en España. Son marcos distintos, aunque una empresa puede estar sujeta a ambos si vende software a las administraciones públicas.
¿Necesito el marcado CE ya?
No todavía. La aplicación plena del Reglamento, incluidos los requisitos esenciales del anexo I y el marcado CE, es exigible desde el 11 de diciembre de 2027. Antes de esa fecha, la obligación urgente es la notificación de vulnerabilidades desde septiembre de 2026.
Fuentes oficiales consultadas
- INCIBE: nota informativa sobre el Reglamento de Ciberresiliencia (Cyber Resilience Act), consultada el 16 de julio de 2026.
- Comisión Europea: resumen oficial del Cyber Resilience Act, consultada el 16 de julio de 2026.
- Comisión Europea: exención de software libre y de código abierto en el CRA, consultada el 16 de julio de 2026.
- Reglamento (UE) 2024/2847 (Cyber Resilience Act), Diario Oficial de la Unión Europea.
Summum Sistemas acompaña a fabricantes de software en la gestión de vulnerabilidades, el inventario de componentes y la preparación técnica frente al CRA. La calificación de tu producto y las obligaciones legales exactas deben validarse con asesoramiento competente; el checker y esta guía son un punto de partida orientativo, no constituyen asesoramiento profesional.