Guia da Comissão Europeia sobre o Regulamento de Ciber-Resiliência

A Comissão Europeia está a elaborar uma Comunicação que indicará orientações práticas sobre a aplicação do Regulamento (UE) 2024/2847, conhecido como Regulamento de Ciber-Resiliência (o “Regulamento”). O Regulamento estabelece um quadro normativo de requisitos de cibersegurança para produtos com componentes digitais e tem por objetivo reforçar a ciber-resiliência e assegurar o bom funcionamento do mercado interno. O Regulamento de Ciber-Resiliência foi adotado em 2024 e será aplicável na sua totalidade a partir de 11 de dezembro de 2027. No entanto, o Capítulo IV (artigos 35.º a 51.º) será aplicável a partir de 11 de junho de 2026 e o artigo 14.º (obrigações de notificação) será aplicável a partir de 11 de setembro de 2026.

O objetivo declarado do guia da Comissão é auxiliar os fabricantes, responsáveis pelo desenvolvimento e demais operadores económicos abrangidos pelo Regulamento a compreender de forma mais precisa as respetivas obrigações e promover uma aplicação coerente do regulamento em toda a UE. No processo de elaboração, a Comissão realizou uma consulta pública sobre o projeto, cujos resultados se encontram disponíveis no seu website. O guia, que não terá carácter vinculativo, será formalmente adotado quando estiverem disponíveis todas as versões linguísticas, e reflete a interpretação da Comissão.

Qual é o objetivo do guia sobre a aplicação do Regulamento?

O guia dá cumprimento ao disposto no próprio Regulamento, que prevê a emissão de orientações para facilitar a sua aplicação, com especial incidência nas microempresas e nas PME, e abrangerá, pelo menos: (i) o âmbito de aplicação (em particular, soluções de tratamento de dados à distância e software livre e de código-fonte aberto), (ii) períodos de apoio, (iii) articulação com outra legislação da UE, e (iv) o conceito de “alteração substancial”.

Principais conteúdos do projeto de guia publicado pela Comissão

De seguida, resumem-se os aspetos mais relevantes do projeto submetido a consulta, seguindo a sua estrutura e identificando os pontos nos quais se prevê um maior impacto prático para os operadores económicos.

1. Âmbito de aplicação do CRA: “colocação no mercado”, software, código-fonte e ligação de dados

O projeto dedica uma secção significativa a esclarecer o âmbito material do CRA e, em particular, quando um produto (incluindo software) se considera “colocado no mercado”. No que diz respeito ao software distribuído por meios digitais, o projeto de orientação indica que a “colocação no mercado” ocorre, essencialmente, quando a versão é disponibilizada pela primeira vez para distribuição ou utilização no mercado da UE, e apresenta exemplos ilustrativos sobre o tratamento de versões sucessivas.

Esclarece também questões práticas sobre combinações de hardware e software, o tratamento do código-fonte quando fornecido no âmbito de uma atividade comercial, o conceito de “ligação de dados” (para além da simples utilização de sinais elétricos) e a integração de sistemas complexos (incluindo aqueles com ciclos de vida longos, dependências herdadas e restrições de interoperabilidade), reforçando uma interpretação assente na abordagem de risco do CRA.

2. Software livre e de código-fonte aberto (FOSS): quando se aplica o CRA e a figura do administrador (steward)

Um dos capítulos mais sensíveis do projeto aborda o tratamento do software livre e de código aberto (FOSS). O guia propõe critérios para determinar quando um FOSS fica “sob a responsabilidade” de um operador económico e quando, em função do modo de fornecimento ou rentabilização, pode ser qualificado como “colocado no mercado” para efeitos do CRA. Inclui exemplos de modelos de utilização (nomeadamente, através de suporte, serviços associados, determinados modelos baseados em dados pessoais, doações, entre outros) e cenários ilustrativos sobre a integração em produtos de terceiros.

Além disso, desenvolve a figura da entidade administradora (open-source software steward), com referências ao conceito de suporte sustentado e a casos em que uma mesma entidade pode atuar como fabricante relativamente a determinados projetos e como administradora relativamente a outros, ficando sujeita a obrigações diferenciadas.

