CRA: calendario de aplicación
| 10/12/2024 | 11/06/2026 | 11/09/2026 | 11/12/2027 |
| Entrada en vigor | Organismos de evaluación de la conformidad | Notificación del artículo 14 YA APLICABLE | Aplicación general del Reglamento |
| Qué cambia después del 11 de septiembre La organización ya no puede limitar el proyecto CRA a una planificación para 2027. Debe disponer hoy de un mecanismo operativo de detección, escalado, decisión y notificación para los eventos del artículo 14, y en paralelo avanzar en el cumplimiento completo de los requisitos que serán exigibles en diciembre de 2027. |
|||
El CRA se aplica, con carácter general, a productos de hardware y software comercializados en la Unión Europea, incluidos componentes que se introduzcan en el mercado por separado y determinadas soluciones de tratamiento remoto de datos cuya ausencia impediría que el producto realizase una de sus funciones. No todo servicio digital queda automáticamente dentro del alcance: la evaluación debe realizarse sobre el producto, su forma de comercialización, su conectividad prevista o razonablemente previsible, el rol de la organización y las exclusiones o regímenes sectoriales que puedan resultar aplicables. [1–2]
En la práctica, el primer error que conviene evitar es empezar a redactar procedimientos sin haber identificado previamente el catálogo de productos, versiones, componentes, mercados y operadores económicos implicados. Un análisis de aplicabilidad y clasificación bien ejecutado evita invertir esfuerzo en productos fuera de alcance y, sobre todo, evita dejar sin tratar productos que sí generan obligaciones.
El CRA distribuye responsabilidades a lo largo de la cadena de suministro. La obligación más intensa recae sobre el fabricante, pero importadores y distribuidores no son meros intermediarios: deben verificar determinados elementos de conformidad y actuar cuando conozcan o sospechen que un producto no cumple. Además, un importador o distribuidor puede pasar a ser considerado fabricante si comercializa el producto bajo su nombre o marca o realiza una modificación sustancial. [1–2]
| Rol | Qué significa | Implicación principal |
| Fabricante | Diseña, desarrolla o fabrica —o encarga hacerlo— y comercializa el producto bajo su nombre o marca. | Evaluación de riesgos, requisitos esenciales, gestión de vulnerabilidades, documentación técnica, conformidad, marcado CE, soporte y notificaciones del art. 14. |
| Representante autorizado | Actúa en la UE por mandato escrito del fabricante para las tareas expresamente delegadas. | Conservar o facilitar documentación cuando proceda, cooperar con vigilancia del mercado y ejecutar las obligaciones incluidas en el mandato. |
| Importador | Introduce en el mercado de la UE un producto fabricado fuera de la Unión. | Verificar evaluación de conformidad, documentación técnica, marcado CE, declaración UE, información al usuario y cumplimiento de obligaciones del fabricante antes de introducir el producto. |
| Distribuidor | Pone el producto a disposición en el mercado sin ser fabricante ni importador. | Actuar con diligencia, verificar marcado y documentación, y no comercializar cuando existan motivos para creer que el producto o los procesos del fabricante no son conformes. |
| Marca propia / modificación sustancial | Importador, distribuidor u otra entidad que reetiqueta el producto con su marca o modifica sustancialmente un producto ya comercializado. | Puede asumir jurídicamente la condición y las obligaciones de fabricante respecto del producto o de la parte afectada. |
| Administrador de código abierto | Entidad que proporciona apoyo sostenido al desarrollo de software libre y de código abierto destinado a actividades comerciales. | Régimen específico del art. 24; sus obligaciones no deben confundirse con las de un fabricante convencional y se aplican conforme al calendario general del Reglamento. |
| Punto crítico para grupos empresariales y distribuidores El rol no se decide por el nombre interno del departamento ni por cómo se describe la empresa comercialmente. Se determina por lo que la organización hace realmente con el producto: quién lo pone en el mercado, bajo qué marca, quién lo modifica y quién asume las responsabilidades sobre su ciclo de vida. |
||
El artículo 13 y el anexo I convierten la ciberseguridad en un requisito del propio producto. El fabricante debe realizar y documentar una evaluación de riesgos de ciberseguridad y utilizarla durante la planificación, diseño, desarrollo, producción, entrega y mantenimiento. El producto debe alcanzar un nivel de seguridad adecuado al riesgo, reducir superficies de ataque, proteger datos y funciones, permitir la gestión segura de vulnerabilidades y facilitar actualizaciones de seguridad. [1–2]
La gestión de vulnerabilidades adquiere un peso específico. El fabricante debe identificar y documentar vulnerabilidades y componentes —incluyendo una lista de materiales de software en un formato común y legible por máquina que cubra, al menos, las dependencias de primer nivel—, disponer de una política de divulgación coordinada, proporcionar un punto de contacto, tratar vulnerabilidades durante el período de soporte y ejercer diligencia debida sobre componentes de terceros, incluido el software libre y de código abierto. [1]
También debe definirse y justificar el período de soporte. Como regla general será de al menos cinco años, salvo que la vida útil esperada del producto sea inferior. La documentación técnica, la declaración UE de conformidad, la información al usuario y las evidencias asociadas deben conservarse durante los plazos exigidos, y las actualizaciones de seguridad publicadas deben permanecer disponibles durante el período establecido por el Reglamento. [1]
No todos los productos siguen la misma vía de evaluación. El CRA distingue una categoría general y categorías de productos importantes —clases I y II— y críticos en función de su funcionalidad esencial. La clasificación condiciona si el fabricante puede utilizar control interno o si necesita una evaluación de terceros mediante un organismo notificado o, cuando proceda, un esquema europeo de certificación de ciberseguridad. [1–2, 5]
| Categoría | Enfoque general | Implicación práctica |
| General | Puede utilizarse la autoevaluación mediante control interno. | El fabricante debe demostrar y documentar por sí mismo el cumplimiento de los requisitos aplicables. |
| Importante – clase I | La autoevaluación queda condicionada al uso de normas armonizadas, especificaciones comunes o esquemas admitidos; en otro caso interviene un tercero. | La estrategia de normas y evidencias debe decidirse pronto para evitar rehacer el expediente técnico. |
| Importante – clase II | Se exige evaluación por terceros o la alternativa de certificación prevista por el CRA cuando esté disponible. | Debe planificarse capacidad y calendario con organismos notificados. |
| Crítico | Puede exigirse certificación europea de ciberseguridad conforme a las condiciones que establezca la Comisión. | La clasificación debe validarse antes de cerrar la estrategia de conformidad. |
| Una evaluación interna realizada por una consultora o auditor independiente puede ser muy útil para preparar la conformidad, pero no sustituye a un organismo notificado cuando el CRA exige evaluación de terceros. | ||
Desde el 11 de septiembre de 2026, los fabricantes deben utilizar la Plataforma Única de Notificación de ENISA para comunicar las vulnerabilidades explotadas activamente y los incidentes graves que repercutan en la seguridad de sus productos. La obligación alcanza también a productos introducidos en el mercado antes del 11 de diciembre de 2027. [1, 3–4]
| Plazo | Entrega | Qué exige a la organización |
| 24 horas | Alerta temprana | Detectar, escalar y confirmar rápidamente si el evento entra en los criterios de notificación. |
| 72 horas | Notificación completa | Consolidar información técnica, impacto, alcance, producto/versiones afectadas y medidas iniciales. |
| Informe final | 14 días tras disponer de medida correctora para una vulnerabilidad explotada activamente; un mes tras la notificación de 72 h para un incidente grave. | Mantener trazabilidad de investigación, causa, correcciones, comunicación a usuarios y cierre. |
La dificultad no está en rellenar un formulario. El verdadero reto es poder saber qué productos y versiones están afectados, qué componentes incorporan, quién tiene capacidad para decidir, qué información se puede comunicar y cómo se preserva la evidencia. Por eso, el cumplimiento del artículo 14 debe integrarse con la gestión de vulnerabilidades, la respuesta a incidentes, el equipo de seguridad del producto, el soporte, el área jurídica y la cadena de suministro.
| Incumplimiento | Límite previsto por el CRA |
| Requisitos esenciales del anexo I y obligaciones de los artículos 13 y 14 | 15 M€ o 2,5 % |
| Obligaciones enumeradas en el artículo 64.3, incluidas obligaciones de operadores económicos y evaluación de conformidad | 10 M€ o 2 % |
| Información incorrecta, incompleta o engañosa a organismos notificados o autoridades de vigilancia | 5 M€ o 1 % |
| Precisión sobre el calendario sancionador El artículo 14 ya es aplicable desde el 11/09/2026, pero el artículo 64 forma parte del régimen de aplicación general del Reglamento previsto para el 11/12/2027. Por ello, conviene distinguir entre la obligación operativa ya vigente y el calendario de aplicación del régimen sancionador propio del CRA, sin perjuicio de otras responsabilidades o regímenes nacionales que puedan resultar aplicables. [1] |
|
La forma más eficaz de abordar el CRA es convertirlo en un programa de producto con responsables, evidencias y fechas de cierre. Desde Internet Security Auditors proponemos una aproximación progresiva que permite conocer el estado real, priorizar la inversión y llegar a la evaluación de conformidad con un expediente técnico coherente y controles probados. Esta aproximación se alinea con nuestro servicio de Evaluación y Soporte al Cumplimiento CRA. [6]
| Fase ISecAuditors | Objetivo | Resultados principales |
| 1. GAP y alcance | Determinar aplicabilidad, rol, clasificación y grado de cumplimiento real. | Inventario de productos y versiones; matriz de aplicabilidad; clasificación; GAP por artículos y anexos; revisión de preparación del art. 14; plan de acción priorizado. |
| 2. Implantación | Cerrar las diferencias identificadas e integrar CRA en el ciclo de vida del producto. | Evaluación de riesgos y amenazas; procesos de desarrollo seguro; gestión de componentes y SBOM; vulnerabilidades y actualizaciones; soporte; pruebas técnicas; procedimientos; documentación técnica e información al usuario. |
| 3. Evaluación / auditoría interna | Comprobar que las medidas están implantadas y que la evidencia soporta una evaluación de conformidad. | Auditoría interna de requisitos aplicables; muestreo de productos; trazabilidad requisito-evidencia; validación de acciones correctoras; informe de preparación y recomendaciones antes de la autoevaluación o del organismo notificado. |
El valor del análisis GAP no es generar una lista de “cumple/no cumple”, sino identificar qué productos requieren cambios de arquitectura, desarrollo o soporte y cuáles son principalmente carencias de gobierno o evidencia. La implantación debe cerrar esas brechas con criterios verificables. Finalmente, la auditoría interna debe intentar demostrar el cumplimiento como lo haría un tercero: seleccionando productos y versiones, siguiendo el rastro desde la evaluación de riesgos hasta las pruebas y verificando que la documentación refleja lo que realmente sucede.
Internet Security Auditors puede acompañar a fabricantes, importadores, distribuidores y otros operadores afectados en las tres etapas: determinación de alcance y clasificación, análisis GAP y plan de acción; soporte técnico y documental a la implantación; y evaluación o auditoría interna de preparación. Cuando la clasificación del producto requiera evaluación de terceros, este trabajo actúa como preparación y no sustituye la intervención del organismo notificado.
Más información sobre el servicio de CRA de Internet Security Auditors: Evaluación y Soporte al Cumplimiento CRA
El 11 de septiembre de 2026 marca el paso de la preparación a obligaciones ya operativas. El fabricante que detecte una vulnerabilidad explotada activamente o un incidente grave debe poder decidir y notificar con rapidez. En paralelo, diciembre de 2027 exige avanzar ya en seguridad por diseño, gestión de vulnerabilidades, soporte, documentación, clasificación, evaluación de conformidad y marcado CE.
El riesgo es descubrir demasiado tarde que el cumplimiento exige cambios de producto o de proceso. Un GAP temprano, una implantación estructurada y una evaluación interna independiente convierten CRA en un proyecto controlable, con prioridades y evidencias verificables
Referencias
Reglamento (UE) 2024/2847 del Parlamento Europeo y del Consejo, de 23 de octubre de 2024, relativo a los requisitos horizontales de ciberseguridad para los productos con elementos digitales (Cyber Resilience Act).
Comisión Europea — Ley de Ciberresiliencia: resumen del texto legislativo y explicación de alcance, operadores, anexos y calendario.
Comisión Europea — Cyber Resilience Act: Reporting obligations. Reglas de notificación aplicables desde el 11 de septiembre de 2026.
ENISA — CRA Single Reporting Platform (SRP) y preguntas frecuentes para las notificaciones del artículo 14.
Comisión Europea — Cyber Resilience Act: Conformity assessment. Categorías de producto y vías de evaluación de conformidad.
Internet Security Auditors — Evaluación y Soporte al Cumplimiento CRA: alcance, análisis GAP, soporte a la implantación y evaluación de cumplimiento.
Comisión Europea — Aplicación de la Ley de Ciberresiliencia: preguntas frecuentes (actualizadas el 4 de septiembre de 2026).
Fuentes consultadas el 11 de septiembre de 2026. Tablas y síntesis de elaboración propia a partir de las fuentes citadas.