A norma regula produtos, não apenas empresas de cibersegurança
O Regulamento da Ciber-Resiliência da UE, conhecido pela sigla inglesa CRA, estabelece requisitos obrigatórios de cibersegurança para produtos com elementos digitais. O quadro abrange hardware e software: a Comissão Europeia cita exemplos do quotidiano, como relógios inteligentes, monitores para bebés, aplicações e programas informáticos. O objetivo é que a segurança seja considerada durante a conceção, o desenvolvimento e a manutenção do produto, e não apenas depois de este chegar ao mercado. [1]
Para uma empresa, a questão inicial não é apenas saber se vende tecnologia, mas que produto disponibiliza no mercado europeu e que função desempenha na cadeia de fornecimento. Fabricantes, importadores e distribuidores podem ter responsabilidades distintas. A Comissão também identifica os programadores de aplicações como fabricantes quando comercializam essas aplicações na UE. Uma designação comercial, por si só, não resolve a classificação: convém analisar o papel efetivo de cada entidade e as características do produto. [2]
Como delimitar o âmbito antes de iniciar um plano de conformidade
Uma análise útil começa com um inventário de produtos e componentes digitais e prossegue com uma avaliação da sua relação com serviços ligados. As orientações publicadas pela Comissão em julho de 2026 abordam, entre outros temas, o âmbito, as alterações substanciais, os períodos de suporte, a avaliação de riscos e a comunicação de vulnerabilidades. Ajudam a interpretar a aplicação prática, mas não substituem o regulamento nem determinam automaticamente a situação de cada produto. [3]
Não se deve presumir que uma categoria inteira está incluída ou excluída sem analisar o caso concreto. Por exemplo, um serviço na nuvem pode ter uma relação técnica com um produto abrangido; uma fonte secundária descreve possíveis situações de tratamento remoto ligado ao produto. Essa explicação pode ajudar a formular perguntas, mas não é suficiente para encerrar uma interpretação jurídica. Quando existirem dúvidas relevantes, a empresa deve comparar a sua arquitetura e o seu papel com o texto legal e procurar aconselhamento especializado. [4]
Requisitos a integrar no ciclo de vida do produto
A Comissão descreve o CRA como um quadro de requisitos de cibersegurança para fabricantes que afeta o planeamento, a conceção, o desenvolvimento e a manutenção de produtos com elementos digitais. Indica também que os fabricantes devem gerir vulnerabilidades durante todo o ciclo de vida. Em termos operacionais, isto implica ligar o trabalho de segurança aos processos de engenharia, manutenção e suporte, em vez de o tratar como uma verificação isolada antes do lançamento. [1]
A aplicação concreta depende do produto e das obrigações que lhe são aplicáveis. As orientações da Comissão de 2026 abordam questões como a análise de riscos e a interpretação dos períodos de suporte. Por isso, as empresas devem conseguir explicar que produto avaliaram, que riscos consideraram e como organizam o tratamento de vulnerabilidades e as atualizações. A documentação deve refletir práticas reais, e não limitar-se a uma declaração genérica de que o produto é seguro. A informação aqui disponível não permite estabelecer um período de suporte universal para todos os produtos. [3]
Comunicação de vulnerabilidades: o primeiro marco operacional
De acordo com a página da Comissão dedicada às obrigações de comunicação, a partir de 11 de setembro de 2026, os fabricantes devem comunicar vulnerabilidades ativamente exploradas e incidentes graves que afetem a segurança dos seus produtos com elementos digitais. A Comissão descreve um aviso inicial no prazo de 24 horas após tomar conhecimento, uma notificação completa no prazo de 72 horas e um relatório final sujeito a prazos que dependem do tipo de ocorrência. [5]
A página oficial indica que o relatório final relativo a uma vulnerabilidade ativamente explorada deve ser apresentado, no máximo, 14 dias depois de estar disponível uma medida corretiva. Para incidentes graves, indica um prazo de um mês a contar da notificação de 72 horas. Explica também que os fabricantes comunicam através de uma plataforma única, com destino à equipa de resposta a incidentes de segurança informática (CSIRT) competente para o seu estabelecimento principal. Os prazos curtos tornam necessário preparar antecipadamente responsáveis, canais de escalonamento e critérios de ativação, em vez de os improvisar durante um incidente. [5]
O mesmo calendário oficial distingue os gestores de software de código aberto: de acordo com a disposição citada pela Comissão, as suas obrigações de comunicação começam em 11 de dezembro de 2027. Esta diferença é relevante para organizações que mantêm software de código aberto e para as empresas que dele dependem; não deve ser confundida com a data aplicável aos fabricantes de produtos. [5]
Calendário: não confundir comunicação com aplicação geral
Segundo a Comissão, o CRA está em vigor desde dezembro de 2024, mas isso não significa que todas as suas obrigações tenham começado ao mesmo tempo. O marco de setembro de 2026 ativa as obrigações de comunicação acima descritas. A Comissão indica que o regulamento será plenamente aplicável a partir de 11 de dezembro de 2027. Para efeitos de planeamento, as empresas devem distinguir entre a entrada em vigor, os marcos de obrigações específicas e a data de aplicação geral. [1][5]
Uma tabela interna de acompanhamento pode ajudar a evitar que um calendário simplificado ou uma publicação de terceiros se torne a única referência:
| Marco | Data indicada pela Comissão | A quem se aplica |
|---|---|---|
| Início da comunicação pelos fabricantes | 11 de setembro de 2026 | Vulnerabilidades ativamente exploradas e incidentes graves |
| Comunicação pelos gestores de software de código aberto | 11 de dezembro de 2027 | Obrigações indicadas para esses gestores |
| Aplicação geral do CRA | 11 de dezembro de 2027 | Quadro geral do regulamento |
A tabela resume datas e grupos tal como constam das informações oficiais consultadas; não substitui a verificação do artigo aplicável a cada organização. [1][5]
O que verificar agora e o que não é possível concluir
Um plano prático pode começar com cinco verificações: identificar produtos e mercados; atribuir o papel de cada entidade; documentar componentes e dependências; estabelecer um processo para detetar, avaliar e escalar vulnerabilidades; e confirmar quem apresenta as comunicações e por que canal. Depois, convém comparar essas medidas com o regulamento e as orientações oficiais, dando atenção à classificação do produto, às alterações, ao suporte e à avaliação de riscos. [2][3][5]
A investigação disponível não inclui declarações diretas de fabricantes afetados, nem permite atribuir a uma empresa específica uma posição, um nível de preparação ou uma interpretação. Também não fornece informação suficiente para resolver todos os casos-limite relativos ao âmbito. Assim, não há aqui fundamento para afirmar que determinada empresa está ou não está em conformidade, nem para apresentar uma novidade regulamentar além dos marcos documentados. A conclusão verificável é mais limitada: existe uma data de início confirmada para as obrigações de comunicação, e as organizações devem incorporar a data de aplicação geral na sua análise. [1][5]