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

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, no de marketing: 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, vehículos, aviación, y productos desarrollados exclusivamente para defensa o seguridad nacional.
  • 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.
La frontera es funcional, no de marketing: la pregunta es si el procesamiento remoto es parte de las funciones de un producto, o si el servicio es la oferta.

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: fuera del ámbito.
  • Vender soporte, 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. 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 sobre componentes de terceros del artículo 13 no distingue código comprado de código clonado.

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 explotación activa 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 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 y no por costumbre.
  3. Marcado CE en software. Sí, se aplica: en la práctica, se coloca en la documentación que acompaña al producto o en la página de descarga. Ver software con marcado CE va a dejar de ser extraño.

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, lo que hace difícil justificar no hacerlo.

Fuentes