Regulamento de Ciber-Resiliência: o que comunicar e a partir de quando

De acordo com a página da Comissão Europeia dedicada às obrigações de comunicação, a obrigação prevista no Regulamento de Ciber-Resiliência (CRA, na sigla inglesa) aplica-se aos fabricantes desde 11 de setembro de 2026. Esta data é relevante, mas a documentação recebida não comprova que tenha sido anunciada agora uma alteração legislativa ou uma nova regra. O tema deve, por isso, ser entendido como um guia de aplicação e não como uma notícia sobre uma alteração recente. Comissão Europeia: obrigações de comunicação.

A obrigação diz respeito a dois casos: vulnerabilidades exploradas ativamente e incidentes graves que afetem a segurança de um produto com elementos digitais. Não equivale a um dever de comunicar todas as falhas, alertas ou vulnerabilidades detetadas durante o desenvolvimento. O limiar é importante: os fabricantes devem definir um processo de classificação e resposta antes de receberem uma comunicação urgente. Regulamento (UE) 2024/2847, texto publicado no Jornal Oficial.

A data posterior de aplicação geral do regulamento não deve ser confundida com este início específico. A Comissão indica que as obrigações de comunicação dos fabricantes começaram em setembro de 2026, enquanto o regulamento prevê outras datas para diferentes obrigações e intervenientes. A aplicação deve ser verificada no artigo pertinente, e não deduzida a partir de uma única data geral.

O primeiro caso é uma vulnerabilidade que está a ser explorada ativamente. A mera existência de uma falha, mesmo que possa ter consequências para a segurança, não demonstra, por si só, que este critério está preenchido. O segundo caso são os incidentes graves que afetem a segurança do produto. A Comissão apresenta ambas as categorias como objeto do dever de comunicação dos fabricantes. Comissão Europeia: obrigações de comunicação.

Esta distinção permite separar a comunicação regulamentar da gestão corrente de vulnerabilidades. Um fabricante tem de tratar e corrigir problemas de segurança ao longo do ciclo de vida do produto, mas a obrigação de comunicação descrita aqui é desencadeada nos casos específicos previstos pelo CRA. Se houver dúvidas sobre se um caso concreto atinge o limiar, uma orientação secundária não substitui o texto legal nem uma avaliação jurídica do incidente.

Segundo o resumo da Comissão, o CRA abrange produtos com elementos digitais disponibilizados no mercado da União. Não se limita a aparelhos domésticos ligados: o âmbito também inclui software e componentes, embora a classificação de um produto concreto tenha de ser verificada face ao texto integral e às respetivas exclusões. Comissão Europeia: resumo do texto legislativo.

A sequência começa quando o fabricante toma conhecimento de uma vulnerabilidade explorada ativamente ou de um incidente grave. A Comissão estabelece um aviso inicial no prazo máximo de 24 horas e uma comunicação completa no prazo máximo de 72 horas. De acordo com o critério de início resumido pela Comissão, estes prazos não se contam a partir da publicação de uma correção nem do momento em que um terceiro descobre o problema, se o fabricante ainda não tiver conhecimento dele. Comissão Europeia: obrigações de comunicação.

Depois é exigido um relatório final, mas o ponto de referência varia consoante o caso. Para vulnerabilidades exploradas ativamente, o limite é de 14 dias a partir do momento em que está disponível uma medida corretiva. Para incidentes graves, o prazo é de um mês a contar da comunicação de 72 horas. Não se devem reduzir os dois casos a um único calendário: a natureza do caso determina a forma de calcular a etapa final.

Os prazos e os respetivos pontos de início constam do resumo da Comissão Europeia; num caso real, deve consultar-se o artigo 14.º do regulamento e as instruções operacionais em vigor. Regulamento (UE) 2024/2847.

O sujeito obrigado é o fabricante. A Comissão indica que a comunicação é efetuada uma única vez através da plataforma única de comunicação do CRA e dirigida ao CSIRT designado como coordenador no Estado-Membro onde o fabricante tem o seu estabelecimento principal. A informação também é disponibilizada à ENISA, de acordo com o mecanismo descrito pela Comissão. Comissão Europeia: obrigações de comunicação.

A ENISA mantém uma página específica sobre a Single Reporting Platform (SRP) e publica materiais de orientação relacionados com o registo e a apresentação de comunicações. Esta documentação ajuda a compreender o canal, mas a existência de uma página ou de instruções de utilização não demonstra, por si só, que todas as funcionalidades estejam disponíveis para todos os utilizadores em qualquer momento. A disponibilidade operacional deve ser verificada na própria plataforma e nas instruções oficiais em vigor. ENISA: Single Reporting Platform.

Para as equipas de produto e segurança, a consequência prática é organizacional: é necessário conseguir detetar um caso, encaminhá-lo, registar quando se tomou conhecimento dele e decidir rapidamente se se enquadra numa das categorias comunicáveis. Não se trata de uma lista adicional de requisitos textuais, mas de uma inferência operacional decorrente de prazos que começam quando se toma conhecimento do caso. Convém atribuir responsabilidades e preparar a coordenação entre segurança, produto, apoio e aconselhamento jurídico.

A Comissão indica que os open-source software stewards ficam sujeitos às obrigações de comunicação relacionadas a partir de 11 de dezembro de 2027, nos termos do artigo 24(3) e do calendário do artigo 71(2). Esta data é diferente do início de aplicação das obrigações dos fabricantes, que começou em setembro de 2026. Comissão Europeia: obrigações de comunicação.

Não se deve presumir que qualquer pessoa que contribua para um projeto de código aberto é automaticamente um steward, nem que o calendário dos fabricantes se aplica sem alterações a todos os projetos comunitários. A qualificação depende das definições e condições do regulamento. O resumo oficial ajuda a localizar a questão, mas o texto publicado no Jornal Oficial é a referência normativa para determinar o âmbito numa situação concreta. Regulamento (UE) 2024/2847.

Nas organizações que desenvolvem ou mantêm software de código aberto, o passo prudente é identificar quem desempenha a função relevante e verificar se o trabalho é realizado nas condições previstas pelo CRA. A data futura dá margem para preparar processos, mas não permite antecipar uma classificação jurídica sem analisar a atividade concreta.

A informação oficial permite estabelecer o calendário, as categorias gerais e o canal de comunicação. Por si só, não resolve todas as nuances técnicas de uma vulnerabilidade ou incidente concreto. Para tomar uma decisão documentada, a equipa responsável pode começar pelas seguintes verificações:

• Identificar o produto e o responsável: verificar se se trata de um produto com elementos digitais abrangido pelo regulamento e quem atua como fabricante.
• Determinar o caso: distinguir uma vulnerabilidade explorada ativamente de um incidente grave e documentar os indícios disponíveis.
• Registar o momento em que se tomou conhecimento: conservar a cronologia necessária para aplicar os prazos a partir do ponto de início indicado.
• Consultar o procedimento oficial: analisar o artigo 14.º e a informação atual da SRP, fazendo escalar o caso quando a sua classificação não for clara.

O regulamento não transforma todas as falhas numa comunicação automática, mas também não é aconselhável esperar pela conclusão de uma investigação para começar a avaliar os prazos. A janela de 24 horas torna importante dispor de um processo de avaliação precoce. Esta é uma implicação prática dos prazos legais, não uma medição do tempo que as empresas demoram nem uma afirmação de que existe uma obrigação legal adicional de adotar um procedimento interno específico.