3. “Alteração substancial”: reparações, peças de substituição e atualizações de software

Outro ponto central é a “alteração substancial”, definida, em síntese, como uma alteração posterior à colocação no mercado que afete a conformidade com os requisitos essenciais de cibersegurança ou modifique a utilização prevista objeto de avaliada. O guia analisa o tratamento a conferir às reparações físicas, às peças de substituição (incluindo a distinção entre peças de substituição “idênticas” e não idênticas) e, especialmente, às atualizações de software num contexto de desenvolvimento iterativo.

É particularmente relevante a orientação de que as atualizações de segurança não devem ser consideradas, em regra geral, modificações substanciais se se limitarem a reduzir o risco sem alterar a finalidade prevista nem introduzir novos riscos; e, inversamente, que mesmo alterações aparentemente menores podem constituir alterações substanciais se afetarem materialmente o perfil de risco ou introduzirem novas superfícies de ataque não contempladas na avaliação final.

4. Período de apoio: critério geral, mínimo e particularidades para o software

É consagrada uma secção específica ao período de apoio e metodologia para a sua determinação nos termos do CRA, indicando que o fabricante deve fixá-lo tendo em conta critérios de proporcionalidade e que se aplica um mínimo geral de cinco anos, salvo se a vida útil esperada do produto com elementos digitais for inferior. O guia também especifica obrigações de transparência (por exemplo, indicar a data de fim do período de apoio: pelo menos o mês e o ano) e a aplicação prática do regime para produtos de software com versões sucessivas.

No que respeita ao software, o guia admite a possibilidade de cessar a correção de versões anteriores quando os utilizadores possam atualizar para a versão mais recente sem custos adicionais, entendendo-se como tal os custos diretamente imputáveis à referida atualização, e exigindo que o utilizador seja adequadamente informado sobre a disponibilidade da atualização e o termo do período de apoio da versão anterior.

5. Produtos “importantes” e “críticos”: “funcionalidade essencial” e avaliação da conformidade

O projeto desenvolve o conceito de “funcionalidade essencial” (“core functionality”) como elemento-chave para classificar um produto nas categorias do CRA (por referência a anexos e categorias) e, consequentemente, determinar o procedimento de avaliação da conformidade aplicável (incluindo os critérios para aferir quando é suficiente uma autoavaliação e quando é exigida uma avaliação por terceiros). Apresenta exemplos (nomeadamente, sistemas operativos, integração de componentes importantes ou críticos num produto com funcionalidade essencial distinta) e delimita o âmbito da presunção de conformidade quando se aplicam normas harmonizadas que abrangem apenas parte dos riscos ou funcionalidades.

6. Avaliação de riscos

Em consonância com a abordagem do CRA, o projeto orientações reitera que o fabricante deve realizar uma avaliação dos riscos de cibersegurança e adotar medidas ao nível do produto para os mitigar; além disso, deve exercer o dever de diligência no que diz respeito aos componentes integrados e às dependências externas. Sublinha que o CRA não admite a transferência do risco para utilizadores ou terceiros através de meras instruções e que a aceitação do risco residual é aferida por referência a um limiar regulamentar (nível de cibersegurança adequado em função dos riscos), e não pelo nível interno de aceitação do risco ou por critérios puramente comerciais.

7. Tratamento de dados à distância (RDPS): quando faz parte do produto

O projeto propõe um teste em três fases para determinar quais as soluções de tratamento de dados à distância (“remote data processing solution” – “RDPS”) que devem ser incluídas no produto: se o tratamento é efetuado “à distância”, se a sua ausência comprometeria uma funcionalidade do produto e se o software foi concebido ou desenvolvido pelo fabricante ou sob a sua responsabilidade. Distingue também entre RDPS e serviços de terceiros não desenvolvidos sob a responsabilidade do fabricante (que devem ser qualificados, quando aplicável, se for o caso, como “componentes” do ponto de vista dos riscos e do dever de diligência), e incorpora casos de utilização (nomeadamente, aplicação bancária, termóstato inteligente, leitor eletrónico, robô industrial, rede móvel).

8. Obrigações de notificação (vulnerabilidades exploradas e incidentes graves)