7 min de lectura<\/p>\n
La Ley de Resistencia Cibern\u00e9tica de la UE (CRA, por sus siglas en ingl\u00e9s) entr\u00f3 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\u00e1n en vigor las primeras obligaciones de notificaci\u00f3n; a partir de diciembre de 2027, todos los productos deber\u00e1n cumplir los nuevos requisitos de ciberseguridad. Para la peque\u00f1a 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\u00e1 agotando.<\/strong><\/p>\n La Ley de Resistencia Cibern\u00e9tica es el primer reglamento de la UE que introduce requisitos vinculantes de ciberseguridad para todos los productos con elementos digitales. Su \u00e1mbito de aplicaci\u00f3n 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.<\/p>\n Para la peque\u00f1a y mediana industria productora, esto tiene consecuencias de gran alcance. Todo sistema de control de maquinaria con conexi\u00f3n de red, cualquier sensor con funci\u00f3n de actualizaci\u00f3n de firmware y todo sistema embebido en una instalaci\u00f3n de producci\u00f3n quedan sujetos a esta normativa. <\/p>\n Particularmente relevante para la PYME: tambi\u00e9n los importadores y distribuidores que introducen productos en el mercado de la UE asumen obligaciones propias. Quien importe un m\u00f3dulo IoT chino y lo comercialice bajo su propia marca ser\u00e1 considerado fabricante y deber\u00e1 demostrar el cumplimiento \u00edntegro de la CRA. Esto afecta a numerosos fabricantes de maquinaria y a integradores de sistemas que incorporan componentes procedentes de terceros pa\u00edses en sus soluciones propias.<\/p>\n Incluso quienes no fabrican dichos productos directamente, sino que los integran en sus propias soluciones, asumen como integradores obligaciones de cumplimiento.<\/p>\n Quedan excluidas \u00fanicamente algunas categor\u00edas: productos sanitarios (ya regulados por el Reglamento MDR), veh\u00edculos de motor (regulaci\u00f3n UNECE), tecnolog\u00eda aeroespacial y determinados productos de seguridad nacional. El software de c\u00f3digo abierto solo queda sujeto a la norma si se comercializa con fines comerciales.<\/p>\n \n\u00abLa 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.\u00bb La CRA entr\u00f3 en vigor el 10 de diciembre de 2024 y se aplica progresivamente en tres fases. La primera fecha l\u00edmite llega m\u00e1s r\u00e1pido de lo que muchas empresas esperan.<\/p>\n 11 de junio de 2026:<\/strong> Entrar\u00e1 en vigor la notificaci\u00f3n de los organismos de evaluaci\u00f3n de la conformidad. A partir de esta fecha, las autoridades nacionales deber\u00e1n haber designado los organismos de evaluaci\u00f3n autorizados para examinar los productos de alto riesgo (categor\u00edas I y II).<\/p>\n 11 de septiembre de 2026:<\/strong> Comienzan las obligaciones de notificaci\u00f3n 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\u00f3n es de 72 horas. Esta obligaci\u00f3n entra en vigor seis meses antes de la aplicaci\u00f3n completa y constituye para muchas empresas la primera fecha l\u00edmite estricta.<\/p>\n 11 de diciembre de 2027:<\/strong> Aplicaci\u00f3n total de todos los requisitos. A partir de esta fecha, \u00fanicamente podr\u00e1n 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\u00e1n de protecci\u00f3n de la situaci\u00f3n existente.<\/p>\n La CRA clasifica los productos en tres clases de riesgo, que determinan c\u00f3mo debe realizarse la evaluaci\u00f3n de la conformidad. Esta clasificaci\u00f3n tiene impacto directo en el esfuerzo y los costes requeridos.<\/p>\n Productos est\u00e1ndar (aproximadamente el 90 % de todos los productos):<\/strong> 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\u00f3n. No se requiere ning\u00fan evaluador externo.<\/p>\n Productos importantes (categor\u00eda I):<\/strong> Sistemas operativos, firewalls, routers, software VPN y sistemas de gesti\u00f3n de redes. Aqu\u00ed es necesaria bien una evaluaci\u00f3n conforme a normas armonizadas, bien una evaluaci\u00f3n por parte de un tercero.<\/p>\n Productos cr\u00edticos (categor\u00eda II):<\/strong> M\u00f3dulos de seguridad hardware, pasarelas de contadores inteligentes, sistemas de control industrial<\/a> e infraestructuras de clave p\u00fablica. Aqu\u00ed es obligatoria una evaluaci\u00f3n de la conformidad por parte de un tercero, llevada a cabo por un organismo notificado.<\/p>\n Los requisitos de la CRA se dividen en tres \u00e1mbitos: desarrollo seguro, gesti\u00f3n de vulnerabilidades y documentaci\u00f3n.<\/p>\n Seguridad desde el dise\u00f1o (Security by Design):<\/strong> Los productos deben desarrollarse desde su concepci\u00f3n seg\u00fan el principio de \u00abseguro por defecto\u00bb (Secure by Default). Esto implica: superficie de ataque m\u00ednima, comunicaci\u00f3n cifrada, ausencia de contrase\u00f1as codificadas de forma fija y mecanismos seguros de actualizaci\u00f3n. Los fabricantes deben demostrar que la seguridad no se a\u00f1ade posteriormente, sino que se integra desde el inicio.<\/p>\n Gesti\u00f3n de vulnerabilidades:<\/strong> Los fabricantes deben proporcionar actualizaciones de seguridad durante todo el ciclo de vida del producto, y al menos durante cinco a\u00f1os 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).<\/p>\n Documentaci\u00f3n t\u00e9cnica:<\/strong> Para cada producto debe existir una documentaci\u00f3n exhaustiva: an\u00e1lisis de riesgos, descripci\u00f3n de la arquitectura de seguridad, informes de ensayos, SBOM (lista de materiales de software) y una declaraci\u00f3n de conformidad con la UE. <\/p>\n Un aspecto que suele subestimarse es la obligaci\u00f3n de proporcionar gratuitamente actualizaciones de seguridad durante al menos cinco a\u00f1os. Para los fabricantes de componentes industriales cuyos ciclos de vida abarcan entre diez y veinte a\u00f1os, esto supone un compromiso a largo plazo considerable. Quien hoy ponga en circulaci\u00f3n un m\u00f3dulo de control conectado debe garantizar que en 2032 a\u00fan pueda parchearse de forma segura. Esto exige una arquitectura de software sostenible y una infraestructura de actualizaci\u00f3n funcional que vaya mucho m\u00e1s all\u00e1 del ciclo de vida t\u00edpico del producto.<\/p>\n En la pr\u00e1ctica, esto implica tambi\u00e9n que los fabricantes deben replantearse sus relaciones con los proveedores. Si una biblioteca de c\u00f3digo abierto integrada en un producto deja de recibir mantenimiento, el fabricante deber\u00e1 desarrollar \u00e9l mismo los parches o sustituir el componente. La SBOM se convierte aqu\u00ed en un sistema de alerta temprana: muestra qu\u00e9 dependencias existen y d\u00f3nde se ocultan los riesgos.<\/p>\n La SBOM resulta especialmente relevante porque debe enumerar todos los componentes de software, incluidas las bibliotecas de c\u00f3digo abierto.<\/p>\n La lista de materiales de software (SBOM, por sus siglas en ingl\u00e9s) es uno de los instrumentos centrales novedosos de la CRA. En la pr\u00e1ctica, 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.<\/p>\n Un sistema embebido t\u00edpico en un sistema de control de maquinaria contiene un sistema operativo en tiempo real, bibliotecas de comunicaci\u00f3n, m\u00f3dulos criptogr\u00e1ficos y decenas de componentes adicionales, muchos de los cuales se incorporan como c\u00f3digo abierto. Cada uno de estos componentes puede contener vulnerabilidades que el fabricante debe conocer y tener bajo control.<\/p>\n La buena noticia: existen est\u00e1ndares y herramientas consolidados. CycloneDX y SPDX son los dos formatos SBOM l\u00edderes. Herramientas de construcci\u00f3n como Syft o Grype generan autom\u00e1ticamente SBOMs a partir del repositorio de c\u00f3digo. Para las empresas que ya utilizan pipelines CI\/CD, la creaci\u00f3n de SBOMs puede integrarse en el proceso de construcci\u00f3n existente sin interrumpir el flujo de trabajo de desarrollo.<\/p>\n 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.<\/p>\n Los costes de cumplimiento dependen en gran medida de la categor\u00eda del producto y del grado de madurez de los procesos de seguridad existentes. Para productos est\u00e1ndar sometidos a autoevaluaci\u00f3n, los expertos del sector estiman unos costes \u00fanicos de entre 20.000 y 50.000 euros por l\u00ednea de productos, principalmente para documentaci\u00f3n, an\u00e1lisis de riesgos y elaboraci\u00f3n de la SBOM.<\/p>\n Para los productos de las categor\u00edas I y II, que requieren una evaluaci\u00f3n externa, los costes aumentan a entre 80.000 y 200.000 euros. Adem\u00e1s, hay costes recurrentes derivados de la gesti\u00f3n de vulnerabilidades: un proceso PSIRT dedicado con monitorizaci\u00f3n, desarrollo de parches y notificaciones a la ENISA requiere al menos media jornada laboral completa, y en la pr\u00e1ctica suele exigir m\u00e1s.<\/p>\n La contrapartida: seg\u00fan el BSI, los costes medios de un incidente de ciberseguridad en la PYME ascienden a 500.000 euros. Un \u00fanico suceso grave supera los costes de cumplimiento durante varios a\u00f1os. Adem\u00e1s, existe la ventaja competitiva del acceso al mercado: quien cumpla con la CRA podr\u00e1 comercializar sus productos en toda Europa sin restricciones, mientras que los competidores no conformes quedar\u00e1n excluidos del mercado.<\/p>\n La CRA no existe de forma aislada. Junto con NIS2<\/a> (seguridad de las redes y de la informaci\u00f3n) y el Reglamento sobre Inteligencia Artificial<\/a>, forma una tr\u00edada regulatoria que afecta simult\u00e1neamente a las empresas europeas. Para la PYME, esto significa: identificar las superposiciones y aprovechar las sinergias.<\/p>\n NIS2 obliga a los operadores de infraestructuras cr\u00edticas e importantes a gestionar los riesgos y notificar los incidentes. La CRA obliga a los fabricantes de los productos que dichos operadores emplean. As\u00ed pues, quien fabrique sensores IoT para empresas suministradoras de energ\u00eda o software de control para plantas de tratamiento de agua deber\u00e1 cumplir tanto con la CRA respecto a sus propios productos como con los requisitos NIS2 de sus clientes.<\/p>\n La buena noticia: muchos requisitos se solapan. Quien ya gestione un sistema de gesti\u00f3n de la seguridad de la informaci\u00f3n conforme a la norma ISO 27001 habr\u00e1 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.<\/p>\n Diciembre de 2027 parece lejano, pero las obligaciones de notificaci\u00f3n a partir de septiembre de 2026<\/a> vencen dentro de seis meses. Una hoja de ruta pragm\u00e1tica.<\/p>\n 1. Elaborar un inventario de productos.<\/strong> \u00bfQu\u00e9 productos con elementos digitales comercializa la empresa? \u00bfCu\u00e1les de ellos cuentan con conexi\u00f3n de red, firmware o componentes de software? Este diagn\u00f3stico inicial constituye la base para la clasificaci\u00f3n de riesgos.<\/p>\n 2. Determinar la clase de riesgo.<\/strong> Para cada producto, verificar: \u00bfest\u00e1ndar, categor\u00eda I o categor\u00eda II? Esta clasificaci\u00f3n determina si basta con una autoevaluaci\u00f3n o si se requiere un evaluador externo.<\/p>\n 3. Establecer un proceso PSIRT.<\/strong> 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\u00f3n documentado.<\/p>\n 4. Elaborar la SBOM.<\/strong> 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.<\/p>\n 5. Implementar un ciclo de vida seguro del desarrollo de software.<\/strong> Security by Design debe integrarse en el proceso de desarrollo. Esto incluye modelado de amenazas, revisiones de c\u00f3digo, pruebas de penetraci\u00f3n y mecanismos seguros de actualizaci\u00f3n.<\/p>\n Un fabricante de sensores de Suabia, con 80 empleados, produce sensores de temperatura y humedad para la industria alimentaria. Dichos sensores disponen de conexi\u00f3n Wi-Fi, env\u00edan datos de medici\u00f3n a una plataforma en la nube y reciben actualizaciones de firmware over-the-air<\/em>. Hasta ahora no exist\u00eda ning\u00fan proceso estructurado de gesti\u00f3n de vulnerabilidades ni ninguna SBOM.<\/p>\n Primer paso: inventario de productos. La empresa identifica tres l\u00edneas de productos con elementos digitales, todas ellas de riesgo est\u00e1ndar (posible autoevaluaci\u00f3n). Segundo paso: elaboraci\u00f3n de la SBOM. Un proveedor externo analiza el c\u00f3digo del firmware y crea una SBOM en formato CycloneDX. Resultado: 47 componentes de software, de los cuales 12 son bibliotecas de c\u00f3digo abierto, tres de las cuales no han recibido mantenimiento durante m\u00e1s de un a\u00f1o. Estas tres deben sustituirse o parchearse internamente.<\/p>\n Tercer paso: establecimiento del PSIRT. El responsable del desarrollo de software asume la funci\u00f3n de responsable de seguridad. Se define un proceso sencillo: monitorizaci\u00f3n de vulnerabilidades mediante la Base de Datos Nacional de Vulnerabilidades (NVD), evaluaci\u00f3n dentro de las 48 horas y notificaci\u00f3n a la ENISA dentro de las 24 horas en caso de explotaci\u00f3n activa. Cuarto paso: documentaci\u00f3n. Se elaboran el an\u00e1lisis de riesgos, la arquitectura de seguridad y los informes de ensayos. Esfuerzo total: aproximadamente 35.000 euros y una duraci\u00f3n del proyecto de tres meses.<\/p>\n La Ley de Resistencia Cibern\u00e9tica transformar\u00e1 de forma duradera el desarrollo de productos en Europa. Para la peque\u00f1a y mediana industria productora, no se trata de una recomendaci\u00f3n opcional, sino de un requisito vinculante para acceder al mercado. Quien desee vender productos conectados en la UE deber\u00e1 cumplir con la CRA a partir de diciembre de 2027.<\/p>\n Sin embargo, la primera fecha l\u00edmite 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\u00fan no existe ninguno. Quien empiece ahora lo lograr\u00e1. Quien espere, tendr\u00e1 que trabajar bajo presi\u00f3n temporal. La inversi\u00f3n en el cumplimiento de la CRA no es un mero gasto. Es una inversi\u00f3n en calidad del producto, seguridad del cliente y acceso al mercado a largo plazo en una Europa que hace de la ciberseguridad una condici\u00f3n previa fundamental.<\/p>\n S\u00ed, si su software se comercializa con fines comerciales. La CRA se aplica a todos los productos con elementos digitales, incluido el software puro. \u00danicamente queda excluido el software de c\u00f3digo abierto no comercial.<\/p>\n<\/details>\n Una lista de materiales de software (SBOM) es un listado completo de todos los componentes de software integrados en un producto, incluidas las bibliotecas de c\u00f3digo abierto, sus versiones y licencias. La CRA exige una SBOM como parte de la documentaci\u00f3n t\u00e9cnica.<\/p>\n<\/details>\n Al menos cinco a\u00f1os tras la puesta en el mercado o durante la vida \u00fatil prevista del producto, seg\u00fan cual sea el per\u00edodo m\u00e1s corto. Las actualizaciones deben ofrecerse gratuitamente y de forma oportuna.<\/p>\n<\/details>\n \u00danicamente para los productos de la categor\u00eda II (cr\u00edticos), como pasarelas de contadores inteligentes o sistemas de control industrial. Los productos est\u00e1ndar (aproximadamente el 90 %) pueden acreditarse mediante la autoevaluaci\u00f3n del fabricante.<\/p>\n<\/details>\n Sanciones econ\u00f3micas de hasta 15 millones de euros o el 2,5 % de la facturaci\u00f3n anual global. Adem\u00e1s, las autoridades pueden denegar el acceso al mercado: los productos no conformes no podr\u00e1n comercializarse en la UE.<\/p>\n<\/details>\n NIS2 regula a los operadores de infraestructuras y servicios, mientras que la CRA regula a los fabricantes de productos. Si su empresa fabrica productos conectados, debe cumplir con la CRA. Si utiliza dichos productos, le ser\u00e1n de aplicaci\u00f3n las obligaciones NIS2.<\/p>\n<\/details>\n Reglamento sobre Inteligencia Artificial a partir de agosto de 2026: IA de alto riesgo en la PYME<\/a><\/p>\nLo m\u00e1s importante<\/h2>\n
\n
Qu\u00e9 regula la CRA y a qui\u00e9n afecta<\/h2>\n
\n– Comisi\u00f3n Europea, comunicado de prensa sobre la CRA, septiembre de 2022<\/cite>\n<\/p><\/blockquote>\nLas tres fechas l\u00edmite: qu\u00e9 entra en vigor y cu\u00e1ndo<\/h2>\n
Categor\u00edas de productos: est\u00e1ndar, importante, cr\u00edtico<\/h2>\n
Qu\u00e9 deben implementar concretamente los fabricantes<\/h2>\n
SBOM: Por qu\u00e9 la lista de materiales de software se convierte en un factor decisivo<\/h2>\n
Cu\u00e1l es el coste concreto de la CRA para la PYME<\/h2>\n
CRA, NIS2 y Reglamento sobre Inteligencia Artificial: la tr\u00edada regulatoria<\/h2>\n
Lista de comprobaci\u00f3n: cinco pasos hacia el cumplimiento de la CRA<\/h2>\n
Ejemplo pr\u00e1ctico: una PYME en su camino hacia el cumplimiento de la CRA<\/h2>\n
Conclusi\u00f3n<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfEstoy afectado como desarrollador de software por la CRA?<\/strong><\/summary>\n
\u00bfQu\u00e9 es una SBOM?<\/strong><\/summary>\n
\u00bfDurante cu\u00e1nto tiempo debo proporcionar actualizaciones de seguridad?<\/strong><\/summary>\n
\u00bfNecesito un organismo de evaluaci\u00f3n externo?<\/strong><\/summary>\n
\u00bfQu\u00e9 ocurre en caso de incumplimiento?<\/strong><\/summary>\n
\u00bfEn qu\u00e9 se diferencia la CRA de NIS2?<\/strong><\/summary>\n
Lecturas recomendadas por la redacci\u00f3n<\/h2>\n
\n
M\u00e1s contenido de la red MBF Media<\/h2>\n
\n
Lectura complementaria<\/h2>\n