Cumplimiento del Reglamento de Ciberresiliencia para productos industriales, IoT, embebidos y de software

Ayudamos a los fabricantes de productos industriales, IoT, embebidos y de software a clasificarlos conforme al Reglamento (UE) 2024/2847, cumplir el anexo I y preparar las evidencias para el marcado CE. Trabajamos en inglés y en español con fabricantes de toda la UE.

En resumen

Para

  • Fabricantes de pasarelas industriales, enrutadores, controladores y equipos embebidos y radioeléctricos cuyos productos o componentes pueden figurar en el anexo III o en el anexo IV.
  • Fabricantes de automatización industrial y OT con un programa IEC 62443 que quieren aprovechar esas evidencias para el CRA.
  • Fabricantes de productos de identidad, de control de acceso y biométricos, sistemas operativos, hipervisores y software de seguridad.

Recibe

  • Informe de clasificación del producto
  • Análisis de brechas frente al anexo I con plan de trabajo
  • Procedimiento de notificación del artículo 14 y política de divulgación coordinada
  • SBOM y proceso de gestión de vulnerabilidades
  • Correspondencia de IEC 62443 y EN 18031 con el CRA
  • Estructura de la documentación técnica

Primer paso

Revisión de preparación para el CRA de una familia de productos

Solicitar esta revisión

Para quién es

  • Fabricantes de pasarelas industriales, enrutadores, controladores y equipos embebidos y radioeléctricos cuyos productos o componentes pueden figurar en el anexo III o en el anexo IV.
  • Fabricantes de automatización industrial y OT con un programa IEC 62443 que quieren aprovechar esas evidencias para el CRA.
  • Fabricantes de productos de identidad, de control de acceso y biométricos, sistemas operativos, hipervisores y software de seguridad.
  • Fabricantes de semiconductores, elementos seguros y tarjetas inteligentes que necesitan un organismo notificado o un certificado europeo de ciberseguridad.
  • Equipos de seguridad de producto y PSIRT que deben cumplir los plazos de notificación del artículo 14.

Qué exige la norma

El Reglamento de Ciberresiliencia se aplica a los productos de hardware y software con elementos digitales que se comercializan en la UE. Es aplicable en su totalidad a partir del 11 de diciembre de 2027, pero las obligaciones de notificación del artículo 14 son aplicables desde el 11 de septiembre de 2026 (artículo 71) y alcanzan también a los productos introducidos en el mercado antes de diciembre de 2027 (artículo 69, apartado 3). Los productos deben cumplir los requisitos esenciales de ciberseguridad del anexo I, parte I, y los procesos del fabricante, los requisitos de gestión de vulnerabilidades del anexo I, parte II: nomenclatura de materiales de los programas informáticos (SBOM), pruebas de seguridad periódicas, una política de divulgación coordinada de vulnerabilidades, distribución segura de actualizaciones y actualizaciones de seguridad durante un período de soporte de al menos cinco años, salvo que se prevea que el producto se utilice durante menos tiempo (artículo 13, apartado 8).

La vía de evaluación de la conformidad depende de la clasificación. La mayoría de los productos pertenecen a la categoría por defecto y pueden acogerse al control interno (módulo A). Los productos importantes se enumeran en el anexo III, divididos en dos clases, y el Reglamento de Ejecución (UE) 2025/2392 recoge la descripción técnica de cada categoría. Los productos de la clase I solo pueden utilizar el módulo A si el fabricante ha aplicado íntegramente normas armonizadas, especificaciones comunes o un esquema europeo de certificación de la ciberseguridad con un nivel de garantía como mínimo «sustancial»; en otro caso interviene un organismo notificado mediante el examen de tipo UE (módulo B seguido del módulo C) o el aseguramiento de calidad total (módulo H) (artículo 32, apartado 2). Los productos de la clase II deben seguir los módulos B y C, el módulo H o dicho esquema de certificación (artículo 32, apartado 3). A los productos críticos del anexo IV, como los dispositivos de equipos informáticos con cajas de seguridad, las pasarelas de contadores inteligentes, las tarjetas inteligentes y los elementos seguros, se les puede exigir un certificado europeo de ciberseguridad en virtud del artículo 8, apartado 1; cuando no se les exija, siguen los procedimientos de la clase II (artículo 32, apartado 4).

