7 min. de lectura<\/p>\n
El Cyber Resilience Act (CRA) de la UE entra en vigor a partir de diciembre de 2024 y afecta a cualquier fabricante que introduce productos con elementos digitales en el mercado europeo. A partir de septiembre de 2026, se implementan las primeras obligaciones de notificaci\u00f3n, y a partir de diciembre de 2027, todos los productos deben cumplir con las nuevas exigencias de ciberseguridad. Para el sector manufacturero, esto significa que cualquier sensor conectado, cualquier control de m\u00e1quina y cualquier componente de software est\u00e1n sujetos a la regulaci\u00f3n. El tiempo para actuar es limitado.<\/strong><\/p>\n El Cyber Resilience Act es la primera regulaci\u00f3n de la UE que introducir obligaciones de ciberseguridad vinculantes para todos los productos con elementos digitales. Su \u00e1mbito de aplicaci\u00f3n est\u00e1 dise\u00f1ado de manera consciente para ser amplio: Incluye dispositivos de hardware conectados como enrutadores, dispositivos de Smart Home y sensores industriales IoT, as\u00ed como software puramente, incluyendo apps, sistemas operativos y firewalls.<\/p>\n Para el sector manufacturero, los implicaciones son amplias. Cualquier control de m\u00e1quina con conexi\u00f3n a la red, cualquier sensor con funci\u00f3n de actualizaci\u00f3n de firmware y cualquier sistema embebido en una planta de producci\u00f3n est\u00e1n sujetos a la regulaci\u00f3n. <\/p>\n Especialmente relevante para el sector manufacturero: Incluso los importadores y distribuidores que introducen productos en la UE tambi\u00e9n tienen obligaciones propias. Quien importa un modulo IoT de origen chino y lo vende bajo su propio etiqueta se considera un fabricante y debe probar la conformidad completa al CRA. Esto afecta a muchos fabricantes de maquinaria y integradores de sistemas que incorporan componentes de terceros en sus soluciones.<\/p>\n Incluso aquellos que no fabrican estos productos, sino que los integran en sus propias soluciones, tienen obligaciones de conformidad como integradores.<\/p>\n Excluidos son algunas categor\u00edas: Productos m\u00e9dicos (ya regulados por el MDR), veh\u00edculos de motor (regulaci\u00f3n UNECE), aeron\u00e1utica y ciertos productos de seguridad nacionales. El software de c\u00f3digo abierto solo est\u00e1 afectado si se comercializa.<\/p>\n \n\u00abEl CRA asegura que los productos de hardware y software con menos vulnerabilidades lleguen al mercado y que los fabricantes tomen la seguridad del producto a lo largo de su ciclo de vida en serio.\u00bb El CRA entr\u00f3 en vigor el 10 de diciembre de 2024 y se aplicar\u00e1 en tres etapas. La primera fecha llega m\u00e1s r\u00e1pido de lo que muchos negocios esperan.<\/p>\n 11 de junio de 2026:<\/strong> La notificaci\u00f3n de las instituciones de evaluaci\u00f3n de conformidad ser\u00e1 efectiva. A partir de este d\u00eda, las autoridades nacionales deben haber nombrado las instituciones que pueden evaluar productos de alto riesgo (categor\u00eda I y II).<\/p>\n 11 de septiembre de 2026:<\/strong> Las obligaciones de notificaci\u00f3n para fallos y incidentes de seguridad comienzan. Los fabricantes deben informar a ENISA sobre las vulnerabilidades activas dentro de las 24 horas. Para incidentes graves, la fecha l\u00edmite es de 72 horas. Esta obligaci\u00f3n comienza seis meses antes de la aplicaci\u00f3n completa y es la primera fecha l\u00edmite duro para muchos negocios.<\/p>\n 11 de diciembre de 2027:<\/strong> Aplicaci\u00f3n completa de todas las exigencias. A partir de este d\u00eda, solo se pueden distribuir productos CRA conformes con la etiqueta CE en el mercado EU. Los productos que ya estaban en el mercado antes de este d\u00eda y no se hayan modificado sustancialmente, se protegen.<\/p>\n El CRA clasifica los productos en tres categor\u00edas de riesgo que determinar\u00e1n c\u00f3mo debe llevarse a cabo la evaluaci\u00f3n de conformidad. La clasificaci\u00f3n tiene implicaciones directas para el esfuerzo y los costos.<\/p>\n Productos est\u00e1ndar (alrededor del 90% de todos los productos):<\/strong> Esto incluye sensores IoT simples, dispositivos Smart Home sin funciones de seguridad, software de consumo y equipos de oficina. Los fabricantes pueden demostrar la conformidad mediante una autoevaluaci\u00f3n. No se requiere un evaluador externo.<\/p>\n Productos importantes (categor\u00eda I):<\/strong> Sistemas operativos, firewalls, enrutadores, software de VPN, sistemas de administraci\u00f3n de redes. Aqu\u00ed es necesario una evaluaci\u00f3n seg\u00fan normas armonizadas o una evaluaci\u00f3n por una tercera parte.<\/p>\n Productos cr\u00edticos (categor\u00eda II):<\/strong> M\u00f3dulos de seguridad de hardware, puertas de enlace de Smart Meters, sistemas de control industriales<\/a> e infraestructuras de clave p\u00fablica. Aqu\u00ed se requiere una evaluaci\u00f3n de conformidad por una entidad designada de una tercera parte.<\/p>\n Las exigencias de la CRA se pueden dividir en tres \u00e1reas: desarrollo seguro, gesti\u00f3n de vulnerabilidades y documentaci\u00f3n.<\/p>\n Seguridad desde la concepci\u00f3n:<\/strong> Los productos deben desarrollarse seg\u00fan el principio \u00abSeguro por defecto\u00bb desde la fase de dise\u00f1o. Esto significa: superficie de ataque m\u00ednima, comunicaci\u00f3n cifrada, contrase\u00f1as no codificadas y mecanismos de actualizaci\u00f3n seguros. Los fabricantes deben demostrar que la seguridad no se ha a\u00f1adido posteriormente, sino que se ha integrado desde el principio.<\/p>\n Gesti\u00f3n de vulnerabilidades:<\/strong> Los fabricantes deben proporcionar actualizaciones de seguridad a lo largo del ciclo de vida del producto, al menos durante cinco a\u00f1os despu\u00e9s de su lanzamiento al mercado. Las vulnerabilidades activamente explotadas deben informarse a la ENISA en un plazo de 24 horas. Esto requiere un proceso PSIRT (Product Security Incident Response Team) operativo.<\/p>\n Documentaci\u00f3n t\u00e9cnica:<\/strong> Para cada producto debe existir una documentaci\u00f3n completa: an\u00e1lisis de riesgos, descripci\u00f3n de la arquitectura de seguridad, informes de pruebas, SBOM (Software Bill of Materials) y una declaraci\u00f3n de conformidad con la UE. <\/p>\n Un aspecto que a menudo se subestima es la obligaci\u00f3n de proporcionar actualizaciones de seguridad gratuitas durante al menos cinco a\u00f1os. Para los fabricantes de componentes industriales con ciclos de vida de diez a veinte a\u00f1os, esto representa una obligaci\u00f3n a largo plazo sustancial. Quien hoy entrega un m\u00f3dulo de control conectado debe garantizar que estar\u00e1 seguro y actualizado hasta 2032. Esto requiere una arquitectura de software sostenible y una infraestructura de actualizaci\u00f3n operativa que se extienda m\u00e1s all\u00e1 del ciclo de vida t\u00edpico del producto.<\/p>\n En la pr\u00e1ctica, tambi\u00e9n significa que los fabricantes deben reconsiderar sus relaciones con sus proveedores. Si una biblioteca de c\u00f3digo abierto que se incluye en un producto deja de ser mantenida, el fabricante debe desarrollar los parches por s\u00ed mismo o reemplazar la componente. La SBOM se convierte en un sistema de alerta temprana: muestra las dependencias y d\u00f3nde se encuentran los riesgos.<\/p>\n La SBOM es especialmente relevante, ya que debe enumerar todas las componentes de software, incluyendo las bibliotecas de c\u00f3digo abierto.<\/p>\n La Software Bill of Materials (SBOM) es uno de los nuevos instrumentos centrales de la CRA. En la pr\u00e1ctica, es similar a una lista de ingredientes en una bebida: enumera cada componente de software que se incluye en un producto. Para muchos peque\u00f1os y medianos empresarios, esto representa un desaf\u00edo, ya que las dependencias en las pilas de software modernas son complejas.<\/p>\n Un sistema embebido t\u00edpico en una m\u00e1quina de control contiene un sistema operativo en tiempo real, bibliotecas de comunicaci\u00f3n, m\u00f3dulos de criptograf\u00eda y decenas de otras componentes, que a menudo se integran como c\u00f3digo abierto. Cada una de estas componentes puede contener vulnerabilidades que el fabricante debe conocer y controlar.<\/p>\n La buena noticia: existen est\u00e1ndares y herramientas estables. CycloneDX y SPDX son los formatos SBOM m\u00e1s utilizados. Las herramientas de compilaci\u00f3n como Syft o Grype generan autom\u00e1ticamente SBOM a partir del repositorio de c\u00f3digo. Para empresas que ya utilizan pipelines de CI\/CD, la integraci\u00f3n de la generaci\u00f3n de SBOM en el proceso de compilaci\u00f3n existente es posible sin perturbar el flujo de trabajo de desarrollo.<\/p>\n Para empresas que no desarrollan software propio y obtienen componentes de proveedores, se aplica: solicite a sus proveedores que proporcionen una SBOM. La CRA transfiere la responsabilidad a lo largo de la cadena de suministro. Quien integre componentes sin SBOM en sus productos es responsable de las vulnerabilidades desconocidas.<\/p>\n Los costos de cumplimiento dependen en gran medida de la categor\u00eda de producto y del nivel de madurez de los procesos de seguridad existentes. Para productos est\u00e1ndar con autovaloraci\u00f3n, los expertos en la industria estiman costos \u00fanicos de 20.000 a 50.000 euros por l\u00ednea de producto, principalmente para documentaci\u00f3n, an\u00e1lisis de riesgos y creaci\u00f3n de SBOM.<\/p>\n Para productos de categor\u00eda I y II que requieren una evaluaci\u00f3n externa, los costos aumentan a 80.000 a 200.000 euros. Adem\u00e1s, se deben considerar costos operativos para el manejo de vulnerabilidades: un proceso PSIRT dedicado con monitoreo, desarrollo de parches y notificaciones a ENISA requiere al menos una posici\u00f3n a tiempo parcial, aunque en la pr\u00e1ctica a menudo m\u00e1s.<\/p>\n El balance: Los costos promedio de un incidente de ciberseguridad, seg\u00fan el BSI para el sector mediano, est\u00e1n en 500.000 euros. Un solo incidente grave superar\u00e1 los costos de cumplimiento durante varios a\u00f1os. Adem\u00e1s, se obtiene un beneficio de acceso al mercado: quien cumple con el CRA puede comercializar sin restricciones en toda Europa, mientras que los competidores no conformes se ven excluidos del mercado.<\/p>\n El CRA no existe aisladamente. Junto con NIS2<\/a> (seguridad de red e informaci\u00f3n) y el AI Act<\/a>, forma una tria reguladora que afecta a las empresas europeas de manera simult\u00e1nea. Para el sector mediano, esto significa: identificar superposiciones y aprovechar sinergias.<\/p>\n NIS2 obliga a los operadores de infraestructuras cr\u00edticas y importantes a implementar un manejo de riesgos y notificar incidentes. El CRA obliga a los fabricantes de productos que estos operadores utilizan. Por ejemplo, si una empresa fabrica sensores IoT para proveedores de energ\u00eda o software de control para plantas de agua, debe cumplir con el CRA para sus productos y con los requisitos de NIS2 para sus clientes.<\/p>\n La buena noticia: Muchos requisitos se superponen. Quien ya opera un sistema de gesti\u00f3n de seguridad de la informaci\u00f3n seg\u00fan ISO 27001 cubre en gran medida las necesidades organizativas. La requisici\u00f3n de SBOM del CRA se completa con las obligaciones de transparencia del AI Act para componentes de inteligencia artificial en productos.<\/p>\n El dezembre de 2027 puede parecer lejano, pero las obligaciones de notificaci\u00f3n a partir de septiembre de 2026<\/a> est\u00e1n a seis meses de cumplirse. Una hoja de ruta pragm\u00e1tica.<\/p>\n 1. Inventario de productos.<\/strong> \u00bfQu\u00e9 productos con elementos digitales comercializa la empresa? \u00bfCu\u00e1les de ellos tienen conexi\u00f3n a la red, firmware o componentes de software? La identificaci\u00f3n de productos es la base para la clasificaci\u00f3n de riesgos.<\/p>\n 2. Clase de riesgo.<\/strong> Para cada producto, determinar: est\u00e1ndar, categor\u00eda I o categor\u00eda II. La clasificaci\u00f3n determinar\u00e1 si una autovaloraci\u00f3n es suficiente o se requiere un evaluador externo.<\/p>\n 3. Proceso PSIRT.<\/strong> A partir de septiembre de 2026, las vulnerabilidades deben informarse en las 24 horas. Para ello, se necesita un proceso de respuesta a incidentes operativo con roles claros, datos de contacto para ENISA y un procedimiento de notificaci\u00f3n documentado.<\/p>\n 4. SBOM.<\/strong> Para cada producto, crear una declaraci\u00f3n de materiales de software que enumere todos los componentes de software, incluyendo versiones y licencias. Herramientas como CycloneDX o SPDX automatizan este proceso.<\/p>\n 5. Implementar ciclo de vida de desarrollo seguro.<\/strong> La seguridad desde la concepci\u00f3n debe integrarse en el proceso de desarrollo. Esto incluye modelado de amenazas, revisi\u00f3n de c\u00f3digo, pruebas de penetraci\u00f3n y mecanismos de actualizaci\u00f3n seguros.<\/p>\n Un fabricante de sensores de temperatura y humedad con 80 empleados en Suiza produce sensores para la industria de alimentos. Los sensores tienen conexi\u00f3n WLAN, env\u00edan datos de medici\u00f3n a una plataforma en la nube y reciben actualizaciones de firmware sobre la marcha. Hasta ahora, no hab\u00eda un manejo estructurado de las vulnerabilidades y no hab\u00eda un inventario de componentes de software (SBOM).<\/p>\n Paso uno: Inventario de productos. La empresa identifica tres l\u00edneas de productos con elementos digitales, todas con riesgo est\u00e1ndar (autoevaluaci\u00f3n posible). Paso dos: Creaci\u00f3n de SBOM. Un proveedor externo analiza el c\u00f3digo de firmware y crea una SBOM CycloneDX. Resultado: 47 componentes de software, de los cuales 12 son bibliotecas de c\u00f3digo abierto, de las cuales tres no se mantienen desde hace m\u00e1s de un a\u00f1o. Estas tres deben reemplazarse o patcheadas por s\u00ed mismas.<\/p>\n Paso tres: Implementaci\u00f3n de PSIRT. El l\u00edder de desarrollo de software assume el papel de responsable de seguridad. Se define un proceso simple: Monitoreo de vulnerabilidades a trav\u00e9s de la National Vulnerability Database (NVD), evaluaci\u00f3n en 48 horas, notificaci\u00f3n a ENISA en 24 horas en caso de una explotaci\u00f3n activa. Paso cuatro: Documentaci\u00f3n. Se crean an\u00e1lisis de riesgos, arquitectura de seguridad y informes de pruebas. Gasto total: aproximadamente 35.000 euros y tres meses de duraci\u00f3n del proyecto.<\/p>\n El Cyber Resilience Act cambiar\u00e1 sustancialmente la forma en que se desarrollan productos en Europa. Para el peque\u00f1o empresario productivo, no es una recomendaci\u00f3n opcional, sino una condici\u00f3n obligatoria para el acceso al mercado. Cualquier empresa que venda productos conectados en la UE debe ser conforme con la CRA a partir de diciembre de 2027.<\/p>\n La primera fecha l\u00edmite no es el diciembre de 2027, sino septiembre de 2026: a partir de entonces, se deben notificar las vulnerabilidades. Seis meses no son mucho tiempo para implementar un proceso PSIRT si a\u00fan no existe. Quien comienza ahora, tendr\u00e1 \u00e9xito. Quien espera, tendr\u00e1 que trabajar bajo presi\u00f3n de tiempo. La inversi\u00f3n en CRA-Compliance no es solo un costo, sino una inversi\u00f3n en la calidad del producto, la seguridad del cliente y el acceso al mercado a largo plazo en un Europa donde la ciberseguridad se convierte en una necesidad b\u00e1sica.<\/p>\n S\u00ed, si tu software se distribuye comercialmente. El CRA se aplica a todos los productos que incluyen elementos digitales, incluyendo software pura. La \u00fanica excepci\u00f3n es la software de c\u00f3digo abierto no comercial.<\/p>\n<\/details>\n Una Software Bill of Materials (SBOM) es una lista completa de todas las componentes de software en un producto, incluyendo bibliotecas de c\u00f3digo abierto, versiones y licencias. El CRA requiere una SBOM como parte de la documentaci\u00f3n t\u00e9cnica.<\/p>\n<\/details>\n Al menos cinco a\u00f1os despu\u00e9s de la introducci\u00f3n al mercado o durante la vida \u00fatil del producto, seg\u00fan el per\u00edodo m\u00e1s corto. Las actualizaciones deben ser gratuitas y proporcionadas de manera oportuna.<\/p>\n<\/details>\n Solo para productos de la categor\u00eda II (cr\u00edtico), como gateways de Smart Meters o sistemas de control industriales. Los productos est\u00e1ndar (aprox. el 90%) pueden ser verificados por el propio fabricante mediante una autoevaluaci\u00f3n.<\/p>\n<\/details>\n Multas hasta 15 millones de euros o el 2,5% del volumen de negocio global al a\u00f1o. Adem\u00e1s, las autoridades pueden negar el acceso al mercado: los productos no conformes no deben ser vendidos en la UE.<\/p>\n<\/details>\n NIS2 regula a los operadores de infraestructuras y servicios, mientras que el CRA regula a los fabricantes de productos. Si tu empresa fabrica productos conectados, debes cumplir con el CRA. Si utilizas estos productos, se aplicar\u00e1n las obligaciones de NIS2.<\/p>\n<\/details>\n Ley AI a partir de agosto de 2026: KI de alto riesgo en la peque\u00f1a y mediana empresa<\/a><\/p>\nLo m\u00e1s importante en resumen<\/h2>\n
\n
\u00bfQu\u00e9 regula el CRA y qui\u00e9n se ven afectados?<\/h2>\n
\n– Comisi\u00f3n Europea, comunicado de prensa sobre el CRA, septiembre de 2022<\/cite>\n<\/p><\/blockquote>\nLas tres fechas: \u00bfCu\u00e1ndo cu\u00e1l se aplica<\/h2>\n
Categor\u00edas de productos: Est\u00e1ndar, Importante, Cr\u00edtica<\/h2>\n
Lo que los fabricantes deben implementar en la pr\u00e1ctica<\/h2>\n
SBOM: Por qu\u00e9 la lista de componentes de software ser\u00e1 el cambio de juego<\/h2>\n
\u00bfCu\u00e1nto costar\u00e1 el CRA para el sector mediano?<\/h2>\n
CRA, NIS2 y AI Act: La tria reguladora<\/h2>\n
Lista de control: Cinco pasos hacia el cumplimiento del CRA<\/h2>\n
Ejemplo pr\u00e1ctico: Un peque\u00f1o empresario en camino a la CRA-Compliance<\/h2>\n
Resumen<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfEstoy afectado como desarrollador de software por el CRA?<\/strong><\/summary>\n
\u00bfQu\u00e9 es una SBOM?<\/strong><\/summary>\n
\u00bfCu\u00e1nto tiempo debo proporcionar actualizaciones de seguridad?<\/strong><\/summary>\n
\u00bfNecesito una entidad de verificaci\u00f3n externa?<\/strong><\/summary>\n
\u00bfQu\u00e9 sucede en caso de violaci\u00f3n?<\/strong><\/summary>\n
\u00bfEn qu\u00e9 se diferencia el CRA de NIS2?<\/strong><\/summary>\n
Recomendaciones de lectura de la redacci\u00f3n<\/h2>\n
\n
M\u00e1s del MBF Media Netzwerk<\/h2>\n
\n
Lectura complementaria<\/h2>\n