CRA para automatización industrial: IEC 62443 y seguridad OT
El CRA en la automatización industrial y OT: alineación IEC 62443, por qué los PLC y SCADA suelen ser de categoría por defecto y qué eleva la clase.
En este artículo
- Resumen
- ¿Qué productos industriales están cubiertos?
- Alineación entre IEC 62443 y el CRA
- Retos de cumplimiento específicos de OT
- SBOM para sistemas industriales
- Evaluación de la conformidad para productos industriales
- Orientación por segmento industrial
- Hoja de ruta práctica de cumplimiento
- Qué se aplica y cuándo
- Recursos del sector
- Checklist para automatización industrial
- Preguntas frecuentes
La mayoría de los PLC, sistemas SCADA y productos DCS son productos estándar dentro del ámbito del CRA. No son automáticamente Importantes ni Críticos. La clasificación sigue la función principal del producto, no el sector en el que opera. Un PLC de control de producción se queda en categoría por defecto. Un PLC comercializado con un cortafuegos industrial integrado pasa a Clase II. La IEC 62443 te da una base técnica sólida para el CRA. La brecha que hay que cerrar es el SBOM: la IEC 62443 nunca lo exigió.
Esta guía aborda el cumplimiento CRA para fabricantes de automatización industrial.
Resumen
- La mayoría de los PLC, SCADA y DCS son productos estándar dentro del ámbito (categoría por defecto). Los productos con VPN, cortafuegos, IDS/IPS, enrutamiento o función de chip de seguridad como función principal comercializada pasan a categorías Importantes.
- La certificación IEC 62443 apoya el cumplimiento CRA de forma notable (no es equivalencia automática).
- Los entornos OT tienen retos propios de actualización y ciclo de vida.
- El periodo de soporte debe reflejar la vida útil esperada del producto (Artículo 13(8)). Cinco años es el mínimo, no un punto de partida de planificación.
- Los requisitos de SBOM se aplican a los sistemas de control industrial. La IEC 62443 no tiene un requisito equivalente.
- La integración seguridad funcional-ciberseguridad es crítica (IEC 62443 junto con IEC 61508 / ISO 13849).
Fuente: Reglamento (UE) 2024/2847, artículo 13(8) (periodo de soporte) y artículo 14(2)(a)(b)(c) (vía de vulnerabilidades explotadas activamente). El artículo 14 tiene dos vías de notificación paralelas: la vía de vulnerabilidades arriba indicada, y una vía de incidentes graves con cadencia de 24 h / 72 h / 1 mes (informe final en el plazo de un mes desde la notificación de incidente de 72 horas, conforme al artículo 14(4)(c)).
¿Qué productos industriales están cubiertos?
Ámbito del CRA en automatización industrial
El CRA se aplica a los «productos con elementos digitales» introducidos en el mercado de la UE. En automatización industrial esto incluye:
Claramente dentro del ámbito:
- PLC (controladores lógicos programables)
- PC industriales y HMI
- Software SCADA
- Sistemas DCS
- Sensores y pasarelas IoT industriales
- Routers y switches industriales
- Soluciones de acceso remoto
- Estaciones de ingeniería y software asociado
Pueden aplicarse exenciones:
- Productos exclusivos para seguridad nacional
- Productos diseñados para uso militar
- Sistemas industriales personalizados y únicos (pueden considerarse «piezas de repuesto»)
Clasificación CRA para productos industriales
La clasificación la determina la función principal comercializada, no el lugar donde está instalado el producto (Artículo 7(1)). Un PLC en una central nuclear es por defecto si su función principal es el control industrial. Un router en una oficina es Clase Importante I si se conecta a internet. El sector no determina la clase. La función sí.
| Clase | Qué la activa | Vía de conformidad | Ejemplos industriales |
|---|---|---|---|
| Crítica | La funcionalidad principal coincide con el Anexo IV: dispositivos hardware con cajas de seguridad; pasarelas de contadores inteligentes u otros dispositivos para fines de seguridad avanzada, incluido el criptoprocesamiento seguro; tarjetas inteligentes y elementos seguros | Esquema europeo de certificación; o Módulo B+C / Módulo H si no existe esquema aplicable (Art. 32(4)) | Un appliance hardware en una caja de seguridad a prueba de manipulaciones; pasarela de contador inteligente según la Directiva (UE) 2019/944; elemento seguro industrial o tarjeta inteligente |
| Importante Clase II | La función principal es: cortafuegos o IDS/IPS (Anexo III Clase II, elemento 2); microprocesador resistente a manipulaciones (elemento 3); microcontrolador resistente a manipulaciones (elemento 4) | Módulo B+C o Módulo H. Organismo notificado obligatorio. O un esquema de certificación de nivel de garantía «sustancial» (Art. 32(3)) | Cortafuegos industriales, IDS/IPS industriales; microprocesadores y microcontroladores resistentes a manipulaciones cuando el propio dispositivo es el producto de seguridad |
| Importante Clase I | La función principal es: VPN (elemento 5); gestión de red (elemento 6); SIEM (elemento 7); router, módem destinado a internet o switch (elemento 12); microprocesador relacionado con la seguridad (elemento 13) o microcontrolador (elemento 14) | Módulo A (autoevaluación) solo si se aplican íntegramente normas armonizadas o especificaciones comunes. En caso contrario, Módulo B+C o Módulo H (Art. 32(2)) | Productos con VPN como función principal; routers y switches industriales que se conectan a internet; productos construidos en torno a un microcontrolador relacionado con la seguridad |
| Por defecto (estándar dentro del ámbito) | Cualquier producto con elementos digitales que no encaje en una categoría superior. La mayoría de los PLC, SCADA y DCS caen aquí. | Módulo A: control interno, autoevaluación | PLC, software SCADA, DCS, la mayoría de pasarelas IIoT, PC industriales, HMI, estaciones de ingeniería |
Un PLC que contiene un microcontrolador con funcionalidades relacionadas con la seguridad no pasa él mismo a Importante Clase I por ese componente. El artículo 7(1) es explícito: «La integración de un producto con elementos digitales que tenga la funcionalidad principal de una categoría de producto del Anexo III no convertirá por sí sola al producto en el que esté integrado en sujeto a los procedimientos de evaluación de la conformidad [Importantes].» Comprueba qué es lo que el propio producto está diseñado y comercializado para hacer. Consulta la guía de clasificación de productos para el flujo de decisión completo.
Alineación entre IEC 62443 y el CRA
¿Qué es la IEC 62443?
La IEC 62443 es la serie internacional de normas para la seguridad de los sistemas de automatización y control industrial (IACS). Cubre:
- IEC 62443-4-1: ciclo de vida de desarrollo seguro.
- IEC 62443-4-2: requisitos de seguridad de componentes (4 niveles de seguridad, SL 1 a SL 4).
- IEC 62443-3-3: requisitos de seguridad de sistema.
- IEC 62443-2-4: requisitos para proveedores de servicios.
IEC 62443 ↔ cobertura CRA de un vistazo
- Proceso de gestión de vulnerabilidades
- Control de acceso
- Criptografía
- Registro de auditoría
- Capacidad de actualización
- Configuración segura por defecto
- Protección de datos
- Prueba de ausencia de vulnerabilidades conocidas
- SBOM
- Marcado CE / Declaración UE de Conformidad
- Notificación del Artículo 14
- Declaración del periodo de soporte
Dónde la evidencia IEC 62443 se corresponde directamente con los requisitos del CRA, dónde cubre solo parte de la obligación y dónde el CRA añade obligaciones nuevas.
Correspondencia IEC 62443 ↔ CRA
| Requisito del CRA | Cobertura IEC 62443 | Estado |
|---|---|---|
| Seguro por defecto | Requisitos de SL (4-2) | Parcial, el CRA es más estricto |
| Gestión de vulnerabilidades | 4-1 (SDL), 2-4 (mantenimiento) | Buena alineación |
| Actualizaciones de seguridad | 4-1, 2-4 | Alineación de procesos |
| Ausencia de vulnerabilidades conocidas | 4-1 (gestión de vulnerabilidades) | Proceso alineado |
| Protección de datos | 4-2 (confidencialidad) | Parcial |
| Control de acceso | 4-2 (autenticación, autorización) | Alineación fuerte |
| Criptografía | 4-2 (requisitos de cifrado) | Buena alineación |
| Registro de auditoría | 4-2 (registros de auditoría) | Buena alineación |
| Capacidad de actualización | 4-2 (actualización de firmware) | Alineación |
| SBOM | No está en IEC 62443 | Brecha |
| Marcado CE | No está en IEC 62443 | Brecha |
| Soporte de 5 años | No especificado | Brecha |
IEC 62443 como base, no como equivalencia
La certificación IEC 62443 NO implica automáticamente cumplimiento CRA. Úsala como base y evidencia, no como equivalencia.
Lo que aporta IEC 62443:
- Una base técnica de seguridad sólida.
- Un ciclo de vida de desarrollo seguro maduro.
- Capacidades de seguridad bien documentadas.
- Evidencia para la evaluación de la conformidad.
Lo que el CRA añade sobre IEC 62443:
- Requisitos de SBOM. La IEC 62443 no tiene un equivalente.
- Notificación de vulnerabilidades explotadas activamente: alerta temprana en 24 h, notificación de vulnerabilidad en 72 h, informe final en el plazo de 14 días tras la disponibilidad de una medida correctora o mitigadora. Tanto el CSIRT designado como coordinador como ENISA reciben las notificaciones simultáneamente a través de la Plataforma Única de Notificación de ENISA.
- Notificación de incidentes graves: mismas vías tempranas de 24 h / 72 h, pero el informe final vence en el plazo de un mes desde la notificación de incidente de 72 horas, no en 14 días. Un incidente es grave cuando afecta negativamente a la disponibilidad, autenticidad, integridad o confidencialidad de funciones importantes, o lleva a la ejecución de código malicioso (Artículo 14(5)).
- Notificación a usuarios: tras tener conocimiento de una vulnerabilidad explotada activamente o de un incidente grave, los fabricantes deben informar a los usuarios afectados y, cuando proceda, a todos los usuarios, de la vulnerabilidad o el incidente y de las medidas correctoras o de mitigación que puedan adoptar.
- Marcado CE y Declaración UE de Conformidad.
- Periodo de soporte que refleje la vida útil esperada del producto, con cinco años como mínimo conforme al Artículo 13(8) del CRA.
- Requisitos específicos de formato en la documentación (Anexo VII).
- Coordinación con la vigilancia del mercado.
Aprovechar IEC 62443 para el CRA
Si ya tienes certificación IEC 62443-4-1 o 4-2, no empiezas de cero. Tienes algo que la mayoría de los fabricantes de software no tiene: un SDL documentado y capacidades de seguridad probadas. La cuestión práctica es si la IEC 62443 acabará convirtiéndose en una norma armonizada CRA bajo el Mandato M/606. Si ocurre, los fabricantes de Clase Importante I podrían usar el Módulo A sin un Organismo Notificado. Eso aún no está resuelto. Consulta el seguimiento del estado de normas armonizadas antes de planificar tu vía de conformidad.
- Si cuentas con certificación IEC 62443-4-1. Reutiliza la documentación del SDL para el expediente técnico del CRA, demuestra tu ciclo de vida de desarrollo seguro y apórtala como evidencia del enfoque de evaluación de riesgos.
- Si cuentas con certificación IEC 62443-4-2. Reutiliza la documentación de capacidades de seguridad, asocia cada nivel de seguridad alcanzado con los requisitos esenciales del CRA y preséntala como evidencia de la implementación de funciones de seguridad.
- Añade por encima lo específico del CRA. Genera un SBOM, implementa la capacidad de notificación a ENISA para ambas vías de notificación, prepara la Declaración UE de Conformidad y aplica el marcado CE.
Retos de cumplimiento específicos de OT
Retos de actualización y parcheo
Los entornos industriales tienen restricciones particulares en las actualizaciones.
Retos:
- Operación 24/7 sin ventanas de mantenimiento.
- Revalidación de sistemas de seguridad funcional tras cada actualización.
- Integración con sistemas heredados.
- Entornos aislados (air-gapped) o semiconectados.
- Ciclos de cualificación largos.
Los requisitos del CRA siguen aplicándose:
- Se deben proporcionar actualizaciones de seguridad durante todo el periodo de soporte. El mínimo es cinco años, y más cuando se prevea que el producto estará en uso durante más tiempo (Artículo 13(8) del CRA).
- Debe existir un mecanismo para entregar actualizaciones. No se exige conectividad online continua, pero la capacidad debe existir.
- Las vulnerabilidades deben corregirse en un plazo razonable.
Las obligaciones de actualización son reales, pero el CRA no exige un canal de entrega específico. El reto es diseñar ese canal para que funcione dentro de las restricciones OT. Consulta la guía de actualizaciones de seguridad para la mecánica de entrega en arquitecturas embebidas, autónomas y aisladas.
- Despliegue por fases. Primero entornos de prueba, después líneas de producción piloto y finalmente despliegue completo con monitorización.
- Planificación de actualizaciones. Coordínate con el mantenimiento planificado, avisa con semanas o meses de antelación y da soporte a ciclos de actualización definidos por el cliente.
- Entrega fuera de línea. Paquetes de actualización por USB, servidores de actualización dentro de la red OT o mecanismos seguros de transferencia de archivos para emplazamientos aislados.
- Revalidación de la seguridad funcional. Documenta el impacto de la actualización sobre las funciones de seguridad, aporta guía de revalidación y considera la coingeniería seguridad-ciberseguridad.
Ciclos de vida de producto largos
Los productos industriales suelen tener ciclos de vida de 15 a 20 años o más, pero el CRA solo exige un mínimo de 5 años.
Las actualizaciones de seguridad y la gestión de vulnerabilidades están en vigor durante el periodo mínimo de soporte.
El fabricante puede seguir aportando actualizaciones de seguridad más allá del mínimo del CRA, sobre todo si el producto sigue en uso.
Actualizaciones limitadas. Una parte mayor del riesgo operativo pasa al cliente.
Responsabilidad del cliente. Comunica con claridad la fecha de fin de soporte en el punto de venta.
El periodo de soporte debe reflejar el tiempo durante el que se prevé que el producto estará en uso, teniendo en cuenta las expectativas razonables del usuario, la naturaleza y el propósito previsto del producto, y el derecho de la Unión pertinente. Cinco años es el mínimo absoluto. Para productos con ciclos de uso desplegado de 15 a 20 años, cinco años es el punto de partida, no el plan. Planifica el periodo de soporte desde la perspectiva del cliente, no desde el mínimo del CRA.
Necesidades de documentación:
- Comunica con claridad el periodo de soporte en la compra.
- Aporta una fecha de fin de soporte.
- Documenta las responsabilidades del cliente tras el fin del soporte.
Integración seguridad funcional y ciberseguridad
Los productos industriales suelen tener requisitos de seguridad funcional (niveles SIL según IEC 61508 / ISO 13849). El CRA añade requisitos de ciberseguridad.
Modelado de amenazas combinado de seguridad funcional y ciberseguridad. Trata las amenazas cibernéticas sobre funciones de seguridad como un modo de fallo de primer nivel.
Los requisitos de seguridad funcional (SIL 1 a SIL 4) y los de ciberseguridad (SL 1 a SL 4) conviven en paralelo. Ninguna medida de ciberseguridad debe comprometer la seguridad funcional.
La validación de seguridad funcional, las pruebas de ciberseguridad y los escenarios combinados se ejecutan antes del lanzamiento. Cada disciplina firma su aprobación de forma independiente.
Revalidación de seguridad funcional tras parches de ciberseguridad. Evaluación de ciberseguridad ante cambios de seguridad funcional. Ambos ciclos son obligatorios, no opcionales.
Ninguna medida de ciberseguridad debe comprometer la seguridad funcional. Cuando ambas disciplinas entran en conflicto, gana la seguridad funcional y se rediseña la medida de ciberseguridad.
SBOM para sistemas industriales
Retos de identificación de componentes
Los productos industriales contienen a menudo:
- Sistemas operativos en tiempo real (RTOS).
- Firmware propietario.
- Librerías de terceros (pilas OPC UA, MQTT, Modbus).
- Componentes de hardware con firmware.
- Componentes de software. RTOS y kernel, pilas de protocolo (OPC UA, Modbus, EtherNet/IP, PROFINET), librerías de seguridad (TLS, criptografía), middleware de terceros y software de aplicación.
- Firmware y componentes de hardware. Cargador de arranque, firmware de dispositivo y componentes programables en campo. Los productos industriales suelen tener componentes de hardware con firmware embebido que deben incluirse en el SBOM. Un HBOM (Hardware Bill of Materials) documenta los componentes de hardware y su firmware asociado. Valora si tu producto necesita uno junto al SBOM de software.
- Profundidad. Los componentes principales están bajo control del fabricante; solicita el SBOM a los proveedores para los componentes de terceros y llega tan profundo como sea prácticamente posible en los componentes anidados.
Complejidad de la cadena de suministro
Los productos industriales suelen tener cadenas de suministro complejas.
Tu software y firmware. SBOM completo obligatorio.
Componentes de terceros. Solicita el SBOM a cada proveedor e inclúyelo en el tuyo.
Componentes dentro de componentes. Inclusión en la medida de lo posible. Documenta las limitaciones conocidas.
Acciones:
- Actualiza los acuerdos con proveedores para incluir requisitos de SBOM.
- Establece un formato de intercambio de SBOM con los proveedores.
- Crea un proceso de integración de SBOM.
- Documenta las limitaciones de la cadena de suministro.
Evaluación de la conformidad para productos industriales
Módulo B+C (examen UE de tipo)
Para productos industriales de Clase Importante II:
- Módulo B, examen de tipo. El organismo notificado examina la integridad del expediente técnico, la idoneidad de la evaluación de riesgos, la cobertura de los requisitos de ciberseguridad, cualquier certificación IEC 62443 presentada como evidencia, la calidad del SBOM y los resultados de pruebas. Entregable: un certificado de examen UE de tipo.
- Módulo C, conformidad con el tipo. El fabricante garantiza que la producción coincide con el tipo examinado, mantiene el control interno de calidad de la producción y conserva la documentación actualizada. Entregable: una autodeclaración de conformidad con el tipo.
Uso de la certificación IEC 62443
Si cuentas con certificación IEC 62443-4-2:
- Preséntala al organismo notificado. Aporta el certificado IEC 62443-4-2, el nivel de seguridad alcanzado (SL 1 a SL 4), el certificado ISASecure si procede y el informe de evaluación.
- Evaluación del organismo notificado. El organismo reconoce IEC 62443 como evidencia, verifica la cobertura de los requisitos del CRA, identifica brechas y puede reducir el alcance de las pruebas.
- Evidencia adicional todavía necesaria. SBOM (no cubierto por IEC 62443), capacidad de notificación a ENISA para ambas vías de notificación, compromiso documentado de soporte que refleje la vida útil esperada del producto (mínimo de cinco años conforme al Artículo 13(8)) y documentación de usuario.
Orientación por segmento industrial
| Tipo de producto | Clase CRA típica | Requisitos clave | Alineación IEC 62443 | Puntos de atención |
|---|---|---|---|---|
| Tipo de productoPLC y controladores | Clase CRA típicaPor defecto (estándar dentro del ámbito) en la mayoría de los casos. Un PLC con VPN integrada, cortafuegos o IDS/IPS como función principal comercializada pasa a Importante. | Requisitos claveCapacidad de arranque seguro, comunicaciones cifradas, autenticación robusta, registro de auditoría, mecanismo de actualización de firmware, SBOM para firmware y runtime. | Alineación IEC 62443IEC 62443-4-2 SL2+ se corresponde bien con los requisitos esenciales; documenta las capacidades de seguridad y prueba las funciones de seguridad como evidencia. | Puntos de atenciónRestricciones de tiempo real frente al procesamiento de ciberseguridad; protección de funciones de seguridad funcional; soporte de protocolos heredados (Modbus y similares); no confundir la clase del PLC con la de los componentes del Anexo III que contiene. |
| Tipo de productoSoftware SCADA / DCS | Clase CRA típicaPor defecto (estándar dentro del ámbito) en la mayoría de los casos. El SCADA y el DCS no figuran en el Anexo III. Si la función principal del producto es un sistema de gestión de red o una monitorización de seguridad similar a un SIEM, se justifica un análisis de Clase Importante I. | Requisitos claveArquitectura segura, control de acceso basado en roles, comunicaciones cifradas, traza de auditoría, mecanismo de actualización, SBOM para todos los componentes. | Alineación IEC 62443Relaciona el control de acceso basado en roles, la auditoría, la actualización y los controles de comunicación con los requisitos de sistema y componente de IEC 62443. | Puntos de atenciónSeguridad de la base de datos, configuración de seguridad de OPC UA, protección de datos del historiador, seguridad del acceso remoto. |
| Tipo de productoPasarelas IoT industriales | Clase CRA típicaDepende del caso. Una pasarela cuya función principal comercializada sea VPN, enrutamiento conectado a internet o gestión de red puede ser Clase Importante I. Una pasarela que principalmente recoge y reenvía datos de sensores probablemente es por defecto. | Requisitos claveArranque seguro, soporte de segmentación de red, protocolos cifrados (MQTT-TLS y similares), autenticación de dispositivo, mecanismo de actualización de firmware, SBOM. | Alineación IEC 62443Usa IEC 62443-4-2 para las funciones de seguridad de componentes y documenta las hipótesis de segmentación de la pasarela. | Puntos de atenciónSeguridad en edge computing, seguridad de la conectividad con la nube, seguridad de la traducción de protocolos, filtrado y validación de datos. |
Hoja de ruta práctica de cumplimiento
Fase 1: Evaluación
Inventario de productos.
- Enumera todos los productos con elementos digitales.
- Clasifícalos según las categorías del CRA.
- Identifica los productos de Clase Importante II.
Certificaciones existentes.
- Enumera las certificaciones IEC 62443.
- Asócialas a los requisitos del CRA.
- Identifica las brechas.
Análisis de brechas.
- Capacidad de SBOM.
- Preparación para la notificación de vulnerabilidades.
- Planificación del soporte de 5 años.
- Brechas de documentación.
Fase 2: Preparación
Técnico.
- Implanta la generación de SBOM.
- Establece un proceso de gestión de vulnerabilidades.
- Prepara la capacidad de notificación a ENISA.
- Actualiza las bases de ciberseguridad del producto.
Documentación.
- Estructura del expediente técnico.
- Actualización de la documentación de ciberseguridad.
- Guía de usuario para despliegue seguro.
- Comunicación del periodo de soporte.
Comercial.
- Definición del periodo de soporte.
- Actualización de contratos con clientes.
- Revisión de precios cuando el coste de cumplimiento sea elevado.
Fase 3: Cumplimiento
A partir del 11 de septiembre de 2026.
- Notificación de vulnerabilidades operativa.
- Plataforma única de notificación en uso.
Durante 2027.
- Completa las evaluaciones de la conformidad.
- Contacta con organismos notificados (Clase Importante II).
- Obtén certificados de examen UE de tipo.
- Actualiza toda la documentación del producto.
Para el 11 de diciembre de 2027.
- Todos los productos en ámbito cumplen con el CRA.
- Marcado CE aplicado.
- Comunicación a clientes completada.
Qué se aplica y cuándo
Productos ya en el mercado
Si tu producto fue puesto en el mercado de la UE antes del 11 de diciembre de 2027, no necesitas incorporar una evaluación de la conformidad, un expediente técnico ni el marcado CE. El corte es la fecha de puesta en el mercado, no la de fabricación. Una unidad de una línea de producto existente que pongas en el mercado de la UE a partir del 11 de diciembre de 2027 debe cumplir íntegramente el CRA en el punto de venta.
La exención transitoria no cubre la notificación de vulnerabilidades. A partir del 11 de septiembre de 2026, debes notificar las vulnerabilidades explotadas activamente y los incidentes graves de todos los productos en ámbito de los que tengas conocimiento, incluidos los productos ya en el mercado. También debes informar a los usuarios afectados de las vulnerabilidades y las medidas correctoras que pueden adoptar. Una base instalada amplia no es una exención.
Modificación de un producto existente
Una modificación es sustancial si afecta al cumplimiento de los requisitos esenciales de ciberseguridad o cambia el propósito previsto contra el que se evaluó el producto. Un producto modificado de forma sustancial vuelve a entrar en pleno cumplimiento del CRA desde el momento en que se pone de nuevo en el mercado. La persona que realiza la modificación y pone el producto de nuevo en el mercado se convierte en fabricante a efectos del CRA. Esto es relevante para los integradores de sistemas OT que modifican y revenden productos de terceros.
La definición existe en el Reglamento. Cómo se aplica a modificaciones OT específicas todavía requiere orientación de la Comisión.
Productos de Clase II y Críticos: empieza a buscar un Organismo Notificado ahora
Se espera que los Estados miembros tengan suficiente capacidad de organismos notificados para diciembre de 2026. La capacidad puede seguir siendo limitada en el primer periodo de transición. Un retraso en asegurar un Organismo Notificado retrasará tu calendario de marcado CE. No lo dejes para 2027.
Recursos del sector
Organismos de normalización
- IEC (Comisión Electrotécnica Internacional). Serie IEC 62443. iec.ch
- ISA (International Society of Automation). Desarrollo de ISA/IEC 62443 y programa de certificación ISASecure. isa.org
- NAMUR (Asociación de la industria de procesos). Recomendaciones NE para ciberseguridad OT. namur.net
- NIST. Cybersecurity Framework, SP 800-82 (guía de ciberseguridad OT). nist.gov
Asociaciones sectoriales
| Asociación | Enfoque | Web |
|---|---|---|
| ZVEI (Alemania) | Industria eléctrica | zvei.org |
| ORGALIM | Ingeniería europea | orgalim.eu |
| VDMA (Alemania) | Maquinaria | vdma.org |
| GAMBICA (Reino Unido) | Automatización industrial | gambica.org.uk |
| ODVA | Redes industriales | odva.org |
Si fabricas maquinaria con elementos digitales, consulta nuestra guía para fabricantes de maquinaria con orientación específica sobre el doble cumplimiento con el CRA y el Reglamento de Máquinas de la UE.
Checklist para automatización industrial
Clasificación del producto
- Clasificación determinada (Por defecto / Importante I / Importante II).
- Ruta de evaluación de la conformidad seleccionada.
- Organismo notificado identificado, si procede.
Certificaciones existentes
- IEC 62443-4-1 (SDL).
- IEC 62443-4-2 (seguridad de componentes).
- Certificación ISASecure.
- Asociadas a los requisitos del CRA.
Cumplimiento técnico
- Configuración segura por defecto.
- Mecanismo de actualización seguro.
- Capacidad de generación de SBOM.
- Proceso de gestión de vulnerabilidades documentado y operativo.
- Política de divulgación coordinada de vulnerabilidades (CVD) publicada.
- Plataforma Única de Notificación de ENISA (SRP) registrada y notificación probada. Cubre tanto la vía de vulnerabilidades explotadas activamente (informe final en 14 días) como la vía de incidentes graves (informe final en 1 mes).
- Proceso de notificación a usuarios en vigor para vulnerabilidades e incidentes graves (Artículo 14(8)).
Documentación
- Expediente técnico preparado.
- Evaluación de riesgos documentada.
- Arquitectura de ciberseguridad documentada.
- Guía de ciberseguridad para el usuario preparada.
Ciclo de vida
- Periodo de soporte definido.
- Mecanismo de entrega de actualizaciones.
- Planificación de fin de vida.
- Proceso de revalidación de seguridad funcional ante actualizaciones.
Cadena de suministro
- Requisitos de SBOM para proveedores.
- Evaluación de ciberseguridad de los componentes.
- Documentación de la cadena de suministro.
Vender a entidades esenciales NIS 2 puede elevar las expectativas de riesgo y de evidencia, pero no cambia la clase CRA del producto. La clase sigue dependiendo de la funcionalidad principal del producto conforme a los Anexos III y IV (Artículo 7(1)).
Si ya tienes certificación IEC 62443, llevas ventaja frente a la mayoría de los fabricantes de software que se enfrentan al CRA. El SDL, los controles de acceso, el registro de auditoría y el proceso de gestión de vulnerabilidades se trasladan directamente. El trabajo real son las tres cosas que la IEC 62443 nunca requirió: un SBOM, un canal formal de notificación a ENISA y un compromiso de periodo de soporte publicado. Esas brechas son reales, pero son manejables.
Preguntas frecuentes
¿La certificación IEC 62443 equivale al cumplimiento CRA?
No. La certificación IEC 62443 no implica automáticamente cumplimiento CRA. Aporta una base técnica de ciberseguridad sólida y evidencia que un organismo notificado puede reutilizar, pero el CRA añade obligaciones que IEC 62443 no cubre: requisitos de SBOM, notificación de incidentes a ENISA según el artículo 14, marcado CE y declaración UE de conformidad, y un compromiso de soporte mínimo de 5 años.
¿Qué productos de automatización industrial entran en Clase Importante II?
Los cortafuegos industriales, los sistemas IDS/IPS industriales y los microprocesadores y microcontroladores resistentes a manipulaciones (cuando el propio dispositivo es el producto de seguridad) pertenecen a la Clase Importante II, que requiere evaluación de la conformidad por un tercero (normalmente Módulo B+C o Módulo H). Los microcontroladores y microprocesadores con funcionalidades relacionadas con la seguridad, y los routers y módems industriales destinados a la conexión a internet, son Clase Importante I. Para los productos Críticos, el Anexo IV cubre tres categorías: dispositivos hardware con cajas de seguridad (elemento 1), pasarelas de contadores inteligentes y otros dispositivos para fines de seguridad avanzada con criptoprocesamiento seguro (elemento 2), y tarjetas inteligentes y elementos seguros (elemento 3). Cada categoría requiere su propio análisis del Anexo IV. Consulta la guía de clasificación de productos para el flujo de decisión completo.
¿Se aplica el soporte mínimo de 5 años del CRA también a productos con ciclos de vida industriales de 15 a 20 años?
Sí. Cinco años es el mínimo. Cuando cabe esperar razonablemente que el producto esté en uso durante más tiempo, el fabricante debe fijar un periodo de soporte mayor que refleje esa vida útil. Los productos industriales con ciclos de 15 a 20 años suelen necesitar planificar soporte muy por encima del mínimo de 5 años y comunicar con claridad la fecha de fin de soporte en el punto de venta.
¿Cómo se gestionan las actualizaciones de ciberseguridad del CRA en entornos OT sin ventanas de mantenimiento?
Combina un despliegue por fases (prueba, piloto, producción completa), ventanas de actualización coordinadas con el mantenimiento planificado, mecanismos de entrega fuera de línea como paquetes USB o servidores de actualización dentro de la red OT, y una revalidación de seguridad funcional documentada para cada actualización. El CRA no exige conectividad online continua, pero sí que exista un mecanismo para entregar actualizaciones y que las vulnerabilidades se corrijan en un plazo razonable.
¿Qué requisitos del CRA no están cubiertos por IEC 62443?
La IEC 62443 no exige un SBOM. El CRA sí. Tampoco cubre las dos vías de notificación del artículo 14 del CRA: la vía de vulnerabilidades explotadas activamente (alerta temprana de 24 h, notificación de 72 h, informe final en el plazo de 14 días tras la disponibilidad de una medida correctora) y la vía de incidentes graves (alerta temprana de 24 h, notificación de 72 h, informe final en el plazo de un mes desde la notificación de 72 horas). Tras tener conocimiento de cualquiera de los dos, debes informar a los usuarios afectados y, cuando proceda, a todos los usuarios, de la vulnerabilidad o el incidente y de las medidas correctoras disponibles. El marcado CE con Declaración UE de Conformidad y un periodo de soporte documentado que refleje la vida útil esperada del producto también son obligatorios. La evidencia IEC 62443 puede respaldar tu expediente técnico, pero ninguna de estas obligaciones está cubierta por la norma. Mantenemos «reporte» como sinónimo cuando hablamos del informe final al regulador.
¿Puede la certificación IEC 62443-4-2 reducir el alcance de las pruebas del organismo notificado?
Sí, es posible. Un organismo notificado que reconozca IEC 62443-4-2 como evidencia verificará la cobertura de los requisitos del CRA, identificará brechas y podrá reducir el alcance de las pruebas en consecuencia. Presenta el certificado, el nivel de seguridad alcanzado (SL 1 a SL 4), cualquier certificado ISASecure y el informe de evaluación. Aun así tendrás que aportar evidencia de SBOM, capacidad de notificación a ENISA para ambas vías de notificación, un compromiso de soporte que refleje la vida útil esperada del producto y documentación de usuario. Consulta la guía de decisión para la evaluación de la conformidad con la comparativa completa de módulos.
Nuestro PLC no tiene conexión a internet. ¿Sigue dentro del ámbito del CRA?
La mayoría de los PLC aislados (air-gapped) siguen dentro del ámbito. La prueba de ámbito del CRA se basa en el propósito previsto del producto o en el uso razonablemente previsible, no en cómo está conectado en tiempo de ejecución. Un PLC con un puerto de programación Ethernet o una interfaz USB está dentro del ámbito aunque nunca toque una red activa en su despliegue. Muy pocos productos industriales carecen por completo de cualquier capacidad de conexión.
Estar aislado es una medida de reducción de riesgos. Pertenece a tu evaluación de riesgos de seguridad. No elimina la obligación del CRA.
La cuestión de la conectividad a internet solo importa para la clasificación. Si un router o módem es Clase Importante I depende de si está destinado a conectarse a internet. Es una regla de clasificación. No tiene ningún efecto sobre si tu PLC está dentro del ámbito.
Este artículo tiene carácter informativo y no constituye asesoramiento jurídico. Para orientación específica de cumplimiento, consulta a asesores legales cualificados.
Artículos Relacionados
ENISA e IA de frontera: 5 consecuencias para el CRA
CRA para fabricantes alemanes: BSI, CERT-Bund y marcado CE
¿Se aplica el CRA a tu producto?
Responde 6 preguntas sencillas para saber si tu producto está dentro del ámbito del Reglamento de Ciberresiliencia de la UE. Obtén tu resultado en menos de 2 minutos.
¿Listo para lograr el cumplimiento del CRA?
Empieza a gestionar tus SBOMs y documentación de cumplimiento con CRA Evidence.