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
| Data | Marco |
|---|---|
| 10 de dezembro de 2024 | Entrada em vigor da CRA |
| 11 de setembro de 2026 | Início das obrigações de reporte |
| 11 de dezembro de 2027 | Aplicaçã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
| Categoria | Requisitos | Exemplos |
|---|---|---|
| Padrão | Autoavaliação | Maioria dos softwares, IoT básico |
| Importante Classe I | Avaliação baseada em normas | Navegadores, gerenciadores de senhas, VPNs, gestão de redes |
| Importante Classe II | Avaliação por terceiros | Sistemas operacionais, firewalls, roteadores, hipervisores |
| Crítico | Avaliação por terceiros + certificação | Mó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:
- Nível de segurança apropriado: Baseado em riscos previsíveis
- Ausência de vulnerabilidades exploráveis conhecidas: No momento da colocação no mercado
- Configuração padrão segura: Incluindo capacidade de restauração de fábrica
- Proteção da confidencialidade: Para dados armazenados, transmitidos e processados
- Proteção da integridade: Contra modificações não autorizadas
- Disponibilidade: Resiliência contra negação de serviço
- Superfície de ataque mínima: Reduzir vetores potenciais de ataque
- 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:
- Identificar vulnerabilidades: Por meio de testes e monitoramento
- Documentar componentes: Manter a lista de materiais de software (SBOM)
- Tratar vulnerabilidades: Fornecer atualizações de segurança sem atrasos indevidos
- Divulgar vulnerabilidades: Coordenar com as partes afetadas
- 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 Relato | Prazos |
|---|---|
| Vulnerabilidade explorada ativamente | 24 horas para a ENISA |
| Incidente com impacto na segurança | 24 horas para ENISA/CSIRT |
| Notificação de vulnerabilidade | 72 horas para a ENISA |
Avaliação de Conformidade
| Categoria | Procedimento |
|---|---|
| Padrão | Autodeclaração ou exame tipo UE |
| Importante Classe I | Normas harmonizadas OU avaliação por terceiros |
| Importante Classe II | Avaliação de conformidade por terceiros |
| Crítico | Exame 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:
- Inventariar produtos: Determinar quais estão no escopo e sua categoria
- Segurança desde o design: Integrar segurança nos processos de desenvolvimento
- Gestão de vulnerabilidades: Estabelecer procedimentos de detecção e tratamento
- Criação de SBOM: Documentar componentes e dependências de software
- Planejamento de suporte: Definir e comunicar períodos de suporte
- Mecanismos de atualização: Construir sistemas seguros de entrega de atualizações
- Preparação para conformidade: Preparar documentação técnica