Saltar para o conteúdo
folhas.io
secure by design para produtos ligados· Artigos

Artigos

CRA para quem faz software: o regulamento não é só para quem solda placas

O equívoco mais comum sobre o CRA é achar que se dirige a fabricantes de dispositivos. Software vendido como produto está dentro. SaaS puro está fora, com uma exceção que apanha muita gente. E 'grátis' não significa 'não comercial'.

Publicado

Nas conversas que temos com equipas de software, o padrão repete-se: “o CRA é para hardware, não é connosco.” É o equívoco mais caro do regulamento. O âmbito do CRA são produtos com elementos digitais disponibilizados no mercado, e um produto com elementos digitais é qualquer produto de software ou hardware, incluindo as suas soluções de processamento remoto de dados. Uma aplicação vendida em licença é tão abrangida como um router.

O que está dentro

  • Software comercializado como produto: aplicações desktop, mobile e web vendidas ou licenciadas, sistemas operativos, bibliotecas e componentes vendidos comercialmente, jogos, ferramentas.
  • Firmware e software embebido, com o produto físico que integram.
  • Processamento remoto de dados integral ao produto: se o produto precisa da vossa cloud para cumprir as suas funções (a app do sensor não funciona sem o vosso backend), esse processamento remoto entra no âmbito do produto. É a exceção que apanha quem pensou que “a parte cloud” ficava de fora.
  • Importadores e distribuidores de qualquer dos anteriores, com obrigações próprias de verificação.

O que está fora

  • SaaS puro, serviço prestado sem produto colocado no mercado, fica fora do CRA; conforme o caso, cai na NIS2 enquanto serviço. A fronteira é funcional, não de marketing: a pergunta é se o processamento remoto é parte integrante das funções de um produto, ou se o serviço é a oferta.
  • Setores com regime próprio: dispositivos médicos, veículos, aviação, e produtos desenvolvidos exclusivamente para defesa ou segurança nacional.
  • Peças sobresselentes que reponham componentes idênticos.
Dois quadros lado a lado: dentro do âmbito estão o software vendido ou licenciado, o firmware, o processamento remoto integral ao produto e os importadores e distribuidores; fora ficam o SaaS puro, o open source fora de atividade comercial e os setores com regime próprio.
A fronteira é funcional, não de marketing: a pergunta é se o processamento remoto é parte das funções de um produto, ou se o serviço é a oferta.

Open source: a fronteira é a comercialização

O CRA não se aplica a software livre e de código aberto desenvolvido ou fornecido fora de uma atividade comercial. Mas a comercialização lê-se em substância:

  • Publicar um projeto no GitHub, aceitar contribuições e doações: fora do âmbito.
  • Vender suporte, versão “enterprise”, ou monetizar por dados: atividade comercial, logo fabricante, com obrigações plenas.
  • Fundações e entidades que apoiam sistematicamente o desenvolvimento de OSS destinado a atividades comerciais têm um regime próprio e mais leve: os open-source software stewards, com obrigações limitadas (política de cibersegurança, cooperação com autoridades, e reporte na medida do seu envolvimento. Os stewards estão, aliás, entre os utilizadores previstos da plataforma única de reporte da ENISA).
  • E um ponto frequentemente ignorado: integrar componentes open source num produto comercial faz do integrador o responsável por eles. A due diligence sobre componentes de terceiros do artigo 13.º não distingue código comprado de código clonado.

Nota igualmente que “grátis” não é o critério: uma app gratuita monetizada por publicidade ou dados pessoais é disponibilização no âmbito de uma atividade comercial.

As obrigações são as mesmas, e algumas doem mais no software

Quem está dentro tem o pacote completo: requisitos essenciais do Anexo I (incluindo entrega sem vulnerabilidades exploráveis conhecidas e configuração segura por omissão), SBOM, gestão de vulnerabilidades durante o período de suporte, política de divulgação coordenada, atualizações de segurança separadas das funcionais sempre que tecnicamente viável, reporte de exploração ativa em 24h/72h a partir de 11 de setembro de 2026, marcação CE e declaração UE de conformidade.

Para equipas de software puro, três destes têm mordida especial:

  1. Atualizações de segurança separadas das de funcionalidade. O hábito de empacotar o patch de segurança no release trimestral com features novas conflitua com o requisito: e com o utilizador que quer o patch sem o resto.
  2. Suporte de versões antigas. Se clientes ficam em versões major anteriores, o período de suporte obriga a decidir formalmente que versões recebem correções de segurança e por quanto tempo, com uma política de fim de vida por escrito e não por costume.
  3. Marcação CE em software. Sim, aplica-se: na prática, aposta-se na documentação que acompanha o produto ou na página de download. Ver software com marcação CE vai deixar de ser estranho.

O que isto significa para quem fabrica

A pergunta de enquadramento certa não é “temos hardware?”, é “colocamos um produto no mercado da UE?”. Se sim, o passo seguinte é o mesmo que recomendamos aos fabricantes de dispositivos: classificar o produto (a esmagadora maioria do software cai em “por omissão”, com autoavaliação; mas repare-se que browsers, gestores de palavras-passe, VPN e sistemas operativos estão no Anexo III), inventariar componentes, e montar o processo de vulnerabilidades antes do processo de papelada. Para software, com pipelines de CI/CD já existentes, o custo marginal de fazer isto bem é dos mais baixos de todo o universo CRA, o que torna difícil justificar não o fazer.

Fontes