Cyber Resilience Act, Artigo 14.º: o Prazo de 24 Horas Já Começou e Também Abrange o Software Vendido

A 11 de Setembro de 2026 começou a aplicar-se a primeira obrigação do Regulamento de Ciber-Resiliência da União Europeia, o Cyber Resilience Act. A maior parte do regulamento só se aplica em Dezembro de 2027. O reporte de vulnerabilidades e incidentes não esperou.

Para uma empresa que vende software, a mudança não está no texto jurídico. Está no tempo que a engenharia demora a responder a uma pergunta simples: que produtos, e que versões, contêm a vulnerabilidade que acabou de ser explorada.

O que mudou a 11 de Setembro

O artigo 14.º do Regulamento (UE) 2024/2847 obriga os fabricantes de produtos com elementos digitais a reportar vulnerabilidades activamente exploradas e incidentes graves que afectem a segurança desses produtos. A sequência é fixa:

1. Aviso inicial em 24 horas, a contar do momento em que o fabricante toma conhecimento da situação.
2. Notificação em 72 horas, com a informação disponível até aí.
3. Relatório final, até 14 dias depois de existir uma medida correctiva, no caso de vulnerabilidades, ou até um mês depois da notificação de 72 horas, no caso de incidentes graves.

As notificações seguem para a equipa nacional de resposta a incidentes (CSIRT) do Estado-Membro onde o fabricante tem o estabelecimento principal, através da plataforma única de reporte gerida pela ENISA, que recebe a mesma informação.

Uma vulnerabilidade conta como activamente explorada quando há provas fiáveis de que um agente malicioso a explorou num sistema sem autorização do responsável por esse sistema, segundo a análise da Freshfields às orientações da Comissão. O prazo começa quando o fabricante tem um grau razoável de certeza de que isso aconteceu.

Quem é fabricante, e o que fica abrangido

A Comissão Europeia define fabricante como a pessoa singular ou colectiva que desenvolve ou fabrica produtos com elementos digitais, ou que os manda desenvolver, e que os comercializa em nome próprio ou com marca própria, seja mediante pagamento, monetização ou a título gratuito.

Dois pontos pesam mais do que parece à primeira leitura.

O reporte cobre produtos já colocados no mercado. As restantes obrigações do regulamento só se aplicam a produtos antigos se sofrerem uma modificação substancial a partir de Dezembro de 2027. As obrigações de reporte, pelo contrário, aplicam-se a todos os produtos abrangidos, incluindo os vendidos antes dessa data. Uma versão entregue há três anos já hoje está abrangida.

Há exclusões, mas são específicas. Ficam fora os produtos já cobertos por outra legislação da União, como acontece em alguns sectores regulados. A aplicação a software disponibilizado apenas como serviço remoto depende de um enquadramento que este artigo não trata, e convém confirmá-la com aconselhamento jurídico antes de a dar por adquirida.

Porque é que o prazo é de engenharia, e não jurídico

O aviso inicial tem de identificar o produto afectado. Parece trivial. Não é, quando a mesma biblioteca vive em várias versões de vários produtos, instaladas em clientes diferentes.

O mesmo relatório mostra porque é que o problema cresce com o tempo em vez de diminuir.

Lidos em conjunto com o artigo 14.º, os números descrevem uma situação concreta. Um produto não pára de envelhecer quando é entregue. As dependências atrasam-se, algumas deixam de ter quem as mantenha, e a equipa que construiu a versão original já está a trabalhar noutra coisa. Quando uma vulnerabilidade numa dessas dependências passa a ser explorada, o relógio de 24 horas começa na mesma.

A diferença entre cumprir e não cumprir raramente está em saber que o prazo existe. Está em conseguir, dentro dele, cruzar uma vulnerabilidade com todos os produtos e versões que a transportam.

O que tem de existir antes do primeiro alerta

Nada disto se constrói nas 24 horas. Tem de estar pronto antes.

1. Inventário de componentes por produto e por versão. Sem ele, identificar o produto afectado é trabalho de arqueologia. Com ele, é uma consulta.
2. Um caminho definido entre o alerta e um responsável nomeado. Quem recebe a informação sobre a exploração, quem a confirma e quem tem autoridade para declarar que o prazo começou.
3. Critério escrito para «activamente explorada». A definição legal pede provas fiáveis. A equipa precisa de saber, antes do caso real, que tipo de prova conta.
4. Acesso à plataforma única de reporte, testado. Credenciais, responsável e substituto, antes de haver pressa.
5. Comunicação aos utilizadores afectados preparada. A Goodwin sublinha que o fabricante tem também de informar sem demora os utilizadores afectados. Uma mensagem-modelo e uma lista de contactos por produto poupam horas.
6. Período de suporte definido por produto. O regulamento pede que o fabricante determine durante quanto tempo vai tratar as vulnerabilidades de cada produto, com a data de fim indicada de forma clara no momento da compra.

A relação com o regime de cibersegurança português

O Cyber Resilience Act recai sobre produtos. O Regime Jurídico da Cibersegurança, aprovado pelo Decreto-Lei n.º 125/2025, que transpõe a Directiva NIS2 para o direito português, recai sobre entidades e sobre os serviços que prestam. Uma empresa de software pode estar sujeita aos dois, com prazos, autoridades e plataformas diferentes. Para quem também é fornecedor de entidades essenciais ou importantes, vale a pena ler NIS2 em Portugal: o que muda para quem fornece uma entidade essencial.

Perguntas frequentes

O Cyber Resilience Act já se aplica por inteiro? Não. Entrou em vigor a 10 de Dezembro de 2024. As obrigações de reporte aplicam-se desde 11 de Setembro de 2026 e as restantes obrigações principais aplicam-se a partir de 11 de Dezembro de 2027.

O reporte aplica-se a produtos vendidos antes de 2027? Sim. As obrigações de reporte cobrem todos os produtos abrangidos, incluindo os que já estavam no mercado, segundo a Comissão Europeia.

Quais são as coimas? As sanções são definidas a nível nacional. As análises jurídicas publicadas apontam para um tecto de 15 milhões de euros ou 2,5% do volume de negócios mundial anual, consoante o que for mais elevado. A Comissão indica que as microempresas e as pequenas empresas estão isentas de coima pelo incumprimento do prazo de 24 horas do aviso inicial.

O que é preciso ter pronto primeiro? O inventário de componentes por produto e versão. Todos os outros elementos, do responsável nomeado à comunicação aos utilizadores, dependem de saber rapidamente o que está afectado.

Conclusão

O artigo 14.º do Cyber Resilience Act transformou a gestão de vulnerabilidades num compromisso com prazo em horas, que abrange também o software já vendido. O texto legal é curto. O trabalho que o torna cumprível é de engenharia: inventário, responsáveis, critérios e acessos definidos antes do primeiro alerta.

Para analisar como estruturar esse inventário e o caminho entre o alerta e o responsável, com capacidade sénior que reforça a equipa interna, é possível agendar uma Sessão de Esclarecimento, sem compromisso.