Ley de Resistencia Cibernética: Qué deben hacer ya los fabricantes

7 min de lectura

La Ley de Resistencia Cibernética de la UE (CRA, por sus siglas en inglés) entró en vigor en diciembre de 2024 y afecta a todo fabricante que introduzca en el mercado europeo productos con elementos digitales. A partir de septiembre de 2026 entrarán en vigor las primeras obligaciones de notificación; a partir de diciembre de 2027, todos los productos deberán cumplir los nuevos requisitos de ciberseguridad. Para la pequeña y mediana industria productora, esto significa lo siguiente: cada sensor conectado, cada sistema de control de maquinaria y cada componente de software queda sujeto al alcance del reglamento. El tiempo para actuar se está agotando.

Lo más importante

Qué regula la CRA y a quién afecta

La Ley de Resistencia Cibernética es el primer reglamento de la UE que introduce requisitos vinculantes de ciberseguridad para todos los productos con elementos digitales. Su ámbito de aplicación es intencionadamente amplio: abarca tanto hardware conectado – como routers, dispositivos para el hogar inteligente y sensores industriales IoT – como software puro, incluidas aplicaciones, sistemas operativos y firewalls.

Para la pequeña y mediana industria productora, esto tiene consecuencias de gran alcance. Todo sistema de control de maquinaria con conexión de red, cualquier sensor con función de actualización de firmware y todo sistema embebido en una instalación de producción quedan sujetos a esta normativa.

Particularmente relevante para la PYME: también los importadores y distribuidores que introducen productos en el mercado de la UE asumen obligaciones propias. Quien importe un módulo IoT chino y lo comercialice bajo su propia marca será considerado fabricante y deberá demostrar el cumplimiento íntegro de la CRA. Esto afecta a numerosos fabricantes de maquinaria y a integradores de sistemas que incorporan componentes procedentes de terceros países en sus soluciones propias.

Incluso quienes no fabrican dichos productos directamente, sino que los integran en sus propias soluciones, asumen como integradores obligaciones de cumplimiento.

Quedan excluidas únicamente algunas categorías: productos sanitarios (ya regulados por el Reglamento MDR), vehículos de motor (regulación UNECE), tecnología aeroespacial y determinados productos de seguridad nacional. El software de código abierto solo queda sujeto a la norma si se comercializa con fines comerciales.

«La CRA garantiza que los productos de hardware y software lleguen al mercado con menos vulnerabilidades y que los fabricantes tomen en serio la seguridad durante todo el ciclo de vida del producto.»
– Comisión Europea, comunicado de prensa sobre la CRA, septiembre de 2022

Las tres fechas límite: qué entra en vigor y cuándo

La CRA entró en vigor el 10 de diciembre de 2024 y se aplica progresivamente en tres fases. La primera fecha límite llega más rápido de lo que muchas empresas esperan.

11 de junio de 2026: Entrará en vigor la notificación de los organismos de evaluación de la conformidad. A partir de esta fecha, las autoridades nacionales deberán haber designado los organismos de evaluación autorizados para examinar los productos de alto riesgo (categorías I y II).

11 de septiembre de 2026: Comienzan las obligaciones de notificación de vulnerabilidades y sucesos de seguridad. Los fabricantes deben informar a la ENISA sobre vulnerabilidades activamente explotadas dentro de las 24 horas. En caso de sucesos de seguridad graves, el plazo de notificación es de 72 horas. Esta obligación entra en vigor seis meses antes de la aplicación completa y constituye para muchas empresas la primera fecha límite estricta.

11 de diciembre de 2027: Aplicación total de todos los requisitos. A partir de esta fecha, únicamente podrán comercializarse en el mercado de la UE productos conformes con la CRA y provistos de la marca CE. Los productos que ya estuvieran en el mercado antes de dicha fecha y que no hayan sido sustancialmente modificados gozarán de protección de la situación existente.

Categorías de productos: estándar, importante, crítico

La CRA clasifica los productos en tres clases de riesgo, que determinan cómo debe realizarse la evaluación de la conformidad. Esta clasificación tiene impacto directo en el esfuerzo y los costes requeridos.

Productos estándar (aproximadamente el 90 % de todos los productos): Incluyen sensores IoT sencillos, dispositivos para el hogar inteligente sin funciones de seguridad, software para consumidores y equipos de oficina. Los fabricantes pueden demostrar la conformidad mediante una autoevaluación. No se requiere ningún evaluador externo.

Productos importantes (categoría I): Sistemas operativos, firewalls, routers, software VPN y sistemas de gestión de redes. Aquí es necesaria bien una evaluación conforme a normas armonizadas, bien una evaluación por parte de un tercero.

Productos críticos (categoría II): Módulos de seguridad hardware, pasarelas de contadores inteligentes, sistemas de control industrial e infraestructuras de clave pública. Aquí es obligatoria una evaluación de la conformidad por parte de un tercero, llevada a cabo por un organismo notificado.

Qué deben implementar concretamente los fabricantes

Los requisitos de la CRA se dividen en tres ámbitos: desarrollo seguro, gestión de vulnerabilidades y documentación.