La presunción de conformidad procede de las normas armonizadas cuyas referencias se hayan publicado en el Diario Oficial, de las especificaciones comunes y de los certificados europeos de ciberseguridad o declaraciones UE de conformidad en la medida en que cubran el anexo I (artículo 27). La Comisión pidió a CEN, CENELEC y ETSI que elaboraran esas normas mediante la Decisión de Ejecución C(2025) 618, de 3 de febrero de 2025: CEN y CENELEC dirigen las normas horizontales, y el comité técnico CYBER de ETSI desarrolla normas verticales, específicas de cada tipo de producto, en la serie EN 304 6xx. Una norma solo otorga presunción desde que su referencia se publica en el Diario Oficial; hasta entonces puede orientar el diseño y la documentación, pero no sustituye la vía de evaluación que corresponda a la clase del producto. Lo mismo ocurre con las evidencias obtenidas con IEC 62443-4-1 e IEC 62443-4-2: pueden mapearse al anexo I, pero no otorgan por sí solas presunción de conformidad. Sea cual sea la vía, el fabricante elabora la documentación técnica del anexo VII antes de introducir el producto en el mercado, firma la declaración UE de conformidad (artículo 28) y coloca el marcado CE. No somos organismo notificado ni emitimos certificados. Preparamos sus productos, procesos y documentación para la evaluación, con la experiencia que aporta nuestra participación en comités técnicos de CEN/CENELEC, grupos de trabajo de ISO, los grupos de trabajo ad hoc de ENISA del esquema EUCC y del esquema candidato EUMSS, y en ETSI, donde ingresamos como miembro de pleno derecho en 2026 para trabajar en el grupo EUSR del comité técnico CYBER. En una revisión financiada por la UE de tres proyectos de normas armonizadas del CRA, se incorporaron 34 de los 37 comentarios que presentamos.

Qué recibe

Informe de clasificación del producto

Análisis de la funcionalidad principal de cada producto frente al anexo III, el anexo IV y el Reglamento de Ejecución (UE) 2025/2392, incluidos los componentes integrados, como interfaces de red, sistemas operativos en tiempo real o microcontroladores de seguridad, con las vías de evaluación de la conformidad disponibles y si es necesario un organismo notificado.

Duración habitual: 1 a 2 semanas por familia de productos

Análisis de brechas frente al anexo I con plan de trabajo

Revisión del diseño, el código, la configuración y los procesos frente a cada requisito del anexo I, partes I y II, entregada como una lista priorizada de tareas de ingeniería que sus equipos pueden planificar.

Duración habitual: 4 a 8 semanas

Procedimiento de notificación del artículo 14 y política de divulgación coordinada

Criterios para identificar vulnerabilidades aprovechadas activamente e incidentes graves, funciones y escalado, plantillas para la alerta temprana de 24 horas, la notificación de 72 horas y el informe final, información a los usuarios conforme al artículo 14, apartado 8, y una política de divulgación coordinada de vulnerabilidades con un punto único de contacto.

Duración habitual: 3 a 5 semanas

SBOM y proceso de gestión de vulnerabilidades

Generación de la SBOM en un formato de uso común y legible por máquina desde su cadena de compilación, vigilancia de componentes, determinación documentada del período de soporte conforme al artículo 13, apartado 8, y las evidencias sobre distribución de actualizaciones que exige el anexo VII.

Duración habitual: 4 a 6 semanas

Correspondencia de IEC 62443 y EN 18031 con el CRA

Trazabilidad de sus evidencias de proceso conforme a IEC 62443-4-1, de componente conforme a IEC 62443-4-2 y, para los equipos radioeléctricos, de sus evaluaciones conforme a EN 18031 con cada requisito del anexo I, indicando las brechas que quedan, para reutilizar las evaluaciones existentes en lugar de repetirlas.

Duración habitual: 3 a 6 semanas

Estructura de la documentación técnica

Una estructura conforme al anexo VII para su producto, con la evaluación de riesgos de ciberseguridad, el índice de informes de ensayo, la lista de normas aplicadas y un borrador de declaración UE de conformidad según el anexo V, lista para completar y entregar al organismo notificado cuando intervenga uno.

Duración habitual: 3 a 4 semanas

Preguntas frecuentes

¿Es mi producto un producto importante de clase I o II y necesito un organismo notificado?

La clasificación depende de la funcionalidad principal del producto. La clase I del anexo III incluye, entre otros, los sistemas operativos, los enrutadores, módems y conmutadores, los sistemas de gestión de redes, los gestores de arranque y los microprocesadores y microcontroladores con funcionalidades relacionadas con la seguridad. La clase II comprende los hipervisores y sistemas de ejecución de contenedores, los cortafuegos, los sistemas de detección y prevención de intrusiones y los microprocesadores y microcontroladores resistentes a las manipulaciones. Los productos de la clase II siempre requieren la intervención de un tercero: módulos B y C, módulo H o un esquema europeo de certificación de la ciberseguridad con nivel de garantía como mínimo «sustancial» (artículo 32, apartado 3). Los de la clase I solo pueden acogerse al control interno si se han aplicado íntegramente normas armonizadas, especificaciones comunes o dicho esquema (artículo 32, apartado 2). Integrar un componente del anexo III no convierte por sí solo en importante el producto que lo incorpora (artículo 7, apartado 1): un controlador industrial no es un producto importante por llevar un microcontrolador de seguridad o una interfaz de red.

