Plazos del CRA 2026 y 2027: qué vence y qué está bloqueado

A fecha de 12 de julio de 2026, NANDO muestra cero organismos notificados designados bajo el CRA. Ninguna norma armonizada del CRA se ha publicado en el Diario Oficial. La plataforma de notificación de ENISA debe estar operativa para el 11 de septiembre de 2026. Quedan unos dos meses antes de que la notificación de vulnerabilidades e incidentes sea obligatoria.

Si fabricas productos con elementos digitales para el mercado de la UE, esta es la situación real: qué tienes que tener montado antes de septiembre, qué está bloqueado ahora mismo y por qué la autoevaluación para Clase I importante hoy no es viable.

Calendario de un vistazo

Situación el 12 de julio de 2026, frente a las dos fechas ancla que vinculan a los fabricantes.

Referencia de fechas

Tres bloqueos que no puedes esquivar

Sin normas armonizadas

Los fabricantes de Clase I importante tienen tres rutas de conformidad: autoevaluación, evaluación por tercero usando normas armonizadas o especificaciones comunes, o evaluación por organismo notificado. Las dos primeras dependen de normas o especificaciones que aún no están disponibles. A fecha de 12 de julio de 2026:

• La página de la Comisión sobre normas armonizadas no tiene ninguna entrada para el Reglamento (UE) 2024/2847.
• No se han adoptado especificaciones comunes para el CRA.
• Ningún acto delegado designa un esquema europeo de certificación de ciberseguridad como ruta de presunción de conformidad para el CRA.

Cuando no existen normas, la ruta de respaldo es el módulo B+C (examen UE de tipo) o el módulo H (aseguramiento total de la calidad). Ambos requieren un organismo notificado.

Por eso, si fabricas un producto Clase I importante, la autoevaluación hoy no funciona. La evaluación por organismo notificado es la única vía conforme.

CEN-CLC/JTC 13/WG 9 está desarrollando la serie EN 40000:

• prEN 40000-1-1 (Vocabulario): consulta pública cerrada, aún no en votación formal.
• prEN 40000-1-2 (Principios): consulta pública cerrada, aún no en votación formal.
• prEN 40000-1-3 (Tratamiento de vulnerabilidades): consulta pública abierta entre diciembre de 2025 y febrero de 2026, actualmente en resolución de comentarios.
• prEN 40000-1-4 (Requisitos generales de seguridad): aún en redacción.
• Verticales tipo C (navegadores, VPN, SIEM y otros): borrador maduro, aún sin entrar en consulta pública.

Cita más temprana realista en el Diario Oficial: cuarto trimestre de 2026. Varias normas verticales se irán probablemente a 2027.

Sin organismos notificados

El capítulo IV se aplica desde el 11 de junio de 2026. El objetivo de la Comisión es capacidad suficiente de organismos notificados para el 11 de diciembre de 2026, pero es un objetivo de mejores esfuerzos, no una garantía por categoría de producto. A fecha de 12 de julio de 2026, no aparecen organismos notificados designados bajo el CRA en NANDO.

Si necesitas una evaluación de Clase I importante completada antes de diciembre de 2027, planifica:

• Preparación del expediente técnico: 3 a 6 meses.
• Evaluación módulo B+C: 2 a 4 meses por producto.
• Disponibilidad de organismo notificado: incierta ahora que la designación formal bajo el capítulo IV ha abierto.

Contacta ya con organismos de evaluación de la conformidad. La maquinaria formal ya está abierta, aunque la capacidad CRA aún no aparece en NANDO. Esperar a que la capacidad madure hace menos probable cerrar tu evaluación antes de diciembre de 2027.

Sin plataforma de notificación de ENISA

La Plataforma Única de Notificación aún no está operativa a 12 de julio de 2026. ENISA está publicando instrucciones operativas y material de formación en junio de 2026, y la plataforma debe estar operativa para el 11 de septiembre de 2026.

Lo que sí puedes hacer ahora:

• Redactar plantillas de notificación para los cuatro tramos: 24 horas, 72 horas, informe final de vulnerabilidad a 14 días e informe final de incidente grave a un mes.
• Identificar al coordinador CSIRT designado de tu Estado miembro.
• Definir quién, internamente, puede autorizar una notificación a las 24 horas en fin de semana o festivo.

Abrir la página de la Plataforma Única de Notificación de ENISA.

Qué debe estar listo antes del 11 de septiembre de 2026

Quedan unos dos meses. Si estos puntos no están hechos, no vas tarde con tareas. Vas tarde con infraestructura, y la infraestructura tarda meses en construirse.

