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]