Durante años, la ciberseguridad del software se ha considerado, ante todo, una tarea técnica. El equipo de desarrollo debía ocuparse de la seguridad del código, los administradores, de la configuración de la infraestructura y, tras la puesta en marcha, había que responder a los problemas notificados y publicar parches. Este modelo sigue vigente en muchas organizaciones.
El reglamento europeo Cyber Resilience Act, abreviado CRA, refuerza un enfoque distinto: la seguridad de un producto digital debe tenerse en cuenta desde el inicio de su diseño y mantenerse durante todo el periodo de soporte. No se trata únicamente de proteger un sistema el día de su lanzamiento, sino también de gestionar las vulnerabilidades, las actualizaciones, la documentación, la responsabilidad del fabricante y la capacidad de responder a incidentes.
Para las empresas que desarrollan software, crean sus propios productos digitales o los introducen en el mercado europeo, esto implica que deben revisar no solo el código, sino también los procesos empresariales y organizativos.
Es importante señalar que el CRA ya no es una regulación cuya preparación pueda aplazarse hasta un futuro lejano. El reglamento entró en vigor el 10 de diciembre de 2024. Las obligaciones relativas a la notificación de determinadas vulnerabilidades e incidentes graves comenzaron a aplicarse el 11 de septiembre de 2026, mientras que la mayor parte de los requisitos será aplicable a partir del 11 de diciembre de 2027. Se trata de dos fases distintas que no deben confundirse.
¿Qué es el Cyber Resilience Act?
El Cyber Resilience Act es un reglamento de la Unión Europea sobre la ciberseguridad de los productos que contienen elementos digitales. Su objetivo es elevar el nivel de seguridad de estos productos disponibles en el mercado de la Unión Europea y reducir los casos en los que los usuarios reciben soluciones vulnerables a ataques, insuficientemente protegidas o carentes de un soporte adecuado.
La regulación abarca una amplia categoría de productos de hardware y software cuyo uso previsto o uso razonablemente previsible implique una conexión lógica o física, directa o indirecta, con un dispositivo o una red. El ámbito puede incluir tanto productos terminados como componentes digitales introducidos en el mercado por separado.
En la práctica, esto significa que el CRA no afecta únicamente a los dispositivos asociados con el Internet de las cosas. En las circunstancias pertinentes, la regulación también puede abarcar software, sistemas operativos, aplicaciones u otros componentes digitales ofrecidos en el mercado.
Sin embargo, es importante distinguir entre el mero desarrollo de software y la introducción de un producto en el mercado. No todos los servicios de programación, sitios web o sistemas creados por encargo están sujetos automáticamente a las mismas obligaciones. Entre los factores relevantes figuran la naturaleza de la solución, la forma en que se ofrece, el papel de cada empresa y las posibles excepciones previstas en la normativa.
Por eso, el primer paso no debería ser implantar sin criterio todos los procedimientos posibles. Primero hay que determinar si un producto concreto entra en el ámbito del CRA y qué papel corresponde a la organización en cuestión.
¿Por qué cambia el CRA el enfoque del desarrollo de software?
El cambio más importante es que la ciberseguridad deja de ser únicamente un conjunto de acciones que se llevan a cabo con motivo del lanzamiento o después de detectar un problema. Se convierte en un elemento de todo el ciclo de vida del producto.
En este modelo, la seguridad debe tenerse en cuenta durante el análisis de requisitos, el diseño de la arquitectura, la implementación, las pruebas, la preparación del lanzamiento, el mantenimiento y la planificación del fin del soporte. No basta con afirmar que una aplicación funciona correctamente. También hay que comprender los riesgos asociados a sus funciones, dependencias, método de actualización e integraciones.
Por ejemplo, un equipo puede proteger correctamente su propio código y, al mismo tiempo, utilizar una biblioteca en la que se haya detectado una vulnerabilidad. Un producto puede disponer de un mecanismo de inicio de sesión, pero gestionar incorrectamente los permisos. Puede haber actualizaciones disponibles sin que exista un procedimiento de distribución claramente definido. La empresa también puede desconocer qué versiones del producto siguen utilizando sus clientes.
Cada uno de estos casos demuestra que la seguridad no depende exclusivamente de las competencias de los programadores. También requiere controlar las dependencias, contar con un proceso para responder a las notificaciones, mantener documentación y asumir la responsabilidad del producto después de ponerlo a disposición del público.
Por tanto, el CRA refuerza una tendencia hacia la que debería avanzar todo proceso maduro de desarrollo de software, independientemente de la propia regulación: la seguridad debe diseñarse, verificarse y mantenerse, no limitarse a declarar.
¿A quién afectan las normas y por qué es necesario determinar el papel de la empresa?
El CRA dirige sus obligaciones principales a los fabricantes de productos con elementos digitales. Según el reglamento, es fabricante la entidad que desarrolla un producto o encarga su desarrollo y, posteriormente, lo pone a disposición del mercado con su propio nombre o marca registrada.
Esta distinción es importante para las empresas de desarrollo de software y las empresas tecnológicas.
Si una empresa crea un sistema por encargo de un cliente, eso no significa automáticamente que vaya a ser fabricante en el sentido del CRA en todos los casos. Son relevantes el modelo concreto de colaboración, la forma en que se pone a disposición el producto y quién figura como entidad responsable en el mercado. Tampoco puede darse por sentado que la responsabilidad recaiga siempre exclusivamente en el cliente. En determinados modelos de negocio, la situación puede ser distinta.
Conviene analizar varios escenarios habituales:
-
Empresa que desarrolla un producto SaaS o una aplicación propia bajo su marca. Hay que comprobar si el producto entra en el ámbito del CRA y si la forma en que se ofrece y su arquitectura hacen que esté sujeto a la regulación.
-
Empresa de desarrollo de software que crea un sistema para un cliente. Hay que determinar quién pondrá la solución a disposición del mercado, bajo qué marca y qué papel desempeña cada parte. El mero hecho de escribir el código no resuelve todas las cuestiones jurídicas.
-
Fabricante que integra componentes de otros proveedores. Puede ser necesario analizar no solo la propia solución, sino también las dependencias, la forma de actualizarlas y la información de seguridad que proporcionan los proveedores.
-
Empresa que vende con su propia marca un producto desarrollado por otra entidad. Este modelo puede tener consecuencias distintas de las de la mera prestación de servicios de programación y requiere una evaluación específica.
-
Proveedor de un componente de software. Si el componente se pone a disposición del mercado por separado, puede requerir un análisis propio del ámbito de aplicación de la regulación.
Esta no es una lista exhaustiva de casos ni una calificación jurídica formal. Su propósito es mostrar por qué conviene empezar por cartografiar los productos y las funciones, en lugar de afirmar de forma general que «el CRA afecta a todos los programadores».
El Reglamento también contempla exclusiones y normas especiales, entre otras, para determinadas categorías de productos regulados por normativa específica y ciertos casos de software de código abierto. Sin embargo, los detalles de estas exclusiones no deben interpretarse basándose únicamente en el nombre del producto o el modelo de licencia. Es necesario analizar cada situación concreta.
Plazos del CRA: ¿qué se aplica ya y qué llegará en 2027?
Las fechas son clave para planificar el cumplimiento de la normativa. Conviene distinguir entre la entrada en vigor del Reglamento, el inicio de la aplicación de las obligaciones de notificación y el inicio de la aplicación de la mayor parte de los requisitos.
10 de diciembre de 2024: entrada en vigor del CRA. El Reglamento fue adoptado y entró en vigor, pero esto no supuso que todas las obligaciones comenzaran a aplicarse al mismo tiempo.
11 de septiembre de 2026: inicio de la aplicación de las obligaciones de notificación del artículo 14. Los fabricantes de productos sujetos a la normativa deben notificar las vulnerabilidades explotadas activamente y los incidentes graves que afecten a la seguridad del producto cuando tengan conocimiento de ellos. Estas obligaciones tienen sus propios plazos y procedimientos de notificación.
11 de diciembre de 2027: inicio de la aplicación de la mayor parte del CRA. A partir de esta fecha comenzarán a aplicarse los principales requisitos del Reglamento relativos a los productos con elementos digitales, incluidos los requisitos relacionados con la seguridad del producto, la gestión de vulnerabilidades y los procedimientos de evaluación de la conformidad, de acuerdo con las disposiciones pertinentes.
Un detalle importante: las obligaciones de notificación que comenzaron a aplicarse en septiembre de 2026 también se aplican a los productos sujetos al CRA que se comercializaron antes del 11 de diciembre de 2027. Por tanto, no debe suponerse que todas las obligaciones relacionadas con la normativa comienzan en diciembre de 2027.
También existen disposiciones transitorias, y la situación de los productos que ya están en el mercado puede depender de circunstancias concretas, entre ellas, si el producto es objeto de una modificación sustancial después de que comience a aplicarse la mayor parte del Reglamento. Por este motivo, conviene considerar las fechas como punto de partida para el análisis y no como una respuesta por sí solas a la pregunta de cuáles son las obligaciones de una empresa concreta.
Las principales fuentes de información son el resumen oficial de la Comisión Europea y su página dedicada a la notificación en el marco del CRA.
Notificación de vulnerabilidades e incidentes: una obligación que ya ha comenzado a aplicarse
Uno de los aspectos más prácticos del CRA es la obligación de notificar determinados eventos relacionados con la seguridad de los productos.
No se trata de notificar cada pequeño defecto, cada error de una aplicación ni cada posible vulnerabilidad mencionada por alguien en un comentario no verificado. La normativa establece categorías concretas de eventos, entre ellas las vulnerabilidades explotadas activamente y los incidentes graves que afectan a la seguridad del producto.
En términos generales, una vulnerabilidad explotada activamente es aquella respecto de la cual existen pruebas fiables de que un atacante la ha explotado sin autorización. Un incidente grave es un evento que tiene un impacto significativo en la seguridad del producto. Para determinar si un evento cumple los criterios legales, es necesario tener en cuenta las circunstancias y las definiciones pertinentes, y no basarse únicamente en la valoración intuitiva del equipo.
Para los fabricantes sujetos a la obligación de notificación, los plazos principales incluyen:
-
24 horas para una alerta inicial desde que se tiene conocimiento del evento sujeto a la obligación;
-
72 horas para la notificación principal;
-
en el caso de una vulnerabilidad explotada activamente, un informe final en un plazo máximo de 14 días después de que se ponga a disposición una medida correctiva o de mitigación;
-
en el caso de un incidente grave, un informe final en el plazo de un mes desde la notificación realizada en 72 horas.
Los plazos y requisitos deben interpretarse de acuerdo con las disposiciones pertinentes y las directrices vigentes. El resumen anterior no debe considerarse una instrucción jurídica completa aplicable a todos los casos.
Las notificaciones se envían a través de la plataforma única de notificación del CRA de la UE (CRA Single Reporting Platform), gestionada por ENISA. De acuerdo con las normas del sistema, el fabricante presenta la notificación a través de esta plataforma, y el CSIRT competente y ENISA participan en las fases posteriores del proceso.
¿Qué implica esto en la práctica? Una empresa no debería esperar a que se detecte un problema para plantearse quién evaluará su gravedad, quién decidirá si se debe notificar y de dónde obtener la información necesaria para preparar el informe.
Conviene establecer con antelación un proceso que incluya, como mínimo:
-
la recepción de notificaciones de clientes, investigadores de seguridad y otras fuentes;
-
la verificación de si la notificación se refiere a una vulnerabilidad o un incidente real;
-
la evaluación del impacto en el producto y la determinación de si el evento puede estar sujeto a la obligación de notificación;
-
la designación de las personas responsables de las decisiones técnicas, organizativas y formales;
-
la preparación de la información requerida y la gestión de los plazos;
-
la elaboración de una corrección u otras medidas para reducir el riesgo;
-
la información a los destinatarios pertinentes de acuerdo con las obligaciones aplicables;
-
la documentación de las acciones y la extracción de conclusiones una vez finalizado el incidente.
No todas las empresas necesitan crear para ello un departamento de seguridad amplio. La dimensión del proceso debe corresponderse con las características del producto, el riesgo y la estructura de la organización. Sin embargo, debe ser lo bastante concreto como para poder actuar con rapidez en una situación de crisis, en lugar de tener que establecer entonces las reglas básicas de responsabilidad.
Seguridad desde el diseño y seguridad por defecto
Dos conceptos describen especialmente bien la dirección que sigue el CRA: seguridad desde el diseño y seguridad por defecto.
La seguridad desde el diseño significa tener en cuenta la seguridad desde la fase de diseño del producto. La seguridad por defecto supone que la configuración predeterminada debe favorecer un uso seguro de la solución, en lugar de exigir al usuario que corrija por su cuenta configuraciones inseguras.
En la práctica, esto no se limita a una sola función ni a una lista de controles en el panel de administración. Se trata de un conjunto de decisiones arquitectónicas y de implementación que afectan a la seguridad de todo el producto.
En función de las características de la solución, conviene analizar, entre otros aspectos:
-
los métodos de autenticación y la gestión de sesiones;
-
el modelo de permisos y el control del acceso a los datos;
-
el almacenamiento seguro de secretos y credenciales;
-
la protección de los datos durante su transmisión y almacenamiento;
-
los mecanismos de actualización y su seguridad;
-
la gestión de errores y el registro de eventos;
-
la reducción de la superficie de ataque y la desactivación de funciones innecesarias;
-
la configuración predeterminada, incluida la ausencia de ajustes iniciales inseguros;
-
la gestión de vulnerabilidades en componentes propios y de terceros.
No todas las medidas serán necesarias para todos los productos de la misma manera. Una aplicación móvil requiere unas soluciones, un sistema integrado otras y una plataforma empresarial compleja, otras distintas. Por eso, el análisis de riesgos debe preceder a la selección de mecanismos concretos.
También es importante tener en cuenta que la seguridad no termina en el código. Una configuración incorrecta del entorno, permisos excesivos, acceso no controlado al repositorio o un proceso poco meditado de publicación de actualizaciones pueden socavar la calidad incluso de una solución bien diseñada.
Análisis de riesgos y documentación técnica
El CRA contempla un enfoque basado en la evaluación de los riesgos de ciberseguridad del producto. Este análisis debe influir en las decisiones relativas al diseño, desarrollo, producción, entrega y mantenimiento de la solución.
Conviene empezar por algunas preguntas básicas:
-
¿Qué datos trata el producto y qué consecuencias tendría su divulgación, modificación o pérdida de disponibilidad?
-
¿Con qué dispositivos, redes y servicios externos se comunica el sistema?
-
¿Qué permisos tiene la aplicación y quién puede utilizarlos?
-
¿Cuáles son las dependencias tecnológicas más importantes?
-
¿Qué ocurrirá si una de las dependencias resulta ser vulnerable?
-
¿Cómo puede el fabricante distribuir una corrección y comprobar que se ha implementado?
-
¿Qué riesgos persisten tras aplicar las medidas de seguridad?
Las respuestas no deben quedar únicamente en la cabeza de los programadores. Según el producto y las obligaciones del fabricante, será importante disponer de documentación técnica que muestre, entre otras cosas, qué solución se ha comercializado, qué riesgos se han identificado y cómo se cumplen los requisitos pertinentes.
Una buena documentación no es solo material preparado para una auditoría. También ayuda a desarrollar el sistema, transferir responsabilidades entre equipos, reconstruir decisiones arquitectónicas y responder a problemas tras la implementación.
Esto no significa que todas las empresas deban preparar de inmediato un documento enorme que describa todos los escenarios posibles. El alcance de la documentación debe depender del tipo de producto y de los requisitos aplicables. Lo fundamental es que los documentos estén actualizados, sean coherentes con la solución real y puedan utilizarse en el trabajo.
Dependencias y componentes externos: la seguridad de toda la cadena de suministro
El software actual rara vez se desarrolla completamente desde cero. Utiliza bibliotecas, frameworks, componentes ya preparados, motores de bases de datos, sistemas operativos y servicios externos. Esto acelera el desarrollo, pero también significa que la seguridad del producto depende en parte de elementos que el fabricante no controla plenamente.
Si se descubre una vulnerabilidad en una biblioteca popular, el problema puede afectar a muchos productos independientes. El mero hecho de que una biblioteca proceda de un proyecto reconocido no garantiza que siga siendo segura durante todo el tiempo que se utilice.
Por eso conviene conocer la composición tecnológica del producto y poder determinar qué componentes se han utilizado, en qué versiones y en qué partes del sistema. Entre las medidas útiles se encuentran el control de dependencias, el análisis de vulnerabilidades, el registro de cambios y los procedimientos de actualización.
En procesos más maduros también se utilizan inventarios de componentes de software, conocidos como SBOM (lista de materiales de software). Este tipo de inventario puede facilitar la identificación de bibliotecas y otros elementos afectados por una vulnerabilidad recién descubierta. Sin embargo, no debe suponerse que el SBOM por sí solo garantiza el cumplimiento del CRA. Es una herramienta de apoyo para la gestión de componentes, no un sustituto de todo el proceso de seguridad ni de la documentación exigida para un producto concreto.
La relación con los proveedores también es importante. La empresa debe saber cómo recibe información sobre vulnerabilidades, quién se encarga de actualizar los componentes utilizados y con qué rapidez puede responder a un problema crítico.
Esto es especialmente importante en sistemas empresariales de larga vida útil, en los que sustituir una sola biblioteca puede afectar a las integraciones, la compatibilidad o la estabilidad de toda la solución.
Actualizaciones y período de soporte del producto
Una de las cuestiones más importantes es el mantenimiento del producto una vez comercializado. En el caso de los productos sujetos al CRA, el fabricante debe determinar el período de soporte y proporcionar una gestión adecuada de las vulnerabilidades durante ese período, de acuerdo con los requisitos del reglamento.
Esto significa que la seguridad debe planificarse no solo para el momento en que se lanza el producto, sino también para los meses y años posteriores de uso.
En la práctica, conviene determinar:
-
quién supervisa la información sobre nuevas vulnerabilidades;
-
cómo se evalúa su impacto en el producto;
-
quién decide si se prepara una corrección;
-
cómo se prueban y publican las actualizaciones;
-
cómo se informa a los usuarios o clientes;
-
durante cuánto tiempo se ofrecerá soporte para el producto;
-
cómo se comunica el fin del período de soporte.
La previsibilidad también es importante. El usuario debe recibir información clara sobre la seguridad y el soporte del producto. Decir simplemente que el fabricante «preparará una actualización cuando sea necesario» no sustituye un proceso que permita gestionar realmente una vulnerabilidad detectada.
No todas las actualizaciones tienen que seguir el mismo procedimiento. Sin embargo, el equipo debe saber distinguir los cambios funcionales habituales de las correcciones de seguridad y evaluar cuándo el riesgo exige actuar con mayor rapidez.
Desde el punto de vista empresarial, también conviene recordar que mantener el software cuesta dinero. Si el modelo de venta no tiene en cuenta el período de soporte, la supervisión de dependencias, la respuesta a vulnerabilidades y la distribución de correcciones, la empresa puede prometer al cliente más de lo que puede ofrecer de forma responsable.
Por tanto, el CRA no es solo un tema para el equipo técnico. Puede influir en la oferta, los contratos, el precio del producto, la planificación del desarrollo y la forma de comunicar las condiciones de soporte.
Pruebas de seguridad y proceso de lanzamiento de nuevas versiones
La seguridad de un producto no puede confirmarse de forma fiable con una única prueba realizada justo antes del lanzamiento. Se necesita un proceso que ayude a detectar problemas a medida que se desarrolla el software.
Según el tipo de producto y el nivel de riesgo, puede incluir revisiones de código, análisis estático, pruebas de dependencias, análisis de configuración, pruebas dinámicas y pruebas de penetración. Las herramientas automatizadas son útiles, pero sus resultados requieren interpretación. No todas las alertas indican una amenaza real, y la ausencia de alertas no demuestra que el sistema sea seguro.
También conviene integrar las actividades de seguridad en el proceso CI/CD, es decir, en la automatización de la compilación, las pruebas y el despliegue del software. De este modo, determinados controles pueden ejecutarse con regularidad y no solo cuando alguien se acuerda de activarlos.
No se trata de bloquear cada cambio con decenas de controles descoordinados. Se trata de elegir las pruebas en función del riesgo y establecer reglas claras sobre qué hacer cuando un control detecta un problema. El equipo debe saber qué errores impiden lanzar una versión, cuáles requieren un análisis adicional y quién puede aceptar el riesgo restante.
El proceso de lanzamiento de versiones también debe permitir identificar una versión concreta del producto, reconstruir los cambios importantes y vincular una corrección con el problema que pretende resolver. Esto facilita el análisis de incidentes y ayuda a demostrar qué medidas se han tomado.
En el caso del CRA, el conjunto detallado de acciones necesarias depende del producto y del procedimiento de evaluación de la conformidad correspondiente. Por tanto, conviene considerar las pruebas y la automatización como elementos que ayudan a cumplir los requisitos, y no como un certificado de conformidad independiente.
¿El CRA también afecta a las pequeñas empresas y a las empresas de desarrollo de software?
El tamaño de la organización no debería ser el único criterio para decidir si merece la pena analizar el tema. Lo fundamental es qué producto crea o comercializa la empresa, qué función desempeña y qué obligaciones se derivan de la normativa.
Las pequeñas empresas pueden disponer de menos recursos que los grandes fabricantes, pero también desarrollan productos digitales, integran componentes y mantienen sistemas que utilizan sus clientes. Por eso, conviene empezar con medidas proporcionales a la escala de la actividad, en lugar de dar por sentado que prepararse para el CRA implica poner en marcha desde el primer día un costoso programa de compliance.
Para una empresa pequeña, un buen punto de partida puede ser elaborar una lista de productos, determinar las funciones jurídicas, identificar las dependencias más importantes, describir el proceso de gestión de vulnerabilidades y designar a las personas responsables de la seguridad. Solo después se podrá determinar qué controles adicionales, documentos o consultas son realmente necesarios.
No debe suponerse que todas las entidades pequeñas están exentas de obligaciones. El CRA incluye normas específicas y soluciones proporcionales en determinados casos, pero no pueden reducirse a la regla general de que una pequeña empresa no tiene que prepararse.
También conviene diferenciar las obligaciones del fabricante de las expectativas de sus clientes. Aunque una empresa de desarrollo de software no sea el fabricante de un producto concreto a efectos del CRA, el cliente puede solicitar información sobre los componentes utilizados, la forma de gestionar las vulnerabilidades, las actualizaciones o la documentación técnica. Unos acuerdos claros reducen el riesgo de que, tras la implementación, cada parte dé por sentado que la seguridad es responsabilidad de la otra.
¿Cómo preparar una empresa para el CRA? Lista práctica de acciones
El mejor punto de partida es un plan basado en los productos, los procesos y las responsabilidades reales. Los siguientes pasos no constituyen una lista completa de los requisitos legales aplicables a todos los casos, pero ayudan a organizar los preparativos.
1. Elabora un inventario de productos digitales. Identifica las soluciones comercializadas, su finalidad, su forma de distribución y sus componentes más importantes. No te limites a los productos que la empresa desarrolla activamente. Incluye también las versiones que mantiene y pone a disposición de sus clientes.
2. Determina la función de la empresa en relación con cada producto. Comprueba quién desarrolla la solución, quién encarga su desarrollo, bajo qué marca se comercializa y quién es responsable del producto en el mercado. Si el modelo de colaboración no es habitual, no bases la decisión exclusivamente en el nombre coloquial del servicio.
3. Verifica el ámbito de aplicación de la normativa y las posibles exclusiones. Para cada producto, evalúa si está incluido en el ámbito del CRA, qué disposiciones pueden aplicarse y si hay circunstancias que requieran una interpretación especial. En caso de duda, consulta las directrices vigentes de la Comisión Europea y solicita asesoramiento jurídico adecuado.
4. Realiza una evaluación de riesgos. Identifica las principales amenazas, los datos, las integraciones, las dependencias y las posibles consecuencias de un incidente. A partir de ahí, determina qué medidas de seguridad y controles son adecuados para el producto.
5. Describe el proceso de gestión de vulnerabilidades. Determina dónde se reciben las notificaciones, cómo se verifican, quién evalúa su gravedad, cómo se preparan las correcciones y cómo se documentan las decisiones. El proceso también debe funcionar si el problema surge fuera del horario laboral habitual.
6. Prepara un procedimiento de notificación. Dado que las obligaciones de notificación del artículo 14 ya son aplicables, las entidades sujetas a estas obligaciones deben conocer los criterios de notificación, los plazos exigidos y cómo utilizar la CRA Single Reporting Platform. El procedimiento interno debe permitir recopilar información sin demoras innecesarias.
7. Revisa las dependencias tecnológicas. Comprueba las bibliotecas, los frameworks y otros componentes que utiliza el producto. Plantéate si la empresa puede determinar rápidamente qué versiones de su software están expuestas a una vulnerabilidad recién descubierta.
8. Verifica las actualizaciones y el periodo de soporte. Determina cómo se preparan, prueban y publican las correcciones de seguridad, y cómo se comunican las condiciones de soporte. Evalúa si el modelo de mantenimiento actual se ajusta a lo prometido a los clientes y a los requisitos aplicables al producto en cuestión.
9. Revisa la documentación. Reúne la información técnica y sobre los procesos necesaria para gestionar la seguridad y demostrar el cumplimiento de los requisitos pertinentes. La documentación debe reflejar el producto real, no solo el funcionamiento previsto.
10. Define las responsabilidades del equipo y en los contratos. Determina quién es responsable de la seguridad del producto, quién toma las decisiones durante un incidente y cómo colaboran el fabricante, la empresa de desarrollo de software, los proveedores de componentes y el cliente. Asegúrate de que el alcance del soporte y de las actualizaciones esté claramente definido.
11. Comprueba la preparación en la práctica. Simula el escenario de detección de una vulnerabilidad grave. Comprueba si el equipo puede determinar el alcance del problema, identificar las versiones vulnerables, tomar decisiones y preparar una corrección. La mera existencia de un procedimiento en un documento no garantiza que funcione ante un incidente real.
12. Mantente al día de las directrices vigentes. Los detalles de la aplicación del CRA se desarrollan en los materiales de la Comisión Europea, y el reglamento incluye mecanismos y requisitos que deben interpretarse en el contexto de cada producto. Conviene consultar periódicamente las publicaciones oficiales y actualizar el plan de preparación.
Errores más frecuentes al prepararse
El primer error es posponer el tema hasta finales de 2027. Esto pasa por alto que las obligaciones de notificar determinados sucesos ya han comenzado y que preparar los procesos de seguridad puede exigir cambios organizativos, técnicos y contractuales.
El segundo error es suponer que el CRA solo afecta a los fabricantes de equipos. El reglamento también abarca las categorías pertinentes de software y componentes digitales, aunque el ámbito de aplicación debe evaluarse en relación con cada producto concreto.
El tercer error es creer que basta con comprar una herramienta para escanear vulnerabilidades. Una herramienta puede ayudar a detectar problemas, pero no sustituye la evaluación de riesgos, la responsabilidad en la toma de decisiones, el proceso de actualización, la gestión de notificaciones ni la documentación requerida.
El cuarto error es tratar el cumplimiento como un proyecto puntual. El producto cambia con el tiempo, aparecen nuevas vulnerabilidades, se actualizan los componentes y puede evolucionar la forma de utilizar la solución. El proceso de seguridad debe tener en cuenta esta dinámica.
El quinto error es no definir claramente el reparto de responsabilidades entre el fabricante, el proveedor de servicios y el cliente. Tanto en los contratos como en la práctica del equipo, debe quedar claro quién supervisa las vulnerabilidades, prepara las correcciones, comunica los problemas y toma las decisiones.
El sexto error consiste en crear documentación que no refleja el estado real del producto. Un documento que describa una arquitectura de hace varios años, una lista de componentes desactualizada o un procedimiento que nadie conoce no proporcionarán una buena base para responder a incidentes.
CRA como impulso para poner en orden el proceso de desarrollo de software
Los nuevos requisitos regulatorios pueden percibirse como una obligación adicional, pero prepararse para el CRA también brinda la oportunidad de comprobar cómo gestiona la empresa la seguridad de sus propios productos.
¿Se sabe de qué componentes está compuesto el sistema? ¿Puede el equipo determinar rápidamente qué versiones requieren una corrección? ¿Las actualizaciones de seguridad siguen un proceso claramente definido? ¿Sabe el cliente durante cuánto tiempo recibirá soporte el producto? En caso de incidente, ¿se sabe quién toma las decisiones y qué acciones deben llevarse a cabo?
Si las respuestas a estas preguntas no están claras, el problema no empieza con la regulación. El CRA simplemente aumenta la importancia de ámbitos que ya influían en la seguridad, la mantenibilidad y la fiabilidad del producto.
El desarrollo de software maduro no consiste en prometer que nunca aparecerán errores. Consiste en limitar los riesgos, detectar rápidamente los problemas, responder de forma responsable y mantener el producto en un estado acorde con su finalidad y con los compromisos del fabricante.
¿Qué conviene hacer ahora?
Para empezar, no es necesario implantar de golpe todos los procedimientos posibles. Conviene elaborar una lista de productos, determinar las funciones de la organización, verificar el ámbito de aplicación del CRA y comprobar si funcionan los procesos básicos para gestionar vulnerabilidades e incidentes. Esto es especialmente urgente para las entidades que ya están sujetas a obligaciones de notificación.
La siguiente etapa consiste en analizar los riesgos, las dependencias, las actualizaciones, los periodos de soporte y la documentación. Solo entonces se pueden planificar cambios tecnológicos y organizativos concretos, así como evaluar si se necesita asesoramiento jurídico adicional o una evaluación especializada de la conformidad.
El Cyber Resilience Act no debería reducirse a una fecha en el calendario. Es una normativa que refuerza el enfoque de ciberseguridad a lo largo de todo el ciclo de vida de un producto digital. Cuanto antes comprenda la empresa a qué producto y a qué función se aplica su situación, más fácil será preparar un plan de acción proporcionado y práctico.
Importante: este artículo tiene carácter informativo y no constituye asesoramiento jurídico ni una evaluación formal de la conformidad. El alcance de las obligaciones debe determinarse a partir del texto íntegro del reglamento, las directrices vigentes y las circunstancias del producto concreto.
Fuentes y lecturas adicionales
-
Comisión Europea: Cyber Resilience Act: resumen de las disposiciones
-
Comisión Europea: Cyber Resilience Act: obligaciones de los fabricantes
-
Comisión Europea: Cyber Resilience Act: obligaciones de notificación
-
ENISA: Preguntas frecuentes sobre la plataforma de notificación del CRA
