Lei de Resiliência Cibernética

Lei de Resiliência Cibernética

Visão Geral

A Lei de Resiliência Cibernética (CRA) introduz requisitos obrigatórios de cibersegurança para produtos de hardware e software com elementos digitais. Cobre todo o ciclo de vida do produto, desde o design até o fim do suporte, e visa enfrentar a proliferação de produtos IoT e de software inseguros.[1]

A CRA aplica-se a produtos colocados no mercado da UE, independentemente do local de fabricação.

Cronograma de Aplicação

DataMarco
10 de dezembro de 2024Entrada em vigor da CRA
11 de setembro de 2026Início das obrigações de reporte
11 de dezembro de 2027Aplicação completa de todos os requisitos

Produtos Abrangidos

Produtos Cobertos

Produtos com elementos digitais que:

  • Possuem conexão lógica ou física direta ou indireta a um dispositivo ou rede
  • Incluem componentes de hardware e software

Categorias

CategoriaRequisitosExemplos
PadrãoAutoavaliaçãoMaioria dos softwares, IoT básico
Importante Classe IAvaliação baseada em normasNavegadores, gerenciadores de senhas, VPNs, gestão de redes
Importante Classe IIAvaliação por terceirosSistemas operacionais, firewalls, roteadores, hipervisores
CríticoAvaliação por terceiros + certificaçãoMódulos de segurança de hardware, medidores inteligentes, cartões inteligentes

Isenções

  • Software de código aberto (desenvolvimento não comercial)
  • SaaS (coberto por outras regulamentações)
  • Produtos já regulados (dispositivos médicos, veículos, aviação)
  • Produtos de defesa e segurança nacional

Requisitos Essenciais de Cibersegurança[2]

Segurança desde o Design

Os produtos devem ser projetados e desenvolvidos para garantir:

  1. Nível de segurança apropriado: Baseado em riscos previsíveis
  2. Ausência de vulnerabilidades exploráveis conhecidas: No momento da colocação no mercado
  3. Configuração padrão segura: Incluindo capacidade de restauração de fábrica
  4. Proteção da confidencialidade: Para dados armazenados, transmitidos e processados
  5. Proteção da integridade: Contra modificações não autorizadas
  6. Disponibilidade: Resiliência contra negação de serviço
  7. Superfície de ataque mínima: Reduzir vetores potenciais de ataque
  8. Limitação do impacto de incidentes: Minimizar consequências de violações

Autenticação e Controle de Acesso

  • Credenciais padrão fortes e únicas ou definidas pelo usuário no primeiro uso
  • Proteção contra ataques de força bruta
  • Mecanismos de autenticação seguros

Proteção de Dados

  • Armazenamento criptografado para dados sensíveis
  • Transmissão segura de dados
  • Excluir ou anonimizar dados quando não forem mais necessários

Requisitos para Tratamento de Vulnerabilidades[3]

Os fabricantes devem:

  1. Identificar vulnerabilidades: Por meio de testes e monitoramento
  2. Documentar componentes: Manter a lista de materiais de software (SBOM)
  3. Tratar vulnerabilidades: Fornecer atualizações de segurança sem atrasos indevidos
  4. Divulgar vulnerabilidades: Coordenar com as partes afetadas
  5. Atualizações de segurança: Atualizações gratuitas durante o período definido de suporte (mínimo 5 anos)

Relato de Vulnerabilidades

A partir de setembro de 2026, os fabricantes devem reportar:

Tipo de RelatoPrazos
Vulnerabilidade explorada ativamente24 horas para a ENISA
Incidente com impacto na segurança24 horas para ENISA/CSIRT
Notificação de vulnerabilidade72 horas para a ENISA

Avaliação de Conformidade

CategoriaProcedimento
PadrãoAutodeclaração ou exame tipo UE
Importante Classe INormas harmonizadas OU avaliação por terceiros
Importante Classe IIAvaliação de conformidade por terceiros
CríticoExame tipo UE + garantia de qualidade da produção

Os produtos devem exibir a marca CE confirmando a conformidade.

Penas

  • Não conformidade: Até €15 milhões ou 2,5% do faturamento global
  • Violação dos requisitos essenciais: Até €10 milhões ou 2% do faturamento
  • Outras infrações: Até €5 milhões ou 1% do faturamento[4]

Itens de Ação para Desenvolvedores

Para fabricantes de software e hardware:

  1. Inventariar produtos: Determinar quais estão no escopo e sua categoria
  2. Segurança desde o design: Integrar segurança nos processos de desenvolvimento
  3. Gestão de vulnerabilidades: Estabelecer procedimentos de detecção e tratamento
  4. Criação de SBOM: Documentar componentes e dependências de software
  5. Planejamento de suporte: Definir e comunicar períodos de suporte
  6. Mecanismos de atualização: Construir sistemas seguros de entrega de atualizações
  7. Preparação para conformidade: Preparar documentação técnica

Fontes e Referências

[1]
Regulamento (UE) 2024/2847 sobre requisitos de cibersegurança para produtos. EUR-Lex: Texto Oficial da CRA
[2]
Anexo I da CRA: Requisitos essenciais de cibersegurança. Portal CRA: Anexo I
[3]
Anexo I Parte II da CRA: Requisitos para tratamento de vulnerabilidades. Portal CRA: Tratamento de Vulnerabilidades
[4]
Artigo 64 da CRA: Penas. Portal CRA: Penas