El Ley de Resiliencia Cibernética de la Unión Europea (CRA) Es la primera normativa importante que trata la ciberseguridad como un requisito de seguridad del producto en lugar de un requisito de gobernanza organizativa.

Si bien existen numerosas normativas que se centran en cómo las organizaciones gestionan internamente el riesgo cibernético, la CRA adopta un enfoque diferente. Se centra en los productos en sí mismos. Más concretamente, en si el software, los dispositivos, las plataformas y las tecnologías conectadas que entran en el mercado europeo son seguros desde su diseño, reciben un mantenimiento adecuado y cuentan con soporte durante todo su ciclo de vida.

Durante años, la ciberseguridad se ha tratado a menudo como una cuestión de gobernanza, una preocupación operativa o un desafío técnico que recae principalmente en los equipos de seguridad. La CRA señala un cambio más amplio: la ciberseguridad se está considerando cada vez más como un requisito de seguridad del producto y, para las organizaciones que venden productos en el mercado de la UE, las implicaciones van mucho más allá del mero cumplimiento normativo.

¿Qué es la Ley de Resiliencia Cibernética?

En esencia, la CRA está diseñada para mejorar la ciberseguridad de los productos con elementos digitales.

En términos prácticos, si un producto contiene software, se conecta a una red, intercambia datos digitalmente o incluye tecnología conectada integrada, es probable que esté dentro del ámbito de aplicación.

La normativa se aplica a lo largo de todo el ciclo de vida del producto, estableciendo obligaciones en materia de desarrollo seguro desde el diseño, gestión de vulnerabilidades, actualizaciones y parches de seguridad, notificación de incidentes y vulnerabilidades, documentación técnica y evaluaciones de conformidad, así como el mantenimiento continuo de la seguridad del producto. Además, introduce sanciones económicas y, quizás aún más importante, la posibilidad de que los productos sean restringidos o retirados del mercado por completo si las organizaciones incumplen la normativa de forma reiterada y grave.

El objetivo es reducir el volumen de productos digitales inseguros que ingresan al mercado europeo, al tiempo que se establece un marco de referencia más uniforme en materia de ciberseguridad en todos los Estados miembros. Es importante destacar que esto no constituye una guía ni un marco recomendado. La CRA es una normativa de obligado cumplimiento.

¿Por qué es importante la CRA?

Una de las razones por las que la CRA ha atraído tanta atención es porque cambia la responsabilidad.

Históricamente, muchas regulaciones cibernéticas se han centrado en la resiliencia organizacional: cómo las empresas gestionan el riesgo, responden a incidentes, controlan a sus proveedores y protegen los servicios críticos. La CRA, en cambio, centra la atención en la seguridad del producto en sí.

En efecto, la normativa trata la ciberseguridad de forma similar a la seguridad tradicional de los productos. Del mismo modo que se espera que los fabricantes garanticen que los productos físicos cumplen con las normas de seguridad antes de su comercialización, la CRA exige que los productos digitales cumplan con los requisitos básicos de ciberseguridad antes de poder venderse en la UE. Esto tiene importantes implicaciones para los equipos de desarrollo de productos, los departamentos de ingeniería, los proveedores de software, los responsables de compras y las cadenas de suministro.

Esto también refuerza una tendencia de mercado más amplia. Clientes, reguladores, aseguradoras e inversores esperan cada vez más que las organizaciones demuestren no solo que pueden responder a incidentes cibernéticos, sino también que la seguridad se ha integrado en los productos desde el principio.

¿A quién se aplica la CRA?

Un error común es creer que la normativa solo se aplica a organizaciones con sede en la UE. En realidad, la CRA se aplica a cualquier organización que comercialice productos que cumplan los requisitos en el mercado de la UE, independientemente de dónde tenga su sede. Esto significa que las organizaciones del Reino Unido, Estados Unidos y de todo el mundo pueden estar sujetas a la normativa si venden productos con componentes digitales en Europa.

Se prevé que la normativa afecte a una amplia gama de organizaciones, entre ellas:

• Proveedores de software
• Proveedores de SaaS y servicios en la nube
• Fabricantes de IoT
• Fabricantes de hardware con software integrado
• Proveedores de tecnología industrial
• Importadores y distribuidores de productos digitales

