Saltar al contenido
folhas.io
secure by design para productos conectados· Artículos

Artículos

CRA para quien hace software: el reglamento no es solo para quien suelda placas

El equívoco más común sobre el CRA es creer que se dirige a fabricantes de dispositivos. El software vendido como producto está dentro. El SaaS puro está fuera, con una excepción que atrapa a mucha gente. Y 'gratis' no significa 'no comercial'.

Publicado
Actualizado

Nota de actualización (23 oct 2026). Hemos añadido las exclusiones del ámbito que faltaban, la fecha a partir de la cual se aplican las obligaciones de los open-source software stewards y los deberes del artículo 13 sobre componentes de terceros, hemos precisado cuándo las donaciones pasan a indicar actividad comercial y hemos corregido dónde se coloca el marcado CE en el software.

En las conversaciones que tenemos con equipos de software, el patrón se repite: “el CRA es para hardware, no va con nosotros.” Es el equívoco más caro del reglamento. El ámbito del CRA son los productos con elementos digitales comercializados en el mercado, y un producto con elementos digitales es cualquier producto de software o hardware, incluidas sus soluciones de procesamiento remoto de datos. Una aplicación vendida bajo licencia está tan cubierta como un router.

Qué está dentro

  • Software comercializado como producto: aplicaciones de escritorio, móviles y web vendidas o licenciadas, sistemas operativos, bibliotecas y componentes vendidos comercialmente, juegos, herramientas.
  • Firmware y software embebido, con el producto físico que integran.
  • Procesamiento remoto de datos integral al producto: si el producto necesita su cloud para cumplir sus funciones (la app del sensor no funciona sin su backend), ese procesamiento remoto entra en el ámbito del producto. Es la excepción que atrapa a quien pensó que “la parte cloud” quedaba fuera.
  • Importadores y distribuidores de cualquiera de los anteriores, con obligaciones propias de verificación.

Qué está fuera

  • El SaaS puro, servicio prestado sin producto introducido en el mercado, queda fuera del CRA; según el caso, cae en la NIS2 como servicio. La frontera es funcional: la pregunta es si el procesamiento remoto es parte integrante de las funciones de un producto, o si el servicio es la oferta.
  • Sectores con régimen propio: productos sanitarios y de diagnóstico in vitro, vehículos de motor y remolques (Reglamento (UE) 2019/2144) y, por acto delegado, los vehículos de categoría L, salvo los L1e diseñados para pedalear (Reglamento Delegado (UE) 2025/1535), productos aeronáuticos certificados con arreglo al Reglamento (UE) 2018/1139 y equipos marinos (Directiva 2014/90/UE). La Comisión puede añadir otras exclusiones mediante actos delegados (artículo 2, apartado 5).
  • Defensa, seguridad nacional e información clasificada: productos desarrollados o modificados exclusivamente para fines de seguridad nacional o defensa, y productos diseñados específicamente para tratar información clasificada (artículo 2, apartado 7).
  • Piezas de recambio que repongan componentes idénticos.
Dos cuadros lado a lado: dentro del ámbito están el software vendido o licenciado, el firmware, el procesamiento remoto integral al producto y los importadores y distribuidores; fuera quedan el SaaS puro, el open source fuera de actividad comercial y los sectores con régimen propio.
El criterio está en el artículo 3, punto 2: el procesamiento remoto entra cuando su software lo diseña y desarrolla el fabricante, o se hace bajo su responsabilidad, y su ausencia impediría al producto desempeñar una de sus funciones.

Open source: la frontera es la comercialización

El CRA no se aplica al software libre y de código abierto desarrollado o suministrado fuera de una actividad comercial. Pero la comercialización se lee en sustancia:

  • Publicar un proyecto en GitHub, aceptar contribuciones y donaciones sin ánimo de lucro: fuera del ámbito. Las donaciones que superen los costes de diseño, desarrollo y suministro del producto ya pueden caracterizar actividad comercial (considerando 15).
  • Vender soporte por un precio que no se limita a recuperar costes, versión “enterprise”, o monetizar por datos: actividad comercial, luego fabricante, con obligaciones plenas.
  • Las fundaciones y entidades que apoyan sistemáticamente el desarrollo de OSS destinado a actividades comerciales tienen un régimen propio y más ligero: los open-source software stewards, con obligaciones limitadas (política de ciberseguridad, cooperación con las autoridades y notificación en la medida de su implicación), aplicables solo a partir del 11 de diciembre de 2027 (artículo 71, apartado 2), a diferencia de la notificación de los fabricantes, aplicable a partir del 11 de septiembre de 2026. Los stewards están, por cierto, entre los usuarios previstos de la plataforma única de notificación de la ENISA.
  • Y un punto frecuentemente ignorado: integrar componentes open source en un producto comercial hace al integrador responsable de ellos. La diligencia debida que el artículo 13, apartado 5, exige al integrar componentes de terceros abarca expresamente el software libre no comercializado en el marco de una actividad comercial. Y el apartado 6 obliga al fabricante que detecte una vulnerabilidad en uno de esos componentes a comunicarla a quien lo mantiene y, si desarrolla una corrección, a compartir con esa persona o entidad el código o la documentación. Ambos deberes se aplican a los productos introducidos en el mercado a partir del 11 de diciembre de 2027. El artículo 09 trata un caso concreto: los fallos de PHP y Node.js corregidos el 21 de octubre de 2026.

Nótese igualmente que “gratis” no es el criterio: una app gratuita monetizada por publicidad o datos personales es comercialización en el marco de una actividad comercial.

Las obligaciones son las mismas, y algunas duelen más en el software

Quien está dentro tiene el paquete completo: requisitos esenciales del Anexo I (incluida la entrega sin vulnerabilidades explotables conocidas y la configuración segura por defecto), SBOM, gestión de vulnerabilidades durante el período de soporte, política de divulgación coordinada de vulnerabilidades, actualizaciones de seguridad separadas de las funcionales siempre que sea técnicamente viable, notificación de vulnerabilidades aprovechadas activamente y de incidentes graves en 24h/72h a partir del 11 de septiembre de 2026, marcado CE y declaración UE de conformidad.

Para equipos de software puro, tres de estos muerden especialmente:

  1. Actualizaciones de seguridad separadas de las de funcionalidad. El hábito de empaquetar el parche de seguridad en la release trimestral con features nuevas choca con el requisito, y también con el usuario que quiere el parche sin el resto.
  2. Soporte de versiones antiguas. Si hay clientes que se quedan en versiones major anteriores, el período de soporte obliga a decidir formalmente qué versiones reciben correcciones de seguridad y durante cuánto tiempo, con una política de fin de vida por escrito.
  3. Marcado CE en software. Sí, se aplica: en el software, el marcado CE se coloca en la declaración UE de conformidad o en el sitio web que acompaña al producto de software, en una sección fácil y directamente accesible para los consumidores (artículo 30, apartado 1).

Qué significa esto para quien fabrica

La pregunta de encuadre correcta no es “¿tenemos hardware?”, es “¿introducimos un producto en el mercado de la UE?”. Si la respuesta es sí, el paso siguiente es el mismo que recomendamos a los fabricantes de dispositivos: clasificar el producto (la inmensa mayoría del software cae en “por defecto”, con autoevaluación; pero obsérvese que los navegadores, los gestores de contraseñas, las VPN y los sistemas operativos están en el Anexo III), inventariar componentes, y montar el proceso de vulnerabilidades antes que el proceso de papeleo. Para software, con pipelines de CI/CD ya existentes, el coste marginal de hacer esto bien es de los más bajos de todo el universo CRA.

Fuentes