CRA Cyber Resilience Act.

O que o Cyber Resilience Act realmente regula

O Cyber Resilience Act impõe obrigações de segurança ao produto, não apenas à organização que o opera. Tudo o que é vendido na UE e contém elementos digitais, ou seja, hardware ou software com uma ligação de dados, entra no âmbito de aplicação: dispositivos de consumo conectados, controladores industriais, sistemas operativos, bibliotecas, aplicações móveis e até o firmware embarcado num componente.

A parte regulada é o operador económico que coloca o produto no mercado, pelo que os fabricantes suportam o encargo principal, enquanto os importadores e distribuidores ficam sujeitos a deveres de verificação. Trata-se de uma transferência de responsabilidade. Durante anos o comprador herdava o risco do software inseguro; o CRA devolve uma base definida de responsabilidade a quem constrói e vende o produto.

Por regular produtos em vez de entidades, o CRA alcança pequenos fornecedores e componentes abertos que nenhuma lei de segurança organizacional jamais tocaria. Um fabricante de firmware sem escritório na UE tem ainda assim de cumprir se o dispositivo chegar a uma prateleira europeia. Esse enquadramento por produto é a coisa mais importante a apreender antes de ler qualquer outra coisa sobre ele.

As obrigações que vinculam um fabricante

O CRA é construído em torno de um ciclo de vida. Um produto tem de ser seguro no momento em que é entregue e manter-se suportável durante o tempo em que se espera razoavelmente que esteja em uso, prazo que o regulamento fixa num período de suporte de base de cerca de cinco anos para o tratamento de vulnerabilidades. Os deveres concretos agrupam-se em dois conjuntos.

• Segurança desde a conceção e por defeito: entregar sem vulnerabilidades exploráveis conhecidas, minimizar a superfície de ataque, proteger a confidencialidade e a integridade dos dados e fornecer uma configuração predefinida segura para que o produto não seja inseguro logo ao sair da caixa.
• Tratamento de vulnerabilidades ao longo do período de suporte: manter um processo de divulgação coordenada, fornecer um Software Bill of Materials para que os componentes existentes no produto fiquem documentados, entregar atualizações de segurança com prontidão e, sempre que viável, de forma automática, e comunicar as vulnerabilidades ativamente exploradas e os incidentes graves à ENISA dentro dos prazos do regulamento.

A conformidade é demonstrada do modo como a UE trata a restante legislação de segurança dos produtos: uma avaliação proporcional à classe de risco do produto, documentação técnica e marcação CE que sinaliza que a base de segurança foi cumprida. As categorias de produtos de risco mais elevado, designadas importantes ou críticas, enfrentam uma avaliação mais rigorosa, por vezes por terceiros, em vez de uma autodeclaração.

Como se posiciona face à NIS 2 e ao AI Act

Estes três instrumentos da UE são deliberadamente complementares e os profissionais não devem confundir os seus âmbitos. O CRA é o ângulo do produto: torna seguro aquilo que se vende. A NIS 2 é o ângulo organizacional: obriga as entidades essenciais e importantes a gerir o risco cibernético, governar a segurança e comunicar incidentes ao nível da empresa. O AI Act é o ângulo do modelo: rege a forma como os sistemas de IA, em especial os de alto risco, são construídos e colocados no mercado. Um dispositivo industrial conectado vendido por um operador regulado que incorpora um componente de IA pode tocar os três ao mesmo tempo, cada um a partir de uma direção diferente.

A consequência prática é que a preparação para o CRA é em grande medida um programa de engenharia e de governação de produto, e não uma formalidade documental aparafusada a um SGSI existente. As equipas que já praticam a divulgação coordenada de vulnerabilidades, mantêm inventários de dependências e aplicam correções numa cadência previsível têm grande parte do caminho percorrido.

As equipas que entregam e esquecem são as que têm mais trabalho pela frente, porque a obrigação de dar suporte e aplicar correções durante anos é exatamente o que uma cultura de entregar e seguir em frente procura evitar. O regulamento foi adotado no final de 2024 e as suas obrigações principais aplicam-se a partir de dezembro de 2027, o que deixa uma margem definida para montar os processos de tratamento de vulnerabilidades e de SBOM antes de se tornarem exigíveis.