Los fabricantes son quienes tienen la mayor responsabilidad en virtud de la normativa, ya que son responsables de garantizar su cumplimiento durante todo el ciclo de vida del producto.

También existen categorías de "productos críticos" que están sujetos a un mayor escrutinio y a requisitos de evaluación de la conformidad más rigurosos debido al nivel de riesgo cibernético asociado a ellos.

Lo que exige la CRA

El impacto operativo de la CRA es donde muchas organizaciones probablemente sentirán la mayor presión. La normativa no se limita a crear documentación o actualizar políticas. Exige que las organizaciones demuestren que la seguridad se ha implementado a lo largo de todo el ciclo de vida del producto. Esto incluye incorporar principios de seguridad desde el diseño en los procesos de desarrollo, mantener capacidades efectivas de gestión de vulnerabilidades, emitir actualizaciones de seguridad adecuadas y conservar evidencia técnica del cumplimiento.

Para muchas empresas, esto requerirá una mayor visibilidad de los componentes de software, las dependencias, los proveedores y los riesgos de terceros. También implicará un mayor énfasis en procesos de gestión de vulnerabilidades maduros y vías de escalamiento más claras entre los equipos de seguridad, ingeniería, producto y cumplimiento normativo. En la práctica, algunas organizaciones podrían descubrir que el mayor desafío no reside en comprender la normativa en sí, sino en la preparación operativa.

Notificación de incidentes en virtud de la CRA y la plataforma ENISA

Uno de los aspectos más importantes desde el punto de vista operativo de la CRA es la introducción de obligaciones obligatorias de notificación de incidentes y vulnerabilidades. Los fabricantes deberán informar lo siguiente:

• Vulnerabilidades explotadas activamente
• Incidentes graves que afectan la seguridad de productos con elementos digitales.

Es importante destacar que las obligaciones de notificación están vinculadas específicamente a la seguridad del producto y a la explotación de vulnerabilidades. Esto hace que la CRA sea distinta de los requisitos de notificación de violación más amplios establecidos en regulaciones como GDPR o NIS 2..

Los plazos en sí mismos son intencionadamente exigentes. Artículo 14 de la CRA, Se espera que las organizaciones presenten lo siguiente:

• Notificación de alerta temprana dentro de las 24 horas posteriores a tener conocimiento de una vulnerabilidad explotada activamente o un incidente grave.
• Recibirá una notificación más detallada en un plazo de 72 horas.
• Un informe final en el plazo de un mes.

Para muchas organizaciones, estos periodos de notificación pueden resultar difíciles de lograr operativamente, especialmente cuando las cadenas de suministro de software son complejas o la visibilidad de las dependencias es limitada.

El reglamento también introduce una estructura centralizada de presentación de informes vinculada a la Agencia de la Unión Europea para la Ciberseguridad (ENISA). ENISA está desarrollando una Plataforma Única de Informes (SRP). Diseñado para simplificar la presentación de informes en todos los Estados miembros. En lugar de exigir a las empresas que notifiquen por separado a múltiples autoridades nacionales, el objetivo es crear un mecanismo de presentación de informes más unificado. El flujo de informes publicado actualmente describe el proceso previsto de la siguiente manera:

• Un fabricante identifica una vulnerabilidad explotada o un incidente grave.
• La notificación inicial se envía a través de la plataforma de informes de ENISA.
• Se informa a las autoridades nacionales pertinentes y a los Equipos de Respuesta a Incidentes de Seguridad Informática (CSIRT, por sus siglas en inglés).
• Posteriormente, la información técnica de seguimiento y los detalles de la subsanación se envían a través de la misma estructura.

En el momento de redactar este informe, la plataforma aún se encuentra en desarrollo, y las obligaciones de presentación de informes comenzarán a aplicarse a partir de septiembre de 2026.

Desde el punto de vista operativo, es probable que estas obligaciones ejerzan una mayor presión sobre:

• Monitoreo de vulnerabilidades
• procedimientos de escalamiento interno
• Visibilidad de la lista de materiales del software (SBOM)
• Supervisión de proveedores
• Coordinación de respuesta a incidentes
• Comunicación interfuncional entre los equipos de ingeniería, seguridad, legal y cumplimiento normativo.

