Regulamento de Ciber-Resiliência (CRA) e plugins WordPress

Quem vende um plugin ou tema WordPress premium a clientes na UE já está sujeito ao Regulamento de Ciber-Resiliência (CRA). Desde 11 de setembro de 2026, é obrigatório notificar as vulnerabilidades ativamente exploradas e os incidentes graves que afetem os seus produtos, a começar por um alerta precoce no prazo de 24 horas. O conjunto mais amplo de deveres, dos requisitos de segurança e da lista de materiais de software (SBOM) às atualizações de segurança e à marcação CE, aplica-se a partir de 11 de dezembro de 2027.

Este guia explica quem conta como fabricante, o que o dever de notificação implica na prática e o que fazer desde já. O texto legal é o Regulamento (UE) 2024/2847.

Quem é fabricante nos termos do Regulamento de Ciber-Resiliência?

O CRA abrange os «produtos com elementos digitais» disponibilizados no mercado da UE no âmbito de uma atividade comercial. Um plugin ou tema WordPress premium vendido a clientes da UE é um desses produtos, e a pessoa ou empresa que o desenvolve e o vende em nome próprio é o seu fabricante. Isto vale tanto para quem está estabelecido na UE como fora dela.

Plugins gratuitos, freemium e pagos

O software livre e de código aberto que não é monetizado fica, em regra, fora do regime dos fabricantes. Um plugin amador no WordPress.org sem qualquer versão paga, ou o código com que alguém contribui para um projeto alheio, são exemplos típicos.

Os modelos freemium são menos claros. Os considerandos do CRA enumeram indícios de atividade comercial: cobrar um preço pelo produto, cobrar pelo suporte acima da mera recuperação de custos, monetizar através de uma plataforma ou de outros serviços, exigir dados pessoais como condição de utilização por motivos que não sejam de segurança, compatibilidade ou interoperabilidade, e aceitar donativos que excedam os custos. Um plugin «lite» gratuito que existe sobretudo para vender uma versão Pro ou um serviço pago pode, por isso, contar como atividade comercial. Se o negócio se enquadra nesta descrição, o prudente é planear como fabricante e obter aconselhamento jurídico quanto aos pormenores.

Administradores de software de código aberto

O CRA cria também a figura do «administrador de software de código aberto» (open-source software steward): pessoas coletivas, como fundações, que apoiam de forma sistemática o desenvolvimento de software livre e de código aberto destinado a atividades comerciais, sem serem o seu fabricante. Os administradores têm um regime mais leve, e as suas obrigações de notificação aplicam-se a partir de 11 de dezembro de 2027.

Porque é que o site não é um produto CRA

Um site ou um serviço alojado, enquanto tal, não é em regra um «produto» na aceção do CRA. O tratamento de dados à distância só fica abrangido quando é essencial para a função de um produto. O site institucional, a loja online e o portal de clientes não são, portanto, em regra, produtos CRA, e ter um site WordPress não faz de ninguém fabricante. Um serviço na nuvem sem o qual o plugin não funciona é um caso a analisar com cuidado.

Para os donos de sites, o CRA atua de forma indireta, através dos deveres dos vendedores de plugins e temas. Os deveres próprios dos donos de sites resultam do RGPD e, para alguns, da NIS2.

Cronologia do CRA para quem vende plugins WordPress

• 10 de dezembro de 2024: o CRA entrou em vigor.
• 11 de junho de 2026: passam a aplicar-se as disposições relativas aos organismos de avaliação da conformidade.
• 11 de setembro de 2026: passam a aplicar-se as obrigações de notificação dos fabricantes.
• 11 de dezembro de 2027: aplicam-se as obrigações principais, incluindo os requisitos essenciais de cibersegurança, a avaliação da conformidade e a marcação CE.

Notificações desde 11 de setembro de 2026: 24 horas, 72 horas, 14 dias

O dever de notificação abrange dois tipos de eventos. Uma vulnerabilidade ativamente explorada é aquela relativamente à qual existem provas fiáveis de que um agente malicioso a explorou num sistema sem autorização do proprietário. Um incidente grave afeta a segurança do produto, por exemplo porque leva, ou pode levar, à introdução de código malicioso no produto ou nos sistemas dos utilizadores. Para um vendedor de plugins, um servidor de atualizações ou de licenças comprometido que distribui uma versão com backdoor é um exemplo claro.

O dever aplica-se também aos produtos colocados no mercado antes de 11 de dezembro de 2027 (art. 69.º, n.º 3). Ou seja, abrange as versões do plugin que os clientes usam hoje.

Os prazos contam a partir do momento em que o fabricante toma conhecimento da vulnerabilidade ou do incidente. As notificações são submetidas através da plataforma única de comunicação de informações do CRA (Single Reporting Platform) da ENISA, operacional desde 11 de setembro de 2026, e seguem para a CSIRT do Estado-Membro onde o fabricante tem o estabelecimento principal na UE (aplicam-se outras regras se não tiver nenhum). A ENISA recebe-as em simultâneo. É ainda obrigatório informar os utilizadores afetados e, se for caso disso, todos os utilizadores sobre o problema e as medidas de mitigação ao seu alcance.

