Cyber Resilience Act: o relógio de reporte começa em 11 de setembro

O prazo que chega antes da aplicação geral

O Cyber Resilience Act entrou em vigor em 10 de dezembro de 2024 e a maioria das suas obrigações aplica-se em 11 de dezembro de 2027. O calendário tem, porém, um marco anterior e operacional: o artigo 14.º aplica-se a partir de 11 de setembro de 2026.

Em 27 de julho, a Comissão publicou a primeira orientação prática sobre o regulamento. A orientação é não vinculativa e não substitui o texto legal, mas trata dúvidas de âmbito, modificações substanciais, períodos de suporte, reporte e avaliação de risco. Em 31 de julho, a Comissão atualizou as páginas dedicadas a fabricantes e ao reporte, confirmando que a plataforma única deve estar operacional no início da obrigação.

Isto não significa que todos os requisitos de conceção, conformidade e marcação CE tenham sido antecipados para setembro. Significa que um dever específico — detetar, decidir, reportar e informar — começa antes e precisa de funcionar com o catálogo de produtos que já existe.

O relógio é do fabricante — a cadeia inteira precisa de o conseguir acionar

O dever obrigatório do artigo 14.º é dirigido ao fabricante: a pessoa ou entidade que desenvolve ou manda desenvolver um produto com elementos digitais e o comercializa sob o seu nome ou marca. Um revendedor, importador, integrador ou cliente não se transforma automaticamente em fabricante por receber um alerta.

A distinção não autoriza passividade. Um importador ou distribuidor que recebe uma vulnerabilidade de um cliente deve saber qual é o fabricante, qual é a versão do produto e qual é o canal de escalonamento. Um fabricante que incorpora componentes de terceiros continua a ter de avaliar se a vulnerabilidade está contida e é explorável no seu produto.

A decisão deve ser feita por produto e por função económica, não pelo nome interno da equipa. Um grupo pode ser fabricante de uma aplicação própria, distribuidor de um dispositivo de terceiro e utilizador de outro serviço ao mesmo tempo.

Dois gatilhos, não uma lista de CVEs

O primeiro gatilho é uma vulnerabilidade contida no produto com elementos digitais que o fabricante saiba estar a ser ativamente explorada. A existência de uma CVE, uma prova de conceito pública ou uma classificação elevada não demonstram, isoladamente, exploração ativa no produto em causa.

O segundo gatilho é um incidente grave com impacto na segurança do produto. O regulamento considera grave o evento que afete, ou possa afetar, a capacidade de proteger disponibilidade, autenticidade, integridade ou confidencialidade de dados ou funções sensíveis/importantes, ou que tenha levado, ou possa levar, à introdução ou execução de código malicioso no produto ou nos sistemas de um utilizador.

O registo de decisão deve guardar o sinal recebido, a hora, o produto e versão, o alcance confirmado, a análise de exploração, a avaliação de gravidade, quem decidiu e que factos ainda faltam. Sem isto, o prazo torna-se uma disputa de memória durante um incidente.

24 horas, 72 horas e dois finais diferentes

Para os dois gatilhos, o fabricante apresenta um aviso inicial sem demora injustificada e até 24 horas depois de tomar conhecimento, seguido de uma notificação mais completa até 72 horas. O conteúdo cresce com a investigação; a primeira entrega não exige a mesma completude da última.

Numa vulnerabilidade ativamente explorada, o relatório final é devido até 14 dias depois de estar disponível uma medida corretiva ou de mitigação. Num incidente grave, o relatório final é devido no prazo de um mês após a notificação de 72 horas. O CSIRT pode ainda pedir um relatório intermédio.

Existe uma linha paralela: o fabricante deve informar os utilizadores afetados e, quando apropriado, todos os utilizadores, incluindo medidas que estes possam aplicar. A comunicação pública indiscriminada não é sinónimo automático desse dever; alcance e detalhe devem ser proporcionais ao risco.

Produtos antigos também entram no inventário de reporte

A regra transitória é material: o artigo 14.º aplica-se a todos os produtos abrangidos pelo CRA que tenham sido colocados no mercado antes de 11 de dezembro de 2027. Uma pesquisa que comece apenas em lançamentos futuros deixa precisamente de fora a base instalada que pode gerar o primeiro caso real.

O inventário precisa de conseguir responder quais versões foram disponibilizadas em que Estados-Membros, quem ainda as utiliza, qual é o período de suporte, que componentes relevantes contêm e como contactar utilizadores afetados. A notificação pede territórios e a comunicação exige alcance; esses dados não aparecem por magia durante as primeiras 24 horas.

A inclusão no inventário não resolve sozinha o âmbito jurídico. Produtos excluídos ou cobertos por legislação setorial própria precisam de uma decisão documentada. O objetivo não é declarar tudo abrangido, mas impedir que a decisão seja feita sem factos.

A plataforma única recebe o reporte; não toma a decisão pela empresa

A ENISA gere a Single Reporting Platform, que encaminha a notificação para o endpoint eletrónico do CSIRT coordenador do Estado-Membro do estabelecimento principal do fabricante e a torna simultaneamente acessível à ENISA. O CSIRT inicial distribui a informação aos CSIRTs dos territórios onde o produto foi disponibilizado, salvo as exceções estritas previstas.

Para o CRA, o estabelecimento principal é, em primeiro lugar, o Estado-Membro onde são predominantemente tomadas as decisões de cibersegurança dos produtos. Se não for determinável, usa-se o estabelecimento com mais trabalhadores na União. Fabricantes sem estabelecimento principal na UE seguem a ordem de representante autorizado, importador, distribuidor e localização dos utilizadores prevista no artigo 14.º.

Antes do primeiro caso, a empresa deve validar acesso, substitutos, contacto fora de horas e um pacote mínimo de factos. Uma credencial guardada numa pessoa ou uma plataforma conhecida apenas pelo jurídico não é prontidão operacional.

Um exercício de 72 horas que produz evidência

Escolha um produto material já colocado no mercado e simule uma vulnerabilidade num componente de terceiro com indícios credíveis de exploração. A equipa não recebe todos os factos de início: tem de confirmar alcance, identificar territórios, decidir o gatilho, preparar o aviso e atualizar a narrativa.

O exercício passa apenas se cada decisão tiver dono e carimbo temporal, se a pessoa de substituição conseguir executar o reporte, se jurídico não bloquear factos técnicos em falta e se apoio conseguir segmentar utilizadores e distribuir mitigação sem revelar detalhes perigosos.

Guarde o resultado como um dossier: cenário, cronologia, participantes, decisões, versão das mensagens, campos da plataforma, lacunas, ações e reteste. Uma reunião sem artefactos não demonstra capacidade.

Plano de preparação até 11 de setembro

A prioridade não é escrever uma política longa. É tornar executável a cadeia entre sinal, produto, decisão, reporte, mitigação e utilizador. Trabalhe primeiro com os produtos de maior alcance ou impacto, declare as lacunas e aumente a cobertura por ciclos.

Este plano é uma recomendação operacional Velqory inferida do regulamento e das páginas oficiais de implementação. Não substitui a classificação jurídica do produto, a validação da autoridade competente ou instruções técnicas que a ENISA e os CSIRTs venham a publicar.