Fechas clave que las empresas deben conocer

Hay dos fechas importantes para las que las organizaciones ya deberían estar preparándose.

A partir del 11 de septiembre de 2026, comenzarán a aplicarse las obligaciones de la CRA en materia de notificación de vulnerabilidades e incidentes.

Las obligaciones de cumplimiento más amplias entrarán en vigor a partir del 11 de diciembre de 2027. Para entonces, los productos que entren en el mercado de la UE deberán cumplir los requisitos de ciberseguridad de la CRA, mantener la documentación técnica, completar las evaluaciones de conformidad pertinentes y cumplir con las obligaciones de marcado CE asociadas– el requisito de marcado de conformidad, habitual en la seguridad física de los productos, que confirma que un producto cumple con las normas reglamentarias aplicables de la UE antes de su comercialización.

Aunque esos plazos puedan parecer lejanos, muchas organizaciones con cadenas de suministro complejas o visibilidad limitada de la base de datos de operaciones ya están descubriendo que la preparación operativa lleva mucho más tiempo del previsto.

Lo que las empresas suelen entender mal sobre la CRA (Agencia Tributaria Canadiense).

Uno de los malentendidos más comunes es creer que la CRA es principalmente una regulación del IoT. Si bien los dispositivos de consumo conectados están ciertamente dentro de su alcance, la regulación se aplica de manera mucho más amplia de lo que muchas organizaciones suponen inicialmente. El software empresarial, las plataformas conectadas a la nube, las tecnologías industriales, los sistemas de software embebido y una amplia gama de productos conectados pueden verse afectados.

Otro error común es creer que la normativa solo se aplica a las organizaciones con sede en la UE. En realidad, la CRA se aplica a las organizaciones que comercializan productos con elementos digitales en el mercado de la UE, independientemente de dónde tenga su sede la empresa. Las organizaciones del Reino Unido y Estados Unidos que venden en Europa están sujetas a las mismas obligaciones que los proveedores con sede en la UE.

También existe la tendencia a subestimar la operatividad de la normativa. La CRA no es simplemente un ejercicio de documentación ni otro marco de cumplimiento normativo. Exige que las organizaciones demuestren prácticas de desarrollo seguras, procesos de gestión de vulnerabilidades, capacidades de gestión de parches y mantenimiento continuo de la seguridad de los productos.

Esto significa que es probable que la regulación tenga un impacto en:

• Equipos de ingeniería y desarrollo
• Funciones del producto
• Operaciones de DevOps y seguridad
• Gestión de compras y proveedores
• Equipos legales y de cumplimiento
• Liderazgo ejecutivo

Muchas organizaciones también subestiman el tiempo de preparación necesario. Es poco probable que el mayor desafío sea comprender la normativa en sí. Con mayor frecuencia, la dificultad radica en la preparación operativa. Las deficiencias más comunes incluyen:

• Visibilidad limitada de los componentes y dependencias del software.
• Gestión incompleta de SBOM
• Supervisión deficiente de la seguridad de los proveedores
• Procesos de gestión de vulnerabilidades fragmentados
• Procedimientos de escalamiento y notificación inmaduros
• Dificultad para demostrar prácticas de desarrollo seguras desde el diseño

Finalmente, muchas empresas se centran inicialmente en las sanciones económicas asociadas a la normativa, pasando por alto las implicaciones comerciales más amplias. Las autoridades pueden restringir las ventas, exigir medidas correctivas, obligar a la retirada de productos o incluso eliminar por completo del mercado de la UE los productos que no cumplan con la normativa. Para muchas organizaciones, el acceso continuo al mercado europeo puede convertirse, en última instancia, en el principal factor que impulse el cumplimiento de la normativa.

Las sanciones por incumplimiento

Las sanciones económicas contempladas en la Ley de Reforma de la Competencia (CRA, por sus siglas en inglés) son considerables. En los casos de infracciones más graves, las organizaciones pueden enfrentarse a multas de hasta 15 millones de euros o el 2.5 % de su facturación anual global, la cantidad que sea mayor. Estas sanciones pueden aplicarse cuando las organizaciones no cumplen con los requisitos de ciberseguridad, incumplen sus obligaciones de información o comercializan productos que no cumplen con la normativa.