Inventario y clasificación de producto

Necesitas una lista completa de todo producto con elementos digitales (PDE) que pongas en el mercado de la UE, con clasificación CRA confirmada producto a producto:

• Clase por defecto: ruta de autoevaluación disponible.
• Clase I importante: evaluación por organismo notificado exigida hoy (ver arriba).
• Clase II importante: organismo notificado obligatorio. Módulo B+C o módulo H.
• Crítico: módulo B+C o aseguramiento total de la calidad. Puede aplicarse además certificación europea de ciberseguridad.

Referencia de clasificación: el Reglamento de Ejecución (UE) 2025/2392 (DOUE de 1 de diciembre de 2025, en vigor desde el 21 de diciembre de 2025) ofrece descripciones técnicas de las categorías de producto del anexo III y IV. Úsalo para resolver casos límite.

Infraestructura SBOM

No puedes notificar una vulnerabilidad explotada activamente en 24 horas si no sabes qué componentes contiene tu producto. La generación de SBOM debe estar operativa antes de septiembre de 2026.

• Formato: CycloneDX o SPDX. Ambos se aceptan bajo el CRA. Elige uno y unifícalo entre productos.
• Alcance: dependencias transitivas, no solo directas. La visibilidad completa de componentes es obligatoria para la evaluación de riesgos del anexo VII.
• Almacenamiento: bajo control de versiones, ligado a las releases del producto. Cada SBOM debe casar con un build concreto.
• Integración: pipeline CI/CD. Una exportación puntual no satisface la obligación continua.

Monitorización de vulnerabilidades

El reloj de las 24 horas arranca con la toma de conciencia: certeza razonable basada en una evaluación inicial. La confirmación forense no es necesaria para activar el reloj. Necesitas monitorización capaz de producir esa evaluación inicial antes de que venza el plazo.

• Suscríbete a NVD, OSV y avisos de proveedores relevantes para tu stack de componentes.
• Automatiza el escaneo contra los componentes de tu SBOM.
• Documenta tu ruta de escalado interno y pruébala de extremo a extremo.
• Redacta plantillas de notificación ahora, antes de que la plataforma de ENISA arranque.

Lista de comprobación previa a septiembre de 2026

INVENTARIO DE PRODUCTO (esto primero: la clasificación define tu ruta de conformidad):
[ ] Lista completa de PDE vendidos en la UE con clasificación CRA confirmada por producto
[ ] Productos Clase I importante: organismo de evaluación de la conformidad ya contactado.
    La notificación formal CRA está abierta, pero NANDO aún no lista organismos designados;
    esperar a que madure la capacidad te lleva más allá de diciembre de 2027.
[ ] Periodo de soporte declarado según vida útil prevista del producto

SBOM (empezar aquí: alimenta monitorización, expediente técnico y notificación a 24 horas):
[ ] Generación de SBOM integrada en el pipeline CI/CD: una exportación puntual no basta
[ ] Formato unificado: CycloneDX o SPDX
[ ] Cobertura de dependencias transitivas verificada: solo dependencias directas no basta
[ ] SBOM bajo control de versiones y ligados a releases concretas del producto

MONITORIZACIÓN DE VULNERABILIDADES (debe estar viva antes del 11 de septiembre):
[ ] Monitorización activa para todos los productos: NVD, OSV, avisos de proveedores
[ ] Escaneo automatizado contra el SBOM en marcha
[ ] Ruta de escalado interno documentada y probada de extremo a extremo
[ ] Cobertura 24/7 confirmada, incluyendo escalado en festivos y fines de semana

PREPARACIÓN DE NOTIFICACIÓN (la plataforma de ENISA aún no está viva: prepara el resto ahora):
[ ] Plantillas a 24 horas, 72 horas, vulnerabilidad a 14 días e incidente a un mes redactadas
[ ] Coordinador CSIRT del Estado miembro identificado
[ ] Persona autorizada a activar una notificación a 24 horas designada y localizable las 24 horas

DOCUMENTACIÓN:
[ ] Documentación técnica auditada contra el anexo VII
[ ] Análisis de brechas finalizado
[ ] Evaluación de riesgos en curso

Qué exige la notificación a partir del 11 de septiembre de 2026

A partir del 11 de septiembre de 2026, debes notificar las vulnerabilidades explotadas activamente y los incidentes graves a dos destinatarios simultáneamente: al coordinador CSIRT designado de tu Estado miembro y a ENISA a través de la plataforma única de notificación.

