Resumo

  • Desde 11 de setembro de 2026, fabricantes de produtos com elementos digitais devem avisar sobre vulnerabilidades exploradas ativamente e incidentes graves de segurança. O alerta inicial vence em até 24 horas após a ciência, e a notificação ampliada, em até 72 horas.
  • A Single Reporting Platform concentra o envio, não o poder. O fabricante seleciona um CSIRT coordenador nacional, que avalia e normalmente dissemina a informação; a ENISA mantém a plataforma. A versão inicial funciona só em inglês, sem API, sem notificações voluntárias e antes do início dos deveres de responsáveis por software de código aberto.

A União Europeia ligou o sistema de alarme quinze meses antes de acionar a maior parte das obrigações de produto do Cyber Resilience Act.

O intervalo é deliberado. A linha do tempo da European Commission põe as exigências principais de segurança, tratamento de vulnerabilidades e conformidade em 11 de dezembro de 2027. Já o dever de notificar previsto no artigo 14 começou em 11 de setembro de 2026.

A partir de agora, quando um fabricante toma conhecimento de uma vulnerabilidade explorada ativamente ou de um incidente com impacto grave na segurança de um produto digital coberto, surge uma sequência própria. O primeiro alerta deve ser enviado sem demora indevida e, no máximo, em 24 horas. A notificação com informações gerais e uma avaliação inicial deve chegar em 72 horas.

O guia de obrigações da European Commission ainda separa os relatórios finais. No caso de vulnerabilidade explorada, o prazo termina até quatorze dias depois que uma correção ou mitigação estiver disponível. No incidente grave, termina um mês depois da notificação de 72 horas.

Nada disso depende da aplicação geral da lei em 2027. Produtos que já foram colocados no mercado da UE podem gerar obrigação de reporte hoje, desde que estejam no escopo. O período de transição não é, portanto, uma zona sem deveres. A infraestrutura de visibilidade regulatória começa antes do conjunto completo de controles de produto.

A ciência nasce dentro da empresa

O relógio legal começa quando o fabricante toma conhecimento. A frase desloca o primeiro problema de governança para dentro da companhia.

Uma equipe técnica pode detectar comportamento suspeito antes de saber quem atacou. Um fornecedor pode avisar que um componente de terceiros está sendo explorado. A confirmação pode amadurecer ao longo de horas. A empresa precisa registrar qual evidência confiável transformou a suspeita em evento reportável e quem fixou esse momento.

O login do representante não inicia o prazo. A abertura do chamado jurídico não inicia o prazo. Tampouco é correto esperar a investigação perfeita quando já há conhecimento suficiente. O registro interno deve preservar a evolução sem transformar uma conclusão tardia em nova hora de partida.

Essa disciplina é especialmente importante porque a primeira janela tem só 24 horas. Identidade da entidade, responsável substituto e país coordenador não podem ser decididos do zero depois do alerta técnico.

Um envio comum, uma cadeia institucional

A Single Reporting Platform da ENISA foi desenhada para que um evento não tenha de ser digitado repetidamente para vários países. Uma notificação basta mesmo quando o fabricante tem múltiplas filiais ou subsidiárias europeias, ou quando a controladora está fora da União.

O fabricante, contudo, deve escolher o CSIRT designado como coordenador competente. Em regra, a decisão acompanha o principal estabelecimento do fabricante. A responsabilidade pela seleção é de quem envia. A lista oficial de coordenadores passa a funcionar como tabela de roteamento jurídico.

No fluxo normal, o CSIRT escolhido e a ENISA recebem a notificação. O coordenador nacional a distribui sem demora aos CSIRTs de outros Estados-Membros em que o produto foi disponibilizado. Informações também podem seguir para autoridades de fiscalização do mercado conforme a necessidade de execução.

O portal resolve a multiplicidade de formulários; não elimina a multiplicidade de mandatos. O fabricante controla fatos e ativos. O CSIRT nacional faz a primeira avaliação pública e gerencia a disseminação. A ENISA opera a camada comum e trabalha com a visão agregada. A fiscalização de mercado decide sobre investigação e medidas corretivas.

Por isso, um recibo de upload não prova o percurso inteiro. A FAQ da ENISA informa que a escolha errada do coordenador pode invalidar a notificação e exigir novo envio. A empresa deve ligar entidade fabricante, estabelecimento e países de disponibilidade do produto antes de clicar em “enviar”.

