Requisitos del Cyber Resilience Act: qué exige el reglamento a los fabricantes de productos digitales
Por el equipo de QuantumSec
El Cyber Resilience Act impone dos tipos de obligaciones a los fabricantes de productos con elementos digitales: requisitos técnicos que el producto debe cumplir (Parte I del Anexo I) y requisitos de proceso para la gestión del ciclo de vida de seguridad del producto (Parte II del Anexo I). Además establece un procedimiento de evaluación de conformidad según la categoría del producto y documentación obligatoria que el fabricante debe generar y conservar. Esta guía desglosa todos estos requisitos con el nivel de detalle que necesita un equipo técnico o un responsable de producto.
Requisitos técnicos del producto: Parte I del Anexo I
La Parte I del Anexo I establece los requisitos esenciales de ciberseguridad que el producto debe cumplir en el momento de su puesta en el mercado y durante todo su ciclo de vida.
1. Sin vulnerabilidades conocidas explotables: el producto no puede comercializarse con vulnerabilidades conocidas y explotables. Esto no significa ausencia total de vulnerabilidades, sino que el fabricante debe verificar activamente que no existe ninguna vulnerabilidad conocida y documentada en bases de datos como NVD o CVE que sea explotable en el producto tal como se comercializa.
2. Configuración segura por defecto: prohíbe explícitamente las contraseñas predeterminadas genéricas (mismo password para todos los dispositivos de un modelo), los puertos abiertos innecesarios, los servicios habilitados sin necesidad y los permisos excesivos en la configuración inicial.
3. Protección de datos almacenados y transmitidos: en la práctica significa cifrado en tránsito (TLS 1.2 o superior), cifrado en reposo para datos sensibles y gestión adecuada de claves criptográficas.
4. Superficie de ataque mínima: se deben deshabilitar todos los puertos, servicios, protocolos y funcionalidades que no sean necesarios para el funcionamiento del producto.
5. Protección frente a acceso no autorizado: autenticación apropiada para el riesgo del contexto, gestión de sesiones, y protección frente a ataques de fuerza bruta.
6. Integridad del software y actualizaciones seguras: el mecanismo de actualización de firmware o software debe ser seguro por diseño: verificación de autenticidad del paquete de actualización, transmisión cifrada, y protección frente a manipulación o rollback no autorizado.
7. Registro de eventos de seguridad: las acciones relevantes para la seguridad —intentos de autenticación, cambios de configuración, conexiones de red, errores de integridad— deben quedar registradas y ser accesibles para el administrador.
8. Ausencia de funcionalidades ocultas: el producto no puede incluir puertas traseras, mecanismos de acceso ocultos ni ninguna funcionalidad que comprometa la seguridad del usuario sin su conocimiento.
Requisitos de gestión de vulnerabilidades: Parte II del Anexo I
La Parte II del Anexo I regula los procesos que el fabricante debe implementar para gestionar el ciclo de vida de seguridad del producto una vez en el mercado.
1. Identificación y documentación de vulnerabilidades: el fabricante debe mantener un inventario completo de componentes y dependencias del producto (Software Bill of Materials o SBOM) y monitorizar activamente las fuentes de inteligencia de vulnerabilidades relevantes.
2. Divulgación coordinada de vulnerabilidades (CVD): el fabricante debe publicar una política de CVD con un canal accesible para que investigadores de seguridad y usuarios puedan reportar vulnerabilidades, y un proceso documentado de evaluación y respuesta.
3. Actualizaciones de seguridad gratuitas durante el ciclo de vida: el fabricante debe proporcionar actualizaciones de seguridad de forma gratuita durante un período no inferior a cinco años desde la puesta en el mercado, o durante el ciclo de vida previsto del producto si este es más largo.
4. Notificación a ENISA: desde agosto de 2026, el fabricante debe notificar a ENISA las vulnerabilidades activamente explotadas. Plazos: 24 horas para la alerta temprana, 72 horas para la notificación completa, y 14 días para el informe final.
5. Información clara al usuario sobre el período de soporte: el fabricante debe comunicar la fecha hasta la que garantiza actualizaciones de seguridad antes de la compra y en la documentación del producto.
6. Integración de la seguridad en el SDLC: prácticas de desarrollo seguro, revisión de código de seguridad, pruebas de seguridad y gestión segura del proceso de release.
El Software Bill of Materials (SBOM): por qué es central en el CRA
El SBOM —inventario completo de todos los componentes de software que forman parte de un producto— es una de las herramientas clave para cumplir con los requisitos del CRA. Sin un SBOM actualizado, es imposible cumplir con la obligación de identificar vulnerabilidades en el producto: no puedes saber si una nueva CVE publicada en una librería de código abierto te afecta si no tienes un inventario de qué librerías usa tu producto y en qué versión. El CRA requiere que el fabricante pueda, ante la publicación de una nueva vulnerabilidad, determinar en minutos si algún componente de sus productos está afectado y notificar a ENISA dentro del plazo de 24 horas. La generación automática del SBOM en formato SPDX o CycloneDX integrada en el pipeline de CI/CD es una de las primeras medidas técnicas que recomendamos implementar en cualquier proyecto de adecuación al CRA.
Evaluación de conformidad: cómo se certifica el cumplimiento
El mecanismo de evaluación de conformidad varía según la categoría del producto.
Productos Default: el fabricante puede realizar una autoevaluación (self-assessment) sin necesidad de involucrar a terceros. El fabricante evalúa su producto contra los requisitos del Anexo I, prepara la documentación técnica y emite la declaración de conformidad UE bajo su propia responsabilidad.
Productos Clase I: pueden elegir entre self-assessment demostrando que aplican íntegramente una norma europea armonizada (cuando estén disponibles, se esperan para 2026-2027), o someter el producto a un módulo de evaluación de calidad del proceso de desarrollo.
Productos Clase II: requieren obligatoriamente la evaluación de conformidad por un organismo notificado, incluyendo la evaluación del producto contra los requisitos del Anexo I y la emisión del certificado de examen de tipo UE.
Documentación técnica obligatoria
El CRA exige al fabricante mantener y conservar durante 10 años documentación técnica que incluye: descripción completa del diseño y del proceso de desarrollo; análisis de riesgos de ciberseguridad con los riesgos identificados y las medidas adoptadas; lista de normas armonizadas aplicadas; procedimientos de pruebas y evaluación de la conformidad; política de divulgación coordinada de vulnerabilidades; y declaración de conformidad UE firmada por el representante autorizado del fabricante. Además, el fabricante debe proporcionar a los usuarios instrucciones de uso con las medidas de seguridad que deben adoptar, información sobre el período de soporte de seguridad, y el punto de contacto para reportar vulnerabilidades.
FAQ
¿Los productos de código abierto están sujetos a los requisitos del CRA?
El CRA excluye explícitamente el software de código abierto que se desarrolla de forma no comercial. Sin embargo, si una empresa comercializa un producto basado en software de código abierto (una distribución de Linux comercial, un router con firmware basado en OpenWRT, o un appliance de seguridad basado en Suricata), ese producto comercial sí está sujeto al CRA. El fabricante comercial es responsable del cumplimiento incluso si parte del código es open source.
¿Qué es una norma armonizada del CRA y cuándo estarán disponibles?
Las normas armonizadas son estándares técnicos europeos (ETSI, CEN-CENELEC) elaborados bajo mandato de la Comisión Europea que, cuando se aplican íntegramente, crean una presunción de conformidad con los requisitos del CRA. Las normas relevantes aún están en desarrollo y se esperan para 2026-2027. En su ausencia, los fabricantes pueden utilizar otras normas técnicas reconocidas como IEC 62443, ETSI EN 303 645, o NIST SP 800-218 para demostrar conformidad, aunque esto requiere un mapeo explícito entre los requisitos de la norma y los del CRA.