Guia do Cyber Resilience Act
Um roteiro prático para as equipas que constroem produtos com elementos digitais: o que fazer, quem é responsável e que evidências guardar. Para saber o que diz a lei, leia o que é o Cyber Resilience Act.
Última atualização: 15 de outubro de 2026
What the Cyber Resilience Act asks manufacturers to do
O âmbito do Regulamento (UE) 2024/2847, as datas em que passa a aplicar-se, os prazos de notificação e onde se situam as obrigações relativas à SBOM e ao tratamento de vulnerabilidades.
Petteri Pulkkinen e Erika Marttinen em Kubernetes Community Days Helsinki 2026, de 8:03 a 15:20 de SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.
Os passos seguem aproximadamente esta ordem, mas os passos 5 a 8 são prioritários para os produtos já no mercado, porque o reporte já se lhes aplica.
Enumere todos os produtos com elementos digitais que disponibiliza na UE, incluindo software vendido separadamente e os backends cloud de que os produtos precisam para funcionar. Para cada um, confirme que não está excluído (dispositivos médicos, veículos, aviação, equipamento marítimo, defesa) e se é o seu fabricante, importador ou distribuidor.
Verifique um produto com o CRA Checker →A maioria dos produtos pertence à categoria predefinida. Compare os seus com as listas de produtos importantes (Anexo III) e críticos (Anexo IV); o Regulamento de Execução (UE) 2025/2392 apresenta as respetivas descrições técnicas. A categoria determina se pode fazer uma autoavaliação ou se precisa de um organismo notificado ou de certificação.
Redija uma avaliação dos riscos de cibersegurança para cada produto. Esta determina como se aplicam os requisitos essenciais do Anexo I e faz parte da documentação técnica. Atualize-a quando o produto ou as ameaças mudarem.
Decida durante quanto tempo trata as vulnerabilidades de cada produto: pelo menos cinco anos, salvo se se esperar que o produto esteja em utilização durante menos tempo. Informe os utilizadores de quando termina o suporte e mantenha cada atualização de segurança disponível durante, pelo menos, 10 anos.
O CRA pede uma lista de materiais de software num formato de uso comum e legível por máquina, que abranja, no mínimo, as dependências de nível superior. Gerá-la no build que produz a versão, em vez de uma vez à mão, mantém-na fiel ao que foi distribuído.
Onde entra o CRACI: O CRACI regista a SBOM enquanto cada build decorre, incluindo dependências transitivas e pacotes restaurados de caches, e exporta-a em CycloneDX ou SPDX.
Vigie as versões lançadas, e não apenas a branch principal, quanto a novas vulnerabilidades durante todo o período de suporte. Corrija-as sem demora, disponibilize as atualizações de segurança gratuitamente e, sempre que possível, separadamente das atualizações de funcionalidades.
Onde entra o CRACI: O CRACI volta a verificar as SBOM monitorizadas face a novas vulnerabilidades depois de o produto ser distribuído, e as equipas de segurança fazem a triagem das conclusões e enviam-nas às equipas responsáveis pela correção. Os policy gates podem bloquear um build com base nas conclusões.
Dê a investigadores e clientes um contacto para reportar vulnerabilidades e uma política de divulgação coordenada de vulnerabilidades. Quando uma atualização estiver disponível, publique informações sobre as vulnerabilidades que corrige.
Desde 11 de setembro de 2026, uma vulnerabilidade ativamente explorada ou um incidente grave exige um alerta precoce no prazo de 24 horas, uma notificação no prazo de 72 horas e um relatório final, através da Single Reporting Platform. Designe quem confirma a exploração ativa, quem submete e quem informa os utilizadores. A parte difícil é saber, em poucas horas, que produtos e versões contêm o componente vulnerável.
Onde entra o CRACI: O histórico de builds do CRACI mostra que builds continham uma dependência vulnerável, a vista de inventário mostra que versões estão implementadas em que produtos, e o CRACI submete as notificações do CRA em seu nome.
Distribua sem vulnerabilidades exploráveis conhecidas e com uma configuração segura por predefinição, proteja os dados e os acessos, limite a superfície de ataque e torne possíveis as atualizações de segurança, automáticas por predefinição quando aplicável. Teste e reveja a segurança regularmente.
Onde entra o CRACI: O CRACI aplica uma política de egress ao que os builds podem descarregar, e os policy gates podem bloquear um build com base nas conclusões.
Reúna a documentação técnica descrita no Anexo VII, realize a avaliação da conformidade para a sua categoria, elabore a declaração UE de conformidade e aponha a marcação CE. Conserve a documentação e a declaração durante, pelo menos, 10 anos ou durante o período de suporte, consoante o que for mais longo.
Onde entra o CRACI: O CRACI exporta SBOM em CycloneDX ou SPDX, incluindo as vulnerabilidades encontradas nos seus componentes, e a API do CRACI devolve SBOM, traços de rede e proveniência para a sua documentação técnica. A avaliação e a declaração continuam a ser o seu processo.
As autoridades de fiscalização do mercado podem pedir a sua documentação técnica. Isto é o que cada requisito deixa para trás e onde o CRACI o regista a partir dos seus builds.
| Requisito | Onde | Evidências a guardar | Do CRACI |
|---|---|---|---|
| Avaliação dos riscos de cibersegurança | Artigo 13.º, Anexo I | Avaliação documentada por produto | O seu processo |
| Nenhuma vulnerabilidade explorável conhecida no lançamento | Anexo I, parte I | Estado de vulnerabilidades do build de lançamento | SBOM do build de lançamento verificada face a avisos de segurança; policy gates |
| Lista de materiais de software | Anexo I, parte II | SBOM legível por máquina por versão | Registada a partir de cada build, CycloneDX ou SPDX |
| Tratamento de vulnerabilidades durante o período de suporte | Artigo 13.º, Anexo I, parte II | Conclusões, decisões de triagem, correções, avisos de segurança | Reavaliação contínua, triagem, VEX |
| Devida diligência sobre os componentes de terceiros | Artigo 13.º | Registos de componentes, incluindo software adquirido | SBOM de fornecedores monitorizadas com as suas; licenças declaradas |
| Reporte de vulnerabilidades exploradas e incidentes graves | Artigo 14.º | Alertas precoces, notificações, relatórios finais | Submete as notificações em seu nome |
| Período de suporte | Artigo 13.º | Data de fim de suporte publicada | O seu processo |
| Documentação técnica e declaração | Artigo 13.º, Anexo VII | Conservadas durante 10 anos ou durante o período de suporte | Exportação de SBOM e dados da API para a documentação |
Cyber Resilience Act
Use esta lista de verificação para atribuir responsabilidades e recolher evidências enquanto prepara produtos com elementos digitais para o CRA.
Perguntas práticas que as equipas fazem ao começar a trabalhar no CRA
Cumprir os requisitos essenciais do Anexo I com base numa avaliação dos riscos de cibersegurança, manter uma SBOM, tratar as vulnerabilidades durante um período de suporte de, pelo menos, cinco anos, reportar vulnerabilidades ativamente exploradas e incidentes graves, manter a documentação técnica, passar por uma avaliação da conformidade e apor a marcação CE.
Pelo âmbito e pelo reporte. Descubra que produtos o CRA abrange e depois certifique-se de que conseguiria cumprir o alerta precoce de 24 horas para uma vulnerabilidade ativamente explorada, porque o reporte se aplica desde 11 de setembro de 2026, incluindo para produtos já no mercado. O resto aplica-se a partir de 11 de dezembro de 2027.
O Anexo VII enumera-o. Inclui a avaliação dos riscos de cibersegurança do produto, a SBOM e informações sobre como o fabricante trata as vulnerabilidades. É conservada durante, pelo menos, 10 anos ou durante o período de suporte, consoante o que for mais longo, e entregue às autoridades de fiscalização do mercado mediante pedido.
Não. A SBOM faz parte da documentação técnica e é entregue a uma autoridade de fiscalização do mercado mediante pedido. O regulamento não exige a sua publicação.
Sim. Em 27 de julho de 2026, a Comissão Europeia publicou orientações não vinculativas, C(2026) 5252, com 67 exemplos práticos. Abrangem o tratamento remoto de dados, o software livre e de código aberto, a modificação substancial, os períodos de suporte, o reporte e a avaliação de riscos. O Regulamento de Execução (UE) 2025/2392 descreve as categorias de produtos importantes e críticos.
As obrigações são as mesmas, mas as micro e pequenas empresas não são alvo de coimas por falharem o prazo de 24 horas do alerta precoce, e as orientações da Comissão foram redigidas a pensar nas microempresas e PME.
Não. Cumprir o CRA é um processo do fabricante, incluindo a avaliação de riscos, a avaliação da conformidade e a declaração. O CRACI automatiza uma parte significativa da visibilidade da cadeia de abastecimento e das evidências de que esse processo precisa: SBOM de cada build, acompanhamento de vulnerabilidades após o lançamento e as notificações do CRA.
Veja como o CRACI regista uma SBOM de cada build, monitoriza o que distribuiu e submete as notificações do CRA em seu nome