El CRA Recibe Su Manual de Instrucciones: Lo Que la Orientación de la Comisión Significa para Usted

El Cyber Resilience Act tiene su texto definitivo desde finales de 2024. Lo que le faltaba era un manual de instrucciones. El 3 de marzo de 2026, la Comisión Europea publicó exactamente eso: la Comunicación preliminar Ares(2026)2319816 — aproximadamente 70 páginas de orientación práctica sobre cómo interpretar el reglamento.

Esta es la orientación del Artículo 26 que la industria llevaba esperando. A continuación se detalla lo que dice y lo que significa para usted.

Introducción

La Comunicación preliminar Ares(2026)2319816, de fecha 3 de marzo de 2026, es el primer documento de orientación integral de la Comisión Europea sobre el Cyber Resilience Act. Con aproximadamente 70 páginas, aborda las preguntas que han mantenido en vela a los equipos de cumplimiento: ¿Qué cuenta como "procesamiento remoto de datos"? ¿Los productos heredados necesitan rediseños completos? ¿Cuándo una actualización de software se convierte en un nuevo producto?

Este artículo resume las nueve resoluciones más importantes en orientación práctica para fabricantes, importadores y distribuidores de productos con elementos digitales.

1. SaaS y Cloud: El Test RDPS

La Comisión introduce un estricto test de tres preguntas para determinar si un componente cloud o SaaS se califica como "soluciones de procesamiento remoto de datos" (RDPS) y, por tanto, queda dentro del alcance de conformidad del producto.

