En este artículo
Notificación del Cyber Resilience Act: guía operativa de 24 y 72 horas
A 5 de octubre de 2026, las obligaciones de notificación del CRA para fabricantes ya se aplican. Las vulnerabilidades explotadas activamente y los incidentes graves exigen una alerta en 24 horas y una notificación en 72 horas desde que se tiene conocimiento. El informe final vence 14 días después de estar disponible una medida correctora para vulnerabilidades, pero un mes después de la notificación de 72 horas para incidentes graves.
Las obligaciones de los fabricantes se aplican desde el 11 de septiembre de 2026. Esta guía técnica las convierte en un proceso operativo, no en un proyecto para un plazo futuro. No es asesoramiento jurídico: verifica el ámbito del producto, el papel del operador económico y el supuesto notificable con profesionales cualificados. Las recomendaciones de implementación no son obligaciones legales adicionales.
¿Qué plazo corresponde a cada notificación?
| Etapa | Inicio y plazo | Evidencia operativa |
|---|---|---|
| Alerta temprana: ambas categorías | Dentro de las 24 horas desde que se tiene conocimiento | Conservar el momento de conocimiento, categoría, hechos iniciales y justificante. |
| Notificación: ambas categorías | Dentro de las 72 horas desde el conocimiento, no desde la alerta temprana | Añadir productos afectados, evaluación y medidas disponibles. |
| Final: vulnerabilidad explotada activamente | Como máximo 14 días después de estar disponible una medida correctora | Registrar la disponibilidad de la medida, la corrección y el envío final. |
| Final: incidente grave | Dentro de un mes desde la notificación de 72 horas | Conservar ese envío, el vencimiento por mes natural y la evaluación final. |
¿Quién controla el conocimiento y la escalada?
Asigna una persona responsable del incidente y una suplencia disponible. No retrases artificialmente el conocimiento hasta la aprobación de un ticket o la publicación de un CVE. Registra qué se sabía, quién lo sabía y cuándo; escala las dudas sobre el supuesto legal sin esperar una atribución perfecta.
- Unifica los avisos de investigadores, clientes, proveedores, CSIRT y monitorización.
- Distingue primera observación, conocimiento de la organización, escalada interna y cada envío externo. Guarda fechas UTC y sus evidencias.
- Evalúa por separado el ámbito y el supuesto: un hallazgo del escáner no equivale automáticamente a explotación activa o incidente grave. Documenta decisión y responsable.
¿Qué debe contener el registro del incidente?
Usa un identificador duradero para todas las etapas. Separa hechos confirmados de hipótesis y asigna un responsable a cada incertidumbre relevante. Este esquema es un control técnico recomendado, no una afirmación de que todos los campos sean obligatorios en el formulario externo.
- Registra producto y versión afectados, papel del fabricante, países, categoría, indicios de explotación o gravedad, conocimiento y los dos plazos iniciales.
- Para vulnerabilidades, registra la disponibilidad de la medida correctora. Para incidentes graves, el momento de la notificación de 72 horas. Calcula el plazo final desde el campo correspondiente.
- Conserva evidencias, revisiones de evaluación, responsables, decisiones de mitigación y despliegue, comunicaciones, contenido enviado y justificantes.
- Limita detalles sensibles de explotación y datos personales. Define accesos, conservación proporcionada y una vista depurada para colaborar.
¿Dónde se notifica y cómo se ensaya?
La Single Reporting Platform de ENISA está operativa desde el 11 de septiembre de 2026. Usa las instrucciones oficiales de acceso y uso, sin presuponer una API pública de envío. Prepara ya accesos autorizados y suplencias; separa el registro interno del formulario externo.
- Comprueba acceso, responsabilidades y ruta CSIRT aplicable con las instrucciones oficiales.
- Ensaya internamente dos casos: vulnerabilidad explotada e incidente grave. No envíes incidentes ficticios al canal real de notificación.
- Prueba cobertura de fines de semana y ausencias, pérdida de acceso, retrasos de proveedores y conservación de justificantes.
Comprobaciones operativas para completar ahora
- Confirma productos incluidos, responsabilidades del fabricante, responsable del incidente y suplencia.
- Verifica el acceso oficial y conserva instrucciones actualizadas en el procedimiento de incidentes.
- Implementa el momento de conocimiento y controles separados de 24 horas, 72 horas y cierre por categoría.
- Conecta la recepción con inventario, versiones y correcciones; prueba permisos y recuperación de evidencias.
- Ensaya ambas categorías, cierra las carencias y programa ejercicios periódicos. Un proyecto de mejora no suspende los plazos de notificación.
Construye el producto, no solo el backlog
Si este artículo conecta con una decisión real de producto, Wavect puede ayudarte a definir, construir, endurecer o liderar el trabajo de software con criterio senior de founder.
Rutas de servicio útiles:
Preguntas sobre notificaciones CRA
¿Ya se aplican las obligaciones de los fabricantes?
¿Las 24 y 72 horas se cuentan consecutivamente?
¿Todos los informes finales vencen en 14 días?
¿Los administradores de software de código abierto tienen la misma fecha?
¿La alerta temprana necesita un análisis de causa raíz terminado?
¿Esta guía certifica el cumplimiento legal?
Reflexiones finales
La prioridad es ejecutar con fiabilidad: un registro de evidencias, responsabilidad con suplencia y reglas de cierre distintas por categoría. Conecta notificación, corrección y comunicación al cliente sin esperar un análisis retrospectivo perfecto.
Fuentes primarias
- Comisión Europea: obligaciones de notificación CRA. Fechas de fabricantes y administradores; categorías y plazos
- ENISA: Single Reporting Platform. Acceso oficial, instrucciones y recursos de notificación
- Comisión Europea: orientaciones de aplicación del CRA. Ámbito y aplicación; consultar la sección vigente de notificación