Seguridad desde el diseño (Security by Design): Los productos deben desarrollarse desde su concepción según el principio de «seguro por defecto» (Secure by Default). Esto implica: superficie de ataque mínima, comunicación cifrada, ausencia de contraseñas codificadas de forma fija y mecanismos seguros de actualización. Los fabricantes deben demostrar que la seguridad no se añade posteriormente, sino que se integra desde el inicio.

Gestión de vulnerabilidades: Los fabricantes deben proporcionar actualizaciones de seguridad durante todo el ciclo de vida del producto, y al menos durante cinco años tras su puesta en el mercado. Las vulnerabilidades activamente explotadas deben notificarse a la ENISA dentro de las 24 horas. Esto exige un proceso PSIRT funcional (Equipo de Respuesta a Incidentes de Seguridad de Productos).

Documentación técnica: Para cada producto debe existir una documentación exhaustiva: análisis de riesgos, descripción de la arquitectura de seguridad, informes de ensayos, SBOM (lista de materiales de software) y una declaración de conformidad con la UE.

Un aspecto que suele subestimarse es la obligación de proporcionar gratuitamente actualizaciones de seguridad durante al menos cinco años. Para los fabricantes de componentes industriales cuyos ciclos de vida abarcan entre diez y veinte años, esto supone un compromiso a largo plazo considerable. Quien hoy ponga en circulación un módulo de control conectado debe garantizar que en 2032 aún pueda parchearse de forma segura. Esto exige una arquitectura de software sostenible y una infraestructura de actualización funcional que vaya mucho más allá del ciclo de vida típico del producto.

En la práctica, esto implica también que los fabricantes deben replantearse sus relaciones con los proveedores. Si una biblioteca de código abierto integrada en un producto deja de recibir mantenimiento, el fabricante deberá desarrollar él mismo los parches o sustituir el componente. La SBOM se convierte aquí en un sistema de alerta temprana: muestra qué dependencias existen y dónde se ocultan los riesgos.

La SBOM resulta especialmente relevante porque debe enumerar todos los componentes de software, incluidas las bibliotecas de código abierto.

SBOM: Por qué la lista de materiales de software se convierte en un factor decisivo

La lista de materiales de software (SBOM, por sus siglas en inglés) es uno de los instrumentos centrales novedosos de la CRA. En la práctica, equivale a la lista de ingredientes de un alimento: enumera cada componente de software integrado en un producto. Para muchas PYME, esto representa un reto, dado que las dependencias en las pilas de software modernas son complejas.

Un sistema embebido típico en un sistema de control de maquinaria contiene un sistema operativo en tiempo real, bibliotecas de comunicación, módulos criptográficos y decenas de componentes adicionales, muchos de los cuales se incorporan como código abierto. Cada uno de estos componentes puede contener vulnerabilidades que el fabricante debe conocer y tener bajo control.

La buena noticia: existen estándares y herramientas consolidados. CycloneDX y SPDX son los dos formatos SBOM líderes. Herramientas de construcción como Syft o Grype generan automáticamente SBOMs a partir del repositorio de código. Para las empresas que ya utilizan pipelines CI/CD, la creación de SBOMs puede integrarse en el proceso de construcción existente sin interrumpir el flujo de trabajo de desarrollo.

Para las empresas que no desarrollan software propio y adquieren componentes de proveedores, la regla es: solicite a sus proveedores una SBOM. La CRA traslada la responsabilidad a lo largo de la cadena de suministro. Quien integre componentes sin SBOM en sus propios productos asume personalmente la responsabilidad por vulnerabilidades desconocidas.

Cuál es el coste concreto de la CRA para la PYME

Los costes de cumplimiento dependen en gran medida de la categoría del producto y del grado de madurez de los procesos de seguridad existentes. Para productos estándar sometidos a autoevaluación, los expertos del sector estiman unos costes únicos de entre 20.000 y 50.000 euros por línea de productos, principalmente para documentación, análisis de riesgos y elaboración de la SBOM.

Para los productos de las categorías I y II, que requieren una evaluación externa, los costes aumentan a entre 80.000 y 200.000 euros. Además, hay costes recurrentes derivados de la gestión de vulnerabilidades: un proceso PSIRT dedicado con monitorización, desarrollo de parches y notificaciones a la ENISA requiere al menos media jornada laboral completa, y en la práctica suele exigir más.

La contrapartida: según el BSI, los costes medios de un incidente de ciberseguridad en la PYME ascienden a 500.000 euros. Un único suceso grave supera los costes de cumplimiento durante varios años. Además, existe la ventaja competitiva del acceso al mercado: quien cumpla con la CRA podrá comercializar sus productos en toda Europa sin restricciones, mientras que los competidores no conformes quedarán excluidos del mercado.

CRA, NIS2 y Reglamento sobre Inteligencia Artificial: la tríada regulatoria

La CRA no existe de forma aislada. Junto con NIS2 (seguridad de las redes y de la información) y el Reglamento sobre Inteligencia Artificial, forma una tríada regulatoria que afecta simultáneamente a las empresas europeas. Para la PYME, esto significa: identificar las superposiciones y aprovechar las sinergias.