¿Bastan IEC 62443 o EN 18031 para demostrar la conformidad con el CRA?

No por sí solas. Según el artículo 27, apartado 1, la presunción de conformidad procede de las normas armonizadas cuyas referencias se han publicado en el Diario Oficial para el CRA. IEC 62443-4-1 encaja bien con los procesos de desarrollo y de gestión de vulnerabilidades del anexo I, parte II, e IEC 62443-4-2 con muchas de las propiedades de producto del anexo I, parte I. EN 18031-1, -2 y -3 son normas armonizadas de la Directiva 2014/53/UE sobre equipos radioeléctricos, publicadas con restricciones por la Decisión de Ejecución (UE) 2025/138, para los requisitos de ciberseguridad que el Reglamento Delegado (UE) 2022/30 aplica a determinados equipos radioeléctricos desde el 1 de agosto de 2025. El Reglamento Delegado (UE) 2026/339 deroga ese acto con efectos a partir del 11 de diciembre de 2027, porque los requisitos esenciales del CRA incluyen todos los elementos de esos requisitos radioeléctricos; desde entonces, los requisitos de ciberseguridad de esos equipos proceden del CRA. El considerando 30 del CRA pide que se tenga en cuenta el trabajo de EN 18031 en las normas armonizadas del CRA, por lo que es un buen punto de partida. Algunas obligaciones no tienen equivalente en ninguna de las dos series, como las notificaciones del artículo 14, el período de soporte mínimo del artículo 13, apartado 8, o la información al usuario del anexo II. Una matriz de trazabilidad le permite reutilizar esas evidencias en la documentación técnica y cerrar las brechas de forma explícita.

¿Qué hay que notificar en 24 horas según el CRA?

Desde el 11 de septiembre de 2026, los fabricantes deben notificar toda vulnerabilidad aprovechada activamente presente en sus productos, y todo incidente grave que repercuta en su seguridad, a través de la plataforma única de notificación establecida por la ENISA (artículos 14 y 16). La notificación se presenta a través del nodo final para notificaciones electrónicas del CSIRT designado como coordinador del Estado miembro de su establecimiento principal y es accesible simultáneamente para la ENISA. Para una vulnerabilidad aprovechada: alerta temprana en un plazo de 24 horas desde que se tenga conocimiento de ella, notificación de la vulnerabilidad en 72 horas e informe final a más tardar 14 días después de que se disponga de una medida correctora o paliativa. Para un incidente grave: alerta temprana en 24 horas, notificación del incidente en 72 horas e informe final en el plazo de un mes desde la notificación del incidente. La obligación alcanza también a los productos introducidos en el mercado antes del 11 de diciembre de 2027 (artículo 69, apartado 3), y debe informarse a los usuarios afectados (artículo 14, apartado 8).

¿Qué exige el CRA sobre la SBOM?

El anexo I, parte II, punto 1, exige una nomenclatura de materiales de los programas informáticos en un formato de uso común y legible por máquina que incluya, como mínimo, las dependencias de máximo nivel del producto. Forma parte de la documentación técnica (anexo VII, punto 2, letra b) y la autoridad de vigilancia del mercado puede pedirla mediante solicitud motivada. Publicarla es decisión suya: el anexo II solo exige indicar a los usuarios dónde consultarla si decide ponerla a su disposición. La Comisión puede concretar su formato y contenido mediante actos de ejecución (artículo 13, apartado 24). En la práctica generamos SPDX o CycloneDX desde la compilación y vamos más allá de las dependencias de primer nivel, porque la SBOM es la base de la vigilancia de vulnerabilidades.

¿Qué debe incluir la documentación técnica del CRA?

El anexo VII fija el contenido mínimo: una descripción general del producto y su finalidad prevista; información sobre diseño, desarrollo y producción, incluida la arquitectura del sistema; los procesos de gestión de vulnerabilidades, con la SBOM, la política de divulgación coordinada de vulnerabilidades y la solución de distribución de actualizaciones; la evaluación de riesgos de ciberseguridad exigida por el artículo 13; la información tenida en cuenta para fijar el período de soporte; las normas armonizadas u otras soluciones aplicadas; los informes de ensayo, y una copia de la declaración UE de conformidad. Se elabora antes de introducir el producto en el mercado, se mantiene actualizada durante el período de soporte (artículo 31) y se conserva al menos 10 años o durante el período de soporte, si este es más largo (artículo 13, apartado 13).

