A partir del 11 de septiembre de 2026, los fabricantes deben notificar en toda la UE las vulnerabilidades explotadas activamente y los incidentes graves: alerta temprana en 24 horas, a través de la nueva Single Reporting Platform (SRP) de ENISA. Le preparamos para notificar antes de que el reloj corra por primera vez.
El Cyber Resilience Act no se aplica plenamente hasta diciembre de 2027, pero las obligaciones de notificación del artículo 14 empiezan 15 meses antes. Desde el 11 de septiembre de 2026, los fabricantes de productos con elementos digitales deben notificar dos tipos de eventos: vulnerabilidades explotadas activamente en sus productos e incidentes graves con impacto en la seguridad del producto. La obligación es por producto, e incluye los productos que llevan años en el mercado. En la notificación no existe cláusula de derechos adquiridos.
La notificación se realiza a través de la Single Reporting Platform (SRP): una plataforma central operada por ENISA que reenvía automáticamente cada notificación al CSIRT nacional coordinador, a los CSIRT de todos los Estados miembros donde el producto se comercializa y a la propia ENISA — notificar una vez en lugar de hasta 27. La plataforma entra en servicio el 11 de septiembre de 2026; ENISA publicó la documentación de acompañamiento (factsheet, FAQ y guías de usuario) el 31 de julio de 2026.
Todos los plazos corren desde el conocimiento («becoming aware»), no desde la corrección. Los fines de semana cuentan.
Dentro de las 24 horas tras tener conocimiento: notificación breve al CSIRT coordinador y a ENISA, para que las alertas lleguen a los demás antes de que ruede la ola de explotación.
Dentro de las 72 horas: información general y una primera evaluación — gravedad, impacto y, si ya están disponibles, medidas correctivas o de mitigación adoptadas.
En vulnerabilidades, a más tardar 14 días después de disponer de una medida correctiva; en incidentes, un mes después de la notificación de las 72 horas: causas, cronología y contramedidas.
Dos supuestos de notificación, un único canal: la Single Reporting Platform de ENISA.
Existen pruebas fiables de que un atacante ha explotado una vulnerabilidad de su producto, con independencia de que el intento tuviera éxito. Las pruebas pueden proceder de su telemetría, de avisos de CSIRT, clientes o investigadores, o de catálogos de exploits.
Un incidente es grave si afecta —o puede afectar— a la capacidad del producto para proteger datos y funciones sensibles, o si ha provocado o puede provocar la introducción o ejecución de código malicioso. Basta el potencial: servidores de build y canales de actualización comprometidos son el caso de manual.
La SRP dirige su notificación al CSIRT designado coordinador, la pone simultáneamente a disposición de ENISA y la difunde sin demora a los CSIRT de todos los Estados miembros donde el producto está disponible. Las autoridades de vigilancia del mercado reciben información seleccionada para su labor.
La plataforma está diseñada para la confidencialidad. La difusión solo puede aplazarse en casos excepcionales justificados —por ejemplo, cuando un parche es inminente— y a criterio del CSIRT (art. 16, apdo. 2 CRA; Reglamento Delegado (UE) 2026/881). No hay opt-out para fabricantes.
La plataforma es deliberadamente sobria: la verdadera preparación ocurre en su organización.
El acceso a la SRP requiere una cuenta EU Login. Cree cuentas para al menos dos personas y regule las suplencias: el caso real no respeta los calendarios de vacaciones.
Tras el primer acceso, su CSIRT valida a los representantes designados; según la FAQ de ENISA, en paralelo al proceso de notificación. La presentación de la notificación no se ve retenida.
Según la FAQ de ENISA, la SRP no ofrecerá API en esta fase: cada notificación se introduce manualmente en el formulario web, en tres etapas con campos comunes y campos específicos de vulnerabilidad o incidente. Bloques de texto preparados y un mapeo de campos son su palanca de velocidad.
Tras un incidente o una vulnerabilidad explotada, también debe informar sin demora a los usuarios afectados, incluidas la información de riesgos y las medidas correctivas. Si no lo hace, el CSIRT puede informar a sus usuarios por usted.
ENISA prevé una fase de pruebas antes de la puesta en marcha y un webinario de onboarding unas dos semanas antes del lanzamiento. Aproveche ambos: con paquetes de notificación preparados, el 11 de septiembre será un día laborable normal.
CRA y NIS2 notifican cosas distintas a organismos distintos. Un mismo evento puede activar varias obligaciones a la vez.
El fabricante notifica vulnerabilidades explotadas activamente e incidentes graves que afectan al producto — vía SRP al CSIRT y a ENISA, con cadencia 24 h / 72 h / 14 días o 1 mes.
Las entidades esenciales e importantes notifican los incidentes significativos de su organización por los canales nacionales (en Alemania: BSI), con cadencia 24 h / 72 h / 1 mes.
Un ransomware en un fabricante de software con el servidor de actualizaciones afectado puede activar a la vez notificaciones CRA, NIS2 y RGPD — y DORA en el sector financiero. La SRP solo le quita la notificación CRA: construya un mapa de obligaciones con un proceso común.
Seis pasos para cumplir el plazo de 24 horas de forma fiable.
Elaborar el inventario de productos y evaluar la aplicabilidad del CRA producto a producto — incluyendo los productos existentes, porque la notificación no tiene cláusula de derechos adquiridos.
Determinar el CSIRT competente a partir del establecimiento principal (art. 14, apdo. 7), crear cuentas EU Login para al menos dos personas y fijar reglas de suplencia.
Definir internamente cuándo existe «conocimiento», quién lo determina y cómo se documenta el momento: es el ancla de todos los plazos. Organizar la disponibilidad en fin de semana.
Mapear los campos del formulario SRP con sus fuentes internas, preparar bloques de texto para las notificaciones de 24 y 72 horas y obtener las aprobaciones por adelantado: sin bucles de comités en la emergencia.
Ejercicio de mesa contrarreloj con un escenario realista, incluida la comunicación a usuarios del art. 14, apdo. 8 y el incómodo caso del viernes por la noche.
Establecer la vigilancia de componentes (base de datos de vulnerabilidades EUVD, CISA KEV), mantener la SBOM actualizada y asegurar contractualmente el deber de información de sus proveedores.
Respuestas concisas — sus productos concretos los vemos en una primera consulta.
Sí. Desde el 11 de septiembre de 2026, la obligación del artículo 14 se aplica por producto, incluidos los que ya están en el mercado. Las demás obligaciones del CRA, como el marcado CE, se aplican desde el 11 de diciembre de 2027.
Con el conocimiento («becoming aware»): en cuanto su empresa sabe de la explotación activa o del incidente grave. No con la corrección ni tras una aprobación interna; por eso los disparadores de conocimiento y el proceso de notificación deben definirse y documentarse de antemano.
Existen pruebas fiables de que un atacante explotó la vulnerabilidad sin el consentimiento del propietario del sistema, o lo intentó; el éxito del ataque es irrelevante (art. 3, pto. 42 CRA). Un aviso externo sólido, por ejemplo de un CSIRT o de un cliente, puede iniciar el reloj.
En los incidentes graves basta el potencial: aunque el incidente solo pueda afectar a la capacidad del producto para proteger datos y funciones, o sea posible la ejecución de código malicioso, es notificable (art. 14, apdo. 5). En caso de duda: notifique — una notificación no es una admisión de culpa.
En el lanzamiento, no. Según la FAQ de ENISA, la SRP funcionará inicialmente sin API: las notificaciones se introducen manualmente en el formulario web. Más razón para preparar bloques de texto, un mapeo de campos y procedimientos ensayados.
En principio, el CSIRT del Estado miembro de su establecimiento principal, donde se toman las decisiones esenciales de ciberseguridad de sus productos (art. 14, apdo. 7). Sin establecimiento en la UE, la cascada pasa por el representante autorizado, el importador y el distribuidor. En Alemania, el BSI es el punto de contacto central; ENISA publica la lista oficial de CSIRT.
Multas de hasta 15 millones de euros o el 2,5 % de la facturación anual mundial —la cantidad mayor— además de medidas de vigilancia del mercado que pueden llegar a la retirada del producto. Y si no informa usted mismo a los usuarios afectados, el CSIRT puede hacerlo — sin su tono.
Del readiness check a la notificación de 24 horas ensayada — pragmático, cercano al producto, defendible en auditoría.
Cartera de productos, aplicabilidad y brechas evaluadas de forma compacta: alcance, capacidad de notificación y gestión de vulnerabilidades — con un plan de acción priorizado hasta el 11 de septiembre.
Definir disparadores, roles y vías de escalado, preparar los accesos EU Login y la asignación de CSIRT, crear mapeos de campos y bloques de texto para las notificaciones de 24 y 72 horas.
Crear o reforzar su equipo de respuesta de seguridad de producto: política CVD, punto de contacto para vulnerabilidades, mantenimiento de la SBOM y vigilancia de exploits como fuente fiable de conocimiento.
Ensayamos el caso real contrarreloj — incluida la evaluación de 72 horas, el informe final y la comunicación a usuarios del art. 14, apdo. 8. Después, cada rol conoce su papel.
Cuando ocurre: apoyo en la evaluación, la contención y la notificación en plazo — técnico y regulatorio de una sola mano.
Notificación hoy, requisitos del anexo I y evaluación de conformidad mañana: le acompañamos de forma continua hasta el marcado CE — como proyecto o como GRC as a Service.
En una primera consulta sin compromiso aclaramos dónde está su cartera, qué brechas ponen en riesgo el plazo de 24 horas y cómo es su hoja de ruta hasta el 11 de septiembre.
