Ir al contenido principal
Volver al resumen

El reporte CRA empieza el 11 de septiembre de 2026: qué deben hacer ya las organizaciones NIS2

Por NIS2Certify
cyber-resilience-actreporte-cranotificacion-incidentescumplimiento-nis2msp
El reporte CRA empieza el 11 de septiembre de 2026: qué deben hacer ya las organizaciones NIS2

Su cliente suministra controladores HVAC inteligentes a edificios de oficinas de toda Europa. El 12 de septiembre de 2026, un investigador le avisa de que hay atacantes explotando activamente un fallo en el firmware. Desde ese momento, su cliente tiene 24 horas para presentar una alerta temprana ante su CSIRT nacional y ENISA.

Esa obligación es nueva. El reporte CRA del Article 14 del Cyber Resilience Act se aplica desde el 11 de septiembre de 2026 — 15 meses completos antes que el resto del reglamento. Si usted asesora a organizaciones reguladas por NIS2 que además fabrican o venden productos con elementos digitales, este plazo también es suyo.

La mayoría de los consultores archivaron el CRA como un asunto de 2027. La parte de reporte es un asunto de 2026, y llega en dos semanas.

Las obligaciones de reporte del CRA empiezan el 11 de septiembre de 2026

Desde el 11 de septiembre de 2026, los fabricantes de productos con elementos digitales deben reportar dos cosas: vulnerabilidades activamente explotadas en sus productos e incidentes graves que afecten a la seguridad de esos productos.

El alcance es amplio. Routers, cerraduras inteligentes, controladores industriales, cámaras IP, firmware y software independiente cuentan como productos con elementos digitales. La obligación cubre los productos que ya están hoy en el mercado — no solo los que se entreguen después de la fecha límite.

Los reportes pasan por el CRA Single Reporting Platform operado por ENISA. El fabricante presenta una sola vez; la notificación llega al CSIRT del Estado miembro donde tiene su establecimiento principal, y ENISA la ve simultáneamente. La Comisión Europea ha confirmado que la plataforma está en fase final de pruebas y estará operativa el 11 de septiembre de 2026.

Fíjese en qué activa el deber: activamente explotada significa que alguien está usando el fallo en el mundo real. Una vulnerabilidad hallada en una revisión interna de código sigue siendo interna — por ahora, gestionada mediante la divulgación coordinada de vulnerabilidades habitual.

El CRA no es NIS2 — y muchos de sus clientes están bajo ambos

NIS2 regula entidades: cómo una organización opera sus redes, su gestión de riesgos, su respuesta a incidentes. El CRA regula productos: qué entrega un fabricante, cómo gestiona las vulnerabilidades de ese producto y durante cuánto tiempo ofrece actualizaciones de seguridad.

Tome un fabricante mediano de dispositivos médicos. Bajo NIS2 es una entidad importante del sector salud — sus fábricas, su TI y su gestión de incidentes caen bajo las diez medidas del Article 21. Cada dispositivo que envía está cubierto por separado por el CRA. Dos regímenes, una empresa, obligaciones distintas, reguladores distintos.

Las rutas de reporte también están separadas. Las notificaciones de incidentes NIS2 van a la autoridad competente o al CSIRT del servicio afectado. Los reportes CRA pasan por el Single Reporting Platform para el producto afectado. Presentar uno no exime del otro.

NIS2 vs ISO 27001 — Comparación de requisitos

Solo NIS2
Notificación obligatoria de incidentes a las autoridades (24h / 72h)
Responsabilidad personal a nivel directivo en materia de ciberseguridad
Obligaciones de seguridad en la cadena de suministro para entidades esenciales
Obligaciones regulatorias específicas del sector
Requisitos compartidos
Gestión de riesgos de seguridad de la información
Control de acceso y gestión de identidades
Continuidad del negocio y recuperación ante desastres
Concienciación y formación en seguridad
Solo ISO 27001
Ciclos de auditoría interna y revisión por la dirección
Documentación de la Declaración de Aplicabilidad (DdA)
Certificación formal y auditoría por terceros

La columna central muestra los requisitos que comparten tanto la NIS2 como la ISO 27001

Un solo evento puede arrancar dos relojes de reporte

Aquí es donde se vuelve operativo. Suponga que ese fabricante de HVAC es además entidad importante bajo NIS2, y que el fallo de firmware explotado permite a los atacantes pivotar hacia su propia red de producción. Ese único evento activa ambos regímenes a la vez.

Bajo el CRA, el reloj corre: alerta temprana en 24 horas, notificación completa en 72 horas y un informe final a más tardar 14 días después de que haya una medida correctiva disponible para una vulnerabilidad explotada. Para incidentes graves de producto, el informe final vence en un mes.

Bajo NIS2, corre un reloj paralelo para el incidente significativo en el lado de la entidad: alerta temprana en 24 horas, notificación del incidente en 72 horas, informe final en un mes. Los plazos NIS2 se aplican desde 2024–2025 según el Estado miembro; las plantillas oficiales de notificación ya están estandarizadas.

