O reporte de 24h e 72h: como funciona a obrigação que chega a 11 de setembro
A partir de 11 de setembro de 2026, um fabricante que saiba de uma vulnerabilidade ativamente explorada no seu produto tem 24 horas para o primeiro aviso. O que se reporta, a quem, por onde, e o que preparar antes.
- Publicado
O artigo 14.º do Cyber Resilience Act é a primeira grande obrigação do regulamento a entrar em aplicação: a 11 de setembro de 2026, quinze meses antes da aplicação plena. A partir dessa data, um fabricante de produtos com elementos digitais que tome conhecimento de uma vulnerabilidade ativamente explorada, ou de um incidente grave com impacto na segurança do produto, entra num calendário medido em horas.
O que dispara a obrigação
Este ponto é o mais mal compreendido. O artigo 14.º não cobre todas as vulnerabilidades. Cobre duas coisas:
- Vulnerabilidades ativamente exploradas: uma falha no produto que está a ser usada num ataque (art. 3.º, n.º 42);
- Incidentes graves com impacto na segurança do produto: comprometimento de disponibilidade, autenticidade, integridade ou confidencialidade, com critérios de gravidade no art. 14.º, n.º 5.
Uma vulnerabilidade que a equipa descobre e corrige antes de ser explorada segue o processo normal de gestão de vulnerabilidades. Não abre nenhum relógio de 24 horas.
O relógio começa no momento em que o fabricante toma conhecimento. A orientação da Comissão clarifica o que isso significa: conhecimento existe quando, após avaliação do evento suspeito, o fabricante pode concluir com razoável certeza que há exploração ativa ou incidente grave. O prazo conta a partir do resultado dessa triagem, o que faz dela um processo formal, com dono, e não uma conversa de corredor.
Os três prazos
- 24 horas, aviso inicial. Deliberadamente magro: existe uma vulnerabilidade ativamente explorada ou um incidente grave, que produto é afetado, e em que Estados-Membros o fabricante sabe que o produto foi disponibilizado.
- 72 horas, notificação. Informação geral sobre o produto, a natureza do exploit e da vulnerabilidade, medidas corretivas ou mitigadoras já tomadas e as que os utilizadores podem tomar.
- Relatório final. Para vulnerabilidades: até 14 dias depois de haver medida corretiva disponível. Para incidentes graves: até um mês após a notificação de 72 horas. Inclui descrição, gravidade e impacto, informação sobre o ator malicioso quando disponível, e detalhes da correção.
A quem e por onde
Reporta-se uma única vez, através da Single Reporting Platform (SRP) que a ENISA está obrigada a ter operacional a 11 de setembro de 2026. A notificação entra pelo ponto do CSIRT coordenador do Estado-Membro do estabelecimento principal do fabricante (em Portugal, o CERT.PT, no Centro Nacional de Cibersegurança) e fica simultaneamente acessível à ENISA. Esse CSIRT dissemina depois a notificação aos CSIRT dos restantes Estados-Membros onde o produto está disponível, e alimenta as autoridades de fiscalização de mercado.
Em circunstâncias excecionais, por exemplo uma divulgação coordenada em curso, a disseminação pode ser adiada por fundamentos de cibersegurança, nos termos do Regulamento Delegado (UE) 2026/881.
Um detalhe com consequências: o “estabelecimento principal” é o Estado-Membro onde as decisões sobre a cibersegurança dos produtos são predominantemente tomadas. Fabricantes sem estabelecimento na UE seguem uma cascata: primeiro o representante autorizado, depois o importador, depois o distribuidor e, por fim, o Estado-Membro com mais utilizadores. Convém resolvê-la antes de um incidente, não durante.
O elefante na sala: a plataforma
À data em que escrevemos, a SRP não está publicamente operacional, e a obrigação não tem cláusula de espera: nada no texto condiciona os prazos à disponibilidade da plataforma. A conclusão prática é a que a própria indústria já tirou: o processo interno constrói-se agora, independente da ferramenta, com respostas claras sobre quem faz triagem, quem decide “tomámos conhecimento”, quem redige, quem aprova, e com que modelos pré-escritos.
O que isto significa para quem fabrica
O reporte de 24 horas não é um problema de comunicação; é um problema de prontidão. Quatro peças que qualquer fabricante, de qualquer dimensão, consegue montar antes de setembro:
- Um gatilho definido. Monitorização das fontes que transformam “vulnerabilidade conhecida” em “ativamente explorada”: o catálogo KEV da CISA, advisories dos componentes da SBOM, e o canal de receção de relatórios externos (a política de divulgação coordenada que o próprio CRA exige).
- Uma decisão de conhecimento com dono. Quem pode declarar, e com que critério, que a empresa “tomou conhecimento”. Sem isto, o relógio começa sem ninguém saber.
- Os três textos pré-escritos. O aviso de 24h cabe em meia página; escrevê-lo durante o incidente é a pior altura. Modelos preenchíveis para as três fases, aprovados de antemão.
- O ensaio. Um exercício de mesa por semestre, com cenário realista, a medir uma coisa: quanto tempo passa entre o sinal e o aviso pronto a submeter.
Numa micro-empresa, tudo isto cabe em meia dúzia de páginas e numa tarde de exercício. O que não cabe é improvisá-lo às 3 da manhã de uma quinta-feira.
Fontes
- Regulamento (UE) 2024/2847, artigo 14.º — https://eur-lex.europa.eu/eli/reg/2024/2847/oj
- Comissão Europeia, Cyber Resilience Act — Reporting obligations — https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
- ENISA, Single Reporting Platform (SRP) e factsheet — https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp
- Regulamento Delegado (UE) 2026/881 (condições para adiar a disseminação) — referido na página da Comissão acima
- itemis, CRA Article 14: Reporting Obligations for Manufacturers — https://www.itemis.com/en/blog/compliance-intelligence/cyber-resilience-act/cra-article-14-reporting-process/
- cyberresilienceact.eu, CRA Reporting: 24h, 72h & 14-Day Deadlines — https://www.cyberresilienceact.eu/reporting.html
- CISA, Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog