O dever de comunicação do Cyber Resilience Act já está em vigor. Na maioria dos fabricantes, os processos ainda são pura encenação.

Hoje, 11 de setembro de 2026, o dever de comunicação do Cyber Resilience Act entra em vigor em toda a União Europeia. Não em dezembro de 2027, quando chegam os requisitos essenciais de produto e toda a gente foi avisada para esperar o verdadeiro ajuste de contas. Hoje. Se fabricas um produto com elementos digitais e o vendes no mercado da UE, o relógio da tua primeira notificação começa a contar a partir deste momento, quer a tua organização tenha marcado a data no calendário, quer não.

Escrevi em julho que o Cyber Resilience Act era o regulamento que ninguém estava a acompanhar com atenção suficiente, aquele que consegue retirar um produto do mercado em vez de apenas multar a empresa por trás dele. Esse texto centrava-se no grande retrato da conformidade: âmbito, categorização, a relação com a NIS2. Este é sobre a obrigação muito mais estreita e muito mais afiada que acabou de entrar em vigor, e sobre a distância incómoda entre quantos fabricantes dizem que a conhecem e quantos conseguem realmente agir dentro das horas que a lei lhes dá.

A data que ninguém estava a acompanhar

A maior parte da cobertura do CRA ainda gravita em torno de dezembro de 2027, e compreensivelmente, já que é aí que os requisitos essenciais de cibersegurança e as obrigações de avaliação da conformidade se aplicam na íntegra. Mas o artigo 14. do regulamento reservou uma data separada e anterior especificamente para a comunicação: a partir de 11 de setembro de 2026, os fabricantes têm de notificar vulnerabilidades ativamente exploradas e incidentes graves que afetem os seus produtos, e esse dever aplica-se a produtos já colocados no mercado, não apenas a novos lançamentos.

A Comissão Europeia publicou as suas orientações práticas sobre isto a 27 de julho de 2026, apenas algumas semanas antes de a data entrar em vigor. É uma janela estreita para uma obrigação com um primeiro prazo de 24 horas associado. Os requisitos essenciais de dezembro de 2027 dão aos fabricantes cerca de quinze meses de margem a partir deste momento. O dever de comunicação deu muito menos.

O que é que tens exatamente de comunicar?

Esta é a pergunta que faz as pessoas tropeçar, e vale a pena respondê-la com precisão em vez de em termos gerais.

Comunicas uma vulnerabilidade ativamente explorada, ou seja, há provas credíveis de que alguém a está a usar contra o teu produto neste momento. Comunicas um incidente grave, ou seja, algo que compromete efetivamente a segurança do teu produto, não apenas uma fragilidade teórica. O que não comunicas é cada CVE atribuída à tua base de código, cada achado do teu próprio teste de intrusão, ou cada submissão feita através do teu programa de divulgação responsável ou de bug bounty, a menos que haja provas de que foi de facto explorada. O webinar que o Ministério dos Assuntos Económicos e Política Climática neerlandês e o National Cyber Security Centre (NCSC) realizaram a 27 de agosto foi direto sobre esta distinção, e por boas razões: sem ela, os fabricantes ou afogariam o seu CSIRT nacional em ruído ou, pior, assumiriam que cada comunicação de vulnerabilidade exige a mesma urgência de 24 horas e esgotariam a equipa que é suposto tratar das que realmente importam.

Podes na mesma comunicar voluntariamente os casos de menor gravidade, e há boas razões para criar esse hábito. Mas o dever legal recai especificamente sobre a exploração ativa e os incidentes graves, e saber onde fica essa linha é a primeira coisa que o teu processo de resposta a incidentes precisa de acertar.

O relógio não faz pausa para a tua reunião de resposta a incidentes

Assim que sabes, o calendário é faseado e implacável. Um aviso prévio sai no prazo de 24 horas depois de teres tomado conhecimento. Uma notificação mais completa segue-se no prazo de 72 horas, cobrindo o que sabes até então sobre a natureza, o impacto e as medidas de mitigação. Um relatório final encerra o assunto: catorze dias depois de uma medida corretiva ficar disponível para uma vulnerabilidade, ou um mês para um incidente grave, de acordo com as orientações da Comissão Europeia.

A análise da Freshfields sobre a nova obrigação faz um ponto que vale a pena assimilar: os prazos de comunicação começam no momento em que tomas conhecimento, e o relógio não pára aos fins de semana nem nos feriados. Não há período de tolerância pelo facto de o teu responsável de segurança estar numa conferência, ou de o incidente ter acontecido a uma sexta-feira à noite. Se a tua organização ainda não tem um processo definido para quem avalia uma comunicação, quem decide se ultrapassa o limiar e quem a submete, estás a construir esse processo pela primeira vez sob um prazo de 24 horas em curso, que é precisamente o pior momento para construir seja o que for.

A comunicação em si passa pelo teu CSIRT nacional, o NCSC nos Países Baixos, e pela Single Reporting Platform à escala da UE operada pela ENISA, por isso um fabricante na Bélgica, na Alemanha ou em qualquer outro ponto da UE segue o mesmo calendário faseado através do seu próprio ponto de contacto nacional. Os mecanismos diferem ligeiramente de Estado-Membro para Estado-Membro; a obrigação e os prazos não.

Porque é que os números de preparação são tão maus?

É aqui que a afirmação de que “na maioria dos fabricantes os processos são pura encenação” tem de justificar o seu lugar, e os dados dos inquéritos apoiam-na de forma mais crua do que eu esperava.

