Regulamento da Ciber-Resiliência.
Desenvolva produtos com elementos digitais seguros, trate vulnerabilidades e prepare a demonstração de conformidade adequada.
- Regulamento (UE) 2024/2847
- Por Derya Altinay
- Atualizado em: 22/10/2026
- Tempo de leitura: 9 min.
Resposta breve.
O Regulamento da Ciber-Resiliência rege a cibersegurança dos produtos com elementos digitais abrangidos na UE. Os fabricantes são responsáveis pela segurança no desenvolvimento, disponibilização e suporte. As notificações dos fabricantes aplicam-se desde 11 de setembro de 2026; as obrigações gerais dos produtos, a partir de 11 de dezembro de 2027. A base é o Regulamento (UE) 2024/2847.
Regulamento da Ciber-Resiliência e prazos CRA.
O Regulamento da Ciber-Resiliência, também designado Cyber Resilience Act ou CRA, regula a cibersegurança dos produtos. O Regulamento (UE) 2024/2847 relaciona requisitos de conceção com obrigações ao longo do ciclo de vida do produto. O objeto de análise é o produto concreto, incluindo componentes relevantes e o processamento remoto de dados associado. Um programa de segurança à escala da empresa pode apoiar este trabalho, mas não responde, por si só, às questões específicas do produto.
Os prazos CRA aplicam-se de forma faseada. Segundo o artigo 71.º, n.º 2, do CRA, os requisitos gerais começam em 11 de dezembro de 2027; as notificações dos fabricantes segundo o artigo 14.º aplicam-se desde 11 de setembro de 2026. O capítulo IV, sobre a notificação de organismos de avaliação da conformidade, aplica-se desde 11 de junho de 2026. Esta data institucional não antecipa uma data geral de marcação CE para todos os produtos de software.
Os produtos antigos não estão genericamente isentos das notificações dos fabricantes. O artigo 69.º, n.os 2 e 3, do CRA distingue as regras transitórias de conformidade dos produtos das notificações. As orientações da Comissão C(2026) 5252, secção 9.1, explicam esta separação também para produtos colocados no mercado antes de dezembro de 2027. As orientações são um apoio interpretativo sem força jurídica vinculativa; prevalece o regulamento.
Produtos e empresas abrangidos pelo CRA.
O CRA abrange produtos de hardware e software disponibilizados no mercado da UE que prevejam uma ligação de dados direta ou indireta a um dispositivo ou rede. Os artigos 2.º e 3.º do CRA definem o âmbito e os conceitos. Podem incluir-se componentes disponibilizados autonomamente. Verifique a função real e as exceções legais antes de classificar toda a carteira da mesma forma.
O papel da empresa determina as suas obrigações. Fabricantes, importadores e distribuidores têm tarefas distintas; o papel de fabricante também pode ser relevante na comercialização sob marca própria. Para o software de código aberto, importa distinguir a disponibilização comercial, os contributos individuais e o papel especial do gestor de software de código aberto. Uma licença livre não isenta genericamente o fabricante de um produto comercial da sua responsabilidade.
Um serviço SaaS não fica abrangido nem excluído do CRA apenas pela sua designação comercial. São determinantes os limites do produto e o processamento remoto de dados associado. As orientações da Comissão, secções 2 e 8, distinguem produtos de software de serviços prestados remotamente. Registe a fundamentação relativa à arquitetura concreta; uma afirmação geral sobre todas as ofertas na nuvem seria demasiado ampla.
As principais áreas dos requisitos CRA.
Os requisitos CRA combinam a segurança dos produtos baseada nos riscos com uma responsabilidade contínua. O artigo 13.º e o Anexo I do CRA constituem a base das obrigações dos produtos; o artigo 14.º regula as notificações dos fabricantes aplicáveis antecipadamente. As áreas seguintes servem de orientação, sem substituir os requisitos legais detalhados.
Compreender o produto e os riscos.
Uma avaliação dos riscos de cibersegurança sustenta as decisões de segurança ao longo do ciclo de vida. Os fabricantes consideram a utilização prevista e a utilização razoavelmente previsível. Descreva na prática as funções, interfaces e dependências do produto e as consequências que um problema de segurança pode ter para os seus utilizadores.
Integrar a segurança no produto.
A conceção segura e as configurações seguras por defeito articulam-se entre si. O Anexo I do CRA abrange características do produto como a proteção de acessos, a proteção de dados e a limitação das superfícies de ataque. Uma política redigida posteriormente não pode substituir características técnicas; as decisões de desenvolvimento e a sua verificação devem corresponder à avaliação dos riscos.
Integrar componentes com responsabilidade.
Os componentes integrados continuam a fazer parte da análise do produto. Os fabricantes precisam de informação rastreável sobre o que fornecem e como as vulnerabilidades nas dependências afetam o seu produto. A Comissão descreve expressamente a diligência devida perante componentes de terceiros; a simples transmissão de uma informação do fornecedor não responde a todas as questões do produto.
Tratar vulnerabilidades e atualizações.
O tratamento de vulnerabilidades é uma tarefa contínua durante o período de suporte relevante. Inclui canais de comunicação acessíveis, avaliação, correção e disponibilização segura de atualizações de segurança. Distinga o tratamento técnico de uma constatação da avaliação jurídica sobre se uma vulnerabilidade ativamente explorada ou um incidente grave está sujeito a notificação.
Definir o suporte e a informação aos utilizadores.
O período de suporte segue os critérios do artigo 13.º, n.º 8, do CRA e a utilização prevista. Em princípio, prevê-se um mínimo de cinco anos; se a utilização prevista for inferior, aplica-se essa duração, e se for superior, pode ser necessário um período mais longo. As orientações da Comissão, secção 5, explicam expressamente que cinco anos não são um máximo geral.
Viabilizar as notificações dos fabricantes.
O artigo 14.º do CRA distingue as vulnerabilidades ativamente exploradas dos incidentes de segurança graves. Os fabricantes estão sujeitos a notificações faseadas: sem demora, um alerta precoce no máximo em 24 horas e mais informações em 72 horas após tomarem conhecimento. Os prazos finais diferem conforme o facto gerador. Por isso, uma deteção por um scanner não é automaticamente uma notificação obrigatória nem motivo suficiente para encerrar o evento.
Preparar a conformidade e a documentação.
A documentação técnica e a avaliação da conformidade devem explicar o produto oferecido. O artigo 32.º do CRA e a categoria do produto determinam o procedimento admissível. Registe a base de avaliação escolhida juntamente com a versão do produto; uma coleção geral de documentos sem ligação rastreável à versão avaliada não é suficiente como estratégia prática de demonstração.
A implementação CRA como processo de produto.
Delimitar a carteira e os papéis.
Como ponto de partida prático, registe os produtos oferecidos, as suas funções relevantes, a entidade jurídica responsável e o papel em cada canal de distribuição.
Distinguir as fases de aplicação.
Separe a capacidade de notificação dos fabricantes já exigida da preparação da conformidade geral dos produtos e verifique as transições para os produtos existentes.
Traduzir os riscos em decisões de produto.
Relacione a avaliação dos riscos com a conceção, a seleção de componentes e critérios de segurança verificáveis para o desenvolvimento e a aprovação.
Testar os canais de notificação.
Nomeie os responsáveis e os seus substitutos e exercite a avaliação, a escalada e a transmissão com informação incompleta dentro dos prazos aplicáveis.
Definir o suporte e o percurso de demonstração.
Planeie a manutenção das versões do produto suportadas e esclareça, com base na categoria, a avaliação da conformidade e a documentação técnica necessárias.
Marcação CE de software e demonstração do produto.
A demonstração CRA é uma avaliação da conformidade específica do produto. A Comissão explica, a propósito do artigo 32.º do CRA, que a categoria padrão admite uma avaliação interna. Para determinados produtos importantes ou críticos, aplicam-se procedimentos mais rigorosos com um organismo notificado ou outros meios de demonstração admissíveis. A função real do produto determina a categoria; um nome comercial não é suficiente.
A declaração UE de conformidade e a marcação CE seguem o procedimento aplicável. Não são um certificado geral de toda a empresa nem uma promessa de que um produto nunca terá uma vulnerabilidade. Por isso, uma validade uniforme de certificado não descreve adequadamente o CRA: a documentação, o tratamento de vulnerabilidades e as obrigações aplicáveis devem ser considerados ao longo do ciclo de vida relevante.
Outros referenciais e obrigações autónomas.
A ISO 27001 organiza um sistema de gestão da segurança da informação; o respetivo certificado não confirma, por si só, a conformidade CRA de um produto. A NIS2 considera as entidades abrangidas e a sua organização de segurança. O RGPD protege os dados pessoais, pelo que um evento num produto pode suscitar questões adicionais de proteção de dados. Os processos relacionados podem ser coordenados, mas os seus factos geradores jurídicos e as evidências continuam a ter de ser analisados separadamente.
No Secani.
O Secani contém um catálogo editorial de trabalho CRA com fontes, perguntas de avaliação e exemplos de evidências. O perfil da empresa regista, entre outros, os papéis e a data da avaliação; os pressupostos por esclarecer permanecem visíveis como necessidades de análise. Este apoio ajuda a organizar a avaliação, mas não confirma a classificação jurídica nem a conformidade de um produto.
Começar por um produto delimitado.
Escolha um produto concreto e esclareça primeiro os seus limites, a entidade jurídica responsável e as pessoas responsáveis pelas notificações de segurança. Verifique depois quais as obrigações atuais e futuras que o afetam. Este ponto de partida torna a preparação viável e evita que um projeto geral de conformidade oculte a capacidade de notificação já exigida.
Fontes.
- Regulamento (UE) 2024/2847 — Regulamento da Ciber-Resiliência
- Comissão Europeia: Regulamento da Ciber-Resiliência e datas de aplicação
- Comissão Europeia: resumo do ato jurídico
- Comissão Europeia: obrigações dos fabricantes
- Comissão Europeia: avaliação da conformidade
- Comissão Europeia: CRA e código aberto
- Comissão Europeia: orientações C(2026) 5252 com anexo
Perguntas frequentes.
Sim. Para os fabricantes abrangidos, as notificações segundo o artigo 14.º do CRA aplicam-se desde 11 de setembro de 2026. As obrigações gerais dos produtos começam em 11 de dezembro de 2027; os papéis especiais e as transições devem ser analisados separadamente.
Não. A designação SaaS não determina o âmbito de aplicação. Analise o produto de software, as suas funções e o processamento remoto de dados associado com base na arquitetura concreta.
Não. O tratamento especial dos contributos de código aberto a montante não isenta genericamente o fabricante comercial do produto das suas obrigações. O papel de fabricante e o possível papel de gestor de software de código aberto devem ser distinguidos.
Não. Um certificado ISO 27001 diz respeito a um sistema de gestão delimitado. O CRA exige uma análise separada do produto e a demonstração de conformidade aplicável.
Organize a segurança dos produtos de forma rastreável.
Trabalhe os requisitos CRA e a sua avaliação de forma estruturada com o Secani.
Esta página explica o Regulamento da Ciber-Resiliência em termos gerais e não substitui uma análise jurídica de cada produto. Prevalecem os atos jurídicos em vigor.