Qué significa «explotada activamente»

El reloj de 24 horas se activa cuando hay pruebas creíbles de que un actor de amenaza ha utilizado la vulnerabilidad en un sistema sin permiso de su titular. Indicadores:

• Ataques confirmados observados in the wild.
• Explotación reportada en feeds de inteligencia de amenazas o por investigadores de seguridad.
• Detección en honeypots con evidencia de despliegue activo.

El borrador de orientación de la Comisión (Ares(2026)2319816, 3 de marzo de 2026) usa «pruebas creíbles de explotación activa» como estándar, más bajo que la confirmación forense.

Lista de preparación para la fase 2

INFRAESTRUCTURA DE NOTIFICACIÓN (antes del 11 de septiembre de 2026):
[ ] Plantillas de notificación preparadas: formatos a 24 horas, 72 horas, vulnerabilidad a 14 días e incidente a un mes
[ ] Coordinador CSIRT del Estado miembro identificado: es tu punto principal de envío
    junto con ENISA
[ ] Ruta de escalado 24/7 confirmada, con cobertura en festivos y contactos de respaldo
[ ] Revisión jurídica de las obligaciones de notificación finalizada

GESTIÓN DE VULNERABILIDADES:
[ ] Monitorización activa operativa para todos los productos
[ ] Integración con CVE/NVD viva
[ ] Plantillas de notificación a clientes listas

PREPARACIÓN DEL EQUIPO:
[ ] Equipo de seguridad formado en las obligaciones de notificación y los cuatro tramos de plazos
[ ] Ruta de escalado a dirección documentada
[ ] Equipo jurídico informado sobre las obligaciones de notificación
[ ] Equipo de comunicación preparado para divulgaciones públicas

Plena conformidad para el 11 de diciembre de 2027

Requisitos esenciales de ciberseguridad (anexo I)

Todo PDE conforme debe cumplir estos requisitos:

Seguridad desde el diseño

• Nivel de seguridad adecuado a los riesgos del producto (anexo I, parte I, §1).
• Protección frente a accesos no autorizados.
• Confidencialidad, integridad y disponibilidad de los datos y de las funciones esenciales.
• Superficie de ataque mínima, configuración segura por defecto, sin credenciales codificadas en duro.

Gestión de vulnerabilidades

• Proceso documentado para identificar y tratar vulnerabilidades.
• Actualizaciones de seguridad oportunas y gratuitas durante el periodo de soporte.
• Política de divulgación coordinada de vulnerabilidades.

Capacidad de actualización

• Mecanismo de actualización seguro y fiable.
• Posibilidad de separar las actualizaciones de seguridad de las funcionales.

Documentación técnica (anexo VII)

Periodo de soporte: dos obligaciones distintas

El CRA impone dos obligaciones diferenciadas sobre las actualizaciones de seguridad.

Duración del soporte: debes proporcionar actualizaciones de seguridad durante un mínimo de cinco años desde la fecha de introducción del producto en el mercado, o durante la vida útil prevista del producto si es menor. Cinco años son el suelo, no la opción por defecto. Un producto con una vida útil prevista de 10 años necesita un compromiso de soporte de 10 años.

Disponibilidad de actualizaciones: cada actualización de seguridad que entregues debe seguir disponible para descarga durante un mínimo de 10 años desde su fecha de emisión, o el resto del periodo de soporte, lo que sea más largo.

Son obligaciones independientes. Una actualización emitida en el cuarto año de un periodo de soporte de cinco años debe seguir descargable hasta el año 14 desde su emisión. Si borras paquetes antiguos o dejas caducar la infraestructura de distribución, puedes incumplir la regla de disponibilidad aunque sigas emitiendo nuevas actualizaciones a tiempo. Planifica almacenamiento y distribución para el largo plazo antes de emitir tu primera actualización bajo el CRA.

Lista de comprobación de diciembre de 2027

CONFORMIDAD DEL PRODUCTO:
[ ] Todos los productos cumplen los requisitos del anexo I: seguridad desde el diseño, gestión de
    vulnerabilidades y capacidad de actualización
[ ] Evaluaciones de la conformidad finalizadas: proceso ante organismo notificado cerrado para
    Clase I importante y Clase II
[ ] Marcado CE aplicado
[ ] Declaración UE de conformidad preparada según el art. 28

EXPEDIENTE TÉCNICO (anexo VII):
[ ] Evaluación de riesgos finalizada y documentada
[ ] SBOM al día y validado
[ ] Evidencia de conformidad organizada y accesible
[ ] Periodo de soporte declarado según la vida útil prevista del producto