O SME Cyber Resilience Maturity Assessment Model da ENISA, publicado a 13 de julho de 2026 e baseado em trabalho de campo com 194 organizações em 31 países, encontrou muita consciência do CRA mas uma preparação prática consistentemente fraca, com a resposta a incidentes e a gestão do ciclo de vida do produto a pontuarem como os dois domínios mais frágeis no conjunto. Estar consciente de que uma lei existe não é o mesmo que ter um processo capaz de agir dentro de uma janela de 24 horas.

A investigação de 2026 da Linux Foundation e da OpenSSF sobre a preparação para o CRA, obtida a partir de 843 inquiridos, conta uma história semelhante de um ângulo diferente. Sessenta e seis por cento ainda não sabiam o que precisavam efetivamente de fazer para cumprir, um valor que mal se tinha mexido desde os 62 por cento do ano anterior. Apenas 41 por cento dos fabricantes esperavam alcançar a conformidade total até ao prazo de dezembro de 2027, e apenas 34 por cento identificaram corretamente essa data logo à partida. Entre os inquiridos que estavam de todo cientes do CRA, 54 por cento ainda não conseguiam distinguir claramente entre as obrigações de um fabricante e as de um responsável pela manutenção.

Nada disto é uma crítica a qualquer equipa de conformidade em particular. Reflete um regulamento que passou de abstrato a operacional mais depressa do que a maioria dos processos organizacionais conseguiu acompanhar. Mas significa, sim, que uma fatia significativa dos fabricantes que estão a ler isto cruzou a linha de 11 de setembro sem qualquer processo testado por trás, que é exatamente o cenário que o dever de comunicação foi concebido para apanhar em falta.

Quem tem de facto de comunicar?

Ao abrigo do CRA, a obrigação de comunicação recai sobre o fabricante, a entidade que coloca um produto com elementos digitais no mercado da UE sob o seu próprio nome ou marca, e a dimensão da organização não te isenta. Um importador ou distribuidor geralmente não carrega um dever de comunicação independente, a menos que venda sob a sua própria marca ou modifique substancialmente o produto, caso em que se torna efetivamente o fabricante desse produto. Os responsáveis pela manutenção de software de código aberto enfrentam uma versão mais leve do mesmo dever, refletindo a relação diferente que têm com os produtos que mantêm. As pequenas e microempresas estão também plenamente abrangidas; a única concessão que o NCSC neerlandês confirmou é que não há penalização por falhar a janela estrita de 24 horas nessa categoria, o que é uma mitigação, não uma isenção.

Um detalhe que vale a pena assinalar porque causa confusão real: o próprio CRA não exige qualquer registo prévio antes de poderes comunicar. Não precisas de uma conta nem de credenciais para submeter uma notificação. Trata-se de uma opção de conceção deliberada, separada do dever de registo que existe ao abrigo da Cyberbeveiligingswet (a transposição neerlandesa da NIS2) para as organizações que também caem sob essa lei. As duas obrigações correm em paralelo, não como um único processo combinado, e confundi-las é um erro fácil de cometer.

Como é que “estar preparado” se parece, na prática?

Preparar-se para o dever de comunicação do CRA não é complicado em princípio. É exigente na prática, o que é um problema diferente.

Começa com um inventário honesto do que está de facto dentro dos teus produtos, idealmente através de um Software Bill of Materials, porque não consegues avaliar se uma vulnerabilidade comunicada te afeta se não sabes que componentes envias. Define de antemão os teus próprios limiares internos para o que conta como exploração ativa ou incidente grave, para que esse juízo não seja feito pela primeira vez sob pressão. Constrói um caminho de escalonamento com papéis nomeados: quem sinaliza, quem decide, quem submete. Redige agora modelos para o aviso prévio, a notificação de 72 horas e o relatório final, enquanto ninguém está sob prazo. E alinha isto com tudo o resto ao abrigo do qual já comunicas, já que um número razoável dos fabricantes que estão a ler isto também está sob a Cyberbeveiligingswet ou a AVG, e correr três processos de comunicação descoordenados é um risco em si mesmo.

Esta é, não por acaso, a mesma disciplina que defendi em julho quando escrevi sobre as exigências de conformidade mais amplas do CRA: sabe o que tens, categoriza-o com honestidade, e constrói a papelada antes de o regulador a pedir. O dever de comunicação limitou-se a mudar esse argumento de “um dia” para “agora”.

Se um cliente te dissesse esta manhã que alguém estava a explorar ativamente uma vulnerabilidade no teu produto, saberia a tua organização, no prazo de 24 horas, exatamente quem recebe essa comunicação? Se a resposta honesta for “logo se via”, o dever de comunicação não entrou em vigor hoje por nada.

Fontes

• European Commission, Cyber Resilience Act, Reporting obligations, Shaping Europe’s Digital Future: digital-strategy.ec.europa.eu/en/policies/cra-reporting
• ENISA, SME Cyber Resilience Maturity Assessment Model, published 13 July 2026.
• Linux Foundation Research, Linux Foundation Europe, and OpenSSF, “The CRA Readiness Reality: What Changed (and What Didn’t) Between 2025 and 2026?”, June 2026: linuxfoundation.org
• Freshfields, “Cyber Resilience Act reporting obligations take effect on 11 September 2026”: freshfields.com
• Ministry of Economic Affairs and Climate Policy and National Cyber Security Centre (NCSC), Cyber Resilience Act, Themasessie Meldplicht (webinar), 27 August 2026.