Hoje valem as obrigações de notificação do CRA: o que um fornecedor de plugins faz agora

Hoje é 11 de setembro de 2026, e com essa data passa a valer o artigo 14 do Cyber Resilience Act. O título oficial dele é obrigações de notificação do fabricante. Que ele se aplique justamente a partir de hoje está no artigo 71 do Regulamento (UE) 2024/2847.

Já se escreveu muito sobre o CRA, quase tudo na mesma altura: existe uma obrigação de notificar, existem prazos, se prepare a tempo. Falta a parte que conta quando chega mesmo um e-mail em que alguém descreve uma falha explorada no seu plugin. Qual órgão, qual prazo a partir de qual momento, e o que você anota nas horas seguintes.

É disso que trata este texto. É uma leitura do estado da pesquisa em 21 de agosto de 2026 e não é consultoria jurídica. Onde um dado estava incerto, isso está dito.

Uma observação para quem lê do Brasil

O CRA é direito da União Europeia. Ele não vale no Brasil por si só. Ele pega pelo caminho da distribuição: se o seu plugin é colocado no mercado da União, pago ou de graça, você entra no texto como fabricante, mesmo com sede em São Paulo ou em Curitiba. No diretório aberto do WordPress isso é o caso por padrão, porque de lá qualquer pessoa na União instala.

E a LGPD não substitui nada disso. Ela trata de dados pessoais, o CRA trata de segurança de produto. São duas obrigações distintas, e cumprir uma não cobre a outra.

De quem se fala aqui

Duas definições sustentam o assunto inteiro. Um produto com elementos digitais é, segundo o artigo 3 n.º 1, um produto de software ou de hardware junto com o tratamento de dados à distância, incluindo de forma expressa componentes colocados no mercado separadamente. Um plugin distribuído por conta própria cabe nessa redação. Fabricante é, segundo o artigo 3 n.º 13, quem desenvolve esses produtos ou manda desenvolver e os comercializa com nome ou marca próprios, seja mediante pagamento, monetização ou de forma gratuita. Um plugin gratuito que está no diretório com o seu nome também faz de você um fabricante pela letra do texto.

A parte honesta: essa leitura se sustenta bem sobre as definições primárias, mas até hoje não existe declaração de nenhuma autoridade nem da Comissão que mencione plugins de WordPress de forma expressa.

Três datas, e só uma é hoje

O CRA chega em etapas, e é aí que mora a confusão mais frequente nas conversas sobre ele. O artigo 71 nomeia três datas:

• 11 de junho de 2026: vale o capítulo IV, as regras sobre os organismos notificados. Para um fornecedor de plugins sem avaliação da conformidade nada muda.
• 11 de setembro de 2026: vale o artigo 14, as obrigações de notificação. É hoje.
• 11 de dezembro de 2027: vale o resto do regulamento. Aí entram a marcação CE, a documentação técnica, a avaliação da conformidade e a lista de materiais de software do anexo I parte II.

O que começa hoje é a obrigação de notificar quando algo acontece. O que começa em 2027 é a obrigação de comprovar de forma permanente como você desenvolve. Quem compra ferramentas de SBOM hoje está comprando para daqui a dois anos.

Duas vias de notificação com prazos separados

A fórmula de 24 horas, 72 horas e 14 dias aparece em quase todo artigo de resumo. Ela descreve exatamente um dos dois casos que o artigo 14 regula. O segundo caso tem as mesmas duas primeiras etapas e termina num prazo diferente.

Via 1: vulnerabilidade explorada ativamente

Via 2: incidente grave de segurança

Duas coisas ficam de fora da fórmula curta. A primeira: no incidente o relatório final vence em um mês, e não em 14 dias. A autoridade alemã BSI cita esse prazo de um mês nas próprias páginas dela. A segunda: os prazos não começam todos no mesmo lugar. As 24 e as 72 horas correm a partir do momento em que você toma conhecimento, os 14 dias correm a partir do momento em que existe uma correção disponível, e o mês corre a partir do momento em que você entregou a notificação das 72 horas.

Na prática isso significa que o relatório final da via da vulnerabilidade pode vencer semanas depois do alerta precoce. A entrada dele na agenda só nasce quando o fix existe.

O que dispara a obrigação e o que não dispara

Uma vulnerabilidade explorada ativamente pressupõe indícios consistentes de que um atacante realmente a explora. Um incidente grave de segurança é um evento que afeta ou pode afetar negativamente a capacidade do produto de proteger a disponibilidade, a autenticidade, a integridade ou a confidencialidade dos dados.

Um erro comum não dispara notificação, e um update de rotina também não. Uma falha que um pesquisador de segurança comunica a você e que ninguém explora segue o caminho normal de correção. Quem recebe indícios de exploração em curso e pensa três dias já perdeu o primeiro prazo. Essa distinção é a primeira pergunta que você responde quando o caso é real.

A segunda obrigação, a que costuma sumir

