A partir de 11 de setembro de 2026, fabricantes passam a ter obrigações de reporte no Cyber Resilience Act para vulnerabilidades exploradas ativamente e incidentes graves que afetem a segurança de produtos com elementos digitais no mercado europeu. A Comissão Europeia informa que o aviso inicial deve ser enviado em até 24 horas após a ciência do problema e que a notificação completa deve chegar em até 72 horas.
O Cyber Resilience Act não trata apenas de software vendido por empresas europeias. A regra se aplica a produtos digitais disponibilizados no mercado da União Europeia, o que pode alcançar fabricantes e fornecedores de fora do bloco. Para empresas brasileiras que disponibilizam na União Europeia um dispositivo conectado, firmware, aplicação embarcada ou outro produto digital coberto, a pauta deixa de ser abstrata. Nem todo SaaS isolado entra automaticamente no escopo: a análise depende de ele constituir uma solução de processamento remoto integrante de um produto com elementos digitais. A orientação da Comissão Europeia sobre o alcance da norma deve guiar essa avaliação caso a caso.
Neste artigo
O que precisa ser reportado
O gatilho principal é uma vulnerabilidade explorada ativamente ou um incidente severo com impacto na segurança do produto. A Comissão Europeia descreve uma sequência de comunicações: alerta inicial em 24 horas, notificação completa em 72 horas e relatório final depois da correção ou em prazo posterior definido para incidentes graves.
Essa janela muda a operação. Um time que descobre exploração ativa não pode esperar a retrospectiva completa para começar o contato institucional. Ao mesmo tempo, o primeiro aviso não substitui a investigação técnica. A empresa precisa separar rapidamente o que sabe, o que ainda está apurando, quais produtos são afetados, qual mitigação existe e que comunicação externa é necessária.
O papel da plataforma única
A ENISA informa que a Single Reporting Platform, ou SRP, é o canal para submissão das notificações. A lógica é reportar uma vez e permitir que a informação siga para CSIRTs e autoridades competentes, em vez de obrigar o fabricante a repetir o mesmo alerta em múltiplos pontos.
Para produto digital, esse desenho pressiona a empresa a manter inventário, responsáveis e processo de resposta antes do incidente. Não basta saber que há uma falha. É preciso identificar representante, produto afetado, versão, exploração observada, severidade, países de disponibilidade e estágio da correção.
Open source tem calendário diferente
A Comissão Europeia também registra que stewards de software open source entram em obrigações específicas a partir de 11 de dezembro de 2027. Isso importa porque nem todo mantenedor open source é fabricante, e nem todo uso de biblioteca cria a mesma obrigação para o projeto original.
O impacto mais imediato em 2026 recai sobre fabricantes. Mesmo assim, empresas que consomem open source precisam melhorar rastreabilidade. Se uma dependência crítica aparece em exploração ativa, o fabricante do produto final precisa saber onde ela está, qual versão usa e como entregar correção ou mitigação aos clientes.
Efeito para times de engenharia
O Cyber Resilience Act transforma resposta a vulnerabilidades em processo de produto. Segurança, jurídico, suporte, engenharia, comunicação e gestão de fornecedor precisam trabalhar com o mesmo inventário. Nas primeiras 24 horas, a operação precisa localizar produto, versão, evidência, severidade, responsável e próxima ação.
Na prática, alguns artefatos deixam de ser opcionais: matriz de produtos e versões, SBOM, canal de recebimento de vulnerabilidades, playbook de severidade, trilha de decisão, responsável por autoridades e plano de comunicação. O post sobre Pod Certificates no Kubernetes mostra um exemplo de como identidade técnica ajuda a reduzir ambiguidade operacional em ambientes distribuídos.
O que preparar agora
O primeiro passo é mapear quais produtos digitais chegam ao mercado europeu e quem responde por cada um. Depois, o time deve testar um incidente fictício: detectar exploração ativa, abrir evidência, classificar impacto, localizar versões afetadas, preparar alerta inicial, simular a notificação completa e registrar a decisão final.
Esse exercício revela lacunas antes do prazo real: dependência sem dono, versão sem inventário, ambiente sem log, fornecedor sem SLA, canal de segurança escondido ou correção que demora demais para chegar ao cliente. O Cyber Resilience Act torna esses problemas visíveis porque o relógio passa a contar cedo.
