Cyber Resilience Act para software: obligaciones desde septiembre de 2026

1. ¿El Cyber Resilience Act se aplica a tu software?

El Reglamento de Ciberresiliencia, conocido como CRA por sus siglas en inglés, se aplica de forma horizontal a productos con elementos digitales que se ponen a disposición en el mercado de la Unión. El concepto incluye productos de software o hardware y sus soluciones de tratamiento remoto de datos, así como componentes que se comercializan por separado. La Comisión cita como ejemplos tanto aplicaciones y programas como sistemas operativos, chips o dispositivos conectados.

Para entrar en el ámbito general debe existir una conexión física o lógica, directa o indirecta, con un dispositivo o una red y una puesta a disposición dentro de una actividad comercial. Cobrar una licencia no es el único indicador: el Reglamento contempla suministros gratuitos cuando forman parte de una actividad comercial. En cambio, un desarrollo puramente interno o un proyecto de código abierto ajeno a una actividad comercial puede exigir un análisis distinto.

2. Identifica tu rol antes de repartir obligaciones

El fabricante es quien desarrolla o fabrica un producto con elementos digitales, o encarga su desarrollo o fabricación, y lo comercializa bajo su nombre o marca. Una empresa puede ser fabricante aunque un proveedor externo escriba todo el código. El contrato de desarrollo no traslada automáticamente la responsabilidad regulatoria frente al mercado.

Importadores, distribuidores y determinados administradores de software de código abierto tienen posiciones diferentes. Dibuja la cadena y asigna acceso a logs, comunicación de vulnerabilidades, soporte, actualizaciones y evidencias. Una cláusula que permita avisar en cinco días puede impedir al fabricante cumplir un plazo legal mucho más corto.

3. Dos fechas distintas: septiembre de 2026 y diciembre de 2027

El artículo 71 fija un calendario escalonado. El capítulo sobre notificación de organismos de evaluación de la conformidad se aplica desde el 11 de junio de 2026. El artículo 14, relativo al reporting de fabricantes, se aplica desde el 11 de septiembre de 2026. El conjunto principal del CRA se aplicará desde el 11 de diciembre de 2027.

La diferencia es decisiva. Desde septiembre de 2026 no tienes que haber completado por ese solo motivo todo el expediente de conformidad de 2027, pero sí debes poder reconocer y notificar los eventos cubiertos por el artículo 14. La Comisión aclara además que estas obligaciones de reporte alcanzan a productos con elementos digitales que ya se hayan puesto a disposición en el mercado de la Unión, incluidos los anteriores al 11 de diciembre de 2027.

• 11 de junio de 2026: aplicación del capítulo sobre organismos de evaluación de la conformidad
• 11 de septiembre de 2026: aplicación del artículo 14 sobre reporting de fabricantes
• 11 de diciembre de 2027: aplicación general del Reglamento
• Productos antiguos: el reporting puede afectarles aunque se comercializaran antes de diciembre de 2027

4. Qué se notifica y en qué plazo

El fabricante debe notificar una vulnerabilidad explotada activamente de la que tenga conocimiento. El Reglamento la define, en esencia, por la existencia de evidencia fiable de que un actor malicioso la ha explotado sin permiso del propietario del sistema. No toda vulnerabilidad conocida entra automáticamente en ese supuesto. También debe notificarse un incidente grave que afecte a la seguridad del producto y cumpla los criterios del artículo 14.

El proceso es escalonado. Para ambos tipos de evento existe una alerta temprana sin demora indebida y, en todo caso, dentro de las 24 horas desde que el fabricante tenga conocimiento. La notificación principal debe presentarse sin demora indebida y dentro de las 72 horas. Para una vulnerabilidad explotada activamente, el informe final vence como máximo 14 días después de que esté disponible una medida correctora o de mitigación; para un incidente grave, dentro de un mes desde la notificación de 72 horas.

La comunicación se realiza una vez mediante la Single Reporting Platform gestionada por ENISA, dirigida al CSIRT coordinador y a ENISA según el sistema previsto. ENISA indica que la plataforma estará operativa el 11 de septiembre de 2026 y mantiene instrucciones actualizadas sobre registro y uso.