A exceção tem proponente e decisor diferentes

Há situações em que disseminar detalhes de uma vulnerabilidade explorada pode aumentar o risco. O fluxo de 72 horas oferece, de maneira restrita, o mecanismo de Particularly Exceptional Circumstances, ou PEC.

Segundo a orientação operacional da ENISA, o representante pode marcar a condição e apresentar uma justificativa. Essa ação não bloqueia a rede automaticamente. O CSIRT coordenador decide se existe motivo para retardar a disseminação.

Quando a decisão é favorável, a ENISA recebe inicialmente apenas informação limitada. O coordenador continua responsável por avaliar quando é possível compartilhar a notificação completa com a ENISA e os CSIRTs interessados.

O fabricante pede; a autoridade decide. A separação impede que sigilo comercial seja confundido com motivo cibernético e também evita a circulação mecânica de material que poderia facilitar novos ataques. Para ser auditável, o registro precisa mostrar a solicitação, a justificativa, a decisão e a posterior liberação.

O lançamento não entrega todas as funções da lei

A primeira versão aceita somente notificações obrigatórias de fabricantes sobre vulnerabilidades exploradas ativamente e incidentes graves. A função de relato voluntário do artigo 15 será acrescentada em outra fase. Pessoas e organizações que não sejam fabricantes devem, por enquanto, procurar o CSIRT nacional correspondente.

Os responsáveis por software de código aberto também não entram no relógio atual. Os deveres específicos do artigo 24(3) começam em 11 de dezembro de 2027. Mencioná-los como usuários futuros da plataforma não antecipa a obrigação.

No lançamento, a interface existe apenas em inglês e não oferece API. É possível automatizar o fluxo interno, mas a apresentação formal requer a interface. Para um fabricante com catálogo grande, isso cria uma fila humana sujeita a turnos, férias e falhas de credenciais.

Os representantes designados usam contas pessoais EU Login com autenticação multifator. O CSIRT valida a associação entre a pessoa e o fabricante. A orientação de cadastro prevê que essa verificação ocorra em paralelo ao reporte: antes de se tornar obrigatória, um representante ainda não validado pode apresentar até vinte notificações para o fabricante.

O desenho preserva a urgência, mas transfere uma tarefa para a preparação. Empresa, coordenador, representantes principal e reserva, contas e autenticação precisam estar mapeados antes de uma exploração real.

O contador visível não altera o prazo

A ENISA registrou uma limitação concreta da versão inicial. O contador mostrado para a notificação de 72 horas atualmente adiciona 48 horas ao momento em que o alerta de 24 horas foi enviado. A lei, porém, soma 72 horas ao momento da ciência. Se o alerta inicial sair cedo, o portal pode mostrar atraso antes do fim do prazo jurídico. A agência diz que mudará o cálculo para usar o campo de ciência.

Essa diferença não autoriza esperar mais nem obriga a fingir que a lei mudou. Ela exige duas linhas de tempo. A organização deve guardar a hora da ciência e sua evidência, o primeiro envio, o vencimento de 72 horas calculado internamente, a hora mostrada na tela e os comprovantes do sistema.

O mesmo cuidado vale para indisponibilidade. A FAQ orienta o fabricante a enviar pelo portal quando ele voltar. Havendo necessidade imediata, pode contatar diretamente o CSIRT competente, mas deverá fazer a submissão formal depois. Uma tentativa individual que falhou não demonstra interrupção geral, e uma ligação à autoridade não substitui para sempre o canal comum.

Transparência operacional sem revelar alvos

É possível verificar a execução sem publicar vulnerabilidades ativas. A ENISA poderia manter um histórico público e protegido de versões: disponibilidade, tipos de remetente e relatório aceitos, idiomas, estado da API, lógica dos contadores e momento efetivo de cada mudança.

Esse registro não teria nomes de empresas, produtos, falhas ou atacantes. Serviria para reconstruir qual regra de interface estava em vigor quando determinada obrigação correu. É minha recomendação editorial, não uma exigência atual do CRA ou promessa da ENISA.

Três textos de Lu Heng orientam essa leitura. The Policy Mirror obriga a localizar a autoridade; Running Code Primary exige conferir a regra que o sistema realmente executa; e Why BTW Media Exists impede que uma expectativa institucional seja publicada como evidência.

A Europa abriu uma porta única. O próximo desafio é provar cada entrega sem transformar a porta em dona de todas as decisões.

Fontes