¿Qué es el Cyber Resilience Act?
El CRA (Reglamento (UE) 2024/2847) es un texto horizontal que cubre todos los productos con elementos digitales comercializados en el mercado de la Unión Europea, ya sean físicos (routers, cámaras IP, termostatos conectados) o puramente de software (aplicaciones móviles, plugins, bibliotecas, sistemas operativos). Es la primera normativa europea que se aplica a la seguridad del código a lo largo de todo el ciclo de vida de un producto.
No se trata de una directiva que cada Estado transpone a su manera: es un reglamento, de aplicación directa y uniforme en los 27 Estados miembros. La fecha de plena aplicación es el 11 de diciembre de 2027 — pero la primera obligación crítica, la notificación de las vulnerabilidades explotadas activamente (a la ENISA), se aplica desde el 11 de septiembre de 2026.
Tres categorías de productos:
- Clase 1 (crítica): productos cuyo compromiso puede tener un impacto grave y extendido — sistemas operativos, hipervisores, gestores de contraseñas, navegadores, cortafuegos, VPN, SIEM, infraestructuras cloud, software industrial. Son objeto de una auditoría de conformidad obligatoria por parte de un organismo notificado.
- Clase 2 (muy crítica): sistemas operativos industriales, chips de seguridad, HSM, tarjetas inteligentes, lectores biométricos. Auditoría de certificación obligatoria por un LSTI acreditado.
- Por defecto: todo lo demás. Conformidad por autoevaluación.
Lo que el CRA obliga en concreto
- Diseño seguro desde el origen (security by design): tener en cuenta los riesgos de seguridad desde la fase de diseño, no como parche posterior al lanzamiento.
- Ausencia de vulnerabilidades conocidas explotables en el momento de la comercialización: las dependencias deben estar actualizadas y auditadas.
- Gestión de las vulnerabilidades durante todo el ciclo de vida (mínimo 5 años): publicar actualizaciones de seguridad, distribuirlas gratuitamente e informar a los usuarios.
- Notificación de incidentes: una vulnerabilidad explotada activamente debe notificarse a la ENISA en un plazo de 24 horas (alerta temprana) y de 72 horas (informe completo), a partir del 11 de septiembre de 2026.
- Documentación técnica: proporcionar instrucciones de uso seguro, una política de divulgación de vulnerabilidades y, para los productos de Clase 1/2, un SBOM (Software Bill of Materials — lista exhaustiva de los componentes de software).
- Marcado CE: a partir de 2027, los productos cubiertos deben llevar el marcado CE de conformidad con el CRA, que demuestra la autoevaluación o la certificación por un tercero realizada.
¿Le afecta a su agencia?
El CRA se aplica si usted pone un producto a disposición en el mercado de la UE, lo que abarca mucho más que la simple venta directa:
- Desarrolla aplicaciones comerciales (SaaS, app móvil, software en caja) distribuidas a empresas o particulares europeos: sí.
- Distribuye plugins o extensiones en marketplaces (WordPress.org, Shopify App Store, extensiones de Chrome/Firefox): sí.
- Desarrolla por encargo (a medida, en marca blanca) un producto que su cliente venderá: el fabricante (su cliente) es el responsable, pero usted es su proveedor de componentes — y el CRA impone obligaciones a los proveedores de componentes integrados en productos cubiertos.
- Utiliza bibliotecas de código abierto en su producto: los componentes integrados en un producto comercial deben cumplir los requisitos del CRA, aunque la propia biblioteca sea gratuita.
- Hace I+D, prototipos no distribuidos o consultoría pura: fuera del ámbito directo del CRA.
El software distribuido bajo licencia de código abierto y sin modelo económico (sin soporte comercial, sin garantía) se beneficia de una exención explícita en el reglamento — pero atención: en cuanto una organización entrega un plugin de código abierto y factura soporte o integración, la exención puede dejar de aplicarse.
Las sanciones y su lógica
El CRA introduce un régimen sancionador de tres niveles:
1. Infracción de los requisitos esenciales (diseño seguro, gestión de vulnerabilidades): hasta 15 000 000 € o el 2,5 % de la facturación mundial anual, la cantidad más elevada.
2. Infracción de las obligaciones de notificación (retraso u omisión de la notificación a la ENISA): hasta 10 000 000 € o el 2 % de la facturación mundial.
3. Suministro de información inexacta o engañosa a las autoridades: hasta 5 000 000 € o el 1 % de la facturación mundial.
Las sanciones las imponen las autoridades nacionales de vigilancia del mercado (en Francia: la ANSSI para la ciberseguridad, la DGCCRF para la conformidad de mercado). La ENISA coordina a nivel europeo. Este régimen es similar al del RGPD — las autoridades pueden decidir el grado de aplicación, pero el marco legal hace posible la sanción desde el momento en que se constata el incumplimiento.
Preparar su agencia antes de diciembre de 2027
Paso 1 — Cartografiar sus productos y su clasificación
Elabore un inventario de todos los productos que comercializa en el mercado de la UE (aplicaciones, plugins, componentes entregados a terceros). Para cada uno, determine:
- ¿Clase por defecto, Clase 1 o Clase 2?
- Audiencia: ¿exclusivamente profesional (B2B) o gran público (B2C)?
- Modelo de distribución: ¿venta directa, marketplace, código abierto + soporte?La clasificación determina el nivel de auditoría exigido (autoevaluación frente a organismo notificado).
Paso 2 — Generar y mantener un SBOM
El SBOM (Software Bill of Materials) es la lista exhaustiva de todos los componentes de software: bibliotecas de terceros, dependencias directas y transitivas, licencias. Para los productos de Clase 1/2 es obligatorio. Para los productos por defecto, es muy recomendable como prueba de diligencia.
Herramientas de código abierto para generar un SBOM:
# Syft — genera un SBOM en formato SPDX o CycloneDX curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin synth packages /chemin/vers/votre/projet -o cyclonedx-json > sbom.json # Trivy — auditoría de las vulnerabilidades a partir del SBOM trivy sbom sbom.json # cdxgen — SBOM para proyectos Node.js, Python, PHP, Go cdxgen -t php /chemin/vers/projet -o sbom-php.jsonPaso 3 — Implantar un proceso de gestión de vulnerabilidades
El CRA obliga a mantener un proceso activo durante toda la vida comercial del producto (mínimo 5 años). En concreto:
1. Vigilancia de las CVE: suscríbase a las alertas de MITRE/NVD para sus dependencias (GitHub Dependabot, npm audit, Composer audit, Trivy en CI/CD).
2. Política de divulgación: publique una páginasecurity.txty unSECURITY.mden cada repositorio, con un contacto para notificaciones y un plazo de tratamiento.
3. Proceso de corrección: defina un SLA interno (p. ej.: vulnerabilidad CVSS ≥ 9 → corrección en 7 días).
4. Canal de notificación a la ENISA: a partir del 11 de septiembre de 2026, las vulnerabilidades explotadas activamente deben notificarse a través del portal de la ENISA en 24 h y luego 72 h.Paso 4 — Documentar la conformidad
El expediente técnico de conformidad debe incluir:
- La descripción del producto y de su arquitectura de seguridad.
- El análisis de los riesgos de ciberseguridad (threat modeling).
- Las medidas de seguridad implementadas y las pruebas realizadas.
- La política de gestión de vulnerabilidades.
- El SBOM (obligatorio para Clase 1/2).
- Las instrucciones de uso seguro.Este expediente debe conservarse 10 años después de la comercialización.
Paso 5 — Evaluar la necesidad de una auditoría externa
Para los productos de Clase 1: auditoría obligatoria por un organismo notificado (lista en el sitio de la Comisión Europea una vez establecidas las acreditaciones).
Para los productos por defecto: basta con la autoevaluación, pero conserve el expediente técnico completo. Una auditoría voluntaria puede reforzar la credibilidad comercial, sobre todo frente a las grandes empresas clientes que exigirán una prueba de conformidad con el CRA antes de 2027.
El impacto en su infraestructura de alojamiento
El CRA no se aplica directamente a los servicios cloud que alojan sus aplicaciones (el alojamiento puro está cubierto por NIS2, no por el CRA). Sin embargo, su infraestructura de alojamiento está directamente implicada en su conformidad con el CRA en tres puntos:
1. Los componentes de software que aloja forman parte del producto. Si su aplicación utiliza PostgreSQL, Redis o Nginx, esos componentes forman parte de la superficie de ataque que hay que documentar en el SBOM y vigilar en cuanto a CVE.
2. El pipeline CI/CD debe integrar las auditorías de seguridad. Sus workflows de GitHub Actions, GitLab CI u otros deben lanzar sistemáticamente escaneos de dependencias (npm audit, Composer audit, Trivy) y bloquear los despliegues si hay vulnerabilidades críticas sin resolver.
3. La gestión de incidentes exige trazabilidad. Su infraestructura debe producir logs suficientemente detallados para identificar que una vulnerabilidad ha sido explotada y en cuánto tiempo se detectó — información requerida para el informe a la ENISA.
CRA vs NIS2 vs RGPD — las tres normativas clave
Desplace la tabla
| Reglamento | Ámbito | A quién afecta | Fecha de aplicación | Sanción máxima |
|---|---|---|---|---|
| **CRA** (2024/2847) | Productos con elementos digitales comercializados en la UE | Fabricantes, importadores y distribuidores de productos de software/hardware | 11 dic. 2027 (obligaciones de seguridad) / 11 sept. 2026 (notificación) | 15 M€ o 2,5% facturación |
| **NIS2** (2022/2555) | Servicios esenciales e importantes (cloud, alojamiento, energía, finanzas, salud…) | Operadores esenciales e importantes, proveedores de cloud/CDN/DNS | Oct. 2024 (en transposición en los Estados miembros) | 10 M€ o 2% facturación |
| **RGPD** (2016/679) | Tratamiento de datos personales de personas en la UE | Todo responsable del tratamiento o encargado | Mayo de 2018 | 20 M€ o 4% facturación |
Herramientas SBOM gratuitas para integrar en su CI/CD
La generación automática de SBOM en cada build es la medida más rentable para preparar el CRA. Tres herramientas de código abierto para integrar desde ahora:
Syft (Anchore) — genera SBOM en los formatos SPDX 2.3 y CycloneDX 1.5 a partir de cualquier directorio o imagen Docker:
# Instalar
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
# Generar el SBOM
synth packages . -o cyclonedx-json > sbom.jsonTrivy (Aqua Security) — escanea las vulnerabilidades a partir de un SBOM CycloneDX o de una imagen Docker:
trivy image --format cyclonedx mon-app:latest | trivy sbom /dev/stdincdxgen — especializada en proyectos Node.js, Python, PHP, Go, Java, Ruby:
npx @cyclonedx/cdxgen -t php /mon-projet -o sbom-php.jsonCalendario de obligaciones — no se salte los dos primeros escalones
El CRA ha publicado un calendario progresivo con dos plazos intermedios importantes antes del 11 de diciembre de 2027:
| Plazo | Obligación |
|---|---|
| 10 dic. 2024 | Entrada en vigor del reglamento |
| 11 sept. 2026 | Obligación de notificar a la ENISA las vulnerabilidades explotadas activamente (24 h/72 h) |
| 11 dic. 2027 | Plena aplicación: todos los requisitos esenciales, marcado CE, documentación |
| Hasta el 11 dic. 2035 | Expediente técnico que hay que conservar (10 años después de la comercialización) |
El error que no hay que cometer: tratar la fecha del 11 de septiembre de 2026 como algo menor. Si una vulnerabilidad de su producto se explota activamente después de esa fecha y usted no la ha notificado a la ENISA en plazo, ya está en situación de infracción — más de un año antes de la plena aplicación del CRA.
ServOrbit y su conformidad con el CRA
Ofrecemos VPS y servicios de alojamiento que constituyen la infraestructura sobre la que funcionan sus productos. Nuestro papel en su conformidad con el CRA es indirecto pero concreto:
- Aislamiento de los entornos: nuestros VPS le permiten desplegar entornos separados por cliente y por criticidad, lo que limita la superficie de impacto en caso de compromiso.
- Copias de seguridad automatizadas: los snapshots diarios incluidos en nuestros planes le proporcionan una base de restauración documentable en caso de incidente, información útil para los informes a la ENISA.
- Acceso a los logs: usted tiene acceso completo a su VPS y puede configurar el registro a nivel de su aplicación — un requisito implícito del CRA para la trazabilidad de los incidentes.
- Ubicación de los datos: nuestros VPS están ubicados en Europa, lo que le ayuda a documentar la localización de su infraestructura en su expediente de conformidad.
Próximos pasos
El CRA se aplica dentro de 16 meses para las obligaciones de notificación y dentro de algo más de 28 meses para la plena conformidad. Es poco tiempo para una agencia que nunca ha formalizado sus prácticas de seguridad.
Para hacer en 30 días:
1. Cartografiar sus productos en el mercado de la UE e identificar su clasificación.
2. Comprobar que sus repositorios tienen un SECURITY.md y una política de divulgación.
3. Instalar Syft o Trivy en su pipeline CI/CD.
En 6 meses:
4. Generar un SBOM inicial para cada producto.
5. Formalizar su proceso de gestión de vulnerabilidades (responsable, SLA, canal de notificación).
6. Para los productos de Clase 1: contactar con un organismo notificado para planificar la auditoría.
Antes del 11 de septiembre de 2026:
7. Disponer de un proceso operativo de notificación a la ENISA y haberlo probado.
