- Desde 11 de setembro de 2026, os fabricantes têm de notificar as vulnerabilidades ativamente exploradas e os incidentes graves que afetem a segurança dos seus produtos (artigo 14.º do Regulamento (UE) 2024/2847).
- Três passos: alerta precoce no prazo de 24 horas, notificação no prazo de 72 horas e um relatório final 14 dias após a disponibilização de uma correção (vulnerabilidades) ou um mês após a notificação (incidentes).
- As comunicações seguem para o CSIRT designado como coordenador no Estado-Membro do seu estabelecimento principal na UE e, em simultâneo, para a ENISA, através da Single Reporting Platform.
- Aplica-se a todos os produtos já no mercado, não só aos novos. O resto do CRA segue-se a 11 de dezembro de 2027.
Quem tem de comunicar: os fabricantes e os produtos abrangidos
O Cyber Resilience Act (CRA) abrange produtos com elementos digitais: hardware e software cuja utilização prevista ou razoavelmente previsível inclua uma ligação de dados a um dispositivo ou a uma rede. Vai de routers, câmaras e dispositivos de casa inteligente a aplicações para computador e telemóvel, firmware e bibliotecas de software vendidas ou monetizadas de outra forma.
Um fabricante é qualquer pessoa que «desenvolve ou fabrica produtos com elementos digitais ou que manda conceber, desenvolver ou fabricar produtos com elementos digitais e os comercializa com o seu nome ou marca, a título oneroso, mediante monetização ou a título gratuito» (artigo 3.º, ponto 13). Um importador ou distribuidor que coloque a sua própria marca num produto, ou que o modifique substancialmente, passa também a ser fabricante (artigo 21.º).
Aspetos a ter em conta pelas PME:
- O SaaS puro está, em geral, fora do âmbito. O CRA só abrange a cloud enquanto «solução de tratamento de dados à distância» necessária para o funcionamento de um produto, como o backend da aplicação de um termóstato inteligente. Os considerandos dizem que os serviços de cloud concebidos fora da responsabilidade de um fabricante de produtos não estão abrangidos e remetem para a NIS2 no caso de SaaS, PaaS e IaaS.
- Existem exclusões setoriais para produtos com regimes próprios, como dispositivos médicos, veículos a motor, aviação civil e equipamentos marítimos.
- A dimensão não isenta da comunicação. Os fabricantes micro e pequenos só escapam às coimas por falharem o prazo de 24 horas do alerta precoce (artigo 64.º, n.º 10, alínea a)), não ao dever em si.
O que desencadeia uma comunicação
1. Uma vulnerabilidade ativamente explorada
Uma vulnerabilidade «relativamente à qual existem provas fiáveis de que um agente malicioso a explorou num sistema sem a permissão do proprietário do sistema» (artigo 3.º, ponto 42). Uma vulnerabilidade comunicada por um investigador, ou encontrada nos seus próprios testes, não é «ativamente explorada» enquanto não houver provas de utilização maliciosa real. A contagem começa então quando toma conhecimento dessas provas.
2. Um incidente grave com impacto na segurança do produto
Nos termos do artigo 14.º, n.º 5, um incidente é grave quando:
- afeta negativamente, ou é suscetível de afetar negativamente, a capacidade do produto de proteger a disponibilidade, a autenticidade, a integridade ou a confidencialidade de dados ou funções sensíveis ou importantes; ou
- levou, ou é suscetível de levar, à introdução ou execução de código malicioso no produto ou nas redes e sistemas de informação de um utilizador.
O exemplo clássico é o comprometimento da cadeia de compilação ou do servidor de atualizações, que poderia enviar código malicioso aos clientes. Note que o incidente diz respeito à segurança do seu produto, o que pode incluir a sua própria infraestrutura de desenvolvimento e distribuição.
Prazos e conteúdo
| Fase | Vulnerabilidade ativamente explorada (art.º 14.º, n.º 2) | Incidente grave (art.º 14.º, n.º 4) |
|---|---|---|
| Alerta precoce | Sem demora injustificada, no prazo de 24 horas após tomar conhecimento. Se forem conhecidos, os Estados-Membros onde o produto está disponível. | No prazo de 24 horas. Se há suspeita de que foi causado por atos ilícitos ou maliciosos e, se forem conhecidos, os Estados-Membros afetados. |
| Notificação | No prazo de 72 horas: informações gerais sobre o produto, a natureza da exploração e da vulnerabilidade, as medidas corretivas ou de mitigação tomadas, as medidas que os utilizadores podem tomar e o grau de sensibilidade que atribui à informação. | No prazo de 72 horas: a natureza do incidente, uma avaliação inicial, as medidas tomadas e as medidas que os utilizadores podem tomar, e a sensibilidade da informação. |
| Relatório final | O mais tardar 14 dias após a disponibilização de uma medida corretiva ou de mitigação: descrição, gravidade e impacto, informações sobre o agente malicioso, se disponíveis, e pormenores da atualização de segurança. | No prazo de um mês após a notificação de 72 horas: descrição pormenorizada, gravidade e impacto, tipo provável de ameaça ou causa raiz, mitigação aplicada e em curso. |
| Relatório intercalar | Só se o CSIRT coordenador pedir atualizações de estado (art.º 14.º, n.º 6). | |
Cada fase posterior aplica-se «salvo se as informações relevantes já tiverem sido fornecidas», pelo que um alerta precoce completo não tem de ser repetido. Use a nossa calculadora de prazos de notificação de violações para transformar o momento do conhecimento em datas concretas e definir lembretes no calendário.
Como comunicar: a Single Reporting Platform
As notificações passam pela Single Reporting Platform (SRP) da ENISA, que entrou em funcionamento a 11 de setembro de 2026 em portal.cra-srp.enisa.europa.eu. A submissão é feita para o ponto de acesso eletrónico do CSIRT designado como coordenador no Estado-Membro do seu estabelecimento principal na UE: onde são predominantemente tomadas as decisões de cibersegurança sobre os seus produtos ou, na falta deste, onde emprega mais pessoal na UE (artigo 14.º, n.º 7). A ENISA recebe a notificação ao mesmo tempo, e o CSIRT coordenador partilha-a com os CSIRT de outros Estados-Membros onde o produto está disponível. Em casos excecionais, pode adiar essa difusão por motivos de cibersegurança.
Os fabricantes sem estabelecimento na UE comunicam ao CSIRT do Estado-Membro onde está estabelecido, por esta ordem, o seu mandatário, importador ou distribuidor do maior número de produtos, ou onde está a maioria dos seus utilizadores.
Segundo as perguntas frequentes da ENISA, as pessoas que comunicam em nome de um fabricante precisam de uma conta EU Login com autenticação multifator, e a plataforma foi lançada em inglês. Registe essas pessoas antes de precisar delas: um prazo de 24 horas é um mau momento para criar contas.
Informar os seus utilizadores
O artigo 14.º, n.º 8, acrescenta um dever fácil de esquecer. Depois de tomar conhecimento de uma vulnerabilidade ativamente explorada ou de um incidente grave, tem de informar os utilizadores afetados e, se adequado, todos os utilizadores, juntamente com as medidas de mitigação e corretivas que podem tomar, se adequado num formato estruturado e legível por máquina. Se não o fizer a tempo, o próprio CSIRT pode informar os seus utilizadores. Uma página de avisos de segurança e um feed CSAF ou semelhante são a resposta prática.
Administradores de software de código aberto e componentes de código aberto
Um administrador de software de código aberto é uma pessoa coletiva, que não um fabricante, que apoia sistematicamente o desenvolvimento de produtos específicos livres e de código aberto destinados a atividades comerciais e assegura a sua viabilidade. As fundações são o exemplo típico. Os administradores têm um regime mais leve (artigo 24.º): uma política de cibersegurança documentada, cooperação com as autoridades de fiscalização do mercado e comunicação ao abrigo do artigo 14.º apenas na medida em que participam no desenvolvimento, ou para incidentes que afetem a infraestrutura que disponibilizam para o desenvolvimento. As perguntas frequentes da ENISA indicam que a comunicação pelos administradores se aplica a partir de 11 de dezembro de 2027. Os administradores não podem ser sancionados com coimas ao abrigo do CRA (artigo 64.º, n.º 10, alínea b)).
Os projetos de código aberto amadores que não são monetizados não são fabricantes. Mas se o seu produto incluir uma biblioteca de código aberto e essa biblioteca for ativamente explorada no seu produto, o dever de comunicação é seu, enquanto fabricante do produto. A partir de 11 de dezembro de 2027, também tem de comunicar as vulnerabilidades que encontrar em componentes integrados, incluindo os de código aberto, a quem os mantém (artigo 13.º, n.º 6).
O resto do calendário do CRA
- 10 de dezembro de 2024O CRA entra em vigor (publicado no Jornal Oficial a 20 de novembro de 2024).
- 11 de junho de 2026Aplica-se o capítulo IV: regras para os organismos de avaliação da conformidade (organismos notificados).
- 11 de setembro de 2026A comunicação do artigo 14.º aplica-se a todos os produtos abrangidos, incluindo os colocados no mercado antes de 11 de dezembro de 2027 (artigo 69.º, n.º 3).
- 1 de outubro de 2026: está aqui
- 11 de dezembro de 2027Aplicação plena: requisitos essenciais de cibersegurança (Anexo I), tratamento de vulnerabilidades, marcação CE, avaliação da conformidade, períodos de suporte, documentação técnica e obrigações dos importadores, distribuidores e administradores de software de código aberto. Os produtos colocados no mercado antes desta data só ficam sujeitos a estes requisitos após uma modificação substancial.
- 11 de junho de 2028Os certificados de exame UE de tipo existentes para requisitos de cibersegurança ao abrigo de outra legislação caducam, salvo se caducarem antes.
As coimas por violação do Anexo I ou dos artigos 13.º e 14.º chegam a 15 milhões de EUR ou 2,5 % do volume de negócios anual a nível mundial, consoante o que for mais elevado (artigo 64.º, n.º 2).
Comunicação CRA e NIS2 lado a lado
Os dois regimes parecem semelhantes (24 horas, 72 horas, um relatório final), mas respondem a perguntas diferentes. A NIS2 pergunta se o seu serviço aos clientes foi perturbado de forma significativa. O CRA pergunta se o seu produto está a ser explorado ou se a sua segurança foi comprometida.
| Artigo 14.º do CRA | Artigo 23.º da NIS2 | |
|---|---|---|
| Quem | Fabricantes de produtos com elementos digitais (de qualquer dimensão) | Entidades essenciais e importantes de setores dos Anexos I/II |
| Acionador | Vulnerabilidade ativamente explorada; incidente grave que afeta a segurança do produto | Incidente significativo que afeta a prestação dos serviços da entidade |
| Destinatário | CSIRT coordenador e ENISA através da Single Reporting Platform | CSIRT nacional ou autoridade competente, através dos canais nacionais |
| Cronologia | 24 h / 72 h / relatório final 14 dias após a correção (vulnerabilidade) ou 1 mês (incidente) | Alerta precoce 24 h / notificação 72 h / relatório final no prazo de 1 mês |
| Desde | 11 de setembro de 2026 | Depende da transposição nacional (o prazo era 17 de outubro de 2024) |
Uma empresa pode estar abrangida por ambos. Um fabricante de equipamento de rede de média dimensão pode estar abrangido pela NIS2 (o fabrico de equipamentos informáticos, eletrónicos e óticos é um setor do Anexo II) e pelo CRA. O comprometimento do seu servidor de atualizações pode então ser simultaneamente um incidente significativo ao abrigo da NIS2 e um incidente grave ao abrigo do CRA, com duas comunicações por dois canais. Planeie ambos num único manual de procedimentos. Os considerandos do CRA incentivam os Estados-Membros a oferecer pontos de entrada únicos nacionais e, em novembro de 2025, a Comissão propôs um ponto de entrada único a nível da UE para a comunicação de incidentes no âmbito do seu pacote Digital Omnibus. Enquanto esse ponto não existir no seu país, parta do princípio de que as comunicações são separadas. Se houver dados pessoais afetados, a notificação de violações de 72 horas do RGPD corre em paralelo com ambas. Se for uma entidade NIS2, a nossa verificação de incidentes significativos NIS2 ajuda com o teste de «significância».
Lista de verificação de preparação
- Liste os seus produtos com elementos digitais e os Estados-Membros onde estão disponíveis.
- Determine o seu estabelecimento principal e, por conseguinte, o seu CSIRT coordenador.
- Registe pelo menos duas pessoas na Single Reporting Platform, com EU Login e autenticação multifator.
- Defina «ativamente explorada» e «incidente grave» nos seus procedimentos de vulnerabilidades e de incidentes, com exemplos.
- Organize a receção: um contacto de segurança (por exemplo, security.txt), uma política de divulgação coordenada de vulnerabilidades e a monitorização de informações sobre ameaças, como o catálogo KEV da CISA e os avisos dos CSIRT.
- Mantenha uma SBOM para conseguir saber em poucas horas se um componente explorado está nos seus produtos.
- Prepare modelos para as comunicações de 24 h, de 72 h e final, bem como um aviso aos utilizadores.
- Registe os momentos de conhecimento: a contagem corre a partir do momento em que toma conhecimento.
- Ensaie uma vez com um exercício de simulação, combinando as contagens do CRA, da NIS2 e do RGPD quando relevante.
Faça as contagens a partir de um único registo de incidente
O registo de incidentes do Dazr Compliance regista uma única vez o momento do conhecimento e mostra cada prazo: 72 horas do RGPD, 24 h, 72 h e um mês da NIS2, e contagens personalizadas como o relatório final do CRA. Guarda as evidências e as referências dos processos da autoridade numa pista de auditoria exportável.
Perguntas frequentes
A comunicação CRA aplica-se a produtos vendidos antes de 11 de dezembro de 2027?
Sim. O artigo 69.º, n.º 3, faz com que as obrigações de comunicação do artigo 14.º se apliquem a todos os produtos abrangidos, incluindo os colocados no mercado antes de 11 de dezembro de 2027. Os requisitos de conceção só se aplicam a esses produtos anteriores após uma modificação substancial.
Quando começa a contagem das 24 horas?
Quando o fabricante toma conhecimento da vulnerabilidade ativamente explorada ou do incidente grave. Para as vulnerabilidades, é quando tem provas fiáveis de exploração maliciosa, não quando o erro foi comunicado pela primeira vez.
A nossa plataforma SaaS está abrangida pela comunicação CRA?
Em geral não, a menos que seja uma solução de tratamento de dados à distância sem a qual um produto com elementos digitais não consegue desempenhar uma das suas funções. O SaaS enquanto tal está abrangido pela NIS2 se cumprir os respetivos critérios de dimensão e setor.
As pequenas empresas estão isentas?
Não. Os fabricantes micro e pequenos também têm de comunicar. Não podem ser sancionados com coima por falharem o prazo de 24 horas do alerta precoce, mas as restantes obrigações e coimas continuam a aplicar-se.
Relacionado
Fontes (situação a 1 de outubro de 2026)
- Regulamento (UE) 2024/2847 (Cyber Resilience Act), artigos 3.º, 13.º, 14.º, 16.º, 21.º, 24.º, 64.º, 69.º e 71.º.
- ENISA: The CRA Single Reporting Platform is launched, 11 de setembro de 2026.
- Perguntas frequentes da Single Reporting Platform da ENISA.
- Comissão Europeia: obrigações de comunicação do Cyber Resilience Act.
- Diretiva (UE) 2022/2555 (NIS2), artigo 23.º.
Este guia explica o CRA à data de 1 de outubro de 2026 e não constitui aconselhamento jurídico.