NIS2 obliga a los operadores de infraestructuras críticas e importantes a gestionar los riesgos y notificar los incidentes. La CRA obliga a los fabricantes de los productos que dichos operadores emplean. Así pues, quien fabrique sensores IoT para empresas suministradoras de energía o software de control para plantas de tratamiento de agua deberá cumplir tanto con la CRA respecto a sus propios productos como con los requisitos NIS2 de sus clientes.

La buena noticia: muchos requisitos se solapan. Quien ya gestione un sistema de gestión de la seguridad de la información conforme a la norma ISO 27001 habrá cubierto gran parte de los requisitos organizativos. El requisito de la SBOM de la CRA complementa las obligaciones de transparencia del Reglamento sobre Inteligencia Artificial respecto a los componentes de IA integrados en los productos.

Lista de comprobación: cinco pasos hacia el cumplimiento de la CRA

Diciembre de 2027 parece lejano, pero las obligaciones de notificación a partir de septiembre de 2026 vencen dentro de seis meses. Una hoja de ruta pragmática.

1. Elaborar un inventario de productos. ¿Qué productos con elementos digitales comercializa la empresa? ¿Cuáles de ellos cuentan con conexión de red, firmware o componentes de software? Este diagnóstico inicial constituye la base para la clasificación de riesgos.

2. Determinar la clase de riesgo. Para cada producto, verificar: ¿estándar, categoría I o categoría II? Esta clasificación determina si basta con una autoevaluación o si se requiere un evaluador externo.

3. Establecer un proceso PSIRT. A partir de septiembre de 2026, las vulnerabilidades deben notificarse dentro de las 24 horas. Para ello se necesita un proceso funcional de respuesta ante incidentes con responsabilidades claras, datos de contacto de la ENISA y un procedimiento de notificación documentado.

4. Elaborar la SBOM. Para cada producto, crear una lista de materiales de software que enumere todos los componentes de software, incluidas sus versiones y licencias. Herramientas como CycloneDX o SPDX automatizan este proceso.

5. Implementar un ciclo de vida seguro del desarrollo de software. Security by Design debe integrarse en el proceso de desarrollo. Esto incluye modelado de amenazas, revisiones de código, pruebas de penetración y mecanismos seguros de actualización.

Ejemplo práctico: una PYME en su camino hacia el cumplimiento de la CRA

Un fabricante de sensores de Suabia, con 80 empleados, produce sensores de temperatura y humedad para la industria alimentaria. Dichos sensores disponen de conexión Wi-Fi, envían datos de medición a una plataforma en la nube y reciben actualizaciones de firmware over-the-air. Hasta ahora no existía ningún proceso estructurado de gestión de vulnerabilidades ni ninguna SBOM.

Primer paso: inventario de productos. La empresa identifica tres líneas de productos con elementos digitales, todas ellas de riesgo estándar (posible autoevaluación). Segundo paso: elaboración de la SBOM. Un proveedor externo analiza el código del firmware y crea una SBOM en formato CycloneDX. Resultado: 47 componentes de software, de los cuales 12 son bibliotecas de código abierto, tres de las cuales no han recibido mantenimiento durante más de un año. Estas tres deben sustituirse o parchearse internamente.

Tercer paso: establecimiento del PSIRT. El responsable del desarrollo de software asume la función de responsable de seguridad. Se define un proceso sencillo: monitorización de vulnerabilidades mediante la Base de Datos Nacional de Vulnerabilidades (NVD), evaluación dentro de las 48 horas y notificación a la ENISA dentro de las 24 horas en caso de explotación activa. Cuarto paso: documentación. Se elaboran el análisis de riesgos, la arquitectura de seguridad y los informes de ensayos. Esfuerzo total: aproximadamente 35.000 euros y una duración del proyecto de tres meses.

Conclusión

La Ley de Resistencia Cibernética transformará de forma duradera el desarrollo de productos en Europa. Para la pequeña y mediana industria productora, no se trata de una recomendación opcional, sino de un requisito vinculante para acceder al mercado. Quien desee vender productos conectados en la UE deberá cumplir con la CRA a partir de diciembre de 2027.

Sin embargo, la primera fecha límite estricta no es diciembre de 2027, sino septiembre de 2026: a partir de entonces, las vulnerabilidades deben notificarse. Seis meses no son mucho tiempo para establecer un proceso PSIRT si aún no existe ninguno. Quien empiece ahora lo logrará. Quien espere, tendrá que trabajar bajo presión temporal. La inversión en el cumplimiento de la CRA no es un mero gasto. Es una inversión en calidad del producto, seguridad del cliente y acceso al mercado a largo plazo en una Europa que hace de la ciberseguridad una condición previa fundamental.

Preguntas frecuentes

Lectura complementaria

Reglamento sobre Inteligencia Artificial a partir de agosto de 2026: IA de alto riesgo en la PYME

Ataque de cadena de suministro GlassWorm: más de 400 herramientas comprometidas – SecurityToday

Seguridad de la cadena de suministro de contenedores: Docker y SBOM – cloudmagazin

Fuente de imagen: Anete Lusina / Pexels