.png)
TL;DR
O CRA (Cyber Resilience Act) torna a segurança obrigatória para tudo o que é "digital" vendido na UE - aplicações, firmware, IoT, software.
Requer segurança desde a conceção, aplicação de correcções, SBOM e divulgação de vulnerabilidades ao longo do ciclo de vida de um produto.
Começa em dezembro de 2027. Falhou a marca? Espere multas de mais de 15 milhões de euros ou proibições de comercialização.
Resumo do quadro de avaliação da Lei da Ciber-resiliência da UE (CRA):
- Esforço do programador: Elevado (requer a incorporação da segurança ao longo de todo o ciclo de vida do produto: conceção segura, codificação segura, testes rigorosos, implementação de processos de tratamento de vulnerabilidades, fornecimento de actualizações seguras, manutenção de SBOM).
- Custo das ferramentas: Moderado a elevado (requer ferramentas SDLC seguras - SAST/SCA/DAST, ferramentas de geração de SBOM, plataformas de gestão de vulnerabilidades, infraestrutura de atualização potencialmente segura - plataformas OTA).
- Impacto no mercado: Muito elevado (obrigatório para quase todos os produtos de hardware/software vendidos na UE; estabelece uma nova base global para as expectativas em matéria de cibersegurança dos produtos).
- Flexibilidade: Moderada (define os requisitos essenciais, mas permite diferentes vias de avaliação da conformidade com base na classificação do risco do produto).
- Intensidade da auditoria: Moderada a elevada (exige avaliações da conformidade - autoavaliação para produtos normalizados, avaliação por terceiros para produtos críticos; as autoridades de fiscalização do mercado aplicarão).
O que é o Ato da UE para a Ciber-resiliência (CRA)?
O Ato para a Ciber-resiliência da UE (CRA) é um regulamento que estabelece requisitos harmonizados de cibersegurança para "produtos com elementos digitais" (PDE) disponibilizados no mercado da União Europeia. O seu objetivo é resolver o problema generalizado dos produtos de hardware e software inseguros e da falta de actualizações de segurança atempadas.
A CRA aplica-se, em termos gerais, a quase todos os produtos de software ou hardware que possam ligar-se direta ou indiretamente a outro dispositivo ou rede, com algumas excepções (por exemplo, dispositivos médicos, aviação, automóveis já abrangidos por legislação específica, SaaS, a menos que seja crítico). Isto inclui dispositivos IoT de consumo, equipamento de rede, componentes de controlo industrial, sistemas operativos, aplicações móveis, software de secretária e muito mais.
Os principais pilares do CRA:
- Requisitos Essenciais de Cibersegurança (Anexo I): Os fabricantes devem assegurar que as PDE cumprem objectivos de segurança específicos ao longo do seu ciclo de vida. Isto abrange:
- Segurança desde a conceção e por defeito: Os produtos devem ser concebidos, desenvolvidos e produzidos para garantir um nível adequado de cibersegurança. Devem ser fornecidos com uma configuração por defeito segura.
- Gestão de vulnerabilidades: Os fabricantes devem ter processos para identificar e corrigir vulnerabilidades ao longo da vida útil prevista do produto ou, no mínimo, durante cinco anos, incluindo o fornecimento de actualizações de segurança "sem demora" e gratuitamente.
- Proteção de dados: Proteção da confidencialidade, integridade e disponibilidade dos dados processados pelo produto.
- Controlo de acesso: Prevenção do acesso não autorizado.
- Resiliência: Capacidade para resistir e recuperar de incidentes.
- Minimizar a superfície de ataque: Limitar as superfícies de ataque e atenuar o impacto dos incidentes.
- Obrigações dos operadores económicos:
- Fabricantes: São os principais responsáveis por garantir a conformidade com as ARC - conceção segura, avaliação da conformidade, documentação técnica (incluindo SBOM), tratamento de vulnerabilidades, comunicação de incidentes/vulnerabilidades, fornecimento de actualizações e instruções claras. Isto aplica-se mesmo que estejam estabelecidos fora da UE.
- Importadores/distribuidores: Têm a obrigação de verificar a conformidade do fabricante (por exemplo, marcação CE, documentação) antes de colocarem os produtos no mercado.
- Tratamento e comunicação de vulnerabilidades: Os fabricantes devem estabelecer processos para lidar eficazmente com as vulnerabilidades e comunicar as vulnerabilidades ativamente exploradas à ENISA (Agência da UE para a Cibersegurança) no prazo de 24 horas após o conhecimento das mesmas. Devem também informar os utilizadores sobre as vulnerabilidades corrigidas e as actualizações disponíveis.
- Avaliação da conformidade e marcação CE: Os PDEs devem ser submetidos a um processo de avaliação da conformidade (que vai desde a autoavaliação do fabricante até à certificação por terceiros, dependendo da criticidade do produto) para demonstrar a conformidade antes de receberem a marcação CE e serem colocados no mercado da UE.
- Fiscalização do mercado: Designa as autoridades nacionais de fiscalização do mercado para fazer cumprir a ARC, investigar o incumprimento e impor sanções ou exigir a retirada/recuperação do produto.
A CRA entrou em vigor no final de 2024, com a maior parte das obrigações a tornarem-se aplicáveis 36 meses mais tarde (cerca de dezembro de 2027), enquanto as obrigações de comunicação dos fabricantes se aplicam mais cedo (cerca de setembro de 2026).
Porque é que é importante?
O CRA é um ato legislativo de referência com implicações significativas:
- Transferência de responsabilidade: Coloca o ónus da segurança dos produtos diretamente sobre os fabricantes, em vez de o deixar principalmente para os utilizadores finais.
- Aumenta a segurança de base: Estabelece normas mínimas obrigatórias de cibersegurança para uma vasta gama de produtos conectados vendidos na UE.
- Segurança da cadeia de fornecimento de software: Aborda as vulnerabilidades provenientes de componentes de terceiros através de requisitos como os SBOM e a gestão de vulnerabilidades ao longo do ciclo de vida.
- Protege os consumidores e as empresas: Visa reduzir o número de produtos inseguros explorados por atacantes, protegendo os utilizadores de violações de dados, perdas financeiras e riscos de segurança.
- Harmoniza os requisitos: Cria um conjunto único de regras em toda a UE, substituindo abordagens nacionais potencialmente fragmentadas em matéria de cibersegurança dos produtos.
- Impacto global: Dada a dimensão do mercado da UE, a CRA estabelece efetivamente uma norma global, influenciando os fabricantes de todo o mundo que pretendem vender produtos na Europa.
- Complementa outros regulamentos: Trabalha em conjunto com o NIS2 (segurança de serviços críticos), o GDPR (proteção de dados pessoais) e o DORA (resiliência financeira) para criar um panorama mais abrangente de cibersegurança na UE.
Para os fabricantes de software e de hardware conectado, a conformidade com o ARC tornar-se-á um requisito fundamental para o acesso ao mercado da UE.
O que e como implementar (técnica e política)
A aplicação da CRA exige a integração dos seus requisitos essenciais (Anexo I) em todo o ciclo de vida do produto:
- Conceção e desenvolvimento seguros (Security by Design):
- Modelação de ameaças: Identificar potenciais ameaças e conceber controlos de segurança desde o início.
- Práticas de codificação segura: Formar os programadores e aplicar normas de codificação seguras (por exemplo, OWASP ASVS, normas de codificação CERT). Utilizar ferramentas SAST.
- Minimizar a superfície de ataque: Limitar as funcionalidades, as portas abertas e os privilégios ao mínimo necessário.
- Predefinições seguras: Assegurar que os produtos são fornecidos com configurações seguras (por exemplo, sem palavras-passe predefinidas, serviços desnecessários desactivados). Implementar a funcionalidade de reinicialização segura.
- Proteção de dados: Implementar a encriptação dos dados em repouso e em trânsito, se for caso disso. Proteger a integridade dos dados.
- Controlo de acesso: Implementar mecanismos robustos de autenticação e autorização.
- Gestão de vulnerabilidades:
- Análise de componentes (SBOM): Gerar e manter uma lista de materiais de software (SBOM) exacta que identifique todos os componentes (incluindo bibliotecas de código aberto). Utilizar ferramentas SCA para encontrar vulnerabilidades conhecidas nas dependências.
- Testes de segurança: Implementar análises regulares de vulnerabilidades (SAST, DAST, SCA, IaC), testes de fuzz e testes de penetração durante o desenvolvimento e após o lançamento.
- Processo de tratamento de vulnerabilidades: Estabelecer procedimentos claros para receber relatórios de vulnerabilidade (internos/externos), analisá-los, desenvolver correcções e distribuir actualizações "sem demora".
- Correcções/actualizações: Fornecer actualizações de segurança gratuitas durante o ciclo de vida previsto do produto (mín. 5 anos). Implementar um mecanismo de atualização seguro (por exemplo, actualizações OTA seguras com verificações de integridade).
- Transparência e documentação:
- Documentação técnica: Manter documentação técnica pormenorizada que demonstre a conformidade com os requisitos essenciais. Incluir o SBOM.
- Informação ao utilizador: Fornecer aos utilizadores instruções claras sobre a utilização segura, a configuração, as actualizações e a duração do suporte do produto.
- Divulgação de vulnerabilidades: Estabelecer uma política e um ponto de contacto para receber relatórios de vulnerabilidades; divulgar publicamente as vulnerabilidades corrigidas.
- Avaliação da conformidade:
- Classificação do risco: Determinar se o produto se enquadra nas categorias por defeito, "importante" (Classe I) ou "crítico" (Classe II) com base no Anexo III.
- Procedimento de avaliação: Seguir o procedimento exigido (por exemplo, controlo interno/autoavaliação para incumprimento, avaliação/certificação de terceiros para classes importantes/críticas).
- Declaração e Marcação CE: Elaborar uma Declaração de Conformidade UE e apor a marcação CE assim que a conformidade for demonstrada.
- Obrigações de comunicação:
- Vulnerabilidades exploradas ativamente: Comunicar à ENISA no prazo de 24 horas após o conhecimento.
- Incidentes significativos: Comunicar à ENISA os incidentes que afectem a segurança dos produtos.
A implementação exige a integração da segurança na cultura, nos processos e nas ferramentas de engenharia, desde a conceção até à manutenção.
Erros comuns a evitar
Os fabricantes que se estão a preparar para a CRA devem evitar estes erros comuns:
- Subestimar o âmbito: Acreditar que a CRA só se aplica a dispositivos IoT complexos e não a software padrão ou hardware mais simples com elementos digitais. O âmbito de aplicação é muito vasto.
- Atraso na ação: Esperar até mais perto do prazo de 2027, subestimando as mudanças significativas necessárias na conceção, desenvolvimento, testes, gestão de vulnerabilidades e processos de atualização.
- Tratar a segurança como uma reflexão tardia: Não integrar a segurança desde a fase de conceção ("Segurança desde a conceção") e tentar integrá-la mais tarde, o que é menos eficaz e mais dispendioso.
- Gestão inadequada das vulnerabilidades: Falta de processos ou ferramentas robustos (SCA, SAST, DAST) para identificar vulnerabilidades, ou não fornecimento atempado e gratuito de actualizações de segurança para o ciclo de vida necessário.
- Inexatidão/Negligência do SBOM: Não gerar um SBOM completo ou não o manter atualizado à medida que os componentes mudam, dificultando a gestão de vulnerabilidades.
- Ignorar mecanismos de atualização seguros: Não ter uma forma fiável e segura (como uma plataforma OTA robusta) para fornecer actualizações "sem demora". As actualizações manuais provavelmente não serão suficientes.
- Documentação insuficiente: Não manter a documentação técnica exigida, o SBOM e as provas de avaliação da conformidade necessárias para a fiscalização do mercado.
- Concentrar-se apenas no desenvolvimento: Negligenciar os requisitos contínuos pós-comercialização para o tratamento de vulnerabilidades e actualizações ao longo do ciclo de vida do produto.
O que os avaliadores/autoridades podem perguntar (foco no desenvolvedor)
Os organismos de avaliação da conformidade (para os produtos críticos) ou as autoridades de fiscalização do mercado podem fazer perguntas relacionadas com os requisitos das ARC que afectam o desenvolvimento:
- (Anexo I) Conceção segura: "Como é que a segurança foi considerada durante a fase de conceção? Pode mostrar modelos de ameaças ou documentos de arquitetura de segurança?"
- (Anexo I) Gestão de vulnerabilidades: "Que ferramentas e processos são utilizados para identificar vulnerabilidades em código próprio e componentes de terceiros (SAST, SCA) durante o desenvolvimento?"
- (Anexo I) Codificação segura: "Que normas de codificação segura são seguidas? Como é que a conformidade é imposta (por exemplo, linters, revisões de código, formação)?"
- (Anexo I) Testes de segurança: "Apresentar provas da realização de testes de segurança (por exemplo, testes de penetração, testes de fuzz) antes do lançamento."
- (Anexo I) Actualizações de segurança: "Descrever o mecanismo de fornecimento de actualizações de segurança. Como são asseguradas a integridade e a autenticidade das actualizações?"
- (Art. 10.º) SBOM: "Fornecer a lista de materiais do software (SBOM) para esta versão do produto."
- (Art. 10.º) Tratamento de vulnerabilidades: "Descrever o processo de tratamento de uma vulnerabilidade comunicada, desde a entrada até ao lançamento da correção."
- (Anexo I) Configuração por defeito segura: "Como é que o produto garante uma configuração segura logo à partida?"
Exigirão provas das fases de conceção, desenvolvimento, teste e manutenção, incluindo documentação, relatórios de ferramentas, descrições de processos e, eventualmente, acesso à revisão do código.
Ganhos rápidos para as equipas de desenvolvimento
Embora a conformidade total com a CRA leve tempo, as equipas de desenvolvimento podem começar a preparar o terreno:
- Implementar a geração de SBOM: Integrar ferramentas para gerar automaticamente um SBOM como parte do processo de construção.
- Integrar SCA e SAST: Garantir que a Análise de Composição de Software e o Teste Estático de Segurança de Aplicações estão a ser executados de forma fiável no pipeline CI/CD.
- Adotar a modelação básica das ameaças: Comece a discutir as potenciais ameaças durante as reuniões de conceção de novas funcionalidades ou produtos.
- Rever as configurações padrão: Avalie ativamente e reforce as definições predefinidas dos produtos antes do envio. Remover credenciais predefinidas.
- Documentar o processo de atualização: Documentar claramente o processo atual de criação e lançamento de actualizações de software, mesmo que inicialmente seja manual.
- Estabelecer o registo de vulnerabilidades: Criar uma forma simples e documentada para as equipas internas ou investigadores externos comunicarem potenciais vulnerabilidades (por exemplo, um endereço de correio eletrónico ou formulário específico).
Ignorar isto e... (Consequências do incumprimento)
O incumprimento das ANC pode ter consequências graves, aplicadas pelas autoridades nacionais de fiscalização do mercado:
- Coimas pesadas: As coimas administrativas podem atingir 15 milhões de euros ou 2,5% do volume de negócios anual total a nível mundial do fabricante no exercício financeiro anterior, consoante o montante mais elevado, por incumprimento dos requisitos essenciais. As infracções menos graves implicam coimas até 10 milhões de euros/2% ou 5 milhões de euros/1%.
- Retirada do mercado/recuperação: As autoridades podem exigir que os produtos não conformes sejam retirados do mercado da UE ou recolhidos dos utilizadores finais.
- Proibição/Restrição de vendas: A colocação de produtos não conformes no mercado pode ser proibida ou restringida.
- Danos à reputação: A divulgação pública de não-conformidades, recolhas ou vulnerabilidades significativas prejudica a confiança na marca e a perceção do mercado.
- Perda de acesso ao mercado: O não cumprimento dos requisitos das ARC bloqueia efetivamente o acesso a todo o mercado único da UE para os produtos abrangidos.
FAQ
Que produtos são abrangidos pelo CRA?
"Produtos com elementos digitais" (PDE) cuja utilização prevista ou razoavelmente previsível inclui uma ligação de dados lógica ou física, direta ou indireta, a um dispositivo ou rede. Isto inclui a maior parte do software (autónomo, móvel, incorporado) e do hardware com conetividade (dispositivos IoT, routers, aparelhos inteligentes, componentes industriais, etc.). Existem exclusões específicas (por exemplo, dispositivos médicos, automóveis, aviação, determinados SaaS).
Quando é que os requisitos das CRA se tornam obrigatórios?
A maior parte das obrigações, incluindo as avaliações de conformidade e os requisitos essenciais, são aplicáveis 36 meses após a entrada em vigor da ARC (cerca de dezembro de 2027). No entanto, a obrigação do fabricante de comunicar vulnerabilidades e incidentes explorados ativamente aplica-se mais cedo, 21 meses após a entrada em vigor (cerca de setembro de 2026).
O CRA aplica-se ao software livre e de código aberto (FOSS)?
O FOSS autónomo desenvolvido ou fornecido fora de uma atividade comercial está geralmente excluído. No entanto, a FOSS integrada num produto comercial está abrangida e o fabricante do produto final é responsável. Os projectos FOSS com estruturas formais (por exemplo, fundações) que rentabilizam o suporte ou as versões podem também ser abrangidos por algumas obrigações do CRA (as especificidades ainda estão em debate).
O que é a marcação CE no contexto da ARC?
À semelhança de outros regulamentos da UE relativos a produtos, os fabricantes devem apor a marcação CE nos PDE conformes para indicar que cumprem os requisitos essenciais da CRA antes de os colocarem no mercado da UE. Para o efeito, é necessária uma avaliação de conformidade bem sucedida.
O que é uma SBOM e porque é necessária?
Uma lista de materiais de software (SBOM) é um registo formal que contém os detalhes e as relações da cadeia de fornecimento de vários componentes utilizados na construção de software. A CRA exige que os fabricantes criem e mantenham uma SBOM para os seus produtos, a fim de melhorar a transparência e facilitar a gestão da vulnerabilidade em toda a cadeia de abastecimento.
Durante quanto tempo devem os fabricantes fornecer actualizações de segurança ao abrigo da CRA?
Os fabricantes devem fornecer actualizações de segurança durante o tempo de vida previsto do produto ou durante um período mínimo de cinco anos a partir da colocação do produto no mercado, consoante o que for mais curto. O tempo de vida esperado deve ser considerado durante a conceção. As actualizações devem ser gratuitas e atempadas ("sem demora").
Qual é a relação entre a CRA e o NIS2 ou o RGPD?
- NIS2: centra-se na segurança das redes e dos sistemas utilizados pelos prestadores de serviços essenciais/importantes. CRA: centra-se na segurança dos próprios produtos que podem ser utilizados por esses fornecedores ou consumidores.
RGPD: Centra-se na proteção dos dados pessoais. A CRA centra-se na cibersegurança dos produtos. Um produto seguro ao abrigo do CRA ajuda a proteger os dados pessoais por ele tratados (apoiando o RGPD), mas o âmbito do CRA é mais vasto do que apenas os dados pessoais. São partes complementares da estratégia de segurança digital da UE.