CADENA DE MERCADO:
[ ] Importadores y distribuidores informados de sus obligaciones bajo el CRA
[ ] Documentación dirigida a cliente actualizada

CONTINUO:
[ ] Proceso de actualización de seguridad activo durante toda la duración del soporte
[ ] Infraestructura de disponibilidad de actualizaciones lista: 10 años desde
    cada fecha de emisión
[ ] Monitorización de vulnerabilidades activa y probada
[ ] Respuesta a incidentes ejercitada al menos trimestralmente

Orientación de la Comisión: borrador de marzo de 2026

La Comisión publicó un borrador de Comunicación (Ares(2026)2319816) el 3 de marzo de 2026, de unas 70 páginas. La consulta a los grupos de interés cerró el 31 de marzo de 2026. El documento no es definitivo. Las versiones lingüísticas finales están pendientes. Para un desglose completo, consulta nuestra guía sobre la orientación de la Comisión.

Decisiones clave relevantes para tu calendario:

Test RDPS para alcance SaaS: el software de tratamiento remoto de datos entra en el alcance del CRA solo si pasa tres condiciones. El software realiza tratamiento remoto de datos. Ese tratamiento remoto es necesario para la función principal del producto. Y el fabricante controla ese tratamiento remoto. El SaaS que no pase este test queda fuera de alcance.

Productos heredados: no se exige reconstrucción histórica de la documentación. Necesitas una evaluación de riesgos actual. Las familias de producto pueden agruparse a efectos de evaluación de riesgos.

Actualizaciones de software: una actualización no constituye una «modificación sustancial» que active una nueva evaluación de la conformidad salvo que introduzca nuevos vectores de amenaza o cambie la finalidad prevista del producto. La orientación incluye un test de cuatro preguntas.

Reloj de las 24 horas: arranca con la toma de conciencia. Basta una certeza razonable basada en una evaluación inicial. La confirmación forense no se exige.

Suelo del periodo de soporte: cinco años son un mínimo, no la opción por defecto. El periodo de soporte debe reflejar la vida útil prevista del producto.

Código abierto: publicar código fuente no constituye introducir un producto en el mercado. Los contribuidores que no controlan la liberación de un producto terminado no son fabricantes a efectos del CRA.

Leer el anuncio de la Comisión.

Sanciones

El tramo sancionador más alto del CRA es 15 millones de euros o el 2,5 % del volumen de negocios anual mundial total, lo que sea más alto. Se aplica a:

• Incumplimiento de los requisitos esenciales de ciberseguridad y de las obligaciones del fabricante.
• Incumplimiento de las obligaciones de notificación de vulnerabilidades e incidentes.

Ambas infracciones están en el mismo tramo sancionador. No hay un tramo más bajo para los fallos de notificación.

Notas por sector

Electrónica de consumo

La automatización de SBOM es la inversión temprana de mayor valor. Alimenta directamente la monitorización de vulnerabilidades y la generación del expediente técnico. Los productos de consumo suelen tener cadenas de suministro complejas con múltiples proveedores de componentes.

Gestionar actualizaciones de firmware sobre grandes parques de dispositivos exige infraestructura OTA. Una actualización emitida en el tercer año de vida del producto debe seguir descargable durante 10 años desde esa fecha de emisión. Planifica tu infraestructura de distribución ahora, no en el momento de la emisión.

Editores de software

La notificación de vulnerabilidades es la obligación más exigente operativamente para productos de software. Las tasas de descubrimiento son más altas y rastrear dependencias en profundidad transitiva en stacks modernos no es trivial. Integra la generación de SBOM en tus pipelines CI/CD existentes. Alimenta directamente la monitorización y el flujo de respuesta.

Equipamiento industrial

Los productos industriales caen con frecuencia en Clase I o Clase II importante, lo que hoy implica evaluación por organismo notificado. Contacta ya con organismos de evaluación de la conformidad. La notificación formal CRA está abierta, pero NANDO aún no lista organismos designados; la capacidad seguirá tensionada al menos hasta diciembre de 2026.

Dispositivos IoT

La eliminación de credenciales por defecto se deriva del requisito de configuración segura por defecto del anexo I, parte I. Atácalo primero. Es una infracción clara del anexo I y, comparado con cambios de arquitectura, está relativamente acotado de resolver. Los mecanismos de actualización seguros para dispositivos con recursos limitados requieren más trabajo. Empieza por las credenciales y luego ataca las actualizaciones.