O artigo 14 n.º 8 obriga o fabricante a informar os usuários do produto sobre a vulnerabilidade ou o incidente e, quando for o caso, sobre as medidas que os próprios usuários podem tomar, em formato legível por máquina quando necessário.

É uma obrigação própria, ao lado da notificação às autoridades, e para um fornecedor de plugins é a parte mais visível do regulamento, porque todo cliente percebe. Sem preparo, é justamente essa parte que falha primeiro: se você distribui o plugin de graça pelo wordpress.org, não conhece os seus usuários. Você tem o canal de updates, as notas de versão e o readme. Quem deixa os updates parados não recebe a informação nem quando você a envia direito, e aí começa outro assunto, o de manter os plugins do WordPress atualizados.

Para onde vai a notificação, e por que isso ainda trava hoje

Notifica-se ao mesmo tempo o CSIRT coordenador e a ENISA, pela plataforma única de notificação do artigo 16, a Single Reporting Platform. O CSIRT que recebe distribui a notificação aos CSIRT dos demais Estados-Membros onde o seu produto é distribuído.

Isso é o que diz o regulamento. O estado real em 21 de agosto de 2026 era este:

• A plataforma não estava acessível ao público. A ENISA formulava no futuro: a partir de 11 de setembro de 2026 ela será usada por CSIRT e fabricantes para as notificações obrigatórias.
• Não havia link público de registro. O endereço produtivo da plataforma ainda não tinha sido publicado.
• Havia documentos de orientação da ENISA para registro e para entrega de notificações, atualizados pela última vez em julho e agosto de 2026, e um endereço de suporte: cra-srp-helpdesk@enisa.europa.eu.
• Segundo essas orientações, o acesso passa pelo EU Login. No primeiro acesso são pedidos o papel, o CSIRT competente, um acordo jurídico e os dados do fabricante.

Uma atualização da ENISA de 3 de agosto de 2026 tira um pouco da pressão. A validação da sua conta pelo CSIRT coordenador não é condição para a obrigação de notificar estar cumprida; ela corre em paralelo, então uma conta ainda não liberada não coloca você em infração por si só. O repasse aos CSIRT de outros Estados-Membros é feito manualmente. E a ENISA recomenda criar a conta EU Login com antecedência e deixar o registro na plataforma para quando houver uma notificação concreta. Esses pontos vêm de uma fonte secundária, os documentos de orientação da ENISA não estavam acessíveis livremente.

A parte nacional: para qual órgão você notifica

Notifica-se o CSIRT do Estado-Membro do seu estabelecimento principal. Qual é esse órgão muda de país para país, porque cada Estado-Membro designa o seu. Se o seu estabelecimento principal fica no Brasil e você distribui na União, essa é uma pergunta jurídica que se resolve antes de precisar da resposta, não durante o incidente. Anote o resultado ao lado do seu endereço de segurança.

A Alemanha serve de exemplo, porque lá a designação já está publicada: o BSI com o CERT-Bund. O BSI confirma nas próprias páginas a escada de prazos, inclusive o relatório final em um mês, e remete à ENISA para a plataforma. A lei alemã de execução ainda não estava em vigor em 21 de agosto de 2026. O projeto consta como documento do Bundestag 21/6134 de 26 de maio de 2026, primeira leitura em 11 de junho de 2026, depois encaminhamento à comissão do interior, sem objeções do Bundesrat. Ela não cria obrigações novas, distribui competências. Em outros Estados-Membros a execução nacional segue o próprio calendário.

A comparação com o AI Act é reveladora. Lá a lei alemã de execução está em vigor desde 29 de julho de 2026. No CRA ela ainda tramita, enquanto o regulamento se aplica hoje de forma direta. Um regulamento não espera pela lei nacional que o acompanha, e isso vale em qualquer Estado-Membro onde você esteja estabelecido.

O que custa a notificação que não sai

O artigo 64 n.º 2 prevê, para infrações aos requisitos essenciais do anexo I e às obrigações dos artigos 13 e 14, multas de até 15.000.000 de euros ou, no caso de empresas, de até 2,5 por cento do volume de negócios anual mundial total do exercício anterior, conforme o que for maior. Essa última parte costuma ser omitida, e ao sumir ela inverte o sentido. Não é uma opção de pagar menos.

Para situar: o artigo 64 n.º 3 prevê até 10.000.000 de euros ou 2 por cento para outras obrigações, e o n.º 4 até 5.000.000 de euros ou 1 por cento por informações incorretas, incompletas ou enganosas a organismos notificados e a autoridades de fiscalização do mercado.

E então vem o artigo 64 n.º 10, com uma exceção que quase ninguém cita. As multas não se aplicam a fabricantes que sejam microempresas ou pequenas empresas no que toca ao descumprimento do prazo do artigo 14 n.º 2 alínea a ou do artigo 14 n.º 4 alínea a. São os dois alertas precoces de 24 horas. Também ficam fora das multas dessa disposição os administradores de software livre, os open-source software stewards.

