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
Atualizado

Nota de atualização (23 out 2026). Acrescentámos as exclusões do âmbito que faltavam, a data a partir da qual se aplicam as obrigações dos open-source software stewards e os deveres do artigo 13.º sobre componentes de terceiros, precisámos quando as doações passam a indicar atividade comercial e corrigimos onde se apõe a marcação CE no software.

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 cloud do fabricante para cumprir as suas funções (a app do sensor não funciona sem esse 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: 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 e de diagnóstico in vitro, veículos a motor e reboques (Regulamento (UE) 2019/2144) e, por ato delegado, os veículos da categoria L, exceto os L1e concebidos para pedalar (Regulamento Delegado (UE) 2025/1535), produtos aeronáuticos certificados ao abrigo do Regulamento (UE) 2018/1139 e equipamento marítimo (Diretiva 2014/90/UE). A Comissão pode acrescentar outras exclusões por ato delegado (artigo 2.º, n.º 5).
  • Defesa, segurança nacional e informação classificada: produtos desenvolvidos ou modificados exclusivamente para fins de segurança nacional ou defesa, e produtos concebidos especificamente para tratar informação classificada (artigo 2.º, n.º 7).
  • 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.
O critério está no artigo 3.º, ponto 2: o processamento remoto entra quando o seu software é concebido e desenvolvido pelo fabricante, ou sob a sua responsabilidade, e a sua falta impediria o produto de desempenhar uma das suas funções.

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 sem intenção de lucro: fora do âmbito. Doações acima dos custos de conceção, desenvolvimento e fornecimento do produto já podem caracterizar atividade comercial (considerando 15).
  • Vender suporte por um preço que não se limita a recuperar custos, 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), aplicáveis só a partir de 11 de dezembro de 2027 (artigo 71.º, n.º 2), ao contrário do reporte dos fabricantes, aplicável a partir de 11 de setembro de 2026. Os stewards estão, aliás, entre os utilizadores previstos da plataforma única de comunicação de informações (a SRP da ENISA).
  • E um ponto frequentemente ignorado: integrar componentes open source num produto comercial faz do integrador o responsável por eles. A diligência devida que o artigo 13.º, n.º 5, exige ao integrar componentes de terceiros abrange expressamente o software livre não disponibilizado no âmbito de uma atividade comercial. E o n.º 6 obriga o fabricante que encontre uma vulnerabilidade num desses componentes a comunicá-la a quem o mantém e, se desenvolver uma correção, a partilhar com essa pessoa ou entidade o código ou a documentação. Os dois deveres aplicam-se aos produtos colocados no mercado a partir de 11 de dezembro de 2027. O artigo 09 trata um caso concreto: as falhas do PHP e do Node.js corrigidas a 21 de outubro de 2026.

Note-se ainda 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 vulnerabilidades ativamente exploradas e de incidentes graves 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 também 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.
  3. Marcação CE em software. Sim, aplica-se: no software, a marcação CE apõe-se na declaração UE de conformidade ou no site que acompanha o produto de software, numa secção fácil e diretamente acessível aos consumidores (artigo 30.º, n.º 1).

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.

Fontes