Actualizado el 15 de septiembre de 2026: las obligaciones de notificación del Cyber Resilience Act (CRA) para fabricantes son aplicables desde el 11 de septiembre de 2026. Un proveedor de microinversores Wi-Fi para la UE necesita ya un proceso operativo, no solo una hoja de ruta para los requisitos generales que se aplican desde el 11 de diciembre de 2027.
Una vulnerabilidad explotada activamente o un incidente grave puede comenzar en nube, gateway, app, librería o firmware. Sin producto, cadena de soporte y responsable definidos, las primeras 24 horas se pierden buscando registros. Esta checklist apoya la diligencia B2B y no sustituye clasificación jurídica, autoridad ni evaluación de conformidad.
Confirme límite del producto y operador económico
El CRA cubre ampliamente hardware y software ofrecidos en la Unión cuyo uso previsto o razonablemente previsible incluya conexión directa o indirecta de datos con un dispositivo o red. Congele modelo, hardware, firmware, radio/gateway, app, portales, API, procesamiento remoto necesario, servicios de actualización, dueño de marca, fabricante, importador UE, distribuidores y proveedores de software.
Un microinversor sin radio no queda necesariamente fuera si un gateway, nube o actualización exigidos forman parte de la oferta. Tampoco declare cada accesorio producto CRA separado sin documentar cómo se comercializa y funciona.
Importador o distribuidor pueden considerarse fabricante si venden bajo su nombre o marca, o hacen una modificación sustancial de ciberseguridad. En marca privada, acuerde antes autoridad de firmware, nube y responsabilidades.
Separe la notificación 2026 de los requisitos 2027
| Hito | Fecha | Significado de compra |
|---|---|---|
| Notificación de organismos | 11 junio 2026 | Puede planificarse capacidad de evaluación |
| Notificación del fabricante | 11 septiembre 2026 | Deben reportarse vulnerabilidades activas e incidentes graves |
| Obligaciones generales CRA | 11 diciembre 2027 | Aplican en general producto, proceso, documentación y conformidad |
La Comisión indica que la obligación de 2026 alcanza productos ya ofrecidos antes de diciembre de 2027. No posponga la preparación hasta la siguiente generación.
Organice los plazos de 24, 72 horas y cierre
Los fabricantes notifican mediante la Single Reporting Platform (SRP) de ENISA.
| Activador | Alerta | Notificación | Informe final |
|---|---|---|---|
| Vulnerabilidad explotada activamente | 24 h desde conocimiento | 72 h | Máximo 14 días tras disponer de corrección o mitigación |
| Incidente grave que afecta seguridad | 24 h | 72 h | Un mes desde la notificación de 72 h |
“Conocimiento” no espera una reunión directiva. Defina quién recibe alertas, evalúa el umbral, envía al SRP y comunica con usuarios y socios. Registre representantes y suplentes antes del incidente y pruebe internamente sin crear una notificación falsa.
Mantenga un expediente por producto afectado
Vincule marca, modelo, series/lotes y mercados con versiones de hardware, firmware, gateway, app, cloud y librerías. Registre descubrimiento y conocimiento en UTC, decisión, evidencia, impacto, mitigación, actualización, rollback, validación, identificadores SRP, comunicaciones, causa y cambios del expediente técnico. Marque supuestos: un ticket puede mostrar menos alcance que la telemetría.
Ajuste el contrato al reloj regulatorio
El fabricante no puede cumplir 24 horas si OEM, nube o proveedor escalan en varios días. Pacte plazos anteriores y contactos permanentes.
| Evidencia | Pregunta RFQ | Respuesta débil |
|---|---|---|
| Contacto de seguridad | ¿Quién responde fuera del horario comercial? | “Su gestor de cuenta” |
| Vulnerabilidades | ¿Cómo se clasifican, reproducen y escalan? | Política sin responsable |
| Componentes | ¿Qué versiones contiene cada release? | BOM sin versiones |
| Actualización | ¿Cómo controlan autenticidad, despliegue y recovery? | Update remoto sin registros |
| Incidente | ¿Qué datos llegan dentro del plazo? | Ayuda según disponibilidad |
| Base instalada | ¿Qué clientes/lotes requieren acción? | Solo totales de envío |
Defina conservación de logs, acceso legal a telemetría, intercambio confidencial y aprobación de correcciones para perfiles de red afectados.
Prepare el expediente técnico de 2027
Incluya riesgo y arquitectura, requisitos con pruebas, inventario versionado, decisiones sobre vulnerabilidades, configuración segura, autenticidad de updates, instalación automática, recuperación/rollback, divulgación, fin de soporte por mes y año, información al usuario, retirada y documentación de conformidad.
El soporte debe reflejar uso esperado, expectativas razonables y naturaleza del producto; no copie automáticamente la garantía. Para equipos de tejado de larga vida, cuestione un soporte cibernético demasiado corto.
El CRA exige una SBOM en formato común legible por máquina, al menos con dependencias superiores, pero no su publicación general a cada usuario. Defina mantenimiento, relación con releases y acceso controlado del importador.
Separe CRA, RED y seguridad operativa
| Vía | Propósito | Control del comprador |
|---|---|---|
| CRA | Seguridad horizontal y vulnerabilidades | Límite, ciclo, reporte y roles |
| RED / EN 18031 | Requisitos de radio y conformidad | Configuración, normas, informes, declaración |
| GDPR | Tratamiento legal de datos | Roles, avisos, conservación, acceso |
| Código de red | Conexión y comportamiento | Modelo, firmware/perfil, operador |
| SLA cloud | Disponibilidad y soporte | Respuesta, recovery, propiedad, salida |
La checklist RED EN 18031 cubre radio; la guía de firmware, releases y recuperación. Para UK use la checklist PSTI.
Aplique seis bloqueos: alcance, proveedor, muestra, release, incidente y embarque. En compras públicas revise también las cláusulas de ciberseguridad para subastas UE.
Envíe Estados objetivo, marca, modelos, conectividad, nube, soporte, volumen y flujo de incidentes mediante TMG Contact. TMG puede estructurar la matriz; clasificación, reporte y conformidad siguen con los responsables. Para marca propia revise la solución OEM.