A exceção é estreita e é lida larga demais com frequência. Ela alcança o prazo do alerta precoce. Ela não libera da obrigação de notificar, não cobre a notificação das 72 horas e não cobre o relatório final. Um fornecedor pequeno que simplesmente não notifica está na mesma faixa de multa que um grande.

As primeiras 24 horas, na prática

O que vem a seguir é um modelo de trabalho e não a reprodução de um formulário legal. O regulamento nomeia prazos e destinatários. Quais campos o formulário da plataforma pede de fato não era consultável publicamente em 21 de agosto de 2026. Aqui está o que você tem que reunir de qualquer forma para notificar.

Hora zero. O aviso chega, por e-mail no seu endereço de segurança, pelo fórum de suporte ou por uma plataforma de divulgação. Registre data e hora com precisão de minuto. É aí que o prazo começa, e é o dado que depois você não reconstrói mais.

Primeira hora. Uma pessoa decide qual via. Há indícios de exploração real, entradas de log, instalações comprometidas, um exploit público? Então via 1. Aconteceu algo que quebra a função protetora do produto, um update adulterado ou uma invasão na sua infraestrutura de build? Então via 2. As duas ao mesmo tempo são possíveis, e na dúvida vale a via mais rígida. A decisão fica registrada por escrito.

Até a hora quatro. Determinar o alcance: qual produto, quais versões, desde quando, qual configuração está afetada, se existe uma medida atenuante sem update. Em paralelo, manter contato com quem avisou para que não publique nesse meio-tempo.

Até a hora 24. Entregar o alerta precoce. Ele se chama alerta precoce e não análise, e pode conter pontos em aberto.

O que você precisa para o alerta precoce

• Nome do produto, versões afetadas, dados do fabricante.
• Momento e fonte do seu conhecimento.
• Descrição curta do que aconteceu e do que leva você a concluir que há exploração.
• Primeira avaliação do impacto e da difusão das versões afetadas.
• Os Estados-Membros onde o produto está disponível. Num plugin do diretório aberto, isso é a União inteira.
• O que já está em andamento e para quando você espera uma correção.

O que entra no seu próprio registro

O registro é a metade menos vistosa e mais útil do trabalho. É ele que depois responde à pergunta se você cumpriu os prazos. Um arquivo de texto no repositório basta, desde que alguém o mantenha.

• Momento e fonte do conhecimento.
• A decisão sobre a via, com duas frases de justificativa.
• Momento do alerta precoce, da notificação das 72 horas e do relatório final, cada um com o destinatário.
• Momento a partir do qual houve uma correção disponível. É daí que você conta os 14 dias na via da vulnerabilidade.
• A versão do aviso a clientes exatamente como saiu, e quando.
• Versões afetadas e a versão que contém a correção.

Como é o aviso a clientes

Curto, objetivo, sem panos quentes. Nomear as versões afetadas, dizer o que o usuário deve fazer agora, dizer a partir de qual versão o problema está resolvido. Se houver uma medida provisória, ela vai bem no topo. Num plugin de WordPress o lugar disso é o readme com a entrada de changelog e o próprio update, mais a página de segurança e, se você tiver lista de clientes, um e-mail. A parte legível por máquina do artigo 14 n.º 8 é, num plugin, a indicação de versão no canal de updates.

O que precisa estar pronto antes para você não procurar na urgência

• Um contato de segurança publicado, de preferência uma caixa própria e não o fórum de suporte.
• Um /.well-known/security.txt conforme a RFC 9116, para quem avisa achar o caminho sem adivinhar.
• Uma política de divulgação coordenada: o que você promete, o que você pede, qual é o escopo.
• Um jeito de alcançar todos os usuários afetados. Em plugins gratuitos do diretório é o canal de updates com o readme, em produtos pagos é a lista de clientes.
• Um lugar fixo para o registro, criado antes de você precisar dele.

Isso tudo não leva nem um fim de semana. No meio de um incidente leva tempo demais. Quais ferramentas ajudam a acompanhar as suas instalações é assunto de outra comparação de plugins de segurança.

Onde nós mesmos estamos

Porque um guia que só cobra vale pouco: aqui existe uma página de segurança com contato de segurança publicado, tempos de resposta prometidos, escopo definido e a política de divulgação coordenada, mais um /.well-known/security.txt conforme a RFC 9116 que aponta para essa página. Atrás dela está a autodeclaração com os dados do fabricante, escrita para quem avisa não precisar perguntar por onde entrar.

O que aqui ainda não está pronto cabe no mesmo parágrafo. Dos nossos plugins gratuitos no diretório do WordPress, por exemplo o Wellenbrecher, não conhecemos as instalações. O nosso caminho até esses usuários é o canal de updates e o readme, nada além disso. Registro na plataforma de notificação ainda não é possível, só dá para preparar a conta EU Login. E o nosso registro de incidentes fica interno, não é uma página pública.

Perguntas frequentes