flowchart TD
    A["¿La solución procesa datos
'a distancia'?"] -->|No| B["No es RDPS"]
    A -->|Sí| C["¿Perdería el producto una función central
sin esta solución?"]
    C -->|No| D["No es RDPS
(tratar como componente,
diligencia debida según Art 13(5))"]
    C -->|Sí| E["¿Diseñada por o bajo la
responsabilidad del fabricante?"]
    E -->|No| F["No es RDPS
(SaaS de terceros = componente,
diligencia debida según Art 13(5))"]
    E -->|Sí| G["RDPS: dentro del alcance de
evaluación de conformidad del producto"]

La orientación ilustra esto con cinco escenarios concretos: una aplicación bancaria, un termostato inteligente, un lector electrónico, un robot industrial y un dispositivo de red móvil.

2. Productos Heredados

Los productos que ya están en el mercado de la UE antes de diciembre de 2027 no necesitan rediseñarse desde cero. Pero tampoco están exentos.

La Comisión aclara tres aspectos:

No se requiere reconstrucción histórica. No es necesario recrear la documentación de desarrollo de hace años. Lo que importa es una evaluación de riesgos de ciberseguridad actualizada que demuestre que el producto cumple los requisitos esenciales en función de su propósito previsto.

Las familias de productos pueden agruparse. Si varios productos heredados comparten la misma arquitectura y perfil de riesgo, puede realizarse una única evaluación de riesgos que cubra toda la familia, en lugar de evaluar cada referencia (SKU) individualmente.

La conformidad completa sigue siendo obligatoria. Los productos heredados siguen necesitando el marcado CE, una Declaración de Conformidad y la gestión activa de vulnerabilidades en el futuro. El alivio se aplica a la documentación histórica, no a las obligaciones en sí.

Para una guía detallada del proceso de evaluación de conformidad, consulte nuestra Guía de Decisión para la Evaluación de Conformidad. Para la planificación de períodos de soporte en productos heredados, consulte Planificación del Período de Soporte.

3. Software y las "Copias Infinitas"

¿Cuándo se "comercializa" el software? La Comisión confirma: una sola vez. La distribución digital inicial constituye la comercialización. Las actualizaciones menores posteriores (p. ej., de v1.0.0 a v1.0.1) no reinician el reloj regulatorio.

Esto se aplica específicamente al software independiente distribuido digitalmente. Los productos de hardware con software integrado siguen las reglas de comercialización estándar para bienes físicos.

4. Cuándo las Actualizaciones se Convierten en "Modificaciones Sustanciales"

Esta sección es la parte más práctica de toda la orientación. La Comisión proporciona ejemplos concretos que distinguen las actualizaciones rutinarias de los cambios que desencadenan una nueva evaluación de conformidad.

La Comisión sugiere cuatro preguntas que todo fabricante debe hacerse antes de publicar una actualización:

1. ¿La actualización introduce nuevos vectores de amenaza?
2. ¿Habilita nuevos escenarios de ataque?
3. ¿Cambia la probabilidad de los escenarios de ataque existentes?
4. ¿Cambia el impacto de los escenarios de ataque existentes?

Si la respuesta a cualquiera de estas preguntas es afirmativa, la actualización probablemente constituye una modificación sustancial que requiere una nueva evaluación de conformidad.

Para más información sobre la clasificación de productos y su relación con las modificaciones, consulte nuestra Guía de Clasificación de Productos.

5. Normas para el Código Abierto

La orientación proporciona varias aclaraciones importantes sobre cómo se aplica el CRA al software de código abierto:

• Publicar código fuente en repositorios públicos no constituye "comercialización". El CRA se aplica en el punto de distribución comercial, no en el punto de disponibilidad del código.
• Edición comunitaria frente a edición de pago = productos diferentes. Si ofrece una versión comunitaria gratuita y una versión comercial de pago, solo la versión de pago activa las obligaciones del fabricante.
• Las donaciones por sí solas no hacen que el FOSS sea comercial, salvo que el acceso al software esté condicionado a la donación. Las donaciones voluntarias están explícitamente excluidas.
• Las entidades sin ánimo de lucro cuyo superávit se destine íntegramente a objetivos sin ánimo de lucro están exentas de las obligaciones del fabricante, incluso si obtienen ingresos.
• Los colaboradores sin control sobre los lanzamientos, la hoja de ruta o la gobernanza NO se consideran fabricantes, incluso si tienen acceso de confirmación (commit). La responsabilidad recae sobre quien controla el proceso de lanzamiento.
• Las obligaciones de los administradores de código abierto se ajustan al nivel de soporte prestado. La administración no técnica conlleva obligaciones más ligeras que el soporte comercial completo.

Para orientación relacionada con la divulgación coordinada de vulnerabilidades en contextos de código abierto, consulte nuestra Plantilla de Política CVD.

6. Período de Soporte: Cinco Años es un Mínimo

La Comisión deja claro que el período de soporte predeterminado de cinco años es un mínimo, no un objetivo. Los productos que se espera que permanezcan en uso durante más de cinco años deben tener períodos de soporte proporcionalmente más largos.

La orientación también aclara la vía del Artículo 13(10): los fabricantes pueden dejar de aplicar parches a versiones anteriores si los usuarios pueden actualizar gratuitamente a una versión con soporte. "Costes adicionales" en este contexto se refiere a compras de hardware obligatorias — las pruebas rutinarias, la reconfiguración o el esfuerzo de despliegue por parte del usuario no están incluidos.

Para estrategias de planificación detalladas, consulte nuestra guía de Planificación del Período de Soporte.

7. Evaluación de Riesgos: El Apetito de Riesgo Interno es Irrelevante

La Comisión es inequívoca: las evaluaciones de riesgos en el marco del CRA deben basarse en criterios de ciberseguridad objetivos, no en el apetito de riesgo interno del fabricante. En concreto:

• La estrategia comercial y las consideraciones de coste no influyen en la evaluación de riesgos de ciberseguridad.
• No se puede transferir el riesgo de ciberseguridad a los usuarios mediante documentación, cláusulas de exención de responsabilidad o condiciones de servicio.
• Si los riesgos identificados no pueden abordarse mediante medidas técnicas u organizativas, es posible que el producto necesite modificaciones de diseño antes de poder comercializarse.

Esta es una declaración de gran relevancia. Significa que un fabricante no puede comercializar a sabiendas un producto con riesgos de ciberseguridad no mitigados simplemente porque la empresa haya "aceptado" ese riesgo.

Para una visión general de las implicaciones en los costes de cumplimiento, consulte nuestra guía de Estimación de Costes de Cumplimiento.

8. Vulnerabilidades Conocidas y Explotables

La orientación aclara qué significa "conocida" en el contexto del requisito del CRA de comercializar productos sin vulnerabilidades conocidas y explotables:

• Incluidas en bases de datos públicas: Base de Datos de Vulnerabilidades de la UE, CVE/MITRE, NVD.
• Divulgadas a través de canales no públicos: programas de divulgación coordinada de vulnerabilidades, pruebas de seguridad internas, pruebas de penetración de terceros.
• Ampliamente reportadas en medios de comunicación fiables: una vulnerabilidad importante cubierta por publicaciones de ciberseguridad de referencia se considera "conocida".

Los fabricantes disponen de una ventana de investigación limitada para confirmar si una vulnerabilidad reportada es realmente aplicable a su producto. Sin embargo, la "investigación" no es una escapatoria: el plazo comienza desde el momento del conocimiento, y los retrasos serán objeto de escrutinio.

Para orientación práctica sobre la documentación de vulnerabilidades, consulte nuestra Guía VEX.

9. Obligaciones de Notificación (Septiembre de 2026)

Las obligaciones de notificación de septiembre de 2026 son el primer plazo del CRA con verdadera fuerza de aplicación. La orientación confirma la estructura de plazos:

• 24 horas: Aviso temprano a ENISA tras tener conocimiento de explotación activa
• 72 horas: Notificación detallada con indicadores técnicos
• 14 días: Informe final para vulnerabilidades / 30 días para incidentes

"Conocimiento" significa certeza razonable tras una evaluación inicial — no confirmación forense completa. Si dispone de evidencia creíble de explotación activa, el plazo está corriendo.

Sobre la notificación a los usuarios: la Comisión confirma que debe basarse en el riesgo y ser proporcional. No existe un requisito obligatorio de divulgación pública si dicha divulgación aumentaría el riesgo de seguridad.

Para una guía completa del proceso de notificación, consulte nuestra guía de Notificación a ENISA en 24 Horas. Para el calendario completo de cumplimiento, consulte nuestro Calendario de Implementación.

Lo Que Esto Significa para Usted

Esta orientación no cambia lo que el CRA exige. Pero sí cambia cuánto margen de incertidumbre existe. Los fabricantes ahora disponen de tests concretos (RDPS), ejemplos concretos (modificaciones sustanciales) y plazos concretos (notificación) con los que trabajar.

Tres acciones inmediatas:

1. Aplique el test RDPS a cada servicio cloud del que dependa su producto. CRA Evidence automatiza esta evaluación como parte de su análisis de riesgos del producto.
2. Revise su proceso de actualización frente a las cuatro preguntas sobre modificaciones sustanciales. Incorpórelas a su lista de verificación de lanzamientos.
3. Prepárese para las notificaciones de septiembre de 2026. Los procesos internos de clasificación, las rutas de escalada y las plantillas de informes deben estar en marcha antes del plazo.

El período de comentarios está abierto a través del portal Better Regulation. Si tiene opiniones sobre la orientación, este es el momento de expresarlas.

Para un enfoque paso a paso hacia la conformidad con el CRA, consulte nuestra Guía de Cumplimiento para Startups.

Este artículo se basa en la Comunicación preliminar Ares(2026)2319816, de fecha 3 de marzo de 2026. Esta orientación aún no ha sido adoptada formalmente por la Comisión Europea y se finalizará una vez que estén disponibles todas las versiones en los idiomas de la UE.