Durante años hemos aceptado una dinámica peligrosa: lanzar primero, descubrir vulnerabilidades después y parchear cuando el problema ya está encima de la mesa.
Ese modelo empieza a tener los días contados en Europa. El Reglamento (UE) 2024/2847, conocido como Cyber Resilience Act (CRA), introduce un cambio de fondo: cuando un producto incorpora elementos digitales, la ciberseguridad deja de ser únicamente una buena práctica técnica y pasa a formar parte de las obligaciones legales del fabricante.
No estamos hablando solo de grandes plataformas. El reglamento alcanza, con las exclusiones y particularidades previstas en su propio texto, a una enorme variedad de productos con elementos digitales: software, dispositivos conectados, equipos de red, productos IoT y muchas soluciones que hoy forman parte de empresas, administraciones y hogares.
El cambio de mentalidad: la seguridad empieza antes de vender
La idea más importante del CRA es sencilla: un producto no debería llegar al mercado y empezar entonces a preguntarse si es seguro.
El artículo 13 obliga a los fabricantes, dentro del calendario de aplicación del Reglamento, a garantizar que sus productos hayan sido diseñados, desarrollados y producidos de acuerdo con los requisitos esenciales de ciberseguridad del anexo I. Además, exige una evaluación de los riesgos de ciberseguridad asociados al producto y que sus resultados se tengan en cuenta desde la planificación y el diseño hasta la producción, entrega y mantenimiento.
Eso cambia bastante el enfoque. La ciberseguridad deja de ser el equipo que aparece al final del proyecto para pasar una auditoría. Tiene que estar dentro del ciclo de vida del producto.
No todo el CRA es aplicable todavía
Aquí conviene ser precisos. El grueso del Cyber Resilience Act será aplicable a partir del 11 de diciembre de 2027.
Sin embargo, una parte especialmente relevante ya ha empezado a producir efectos. Desde el 11 de septiembre de 2026 es aplicable el artículo 14, relativo a determinadas obligaciones de notificación de vulnerabilidades explotadas activamente e incidentes graves que afecten a la seguridad de productos con elementos digitales.
Es decir: Europa ha empezado por exigir que determinados problemas graves de seguridad dejen de quedarse dentro de la empresa.
¿Qué cambia para un fabricante?
La consecuencia práctica es que fabricar software o hardware conectado ya no consiste únicamente en desarrollar funcionalidades.
Una organización tendrá que conocer los riesgos del producto, gestionar vulnerabilidades, mantener procedimientos internos de respuesta y poder demostrar que la seguridad ha formado parte del proceso.
Eso obliga a plantearse preguntas que deberían haberse hecho siempre:
- ¿Qué componentes y dependencias forman parte del producto?
- ¿Qué ocurre cuando se descubre una vulnerabilidad crítica?
- ¿Quién decide la prioridad de un parche?
- ¿Durante cuánto tiempo se mantendrán actualizaciones de seguridad?
- ¿Cómo se reciben avisos de investigadores externos?
- ¿Qué evidencias quedan de las decisiones adoptadas?
Si ninguna de esas preguntas tiene una respuesta clara, probablemente el problema no sea solo técnico.
La vulnerabilidad no termina cuando se publica el CVE
Durante demasiado tiempo hemos medido la gestión de vulnerabilidades por la capacidad de instalar parches.
Pero antes de parchear hay que saber que estamos afectados.
Un producto moderno puede depender de decenas o cientos de bibliotecas, frameworks, paquetes y componentes de terceros. Cuando aparece una vulnerabilidad en una de esas piezas, el fabricante necesita saber dónde está integrada y qué productos pueden estar expuestos.
Por eso el CRA presta especial atención a la documentación de componentes y vulnerabilidades. Aquí aparece un concepto cada vez más conocido: la Software Bill of Materials (SBOM).
SBOM: saber qué lleva realmente nuestro software
Una SBOM puede entenderse como una lista estructurada de los componentes que forman parte de un producto de software.
No evita vulnerabilidades por sí sola. Pero puede reducir muchísimo el tiempo necesario para responder cuando aparece un problema en una dependencia.
Imaginemos que mañana se publica una vulnerabilidad crítica en una biblioteca ampliamente utilizada.
Una empresa con inventario puede preguntar: “¿En qué productos usamos esta versión?”.
Una empresa sin inventario tiene que empezar por otra pregunta bastante peor: “¿La usamos en algún sitio?”.
En una crisis de seguridad, esa diferencia puede ser de horas o días.
Security by design deja de ser un eslogan
El término security by design se utiliza desde hace años, a veces hasta vaciarlo de contenido.
Aplicarlo de verdad significa pensar en seguridad antes de escribir la primera línea importante de código.
¿Qué ocurre si alguien roba una credencial? ¿Qué privilegios obtiene? ¿Puede un servicio quedar expuesto accidentalmente a Internet? ¿Cómo se validan las actualizaciones? ¿Qué sucede si falla una dependencia? ¿Existe una forma segura de recuperar el producto?
Son decisiones de arquitectura, no solo decisiones del equipo de seguridad.
El artículo 14 ya cambia el escenario
Desde el 11 de septiembre de 2026, las obligaciones del artículo 14 sobre notificación ya son aplicables. El Reglamento establece mecanismos de notificación para vulnerabilidades explotadas activamente y para determinados incidentes graves que afecten a la seguridad de productos con elementos digitales.
El mensaje regulatorio es importante: cuando existe explotación real o un incidente grave, la información puede tener valor para proteger a muchos más actores que el fabricante afectado.
Esto también obliga a preparar procedimientos internos. Detectar un incidente es solo el principio. Hay que saber quién lo evalúa, quién determina si entra en el régimen de notificación, qué información se conserva y cómo se coordina la respuesta.
¿Qué haría yo si fabricara software o hardware?
No esperaría a diciembre de 2027.
Empezaría por un inventario real de productos y componentes. Después revisaría dependencias, procesos de desarrollo, gestión de secretos, control de acceso, pipelines CI/CD y capacidad de actualización.
También definiría un proceso de vulnerabilidades con responsabilidades concretas:
- Recepción de avisos de seguridad.
- Validación técnica del hallazgo.
- Evaluación del riesgo real.
- Priorización de la corrección.
- Pruebas del parche.
- Despliegue y comunicación.
- Conservación de evidencias y trazabilidad.
Y añadiría algo más: simulacros. La primera vez que una empresa comprueba si su procedimiento funciona no debería ser durante una explotación activa.
La seguridad también se convierte en una cuestión de producto
El CRA obliga a romper otra barrera artificial: la que separa producto y ciberseguridad.
Si una función añade superficie de ataque, esa decisión tiene impacto de seguridad. Si una dependencia ya no recibe mantenimiento, es un riesgo de producto. Si una actualización no puede desplegarse sin interrumpir el servicio durante horas, también existe una decisión de diseño detrás.
Por eso el cambio más importante puede no ser jurídico, sino cultural.
Europa quiere que la responsabilidad viaje con el producto
El Cyber Resilience Act no va a eliminar las vulnerabilidades. Ninguna norma puede hacerlo.
Lo que sí puede hacer es elevar el nivel mínimo exigible: conocer los riesgos, diseñar con seguridad, gestionar vulnerabilidades y responder cuando algo falla.
Durante años hemos preguntado si un producto funciona.
A partir de ahora habrá otra pregunta cada vez más difícil de esquivar:
¿Está construido y mantenido para seguir siendo razonablemente seguro cuando alguien intente romperlo?
Ese es el verdadero cambio.