Um cenário realista: um investigador de segurança ou uma empresa de alojamento avisa que uma falha no plugin está a ser usada em ataques. A partir desse momento, o prazo de 24 horas está a correr. O nosso guia sobre plugins WordPress vulneráveis mostra a rapidez com que estas falhas são exploradas depois de se tornarem públicas. Se também tiverem ficado expostos dados pessoais, por exemplo no próprio servidor de licenças, as regras do RGPD sobre violações de dados aplicam-se em paralelo; veja a notificação de violações de dados em 72 horas.

O que se aplica a partir de 11 de dezembro de 2027

A partir de dezembro de 2027, as obrigações completas dos fabricantes aplicam-se aos plugins e temas que colocam no mercado. Os produtos colocados no mercado antes dessa data só ficam abrangidos se forem objeto de uma modificação substancial posterior (art. 69.º, n.º 2). Os principais deveres:

• Segurança desde a conceção e nenhuma vulnerabilidade explorável conhecida no lançamento.
• Configuração segura por predefinição.
• Um período de suporte durante o qual o fabricante trata as vulnerabilidades. Em regra, é de pelo menos cinco anos, salvo se se previr que o produto seja usado durante menos tempo, e a data de fim (pelo menos mês e ano) tem de ser clara no momento da compra.
• Atualizações de segurança distribuídas sem demora, gratuitamente e acompanhadas de avisos. Convém verificar como isto se conjuga com um modelo de licenças em que as atualizações param quando a subscrição termina.
• Um processo de tratamento de vulnerabilidades e uma política de divulgação coordenada de vulnerabilidades (CVD), além de um ponto de contacto único que os utilizadores consigam contactar rapidamente.
• Uma SBOM num formato legível por máquina que abranja, pelo menos, as dependências de nível superior. Num plugin, pense-se nos pacotes Composer e npm e em quaisquer bibliotecas incluídas.
• Documentação técnica, uma avaliação da conformidade e a marcação CE.

Alguns tipos de produtos constam do Anexo III como «produtos importantes», com regras de avaliação da conformidade mais exigentes. Incluem software que procura, remove ou coloca em quarentena software malicioso, gestores de palavras-passe e software de gestão de identidades e de gestão de acessos privilegiados (classe I), bem como firewalls e sistemas de deteção e prevenção de intrusões (classe II). Se o plugin for um produto de segurança, estas categorias merecem uma verificação cuidadosa.

Coimas nos termos do artigo 64.º

O incumprimento dos requisitos essenciais de cibersegurança ou das obrigações dos fabricantes, incluindo o dever de notificação, pode dar lugar a coimas até 15 milhões de euros ou 2,5 % do volume de negócios anual a nível mundial, consoante o montante mais elevado. Há um alívio para os pequenos vendedores: as microempresas e pequenas empresas não podem ser sancionadas com coima por falharem o prazo de 24 horas do alerta precoce, e os administradores de software de código aberto não podem, de todo, ser alvo de coimas ao abrigo do CRA. Para os fabricantes micro e pequenos, a notificação de 72 horas e todos os outros deveres continuam plenamente exigíveis.

Lista de tarefas para vendedores de plugins WordPress

• Listar todos os plugins e temas pagos, extras (add-ons) e produtos freemium oferecidos a clientes da UE, e determinar em quais a empresa é o fabricante.
• Montar uma receção de vulnerabilidades que funcione em 24 horas: um endereço de contacto de segurança, um ficheiro security.txt no site, uma caixa de correio vigiada e um substituto designado para as férias.
• Pôr por escrito o procedimento de notificação: quem decide se uma vulnerabilidade está a ser ativamente explorada, quem submete a notificação na plataforma única e quem redige o aviso aos utilizadores.
• Preparar modelos para o alerta precoce, a notificação de 72 horas e o relatório final.
• Publicar uma política de divulgação coordenada de vulnerabilidades.
• Gerar uma SBOM para cada versão (CycloneDX e SPDX são formatos comuns) e guardá-la junto do build.
• Proteger a cadeia de publicação: autenticação multifator em todas as contas que possam publicar código, e servidores de atualizações e de licenças reforçados.
• Definir um período de suporte para cada produto e planear como os clientes com licenças expiradas recebem as correções de segurança.
• Iniciar a documentação técnica: arquitetura, fluxos de dados, avaliação de riscos e resultados de testes.
• Verificar se algum dos produtos se enquadra no Anexo III.

Como verificação adicional antes de um lançamento, o plugin gratuito Security Audit & Compliance da secaudit.eu inclui uma análise de vulnerabilidades no código (análise de taint) de plugins e temas. Complementa a revisão de código e os testes próprios; não os substitui.

Perguntas frequentes

O CRA aplica-se a plugins gratuitos no WordPress.org?

Em regra, não, se o plugin não for monetizado. Se a versão gratuita servir de porta de entrada para um produto ou serviço pago, pode contar como atividade comercial, pelo que convém obter aconselhamento.

Só crio sites para clientes. Sou fabricante?

Não em relação ao site: um site, enquanto tal, não é em regra um produto CRA. Quem também vende um plugin ou tema no mercado da UE é o fabricante desse produto.

Este artigo contém informação geral e não constitui aconselhamento jurídico.