O Cyber Resilience Act —Regulamento (UE) 2024/2847— transforma a cibersegurança num requisito legal de acesso ao mercado europeu para qualquer produto conectado, com a marcação CE como prova de conformidade. Se precisa de esclarecer primeiro o enquadramento —que produtos entram, que papel lhe cabe, como se classifica o seu portefólio e que sanções existem—, comece por Cyber Resilience Act (CRA): o que é, a quem obriga e como se classificam os produtos.
Esta segunda parte vai ao trabalho real: o que o Anexo I exige tecnicamente, como se monta o processo de notificação de vulnerabilidades e incidentes, o que contém o dossiê de marcação CE, como o CRA se articula com a NIS2 e a ISO 27001 sem duplicar esforço e por que ordem convém abordar tudo.
11 de setembro de 2026 — obrigações de notificação de vulnerabilidades exploradas ativamente e incidentes graves, através da plataforma única gerida pela ENISA. Aplica-se também a produtos já comercializados, sem período transitório. É o primeiro requisito exigível e está a semanas.
11 de dezembro de 2027 — requisitos essenciais do Anexo I, avaliação da conformidade, documentação técnica, declaração UE de conformidade e marcação CE.
Um aviso do terreno: a Comissão propôs adiar dois meses os prazos do pedido de normalização. As normas horizontais de gestão de vulnerabilidades são esperadas para o final de outubro de 2026 e as normas verticais por produto ao longo de dezembro de 2026. Como a autoavaliação dos produtos importantes de classe I depende de poder aplicar normas harmonizadas, convém rever o seu estado antes de fechar o plano de conformidade.
Requisitos essenciais do Anexo I: segurança por conceção e gestão de vulnerabilidades
O coração técnico do CRA é o seu Anexo I, dividido em duas partes que correspondem a dois momentos distintos do ciclo de vida: como o produto é concebido e entregue, e como é mantido depois de vendido.
Parte I — Propriedades de cibersegurança do produto
O produto deve ser concebido, desenvolvido e fabricado de forma a garantir um nível de cibersegurança adequado ao risco. Entre outros requisitos:
- Ser comercializado sem vulnerabilidades exploráveis conhecidas.
- Ser entregue com uma configuração segura por defeito e com possibilidade de a repor.
- Permitir a correção de vulnerabilidades através de atualizações, automáticas quando aplicável e com aviso ao utilizador.
- Proteger contra acessos não autorizados com mecanismos de autenticação, gestão de identidades e controlo de acessos.
- Garantir a confidencialidade e integridade de dados e comandos, com cifragem em repouso e em trânsito.
- Aplicar minimização de dados: tratar apenas os dados necessários para o uso previsto.
- Proteger a disponibilidade das funções essenciais e reduzir a superfície de ataque.
- Registar e monitorizar a atividade interna relevante para a segurança (logs).
- Permitir o apagamento seguro e a portabilidade de dados e configurações.
Nenhum destes requisitos é exótico para uma equipa que já trabalha com práticas de desenvolvimento seguro. A novidade não é o «quê», mas sim que, a partir de dezembro de 2027, é preciso conseguir demonstrá-lo documentalmente, produto a produto, perante uma autoridade de fiscalização do mercado.
Parte II — Gestão de vulnerabilidades durante o período de suporte
A segunda parte obriga a manter o produto seguro após a venda. Aqui surgem as três novidades com maior impacto operacional:
Lista de materiais de software
O fabricante deve identificar e documentar os componentes do produto e elaborar um SBOM em formato legível por máquina que cubra, no mínimo, as dependências de primeiro nível.
Período de suporte
Deve ser declarado um período de suporte de pelo menos cinco anos —ou a vida útil esperada do produto, se for inferior— com data de fim explícita (mês e ano) conhecida no momento da compra.
Divulgação coordenada
É necessário publicar uma política de divulgação coordenada de vulnerabilidades, um ponto de contacto para as reportar e distribuir os patches de segurança de forma gratuita e sem demora.
Estas três peças estão encadeadas: sem SBOM não se sabe se uma vulnerabilidade publicada afeta o produto; sem o saber, não se pode aplicar um patch dentro do período de suporte declarado; e sem patch não há nada a comunicar nos prazos de notificação que vêm a seguir.
Notificação de vulnerabilidades e incidentes: 24 horas, 72 horas e 14 dias
A partir de 11 de setembro de 2026, os fabricantes devem notificar simultaneamente o CSIRT designado como coordenador —o do Estado-Membro onde tenham o seu estabelecimento principal; em Espanha, INCIBE-CERT— e a ENISA, através da plataforma única de notificação. Notificam-se dois cenários: vulnerabilidades exploradas ativamente e incidentes graves que afetem a segurança do produto.
Alerta precoce
Desde que o fabricante tem conhecimento. Basta indicar que existe e, se conhecidos, os Estados-Membros afetados.
Notificação
Informação geral sobre o produto afetado, a natureza do problema e as medidas corretivas ou mitigadoras disponíveis.
Relatório final
14 dias desde que exista uma medida corretiva, em vulnerabilidades exploradas ativamente. 1 mês desde a notificação, em incidentes graves.
Em paralelo com esses três marcos, o fabricante deve informar sem demora indevida os utilizadores afetados —e, quando aplicável, o público— sobre o incidente e as medidas corretivas que devem aplicar. Não é um quarto prazo: é uma obrigação simultânea que convém ter guionizada, porque envolve comunicação e suporte, não apenas segurança.
As microempresas e pequenas empresas não enfrentam multas por incumprirem especificamente o prazo do alerta precoce de 24 horas, mas mantêm as restantes obrigações de notificação.
Marcação CE e avaliação da conformidade
Antes de comercializar o produto —e com data-limite de 11 de dezembro de 2027—, o fabricante tem de completar e conservar um dossiê de conformidade. Por ordem:
- Realizar e documentar uma avaliação dos riscos de cibersegurança do produto.
- Concluir com sucesso o procedimento de avaliação da conformidade correspondente à sua classe —autoavaliação por controlo interno, exame UE de tipo, garantia da qualidade total ou certificação europeia, conforme a classificação do produto.
- Elaborar a documentação técnica que comprove o cumprimento dos requisitos do Anexo I.
- Emitir a declaração UE de conformidade.
- Afixar a marcação CE no produto, na sua embalagem ou na documentação que o acompanha.
- Entregar instruções de utilização e informação ao utilizador, incluindo a data de fim do período de suporte.
Essa documentação deve ser conservada durante pelo menos dez anos —ou durante o período de suporte, se for superior— à disposição das autoridades de fiscalização do mercado.
Em Espanha, a distribuição institucional prevista fica assim:
| Função | Organismo |
|---|---|
| Autoridade de fiscalização do mercado Inspeciona, solicita documentação e pode ordenar a retirada do produto. |
Ministério para a Transformação Digital e da Função Pública |
| Autoridade notificante Designa e supervisiona os organismos de avaliação da conformidade. |
Centro Criptológico Nacional (CCN) |
| CSIRT coordenador Recetor das notificações de vulnerabilidades e incidentes, juntamente com a ENISA. |
INCIBE-CERT |
Tem de deixar pronto o processo de notificação antes de setembro de 2026? Mostramos-lhe como se gerem os relógios de 24 h, 72 h e 14 dias com registo auditável de cada comunicação.
Solicite uma demonstraçãoCRA, NIS2 e ISO 27001: como se articulam sem duplicar trabalho
É a confusão mais habitual, e tem uma resposta clara: o CRA regula produtos; a NIS2 regula organizações. Uma empresa pode estar sujeita a ambos —como entidade essencial ou importante ao abrigo da NIS2 e como fabricante ao abrigo do CRA— e, nesse caso, os dois quadros sobrepõem-se em governação, gestão de riscos e notificação de incidentes, mas não no objeto regulado.
Abordagem em silos
- Um projeto independente por cada norma: CRA, NIS2, ISO 27001, ENS.
- Inventários de ativos e de produtos duplicados e desalinhados.
- Evidências recolhidas três vezes para controlos que são o mesmo.
- Notificações geridas por e-mail, sem rastreabilidade de prazos.
- Nenhuma visão consolidada do risco perante a direção.
Abordagem integrada
- Um único quadro de controlos com rastreabilidade a cada requisito legal.
- Inventário partilhado de produtos, componentes e fornecedores.
- Uma evidência satisfaz em simultâneo o CRA, a NIS2 e a ISO 27001.
- Fluxos de notificação com relógios de 24 h/72 h e registo auditável.
- Painel único de risco e conformidade para o comité.
A boa notícia é que um Sistema de Gestão de Segurança da Informação baseado na ISO/IEC 27001:2022 cobre boa parte do terreno comum com a Parte I e a Parte II do Anexo I: análise de riscos, gestão de vulnerabilidades técnicas, segurança no desenvolvimento, relações com fornecedores e gestão de incidentes. Para o ciclo de vida do produto, a referência setorial é a série IEC 62443 (especialmente 62443-4-1 e 4-2) e, em desenvolvimento seguro de software, a ISO/IEC 27034. Nenhuma certificação substitui, por si só, a conformidade com o CRA, mas todas reduzem drasticamente o esforço da análise de lacunas que vem a seguir.
Como preparar-se para o CRA: roteiro em 7 passos
Com setembro de 2026 mesmo ao virar da esquina e dezembro de 2027 como horizonte de aplicação plena, esta é a ordem de trabalho que melhor funciona:
Inventarie e classifique o seu portefólio
Liste todos os produtos com elementos digitais que comercializa na UE e classifique-os de acordo com o Anexo III/IV e o Regulamento de Execução 2025/2392. Determine também o seu papel: fabricante, importador ou distribuidor.
Faça uma análise de lacunas face ao Anexo I
Compare cada requisito essencial com o que o seu processo de desenvolvimento faz hoje. Identifique o que está coberto pelo seu SGSI, o que exige alterações de engenharia e o que requer documentação nova.
Priorize o bloco de notificação
É o primeiro requisito exigível. Defina o processo, os papéis de piquete, os modelos e os relógios de 24 h, 72 h e 14 dias, e ensaie-o antes de setembro de 2026.
Gere SBOM e rastreabilidade de componentes
Automatize a geração do SBOM em formato legível por máquina e integre-o com a vigilância de vulnerabilidades das suas dependências.
Fixe e publique o período de suporte
Decida o período por família de produto, documente o critério e coordene a comunicação comercial: a data de fim deve ser visível no momento da compra.
Estenda as exigências à sua cadeia de fornecimento
Transfira requisitos do CRA para contratos com fornecedores de componentes e software de terceiros, e peça SBOM e compromissos de patching. A sua conformidade depende da deles.
Prepare o dossiê e a via de conformidade
Monte a documentação técnica, a declaração UE de conformidade e, se o seu produto for importante classe II ou crítico, contrate antecipadamente o organismo notificado ou o esquema de certificação.
Como pode um software GRC ajudar a cumprir o Cyber Resilience Act?
Na GlobalSuite Solutions, abordamos o CRA como aquilo que realmente é: um problema de governação, risco e conformidade com prazos legais definidos, não uma folha de cálculo de requisitos técnicos. A nossa plataforma GlobalSuite® permite rastrear cada requisito essencial do Anexo I até um controlo, um responsável e uma evidência concreta, reutilizando o que já tenha implementado no seu SGSI baseado na ISO 27001, de forma que a análise de lacunas deixe de ser um documento solto e passe a ser um plano de ação com responsáveis e alertas de vencimento. Com a mesma base, gerem-se a análise de riscos de cibersegurança do produto, o ciclo de vida das vulnerabilidades ligado ao inventário de componentes e ao SBOM, a avaliação de fornecedores e da cadeia de fornecimento, e os fluxos de notificação com os relógios de 24 h, 72 h e 14 dias e registo auditável de cada comunicação ao INCIBE-CERT e à ENISA. E porque quase nenhuma organização enfrenta o CRA sozinha, a abordagem multinorma da plataforma permite mapear uma única vez os controlos comuns com a NIS2, a ISO 27001, a IEC 62443, a DORA ou o ENS, de forma que uma evidência sirva para vários quadros e a direção disponha de um painel único do estado de conformidade e do risco residual, pronto para auditoria ou para uma inspeção da autoridade de fiscalização do mercado.
Perguntas frequentes sobre o cumprimento do CRA
O que é o SBOM e porque é exigido pelo CRA?
O Software Bill of Materials (SBOM) é a lista de componentes e dependências que integram um produto de software, em formato legível por máquina. O Anexo I, parte II, do CRA exige elaborá-lo e mantê-lo —cobrindo pelo menos as dependências de primeiro nível— porque, sem conhecer os componentes, é impossível saber se uma vulnerabilidade publicada afeta o produto e agir dentro dos prazos de notificação.
Durante quanto tempo deve o fabricante manter a segurança do produto?
Durante o período de suporte, que deve ser de pelo menos cinco anos —ou igual à vida útil esperada do produto, se esta for inferior— e cuja data de fim (mês e ano) tem de ser conhecida pelo comprador no momento da aquisição. Durante esse período, o fabricante gere as vulnerabilidades e distribui patches de segurança de forma gratuita.
A quem é necessário notificar uma vulnerabilidade explorada e em que prazo?
Simultaneamente ao CSIRT designado como coordenador —o do Estado-Membro do estabelecimento principal; em Espanha, INCIBE-CERT— e à ENISA, através da plataforma única de notificação. Os prazos são 24 horas para o alerta precoce, 72 horas para a notificação com detalhe do produto e das medidas, e 14 dias desde que exista uma medida corretiva para o relatório final (1 mês no caso de incidentes graves). Em paralelo, é necessário informar os utilizadores afetados.
Que documentação técnica é necessário conservar e durante quanto tempo?
A avaliação de riscos de cibersegurança, a documentação técnica que comprova o cumprimento do Anexo I, os resultados do procedimento de avaliação da conformidade e a declaração UE de conformidade. Deve ser conservada por pelo menos dez anos desde a introdução do produto no mercado —ou durante o período de suporte, se for mais longo— e estar à disposição das autoridades de fiscalização do mercado.
Que diferença existe entre o CRA e a NIS2?
O CRA regula produtos e a NIS2 regula organizações. O CRA impõe requisitos de cibersegurança ao que se fabrica e vende, com a marcação CE como prova de conformidade; a NIS2 obriga entidades essenciais e importantes de setores críticos a implementar medidas de gestão de riscos e a notificar incidentes. Uma empresa pode estar sujeita a ambos e convém abordá-los de forma integrada para não duplicar controlos nem evidências.
A ISO 27001 serve para cumprir o CRA?
Não substitui a conformidade com o CRA, mas encurta muito o caminho. Um SGSI conforme a ISO/IEC 27001:2022 já cobre gestão de riscos, gestão de vulnerabilidades técnicas, segurança no desenvolvimento, relações com fornecedores e gestão de incidentes. Para os requisitos específicos do ciclo de vida do produto, convém complementá-lo com a série IEC 62443 e com práticas de desenvolvimento seguro.
O cumprimento do CRA assenta em três blocos. O Anexo I define as propriedades de cibersegurança do produto (Parte I) e a gestão de vulnerabilidades durante o período de suporte (Parte II), com SBOM, cinco anos mínimos de suporte e política de divulgação coordenada como as novidades de maior impacto operacional. A notificação impõe relógios de 24 horas, 72 horas e 14 dias perante o INCIBE-CERT e a ENISA. E o dossiê de marcação CE —avaliação de riscos, documentação técnica e declaração UE de conformidade— deve ser conservado durante dez anos.
A ordem importa: primeiro o bloco de notificação, porque é exigível desde 11 de setembro de 2026 e também para produtos já vendidos; depois a análise de lacunas face ao Anexo I, o SBOM, o período de suporte, a cadeia de fornecimento e o dossiê, com vista a 11 de dezembro de 2027. Quanto mais integrada for a abordagem com a NIS2 e a ISO 27001, menor será o custo total: uma única evidência pode servir para vários quadros.
Prepare a sua conformidade com o CRA numa única plataforma
Rastreabilidade do Anexo I até controlo, responsável e evidência; gestão de vulnerabilidades ligada ao SBOM; fluxos de notificação com relógios de 24 h e 72 h e registo auditável; avaliação de fornecedores e mapeamento multinorma com a NIS2 e a ISO 27001. Mostramos-lhe com um caso real.
Solicite uma demonstração
