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

A fecha de 30 de mayo de 2026, hay cero organismos notificados designados bajo el CRA. Ninguna norma armonizada ha sido publicada en el Diario Oficial. La plataforma de notificación de ENISA todavía no existe. Quedan unos 3,4 meses antes de que el 11 de septiembre de 2026 empiece la aplicación del artículo 14.

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.

Tres bloqueos que no puedes esquivar

Sin normas armonizadas

El artículo 32, apartado 2, da a los fabricantes de Clase I importante tres rutas de conformidad: autoevaluación, evaluación por tercero usando normas armonizadas o especificaciones comunes, o evaluación por organismo notificado. La ruta intermedia exige normas armonizadas del CRA. Pero ninguna norma armonizada del CRA ha sido publicada en el Diario Oficial. A fecha de 30 de mayo 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 al amparo del artículo 27, apartado 2.
• Ningún acto delegado del artículo 27, apartado 9, designa esquema europeo de certificación de ciberseguridad alguno como ruta de presunción de conformidad para el CRA.

Cuando no existen normas, el artículo 32, apartado 2, exige 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 activa 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 (artículo 35, apartado 2, redacción de mejor esfuerzo). A fecha de 30 de mayo de 2026, no aparecen organismos notificados designados bajo el CRA en el Single Market Compliance Space.

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 hasta que la designación formal abra después de junio de 2026.

Contacta ya con organismos de evaluación de la conformidad. La maquinaria formal no abre hasta mediados de 2026. Esperar hasta entonces hace poco probable cerrar tu evaluación antes de diciembre de 2027.

Sin plataforma de notificación de ENISA

La plataforma única de notificación del artículo 16 no está disponible a fecha de mayo de 2026. ENISA ha contratado a un proveedor. La plataforma está prevista para abrir antes del 11 de septiembre de 2026. No se ha publicado ninguna URL de registro ni guía dirigida a fabricantes.

Lo que sí puedes hacer ahora:

• Redactar plantillas de notificación según los requisitos de formato del artículo 14: notificaciones a 24 horas y 72 horas, un informe final de vulnerabilidad a 14 días y un 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.

Página de la SRP de ENISA: https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp

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

Quedan unos 3,4 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 designación de organismos notificados no abre hasta junio de 2026; esperar
    hasta entonces te lleva más allá de diciembre de 2027.
[ ] Periodo de soporte declarado según vida útil prevista del producto (art. 13, apartado 8)

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 según art. 14
[ ] 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

Artículo 14: 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 (artículo 16).

Excepción para pymes: el artículo 64, apartado 10, letra a, exime a microempresas y pequeñas empresas de multas por incumplimiento de los plazos del artículo 14, apartado 2, letra a, y del artículo 14, apartado 4, letra a. La exención cubre solo los plazos. La obligación de notificar en sí sigue aplicándose.

Qué significa «explotada activamente»

El artículo 14, apartado 2, letra a, se aplica 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 del art. 14 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 del artículo 14 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 (art. 13, apartado 6).

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.

Artículo 13, apartado 8: 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.

Artículo 13, apartado 9: 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, infringes el artículo 13, apartado 9, 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 art. 13, apartado 8

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

CONTINUO:
[ ] Art. 13, apartado 8: proceso de actualización de seguridad activo durante toda la duración del soporte
[ ] Art. 13, apartado 9: 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.

Anuncio oficial: https://digital-strategy.ec.europa.eu/en/news/commission-publishes-feedback-draft-guidance-assist-companies-applying-cyber-resilience-act

Sanciones

El artículo 64, apartado 2, del Reglamento (UE) 2024/2847 fija la sanción del tramo más alto en 15 millones de euros o el 2,5 % del volumen de negocios anual mundial total, lo que sea más alto, por:

• Incumplimiento de los requisitos esenciales de ciberseguridad del anexo I y de las obligaciones del artículo 13.
• Incumplimiento de las obligaciones del artículo 14 (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.

El artículo 64, apartado 3 (10 millones de euros o 2 %), cubre un conjunto distinto de obligaciones: artículos 18 a 23, 28, 30 a 33, 39, 41, 47, 49 y 53. Son principalmente obligaciones de importadores, distribuidores y organismos notificados. El artículo 14 no figura en esta lista.

Excepción para pymes: el artículo 64, apartado 10, letra a, exime a microempresas y pequeñas empresas de multas por incumplimiento de los plazos específicos del artículo 14, apartado 2, letra a, y del artículo 14, apartado 4, letra a. La exención cubre los plazos, no el contenido sustantivo de la obligación de notificar.

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 (artículo 13, apartado 9). 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 ciclos de vida largos (10 a 20 años) interactúan directamente con el suelo mínimo de cinco años de soporte (artículo 13, apartado 8) y con la disponibilidad de actualizaciones a 10 años por emisión (artículo 13, apartado 9). Un producto con vida útil prevista de 20 años puede requerir un compromiso de soporte de 20 años.

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. El proceso formal de designación de organismos notificados abre tras junio de 2026, y la capacidad estará tensionada al menos hasta diciembre de 2026.

Dispositivos IoT

La eliminación de credenciales por defecto es un requisito duro (anexo I, parte I, §2, letra e). 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.