¿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).