El Cyber Resilience Act ya está en vigor: lo que tu equipo necesita tener funcionando desde el 11 de septiembre

Hay una fecha en el calendario regulatorio europeo que convierte un problema técnico en un problema legal: el 11 de septiembre de 2026. Desde ese día, cualquier fabricante que comercialice productos con elementos digitales en la Unión Europea está obligado a notificar las vulnerabilidades explotadas activamente y los incidentes graves que afecten a la seguridad de sus productos — con una alerta temprana en las primeras 24 horas desde que tiene conocimiento.

Si tu empresa vende software en la UE — un SaaS con componente de producto, una aplicación, un dispositivo con firmware, una librería comercial — esto te afecta. Y la parte incómoda no es el formulario de notificación: es todo lo que tiene que existir en tu organización para que ese formulario se pueda rellenar en 24 horas.

Qué exige exactamente el CRA desde septiembre

El Cyber Resilience Act entró en vigor en diciembre de 2024 con un calendario escalonado. Las obligaciones principales — requisitos esenciales de ciberseguridad, marcado CE, evaluación de conformidad — aplican desde el 11 de diciembre de 2027. Pero las obligaciones de notificación se adelantaron más de un año, al 11 de septiembre de 2026, y funcionan así:

24 horas para enviar una alerta temprana desde que el fabricante tiene conocimiento de una vulnerabilidad explotada activamente o de un incidente grave.
72 horas para la notificación completa, con la evaluación del riesgo y las medidas correctivas o paliativas adoptadas o previstas.
Informe final a más tardar 14 días después de que exista una medida correctiva disponible (vulnerabilidades) o un mes después de la notificación (incidentes graves).

La notificación se presenta una sola vez a través de la Single Reporting Platform (SRP) que opera ENISA, y llega simultáneamente al CSIRT del Estado miembro donde el fabricante tiene su establecimiento principal y a la propia ENISA. La plataforma está operativa desde el 11 de septiembre; ENISA publicó durante junio de 2026 instrucciones de registro, materiales de formación y soporte para ensayos, y el 3 de marzo de 2026 la Comisión publicó su primera guía interpretativa sustantiva del reglamento.

Dos matices que sorprenden a muchos equipos. Primero: las obligaciones no se limitan a productos nuevos — cubren también los productos ya comercializados en la UE antes de la aplicación plena del reglamento. Segundo: el incumplimiento de los requisitos esenciales y de las obligaciones de los artículos 13 y 14 puede sancionarse con multas de hasta 15 millones de euros o el 2,5% de la facturación anual mundial, la cifra que sea mayor (artículo 64).

Para el ecosistema open source hay una exención relevante: los open-source software stewards — fundaciones y entidades que dan soporte al desarrollo de software libre sin comercializarlo — quedan fuera del régimen sancionador. Si monetizas el software, en cambio, eres fabricante a todos los efectos. Un modelo Open Core como el nuestro cae del lado comercial de esa línea, y lo asumimos con naturalidad: las obligaciones se aplican también a nosotros.

El problema real no es el formulario — es el reloj

Léelo otra vez: 24 horas desde que tienes conocimiento. Así se ve el calendario de un caso real:

# Cronología de una notificación CRA — vulnerabilidad explotada activamente

T+0h    Se publica que un CVE de tu dependencia de autenticación
        se está explotando in the wild
T+2h    Tu escaneo continuo marca el hallazgo en `main`
        → a partir de aquí "tienes conocimiento"
T+24h   ━━ Límite: alerta temprana a la SRP ━━
T+72h   ━━ Límite: notificación completa (evaluación + medidas) ━━
T+14d   ━━ Límite: informe final tras la medida correctiva ━━

El reglamento no te obliga a saberlo todo al instante — el reloj arranca cuando tienes conocimiento del problema. Pero esa formulación tiene doble filo: tu tooling de detección determina cuándo “sabes”, y una organización que escanea una vez al trimestre no queda protegida por su propia ceguera — la diligencia exigible incluye tener capacidad razonable de enterarte. En la práctica, el plazo desplaza la presión hacia atrás, a la pregunta previa: ¿cuánto tardas en enterarte de que una vulnerabilidad de tu producto está siendo explotada?

Responder a eso en un plazo útil exige tener resueltas, de antemano, al menos cuatro capacidades:

Inventario continuo de vulnerabilidades. Cuando se publica que un CVE está siendo explotado activamente, la primera pregunta es “¿nos afecta?” — y la respuesta requiere saber qué dependencias, en qué versiones, viven en qué productos y en qué ramas. Si esa respuesta implica clonar repositorios y lanzar escaneos ad hoc, las 24 horas se van en la fase de averiguación. Un escaneo SCA continuo (OSV-Scanner, en el pipeline de Gerion) convierte esa pregunta en una consulta a datos que ya existen.

Distinguir producción de desarrollo. La notificación se refiere al producto comercializado — el código que tus clientes ejecutan. Necesitas poder filtrar hallazgos por rama y separar lo que está en main o en ramas de release de lo que vive en una feature branch a medio hacer. Esa distinción, que en Gerion además determina el multiplicador financiero 10×, es exactamente la que delimita el alcance de una notificación CRA.

Histórico auditable. El informe final pide cronología: cuándo se detectó, qué se evaluó, qué medida correctiva se aplicó y cuándo. Un registro de hallazgos con estados y fechas — detectado, en remediación, mitigado, cerrado — es la diferencia entre redactar el informe consultando datos y reconstruirlo entrevistando a gente. La documentación de diligencia también es tu mejor defensa si la autoridad de vigilancia de mercado pregunta.

Control sobre datos sensibles. Hay pocas cosas más delicadas que la lista de vulnerabilidades sin parchear de tu producto: es, literalmente, un mapa de ataque. Con el CRA esa información adquiere además relevancia legal. Es un argumento de peso para reducir lo que viaja: con Gerion, tu código no sale de tu CI, y a la plataforma — un SaaS en infraestructura europea — solo llegan metadatos de hallazgos (severidad, tipo, ruta, línea, mensaje de la regla y contexto de git), nunca código. Aun así, esa lista es información sensible: decide con quién la compartes y en qué condiciones.

Si todavía no lo tienes montado

El reloj de 24 horas ya está corriendo — pero no es tarde para ponerte al día. Un plan realista:

Determina si eres fabricante bajo el CRA. Si pones productos con elementos digitales en el mercado de la UE a cambio de contraprestación comercial, casi con seguridad sí. La guía de la Comisión de marzo es la referencia más autorizada para los casos dudosos.
Monta el escaneo continuo ya, no cuando llegue el primer incidente. El valor para el CRA no es el escaneo puntual — es el histórico acumulado que te permite responder “¿desde cuándo nos afecta esto?” con datos.
Define el runbook de notificación. Quién decide que un hallazgo es notificable, quién redacta, quién envía a la SRP. Con un plazo de 24 horas, el proceso no se puede improvisar durante el incidente.
Regístrate en la SRP y participa en los ensayos. ENISA ha publicado instrucciones y materiales. Un dry-run interno cuanto antes vale más que cualquier documento de proceso.

Septiembre es el ensayo general de diciembre de 2027

Las obligaciones de notificación son solo la primera fase. El 11 de diciembre de 2027 entra en aplicación el resto del reglamento: requisitos esenciales de ciberseguridad verificables, gestión de vulnerabilidades durante todo el ciclo de vida del producto, documentación técnica que incluye el inventario de componentes, y el marcado CE como condición de acceso al mercado.

La relación entre las dos fechas no es casual. Todo lo que montes para cumplir con la notificación — escaneo continuo, inventario de dependencias, registro de hallazgos con histórico — es infraestructura que la fase de 2027 da por sentada. Los equipos que traten septiembre como un trámite aislado tendrán que reconstruir el mismo músculo en quince meses, esta vez con la evaluación de conformidad de por medio. Los que lo traten como la primera pieza del programa completo llegan a 2027 con la mitad del trabajo hecho.

La lectura menos cínica

Es fácil leer el CRA como burocracia con multas. La lectura más útil es otra: todo lo que exige — inventario continuo de vulnerabilidades, priorización con contexto de producción, histórico de remediación, capacidad de respuesta rápida — es lo que un programa de seguridad de producto maduro hace de todos modos. El reglamento no pide nada que no quisieras tener; pide que lo tengas demostrablemente y con fecha límite.

Los equipos que llegaron al 11 de septiembre con esa infraestructura funcionando no están notando el CRA como una carga. Si tu equipo todavía no la tiene, este es el momento de montarla, y la vivirás como la primera vez que tu trabajo de seguridad tiene una traducción directa a una obligación que el negocio entiende sin explicaciones.