¿Se aplica el CRA a los componentes y proyectos de código abierto?

Si integra componentes de código abierto, sigue siendo responsable de ellos: el artículo 13, apartado 5, exige diligencia debida, y el artículo 13, apartado 6, obliga a comunicar al responsable del componente las vulnerabilidades que detecte y a subsanarlas. La persona jurídica distinta de un fabricante que da soporte de forma sostenida al desarrollo de productos libres y de código abierto destinados a actividades comerciales es un administrador de comunidad de programas informáticos de código abierto (artículo 3, punto 14). Estos administradores tienen un régimen más ligero, previsto en el artículo 24: una política de ciberseguridad documentada, cooperación con las autoridades de vigilancia del mercado y notificación de vulnerabilidades aprovechadas activamente en la medida en que participen en el desarrollo. No se les aplican multas administrativas (artículo 64, apartado 10).

¿Cómo se clasifican en el CRA las pasarelas industriales, los autómatas programables (PLC) y los dispositivos IoT?

El anexo III no contiene una categoría para los autómatas programables ni para los controladores industriales como tales, de modo que la clasificación depende de la funcionalidad principal de cada producto, leída a la luz de las descripciones técnicas del Reglamento de Ejecución (UE) 2025/2392. Un enrutador que controla el flujo de datos entre redes es de clase I, sea por cable, inalámbrico o virtual; la misma categoría abarca los módems celulares, los conmutadores gestionados y los puntos de acceso inalámbrico. Una pasarela cuya función principal sea convertir protocolos requiere un análisis más detallado frente a esa descripción. Las tarjetas de interfaz de red, controladores y adaptadores comercializados como productos, también para Fieldbus, son interfaces físicas de red (clase I); los sistemas operativos en tiempo real son sistemas operativos (clase I); las pasarelas de redes privadas virtuales y la gestión de accesos privilegiados que controla el acceso a sistemas informáticos o a tecnologías operativas también son de clase I, y los cortafuegos y los sistemas de detección y prevención de intrusiones son de clase II. Un microcontrolador solo es de clase I si sus funcionalidades de seguridad tienen por objeto proteger otros productos, redes o servicios más allá del propio microcontrolador. Un controlador cuya funcionalidad principal es el control no se convierte en producto importante por integrar uno de estos componentes (artículo 7, apartado 1), pero usted debe demostrar igualmente que el producto en su conjunto cumple el anexo I. Las máquinas sujetas al Reglamento (UE) 2023/1230 deben cumplir ambos reglamentos y seguir ambos procedimientos de evaluación de la conformidad; el considerando 53 del CRA indica que cumplir el CRA puede facilitar el cumplimiento de los requisitos de protección contra la corrupción y de seguridad y fiabilidad de los sistemas de control del anexo III, secciones 1.1.9 y 1.2.1, de ese Reglamento.

¿Son productos importantes en el CRA los lectores biométricos y los productos de identidad?

Sí, cuando esa es su funcionalidad principal. La clase I, punto 1, del anexo III comprende los «sistemas de gestión de la identidad y programas y equipos informáticos de gestión de accesos privilegiados, incluidos los lectores de autenticación y control de acceso, como los lectores biométricos». El Reglamento de Ejecución (UE) 2025/2392 describe los sistemas de gestión de identidad como productos que proporcionan mecanismos de autenticación o autorización, también para el acceso a recursos digitales o lugares físicos, y menciona los programas de inicio de sesión único, de gestión de identidades federadas, de contraseñas de un solo uso, de autenticación y de autenticación multifactor, así como los dispositivos de autenticación de equipos informáticos. Como productos de la clase I, solo pueden acogerse al control interno si se han aplicado íntegramente normas armonizadas, especificaciones comunes o un esquema europeo de certificación de la ciberseguridad con nivel de garantía como mínimo «sustancial» (artículo 32, apartado 2). Su servicio en la nube forma parte del producto si constituye tratamiento de datos a distancia: un programa diseñado y desarrollado por usted, o bajo su responsabilidad, sin el cual el producto no podría cumplir alguna de sus funciones (artículo 3, punto 2). Un servicio de registro o de cotejo que usted desarrolla y que su lector o su aplicación necesitan entra, por tanto, en el ámbito de aplicación; un servicio en la nube desarrollado fuera de su responsabilidad, no (considerando 12). Si el producto es además un sistema de IA de alto riesgo conforme al artículo 6 del Reglamento (UE) 2024/1689, cumplir el anexo I y hacerlo constar en la declaración UE de conformidad hace que se considere conforme con los requisitos de ciberseguridad del artículo 15 de ese Reglamento (artículo 12, apartado 1).