• Clasificar: vulnerabilidad explotada activamente, incidente grave u otro evento
• Alerta temprana: máximo 24 horas desde que se conoce el evento
• Notificación principal: máximo 72 horas
• Informe final de vulnerabilidad: hasta 14 días desde que exista una medida correctora o de mitigación
• Informe final de incidente grave: dentro del mes posterior a la notificación principal
• Conservar evidencia de conocimiento, decisión, contenido, envío, parche y comunicación al usuario

5. Cómo preparar un circuito de reporting que funcione de verdad

Un procedimiento que solo conoce el equipo jurídico no será suficiente. La señal suele aparecer en soporte, ingeniería, un proveedor, un investigador o un cliente. Crea un canal único y una guardia con sustitutos; registra la hora exacta de recepción, producto, versiones, explotación observada, alcance territorial y medidas disponibles. Separa hechos confirmados de hipótesis.

Define una matriz de decisión con seguridad, producto, legal, comunicación y dirección. El responsable jurídico no debe decidir solo si una vulnerabilidad está siendo explotada; necesita evidencia técnica. El equipo técnico tampoco debería enviar una descripción sensible sin revisar destinatarios, confidencialidad, países afectados y mensajes al usuario.

6. No pierdas de vista el expediente completo de 2027

El reporting es solo la primera pieza. Para la aplicación general, el fabricante deberá realizar una evaluación de riesgos de ciberseguridad, aplicar los requisitos esenciales del anexo I durante diseño, desarrollo, producción, entrega y mantenimiento, preparar documentación técnica y realizar el procedimiento de evaluación de la conformidad que corresponda. Si demuestra la conformidad, elaborará la declaración UE y colocará el marcado CE.

El producto deberá ir acompañado de identificación, datos de contacto e instrucciones claras para su instalación y uso seguro. También deberá indicarse la fecha final del período de soporte. Durante ese período deben gestionarse eficazmente las vulnerabilidades. La Comisión resume medidas como configuración segura por defecto, control de acceso, criptografía y actualizaciones, siempre aplicadas según el riesgo y el texto legal.

7. Ajusta contratos, compras y documentación de producto

El CRA convierte varias dependencias técnicas en asuntos contractuales. El fabricante necesita información y cooperación de desarrolladores, proveedores de componentes y operadores cloud para evaluar riesgos, investigar eventos y corregir vulnerabilidades. Los contratos deben reconocer ese flujo sin atribuir a un proveedor una responsabilidad regulatoria que legalmente corresponda al fabricante.

Revisa obligaciones de seguridad por diseño, inventario de componentes, notificación inmediata, niveles de soporte, correcciones, acceso a evidencias, auditoría proporcionada, subcontratación, continuidad, fin de soporte y asistencia regulatoria. Coordina esas cláusulas con el contrato SaaS, el acuerdo de tratamiento de datos y el plan de incidentes. Un documento no debe contradecir al otro.

8. Plan de 90 días para una empresa de software

Empieza por un inventario de productos y versiones disponibles en la Unión. Para cada uno, registra titular, marca, rol, países, componentes, tratamiento remoto, soporte, responsables, clientes y estado del ciclo de vida. Documenta la conclusión provisional de alcance y escala los casos dudosos.

• Días 1–30: inventario, alcance, roles, responsables y proveedores críticos
• Días 31–60: procedimiento de reporte, contratos prioritarios y evidencias disponibles
• Días 61–90: simulacro, correcciones y hoja de ruta de conformidad para 2027

Preguntas frecuentes

Fuentes y referencias

• EUR-Lex · Reglamento (UE) 2024/2847 de Ciberresiliencia
• Comisión Europea · Resumen del Cyber Resilience Act
• Comisión Europea · Obligaciones de reporting del CRA
• Comisión Europea · Guía de implementación del CRA
• ENISA · Preguntas frecuentes de la Single Reporting Platform
• ATLAN LEGAL · Cláusulas clave de un contrato SaaS
• ATLAN LEGAL · Analizar un documento tecnológico

Evaluar el impacto del CRA en mi producto

Cuéntanos qué software o producto digital comercializas. ATLAN ordenará alcance, roles, reporting, contratos y hoja de ruta para que un profesional valide el plan.