Desde 11 de setembro de 2026, fabricantes de produtos com elementos digitais vendidos na União Europeia operam sob um relógio regulatório novo: vulnerabilidade em exploração ativa e incidente grave precisam ser comunicados pela plataforma única da ENISA, com alerta em até 24 horas. A mudança afeta qualquer empresa que coloca software, firmware ou hardware conectado no mercado europeu — inclusive fabricantes brasileiros que exportam para o bloco ou atuam por representantes autorizados. A ação prioritária é definir, nesta semana, quem detecta, valida e envia a notificação, porque o prazo curto não admite reunião de emergência para descobrir o responsável.
O que a nova regra exige
A mudança transforma o momento da descoberta em evento regulatório: vulnerabilidades ativamente exploradas e incidentes graves tornaram-se obrigatórias para fabricantes assim que existe evidência confiável de que um ator malicioso explorou a falha sem permissão do dono do sistema, ou de que o incidente afeta gravemente a disponibilidade, autenticidade, integridade ou confidencialidade do produto. A obrigação vem do artigo 14 do Cyber Resilience Act e alcança produtos colocados no mercado mesmo antes da aplicação plena do regulamento, marcada para dezembro de 2027. A ENISA consolidou prazos, procedimentos e interpretações em página oficial, atualizada depois do lançamento, e mantém manual e glossário para quem opera a plataforma.
Dois detalhes merecem atenção de quem monta o processo. Primeiro, a obrigação vale a partir do momento em que o fabricante toma conhecimento da exploração — e a Comissão Europeia publicou, em julho de 2026, diretriz que discute quando isso ocorre. Segundo, a regra não exige relatar retroativamente explorações conhecidas antes de setembro de 2026, mas conhecimento posterior reativa o dever, ainda que a vulnerabilidade existisse antes. Guardar evidência de quando o time soube de cada evento passa a ser controle obrigatório, não burocracia.
O escopo é mais amplo do que parece. Importadores e distribuidores que revendem o produto sob a própria marca ou fazem modificação substancial são tratados como fabricantes. Mantenedores de software livre entram em dezembro de 2027, limitados à notificação de vulnerabilidades em exploração ativa. Isso alcança firmware de dispositivos, gateways industriais, aplicativos embarcados e componentes vendidos como parte de solução maior — o produto com elementos digitais do regulador é definido pela função, não pela caixa.
Os três prazos do reporte
O alerta inicial precisa sair em até 24 horas depois que o fabricante toma conhecimento do evento, com o essencial: produto afetado, natureza do problema e impacto conhecido. A notificação completa chega em até 72 horas, com avaliação inicial e medidas em curso. O relatório final tem relógio próprio: 14 dias após a correção ficar disponível, quando o caso é vulnerabilidade explorada; um mês após a notificação de 72 horas, quando é incidente grave. A ENISA resume o calendário no factsheet oficial da plataforma.
| Etapa | Prazo | Conteúdo esperado |
|---|---|---|
| Alerta inicial | 24 horas após o conhecimento | Produto afetado, natureza do evento, impacto conhecido |
| Notificação | 72 horas após o conhecimento | Informações gerais, avaliação inicial, mitigação em curso |
| Relatório final de vulnerabilidade | Até 14 dias após correção disponível | Detalhe técnico, natureza do exploit, medida corretiva aplicada |
| Relatório final de incidente | Até 1 mês após a notificação | Causa provável, linha do tempo, lições e medidas |
A tabela existe para um motivo: os contadores da plataforma calculam prazos a partir do envio do alerta, não do momento do conhecimento, e a própria ENISA avisa que a tela pode marcar atraso antes de a obrigação vencer. O relógio legal é o do conhecimento interno — mais um motivo para registrar a hora de cada descoberta.
Como a plataforma funciona
Do alerta inicial ao relatório final, toda a comunicação passa pela plataforma única operada pela ENISA, em portal próprio com autenticação via EU Login e multifator obrigatório. O acesso é gerido por representantes designados: um primário, com poderes administrativos, e até 20 secundários convidados por ele. A associação entre representante e fabricante é validada pelo CSIRT coordenador, mas a verificação roda em paralelo — antes dela, é possível enviar até 20 notificações. Não existe API na versão inicial: tudo entra pela interface manual, o que obriga ensaio prévio em vez de automação improvisada.
Cada notificação seleciona o CSIRT designado como coordenador, em regra o do Estado-membro do estabelecimento principal do fabricante na União Europeia. Errar o destinatário invalida o envio e exige reenvio. O CSIRT que recebe dissemina para os demais países onde o produto está disponível e para autoridades de vigilância de mercado. Em circunstâncias excepcionais, marcadas na própria notificação, a disseminação pode ser retardada para não ampliar risco de segurança — mecanismo detalhado em regulamento delegado da Comissão de dezembro de 2025. Se a plataforma ficar indisponível, o caminho é aguardar e enviar; contato direto com o CSIRT não substitui o registro formal.
Sinais que disparam o relógio
Nem toda falha reportada abre obrigação. O gatilho é evidência confiável de exploração: alertas de detecção interna, telemetria de ataque em produção, aviso de CSIRT ou de terceiro, publicação de prova de conceito com uso observado em campo. Quase-acidentes e falhas apenas teóricas ficam fora do regime obrigatório. Diante da dúvida, a decisão defensável é registrar a suspeita com data e hora, acionar o CSIRT coordenador ou o helpdesk da ENISA e documentar a consulta — silêncio não é estratégia quando o prazo é de 24 horas.
Onde as equipes erram
- Não ter critério escrito de tomada de conhecimento: sem registro de quando o time soube, o prazo de 24 horas vira disputa de memória em auditoria.
- Concentrar o processo no jurídico: o conteúdo exigido — versões afetadas, natureza do exploit, mitigações — nasce do time técnico, que precisa treinar o preenchimento antes do primeiro caso real.
- Confundir regimes: o reporte do CRA não substitui a avaliação de incidente de dados pessoais prevista na LGPD nem os fluxos de notificação de violação; um mesmo evento pode exigir comunicações distintas, com prazos diferentes.
- Esperar a correção pronta para notificar: o alerta de 24 horas é anterior à correção; adiar para terminar o patch é infração com data marcada.
- Manter inventário de componentes desatualizado: sem SBOM confiável, identificar quais produtos contêm o componente vulnerável vira trabalho de semanas — exatamente o que a transparência de cadeia do próprio CRA já pedia.
Plano de ação priorizado
Ações P1, para as próximas duas semanas: nomear por escrito o representante primário e os secundários na plataforma; criar registro de conhecimento com data e hora para cada suspeita de exploração; definir rota de decisão que funcione em fim de semana, porque 24 horas não respeitam expediente; e rodar um ensaio seco de notificação com um caso hipotético.
Ações P2, dentro de um mês: integrar a triagem de vulnerabilidades exploradas ao fluxo de resposta a incidentes, com gatilho claro de quando abrir notificação; revisar contratos com representantes autorizados e importadores na Europa, deixando explícito quem notifica; e alinhar o relatório de correção com a engenharia, para que os 14 dias após a disponibilização do patch tenham conteúdo pronto. Backup imutável de evidências e logs de descoberta completa o kit — o relatório final pede linha do tempo, não impressões.
Governança é o que sustenta o resto: dono nomeado para o processo, métrica de tempo médio entre descoberta e alerta, revisão trimestral do fluxo e participação do time técnico no teste da plataforma. O texto do Regulamento (UE) 2024/2847 é curto no que importa — notificar sem demora — e longo nas consequências para quem não se preparar.