O Cyber Resilience Act já está a produzir efeitos práticos para as empresas.
Desde 11 de setembro de 2026, passou a aplicar-se o artigo 14.º do Regulamento (UE) 2024/2847, que impõe aos fabricantes de produtos com elementos digitais novas obrigações de comunicação de determinadas vulnerabilidades e incidentes de segurança.
Importa, porém, fazer uma distinção: o Cyber Resilience Act não entrou hoje em vigor. O Regulamento entrou em vigor em 10 de dezembro de 2024 e a maioria das suas disposições só será aplicável a partir de 11 de dezembro de 2027.
O que mudou agora foi a antecipação das obrigações de reporte previstas no artigo 14.º.
Para as empresas abrangidas, significa que esta parte do regime já não é uma questão para 2027.
O que tem de ser comunicado?
O artigo 14.º prevê essencialmente duas situações.
A primeira é a existência de uma vulnerabilidade ativamente explorada.
Não basta, portanto, existir uma vulnerabilidade num produto.
A obrigação de reporte surge quando exista evidência fiável de que essa vulnerabilidade está efetivamente a ser explorada por um agente malicioso, sem autorização do proprietário do sistema.
Uma falha de software identificada internamente ou uma vulnerabilidade conhecida não é, só por si, automaticamente comunicável ao abrigo desta norma.
A segunda situação respeita a incidentes graves com impacto na segurança do produto.
Estão aqui em causa ocorrências suscetíveis de afetar de forma grave a disponibilidade, autenticidade, integridade ou confidencialidade de dados ou funções relevantes do produto, ou de permitir, por exemplo, a introdução ou execução de código malicioso.
Ou seja, o Cyber Resilience Act não obriga a comunicar indiscriminadamente qualquer problema informático.
É necessário avaliar se estão preenchidos os critérios estabelecidos no Regulamento.
O primeiro prazo pode ser de apenas 24 horas
É provavelmente aqui que surge o maior desafio operacional para as empresas.
Quando o fabricante tome conhecimento de uma vulnerabilidade ativamente explorada ou de um incidente grave abrangido pelo artigo 14.º, deve apresentar um alerta precoce sem demora injustificada e, em qualquer caso, no prazo máximo de 24 horas.
Isto não significa que a empresa tenha 24 horas para investigar completamente o incidente, identificar a causa e resolver o problema.
Significa que tem, no máximo, 24 horas para iniciar formalmente o processo de reporte.
Segue-se uma segunda comunicação.
No prazo máximo de 72 horas contado desde o momento em que o fabricante tomou conhecimento da ocorrência, deve ser apresentada uma notificação mais completa, com a informação disponível sobre a vulnerabilidade ou incidente, uma avaliação inicial e as medidas corretivas ou de mitigação já adotadas ou disponíveis.
Há aqui um detalhe importante:
não são 24 horas mais 72 horas.
Os dois prazos contam a partir do momento em que o fabricante toma conhecimento da situação.
E depois das 72 horas?
O processo não termina com a segunda comunicação.
Existe ainda um relatório final.
Quando esteja em causa uma vulnerabilidade ativamente explorada, esse relatório deve ser apresentado, em regra, até 14 dias depois de estar disponível uma medida corretiva ou de mitigação.
Nos casos de incidente grave, o relatório final deve ser apresentado no prazo de um mês após a notificação das 72 horas.
O modelo europeu reconhece, assim, que uma empresa pode não ter todas as respostas nas primeiras horas.
O que exige é que exista capacidade para detetar, avaliar, escalar e comunicar rapidamente uma situação potencialmente relevante.
Onde é feito o reporte?
As comunicações são efetuadas através da CRA Single Reporting Platform, criada e gerida pela Agência da União Europeia para a Cibersegurança — ENISA.
O fabricante efetua uma única submissão através da plataforma e identifica o CSIRT designado como coordenador que lhe seja aplicável.
Em Portugal, o CSIRT designado como coordenador é o CERT.PT, do Centro Nacional de Cibersegurança.
Isto significa que as empresas abrangidas devem garantir que sabem quem está autorizado internamente a efetuar o reporte e que os respetivos acessos e procedimentos estão definidos antes de surgir um incidente.
Um prazo de 24 horas é pouco compatível com uma organização que só começa a discutir responsabilidades quando o problema já ocorreu.
Produtos já comercializados também podem estar abrangidos
Este é um dos aspetos mais relevantes do regime.
As obrigações que começaram a aplicar-se em 11 de setembro de 2026 não se limitam aos novos produtos que sejam colocados no mercado após dezembro de 2027.
O artigo 14.º pode também aplicar-se a produtos com elementos digitais que já tenham sido colocados no mercado.
Isto significa que uma empresa não deve olhar apenas para os produtos que está atualmente a desenvolver.
Deve também identificar os produtos que já comercializa e perceber se continuam abrangidos por obrigações de reporte.
Existe, contudo, uma nuance temporal importante.
A obrigação não funciona, em princípio, de forma retroativa relativamente a situações de exploração ativa de que o fabricante já tivesse conhecimento antes de 11 de setembro de 2026.
Se, porém, o fabricante apenas tomar conhecimento da exploração ativa depois dessa data, a obrigação poderá aplicar-se mesmo que a vulnerabilidade técnica já existisse anteriormente.
E se a vulnerabilidade estiver num componente de outro fornecedor?
A existência de um componente desenvolvido por um terceiro não elimina automaticamente a responsabilidade do fabricante do produto final.
Se uma vulnerabilidade existente num componente estiver presente e puder ser explorada no produto final, poderá existir uma obrigação de reporte relativamente a esse produto.
Este ponto torna especialmente importante a relação contratual com fornecedores de software, componentes, serviços tecnológicos e prestadores de cibersegurança.
Uma empresa pode ter apenas 24 horas para comunicar uma situação e, ao mesmo tempo, depender de terceiros para obter a informação técnica necessária.
Contratos que não prevejam mecanismos rápidos de comunicação de vulnerabilidades, cooperação na investigação, preservação de registos ou acesso a informação técnica podem tornar o cumprimento muito mais difícil.
Comunicar à autoridade não é suficiente
O artigo 14.º não se limita ao reporte institucional.
Quando estejam em causa vulnerabilidades ativamente exploradas ou incidentes graves, o fabricante pode também ter de informar os utilizadores afetados e, quando adequado, outros utilizadores.
Essa comunicação deve incluir, quando necessário, informação sobre medidas corretivas ou de mitigação que possam ser adotadas.
Na prática, isto significa que uma resposta a um incidente pode exigir intervenção simultânea das equipas técnicas, jurídicas, de compliance, produto, gestão e comunicação com clientes.
Não é apenas uma questão de cibersegurança.
É também uma questão de governação interna.
Quem está efetivamente abrangido?
As obrigações do artigo 14.º dirigem-se essencialmente aos fabricantes de produtos com elementos digitais abrangidos pelo Cyber Resilience Act.
O conceito pode abranger diferentes tipos de hardware e software disponibilizados no mercado da União Europeia.
Isso não significa que qualquer empresa que utilize software esteja automaticamente sujeita a estas obrigações.
A primeira pergunta deve ser:
A empresa é juridicamente fabricante de um produto abrangido pelo Cyber Resilience Act?
Só depois deve ser analisado se ocorreu um evento sujeito a reporte.
Importadores e distribuidores também merecem atenção, sobretudo quando colocam produtos no mercado sob a sua própria marca ou introduzem alterações que possam modificar a sua qualificação jurídica.
Quando começa a contar o prazo?
Esta é uma das questões mais sensíveis do novo regime.
Os prazos começam quando o fabricante toma conhecimento da ocorrência.
A empresa não deve partir do princípio de que o prazo apenas começa quando o departamento jurídico, o responsável de cibersegurança ou a administração formalmente qualificam a situação como reportável.
O primeiro sinal pode surgir através de sistemas de monitorização, clientes, fornecedores, investigadores de segurança, equipas técnicas ou autoridades.
Por isso, é essencial conseguir reconstruir a cronologia.
Quando surgiu o primeiro alerta?
Quem recebeu a informação?
Quando foi escalada internamente?
Em que momento existiam elementos suficientes para concluir que poderia estar em causa uma vulnerabilidade ativamente explorada ou um incidente grave?
Estas perguntas podem ser decisivas para demonstrar que a empresa cumpriu os prazos aplicáveis.
E as coimas?
O Cyber Resilience Act prevê um regime sancionatório significativo.
O artigo 64.º admite, para determinadas violações, incluindo o incumprimento das obrigações previstas nos artigos 13.º e 14.º, coimas que podem atingir 15 milhões de euros ou 2,5% do volume de negócios anual mundial da empresa no exercício anterior, consoante o valor mais elevado.
Contudo, há que distinguir novamente as datas de aplicação.
O artigo 14.º começou a aplicar-se em 11 de setembro de 2026, mas o artigo 64.º não consta das disposições cuja aplicação foi antecipada.
Por isso, não é rigoroso afirmar que uma empresa que falhe hoje uma obrigação de reporte fica automaticamente sujeita, desde já, à coima máxima prevista pelo CRA.
O que pode afirmar-se é que o incumprimento do artigo 14.º está integrado no escalão sancionatório mais elevado previsto pelo Regulamento quando o respetivo regime sancionatório passar a ser plenamente aplicável.
Isto não exclui que os mesmos factos possam gerar obrigações ou responsabilidades ao abrigo de outros regimes jurídicos.
O que devem fazer as empresas agora?
Para os fabricantes abrangidos, a preparação para o artigo 14.º já não deve ser tratada como um projeto para 2027.
A obrigação já começou.
Na prática, quatro questões devem ser tratadas como prioritárias.
Identificar os produtos abrangidos.
A empresa deve saber quais os seus produtos atuais e já comercializados que podem estar sujeitos ao Cyber Resilience Act.
Definir quando começa o relógio.
Devem existir procedimentos que permitam registar o momento em que surge informação relevante e escalar rapidamente a ocorrência.
Definir quem reporta.
É necessário identificar responsáveis, substitutos e acessos à plataforma de reporte. Um sistema dependente de uma única pessoa é, por definição, frágil perante um prazo de 24 horas.
Rever as relações com fornecedores.
Os contratos devem assegurar que fornecedores tecnológicos, programadores e prestadores de segurança transmitem rapidamente informação sobre vulnerabilidades e colaboram na investigação e mitigação.
Há uma regra simples a retirar desta alteração:
24 horas é um prazo para comunicar. Não é um prazo para começar a descobrir quem, dentro da organização, deve fazer o quê.
É precisamente por isso que o artigo 14.º do Cyber Resilience Act deve ser encarado não apenas como uma obrigação de cibersegurança, mas também como uma questão de contratos, compliance e governação empresarial.
_______________________________________________________________________________________________________________________________________________________
Fontes:
Regulamento (UE) 2024/2847 do Parlamento Europeu e do Conselho, de 23 de outubro de 2024 — Cyber Resilience Act, em especial os artigos 14.º e 71.º. O artigo 71.º determina expressamente que o artigo 14.º se aplica desde 11 de setembro de 2026.
Comissão Europeia — Cyber Resilience Act: Reporting obligations: orientação oficial sobre o funcionamento das notificações, incluindo os prazos de 24 horas, 72 horas e relatório final.
ENISA — CRA Single Reporting Platform (SRP): confirma que, desde 11 de setembro de 2026, os fabricantes devem apresentar as notificações obrigatórias através da plataforma única.
ENISA — Single Reporting Platform
ENISA — Frequently Asked Questions — CRA Single Reporting Platform, atualizadas em 10 de setembro de 2026: particularmente úteis para as questões práticas e transitórias, incluindo produtos colocados no mercado antes de 11 de dezembro de 2027.
ENISA — FAQ sobre a CRA Single Reporting Platform
ENISA — CRA SRP Guidance: Notification submission and update, atualizada em 9 de setembro de 2026: explica operacionalmente como submeter o early warning e atualizar as notificações.