En los últimos meses, el Cyber Resilience Act (CRA) se ha convertido en un tema recurrente en conversaciones entre fabricantes, integradores y clientes finales. Sin embargo, sigue existiendo una confusión significativa sobre qué exige exactamente esta normativa y, en particular, sobre su impacto real en el hardware industrial.
¿Es una regulación sólo de software?
¿Obliga a rediseñar plataformas hardware existentes?
¿A quién afecta realmente dentro de la cadena de valor?
A continuación aclaramos qué dice el CRA, qué no dice, y cómo afecta de forma práctica a los sistemas industriales y embebidos.
Qué es el Cyber Resilience Act
El CRA es una normativa europea que establece requisitos obligatorios de ciberseguridad para los productos con elementos digitales que se introduzcan en el mercado de la Unión Europea.
Enlace oficial: https://digital-strategy.ec.europa.eu/es/policies/cyber-resilience-act
Este concepto es clave:
producto con elementos digitales ≠ solo software
Incluye:
- software,
- hardware que incorpora software o firmware,
- sistemas embebidos,
- equipos industriales, edge, networking, etc.
Por tanto, el hardware está formalmente dentro del alcance del CRA, aunque eso no implica automáticamente modificaciones físicas.
El error más común: “el CRA solo afecta al software”
Es cierto que muchas de las obligaciones del CRA se implementan a nivel software y de procesos, pero eso no convierte al hardware en irrelevante.
El CRA no exige que el hardware “sea seguro por sí mismo”, pero sí exige que permita implementar determinadas funciones de ciberseguridad.
Dicho de otra forma:
El hardware no siempre tiene que cambiar,
pero debe ser capaz de soportar los requisitos de seguridad exigidos.
Qué se espera realmente del hardware industrial bajo el CRA
En la práctica, el CRA no define componentes concretos ni arquitecturas específicas, pero sí exige que el producto, en su conjunto, pueda cumplir requisitos como los recogidos en el Anexo I de la normativa.
Desde el punto de vista del hardware, esto se traduce en capacidades habilitadoras, como por ejemplo:
- Soporte para secure boot o verificación de integridad de firmware
- Mecanismos que permitan actualizaciones seguras de firmware
- Capacidad de aislamiento básico y control de accesos, aunque se implemente por software
- Soporte para protección de integridad y disponibilidad del sistema
Si una plataforma hardware ya soporta estas capacidades, no es necesario rediseñarla para cumplir el CRA.
¿Cuándo sí podría ser necesario cambiar hardware?
Solo en un caso claro:
cuando la plataforma no puede soportar los requisitos mínimos de ciberseguridad.
Por ejemplo:
- hardware sin posibilidad de validar firmware,
- plataformas sin mecanismos de actualización segura,
- arquitecturas cerradas que impiden aplicar medidas de mitigación.
En estos casos, el impacto no viene impuesto directamente por el CRA, sino por la imposibilidad técnica de cumplirlo con esa plataforma.
El papel de IEC 62443‑4‑1 en el contexto del CRA
En eventos recientes como Embedded World en Núremberg, muchos fabricantes han comunicado su preparación frente al CRA apoyándose en la certificación IEC 62443‑4‑1. Este punto merece una aclaración importante.
La IEC 62443‑4‑1 no es una certificación de producto, ni equivale al cumplimiento directo del Cyber Resilience Act.
Se trata de un estándar que certifica que el fabricante sigue procesos de desarrollo seguro a lo largo del ciclo de vida del producto (Secure Development Lifecycle).
En la práctica, esta certificación demuestra que el fabricante:
- gestiona de forma estructurada los riesgos de ciberseguridad,
- aplica controles durante el desarrollo,
- dispone de procesos de gestión de vulnerabilidades y actualizaciones,
- mantiene trazabilidad y control del software y firmware.
Este enfoque está bien alineado con el espíritu del CRA, especialmente en lo relativo a:
- responsabilidad del fabricante,
- gestión de vulnerabilidades,
- mantenimiento de la seguridad durante el ciclo de vida.
Por este motivo, muchos fabricantes están utilizando IEC 62443‑4‑1 como base o evidencia parcial de su enfoque frente al CRA. No obstante, es importante subrayar que no exime por sí sola del cumplimiento de la normativa, ni sustituye al análisis concreto de cada producto.
En la práctica, esta certificación suele formar parte de la documentación de soporte, junto con explicaciones adicionales sobre cómo las plataformas hardware permiten implementar los requisitos exigidos por el CRA.
Impacto real por tipo de actor
Fabricantes
- Deben demostrar que sus productos permiten cumplir los requisitos de seguridad.
- Aportar documentación técnica y de procesos.
- Gestionar vulnerabilidades y actualizaciones durante el ciclo de vida.
Integradores
- Implementar correctamente las funciones de seguridad.
- Configurar y mantener los sistemas conforme al CRA.
- Justificar el cumplimiento en soluciones finales.
Distribuidores técnicos
- Acreditar que los productos suministrados son aptos para proyectos sujetos al CRA.
- Coordinar documentación entre fabricantes e integradores.
- Actuar como nexo técnico y regulatorio.
Entonces, ¿el CRA obliga a rediseñar el hardware?
La respuesta corta es:
No, en la mayoría de los casos.
La respuesta correcta es:
El CRA no obliga a modificar hardware existente
siempre que este ya permita implementar los requisitos de ciberseguridad exigidos.
Por eso, el impacto real del CRA está hoy más relacionado con:
- software,
- firmware,
- procesos,
- documentación,
- gestión del ciclo de vida.
Pero el hardware sigue siendo parte formal del alcance.
Conclusión
El Cyber Resilience Act no es una normativa “solo de software”, ni tampoco una obligación de rediseño masivo de hardware.
Es una regulación que exige responsabilidad técnica a lo largo de toda la cadena, y que obliga a entender bien qué capacidades debe ofrecer una plataforma hardware para poder cumplirla.
En este contexto, certificaciones de proceso como IEC 62443‑4‑1 se están consolidando como un punto de apoyo relevante, aunque no suficiente por sí mismo, para demostrar un enfoque coherente con los requisitos del CRA.
La clave no está en alarmarse, sino en analizar con rigor cada plataforma y su encaje real con la normativa.