Mismo evento, dos presentaciones, dos destinatarios, dos expedientes de evidencia. Un runbook de respuesta a incidentes que solo conoce NIS2 es ahora medio runbook.

Cronología de Notificación de Incidentes NIS2

24h

Alerta Temprana

Notifique a la autoridad competente (CSIRT/ANC) en las 24 horas siguientes a tener conocimiento de un incidente significativo.

72h

Notificación de Incidente

Presente una notificación detallada en 72 horas con una evaluación inicial de la gravedad, el impacto y los indicadores de compromiso.

1mo

Informe Final

Entregue un informe final completo en el plazo de un mes que cubra la causa raíz, las medidas adoptadas y el impacto transfronterizo.

Las sanciones se acumulan

El CRA contempla multas de hasta 15 millones de euros o el 2,5 % de la facturación anual global — y ese tramo superior incluye explícitamente las infracciones de los deberes de reporte del Article 14. NIS2 añade hasta 10 millones de euros o el 2 % para entidades esenciales y 7 millones de euros o el 1,4 % para entidades importantes.

Son bases jurídicas separadas. Un fabricante que falle en ambas presentaciones sobre el mismo evento se expone bajo ambos reglamentos, más el RGPD si hay datos personales implicados. Los reguladores no compensan una multa con la otra.

Las consecuencias no financieras siguen el mismo patrón que NIS2: las autoridades de vigilancia del mercado pueden imponer medidas correctivas, restringir la comercialización de un producto o retirarlo por completo del mercado de la UE. Para una empresa de producto, eso duele más que la multa.

Escalada de sanciones NIS2 — Más allá de la multa

!

Desencadenante

Incumplimiento detectado o incidente ocurrido

Una autoridad supervisora identifica una brecha de cumplimiento o una organización no cumple los requisitos NIS2

Las autoridades pueden imponer
Sanciones no financieras
1

Órdenes de cumplimiento con plazos vinculantes

2

Auditorías de seguridad obligatorias a tu cargo

3

Divulgación pública de infracciones

4

Instrucciones vinculantes sobre medidas de seguridad específicas

Escala hacia
Consecuencias operativas y personales
1

Suspensión de certificaciones o licencias de operación

2

Prohibición temporal de funciones directivas para individuos

3

Identificación pública de personas físicas responsables

Desencadenante
No financiero
Operativo / personal

Qué deben hacer los MSP y consultores antes del 11 de septiembre

Empiece con una pregunta de inventario que puede responder esta semana: ¿cuáles de sus clientes ponen productos con elementos digitales en el mercado de la UE? Fabricante, importador e incluso revendedor de marca blanca cargan con deberes CRA. Si un cliente rebrandea hardware de terceros y lo vende con su propio nombre, cuenta como fabricante.

Para cada cliente que califique, ahora importan cinco acciones.

Uno: determinar el establecimiento principal. Decide qué CSIRT nacional recibe sus reportes a través de la plataforma.

Dos: conectar la detección con el reporte. Un plazo de 24 horas fracasa un sábado a las 3 de la madrugada si los avisos de investigadores, clientes y monitorización no desembocan en una guardia definida. Es la misma disciplina que NIS2 ya exige en la gestión de vulnerabilidades del Article 21(2)(e) — extiéndala al lado del producto.

Tres: actualizar el runbook de respuesta a incidentes para que un solo triaje resuelva las dos preguntas: ¿es esto un incidente significativo bajo NIS2 y es esto un evento reportable bajo el CRA? Una matriz de severidad, dos rutas de salida.

Cuatro: revisar la cadena de proveedores. Si su cliente integra componentes de terceros, sus contratos con proveedores deben obligar a los proveedores aguas arriba a transmitir la información de explotación con la rapidez suficiente para cumplir el reloj de 24 horas.

Cinco: registrarse en el Single Reporting Platform en cuanto abra el onboarding, no el día del primer incidente.

Para los MSP, esto también es una oportunidad de servicio. Los clientes que sufrieron con el registro NIS2 afrontan ahora un segundo régimen con relojes más exigentes. El asesor que mapea ambos en una sola evaluación gana el contrato recurrente.

Dos semanas bastan — si empieza por la brecha

No necesita un programa CRA terminado para el 11 de septiembre. Necesita saber qué clientes están en alcance, adónde van sus reportes y si su proceso de incidentes cumple un plazo de 24 horas. Eso es un análisis de brechas, no un proyecto de transformación.

Ejecute un quick scan NIS2 gratuito para cada cliente que entregue productos y establezca su postura de cumplimiento en el lado de la entidad — y extienda los hallazgos al lado del producto. Las organizaciones que superen bien septiembre serán las que conocían sus brechas en agosto.

¿Tienes otra pregunta?

Las respuestas se generan a partir de nuestros artículos y no constituyen asesoramiento jurídico. No introduzcas datos personales o confidenciales.