Podrán aplicarse sanciones adicionales si las organizaciones proporcionan información inexacta o engañosa a los organismos reguladores.

Sin embargo, las sanciones económicas por sí solas no reflejan completamente el riesgo empresarial asociado a la normativa. El impacto potencial en el acceso al mercado, la confianza del cliente, la elegibilidad para la contratación pública y las relaciones con los proveedores podría resultar aún más significativo desde el punto de vista comercial.

Preparación para la CRA: ¿Por dónde empezar?

Para muchas organizaciones, La preparación requerirá más que revisar las políticas o actualizar la documentación de cumplimiento.Es probable que la normativa obligue a las empresas a examinar cómo se integra la seguridad en el diseño, desarrollo y mantenimiento de los productos, así como en la supervisión de los proveedores y la respuesta ante incidentes.

Para muchas organizaciones, el mejor punto de partida es el alcance: comprender qué productos están sujetos a la normativa y cuáles no. A partir de ahí, la preparación puede seguir una secuencia lógica:

Fundación: lograr visibilidad. La mayoría de las organizaciones constatan que la principal deficiencia inicial no radica en la madurez de los procesos, sino en la visibilidad básica; concretamente, en la capacidad de mapear los componentes y dependencias del software mediante una lista de materiales de software (SBOM) actualizada. Sin esto, la gestión de vulnerabilidades y la supervisión de proveedores carecen de una base sólida sobre la que construir.

Proceso: reforzar la vulnerabilidad y la respuesta ante incidentes. Una vez establecida la visibilidad, las organizaciones pueden evaluar la madurez de sus procesos de gestión de vulnerabilidades, su capacidad para cumplir con los plazos de presentación de informes estrictos de la CRA y la eficacia de las vías de escalamiento entre las funciones de ingeniería, seguridad y cumplimiento.

Garantía: evidencia de prácticas seguras desde el diseño. La capa final consiste en demostrar que la seguridad se ha integrado en el propio ciclo de vida del desarrollo, y no se ha añadido posteriormente. Aquí es donde normalmente se Las organizaciones con marcos de gobernanza maduros, como la norma ISO 27001, se encuentran en una mejor posición.La infraestructura de control ya existe; es necesario ampliarla y orientarla hacia la seguridad del producto.

Por ello, muchas empresas están adaptando cada vez más sus marcos de gobernanza y seguridad existentes a los nuevos requisitos de seguridad de los productos. Si bien los marcos por sí solos no garantizan el cumplimiento, las organizaciones con una gobernanza, gestión de riesgos, supervisión de proveedores y capacidades de respuesta a incidentes maduras estarán en una posición más sólida cuando entren en vigor las obligaciones de la CRA.

La dirección del viaje

La Ley de Resiliencia Cibernética representa una evolución significativa en la regulación de la ciberseguridad. En lugar de centrarse únicamente en la gobernanza o la resiliencia organizacional, la Ley traslada las expectativas de ciberseguridad directamente a los productos digitales. Para las organizaciones que venden en el mercado europeo, esto probablemente se convierta no solo en una cuestión de cumplimiento, sino también en una cuestión de estrategia de producto, resiliencia operativa y confianza comercial.

Es probable que las organizaciones mejor posicionadas para responder con éxito sean aquellas que dejen de considerar la CRA como un ejercicio de cumplimiento de último minuto y, en cambio, la traten como parte de un cambio más amplio hacia operaciones seguras desde el diseño, una mayor resiliencia y una mayor responsabilidad del producto.

En definitiva, la CRA refleja una realidad más amplia a la que se enfrentan las empresas modernas: la ciberseguridad ya no es simplemente responsabilidad del departamento de TI. Se está convirtiendo cada vez más en una expectativa fundamental para la calidad del producto, la confianza del cliente y el acceso al mercado.

Amplíe su conocimiento

Blog: De NIS2 a la Ley de Resiliencia Cibernética: El aspecto “producto” de la gobernanza

Blog: Cuidado con la brecha: El incidente de Salesforce y la naturaleza cambiante del riesgo en la nube.

Podcast: Phishing para causar problemas T02 E05: Cumples con las normas. ¿Eres resiliente?