TL;DR

CRA (Lei de Ciber-Resiliência) torna a segurança obrigatória para qualquer coisa “digital” vendida na UE—aplicativos, firmware, IoT, software.

Exige segurança por design, aplicação de patches, SBOMs e divulgação de vulnerabilidades ao longo do ciclo de vida de um produto.

Começa em dezembro de 2027. Perder o prazo? Espere multas de €15M+ ou proibições de mercado.

Lei de Ciber-Resiliência da UE (CRA) Resumo do Scorecard:

• Esforço do Desenvolvedor: Alto (Exige a incorporação de segurança em todo o ciclo de vida do produto: design seguro, codificação segura, testes rigorosos, implementação de processos de tratamento de vulnerabilidades, fornecimento de atualizações seguras, manutenção de SBOMs).
• Custo de Ferramentas: Moderado a Alto (Requer ferramentas SDLC seguras - SAST/SCA/DAST, ferramentas de geração de SBOM, plataformas de gerenciamento de vulnerabilidades, infraestrutura de atualização potencialmente segura - plataformas OTA).
• Impacto no Mercado: Muito Alto (Obrigatório para quase todos os produtos de hardware/software vendidos na UE; estabelece uma nova linha de base global para as expectativas de cibersegurança de produtos).
• Flexibilidade: Moderada (Define requisitos essenciais, mas permite diferentes rotas de avaliação de conformidade com base na classificação de risco do produto).
• Intensidade da Auditoria: Moderada a Alta (Exige avaliações de conformidade – autoavaliação para produtos padrão, avaliação de terceiros para produtos críticos; as autoridades de vigilância de mercado farão cumprir).

O que é a Lei de Ciber-Resiliência da UE (CRA)?

A Lei de Ciber-Resiliência da UE (CRA) é um regulamento que estabelece requisitos harmonizados de cibersegurança para "produtos com elementos digitais" (PDEs) disponibilizados no mercado da União Europeia. Seu objetivo é combater o problema generalizado de produtos de hardware e software inseguros e a falta de atualizações de segurança em tempo hábil.

A CRA aplica-se amplamente a quase todo produto de software ou hardware que possa se conectar direta ou indiretamente a outro dispositivo ou rede, com algumas exceções (por exemplo, dispositivos médicos, aviação, carros já cobertos por legislação específica, SaaS, a menos que crítico). Isso inclui dispositivos IoT de consumo, equipamentos de rede, componentes de controle industrial, sistemas operacionais, aplicativos móveis, software de desktop e muito mais.

Pilares-chave da CRA:

1. Requisitos Essenciais de Cibersegurança (Anexo I): Os fabricantes devem garantir que os PDEs (Produtos com Elementos Digitais) atendam a objetivos de segurança específicos ao longo de seu ciclo de vida. Isso abrange:
   
   • Segurança por Design e Padrão: Os produtos devem ser projetados, desenvolvidos e produzidos para garantir um nível apropriado de cibersegurança. Devem ser entregues com uma configuração padrão segura.
   • Gerenciamento de Vulnerabilidades: Os fabricantes devem ter processos para identificar e remediar vulnerabilidades durante toda a vida útil esperada do produto ou por um mínimo de cinco anos, incluindo o fornecimento de atualizações de segurança "sem demora" e gratuitamente.
   • Proteção de Dados: Proteção da confidencialidade, integridade e disponibilidade dos dados processados pelo produto.
   • Controle de Acesso: Prevenção de acesso não autorizado.
   • Resiliência: Capacidade de resistir e se recuperar de incidentes.
   • Minimizando a Superfície de Ataque: Limitando as superfícies de ataque e mitigando o impacto de incidentes.
2. Obrigações para Operadores Econômicos:
   
   • Fabricantes: Assumem a responsabilidade principal por garantir a conformidade com a CRA – design seguro, avaliação de conformidade, documentação técnica (incluindo SBOM), tratamento de vulnerabilidades, relatórios de incidentes/vulnerabilidades, fornecimento de atualizações e instruções claras. Isso se aplica mesmo se baseados fora da UE.
   • Importadores/Distribuidores: Têm obrigações de verificar a conformidade do fabricante (ex: marcação CE, documentação) antes de colocar produtos no mercado.
3. Tratamento e Relato de Vulnerabilidades: Os fabricantes devem estabelecer processos para lidar com vulnerabilidades de forma eficaz e relatar vulnerabilidades ativamente exploradas à ENISA (Agência da UE para a Cibersegurança) dentro de 24 horas após a ciência. Eles também devem informar os usuários sobre vulnerabilidades corrigidas e atualizações disponíveis.
4. Avaliação de Conformidade e Marcação CE: PDEs devem passar por um processo de avaliação de conformidade (variando da autoavaliação do fabricante à certificação por terceiros, dependendo da criticidade do produto) para demonstrar conformidade antes de receber uma marcação CE e ser colocado no mercado da UE.
5. Vigilância do Mercado: Designa autoridades nacionais de vigilância do mercado para fazer cumprir o CRA, investigar a não conformidade e impor penalidades ou exigir a retirada/recolha de produtos.

A CRA entrou em vigor no final de 2024, com a maioria das obrigações tornando-se aplicáveis 36 meses depois (por volta de dezembro de 2027), enquanto as obrigações de relatórios dos fabricantes se aplicam mais cedo (por volta de setembro de 2026).

Por que é Importante?

A CRA é uma legislação marcante com implicações significativas:

• Transfere a Responsabilidade: Coloca a responsabilidade pela segurança do produto diretamente nos fabricantes, em vez de deixá-la principalmente para os usuários finais.
• Eleva a Linha de Base de Segurança: Estabelece padrões mínimos obrigatórios de cibersegurança para uma vasta gama de produtos conectados vendidos na UE.
• Segurança da supply chain de software: Aborda vulnerabilidades originadas de componentes de terceiros por meio de requisitos como SBOMs e gerenciamento de vulnerabilidades ao longo do ciclo de vida.
• Protege Consumidores e Empresas: Visa reduzir o número de produtos inseguros explorados por invasores, protegendo os usuários contra violações de dados, perdas financeiras e riscos de segurança.
• Harmoniza Requisitos: Cria um conjunto único de regras em toda a UE, substituindo abordagens nacionais potencialmente fragmentadas para a cibersegurança de produtos.
• Impacto Global: Dado o tamanho do mercado da UE, o CRA efetivamente estabelece um padrão global, influenciando fabricantes em todo o mundo que desejam vender produtos na Europa.
• Complementa Outras Regulamentações: Funciona em conjunto com NIS2 (garantindo serviços críticos), GDPR (protegendo dados pessoais) e DORA (resiliência financeira) para criar um cenário de cibersegurança da UE mais abrangente.

Para fabricantes de software e hardware conectado, a conformidade com CRA se tornará um requisito fundamental para acesso ao mercado na UE.

O Quê e Como Implementar (Técnico e Político)

A implementação do CRA exige a integração de seus requisitos essenciais (Anexo I) ao longo de todo o ciclo de vida do produto:

1. Design e Desenvolvimento Seguro (Segurança por Design):
   
   • Modelagem de Ameaças: Identificar ameaças potenciais e projetar controles de segurança desde o início.
   • Práticas de Codificação Segura: Treine desenvolvedores e aplique padrões de codificação segura (por exemplo, OWASP ASVS, padrões de codificação CERT). Use ferramentas SAST.
   • Minimizar Superfície de Ataque: Limitar funcionalidades, portas abertas e privilégios ao mínimo necessário.
   • Padrões Seguros: Garantir que os produtos sejam entregues com configurações seguras (por exemplo, sem senhas padrão, serviços desnecessários desabilitados). Implementar funcionalidade de redefinição segura.
   • Proteção de Dados: Implementar criptografia para dados em repouso e em trânsito, quando apropriado. Proteger a integridade dos dados.
   • Controle de Acesso: Implementar mecanismos robustos de autenticação e autorização.
2. Gerenciamento de Vulnerabilidades:
   
   • Análise de Componentes (SBOM): Gere e mantenha uma lista de materiais de software (SBOM) precisa identificando todos os componentes (incluindo bibliotecas de código aberto). Use ferramentas SCA para encontrar vulnerabilidades conhecidas em dependências.
   • Testes de Segurança: Implemente varreduras de vulnerabilidades regulares (SAST, DAST, SCA, IaC), fuzz testing e testes de penetração ao longo do desenvolvimento e pós-lançamento.
   • Processo de Tratamento de Vulnerabilidades: Estabelecer procedimentos claros para receber relatórios de vulnerabilidade (internos/externos), analisá-los, desenvolver patches e distribuir atualizações "sem demora".
   • Patching/Atualizações: Forneça atualizações de segurança gratuitas pelo ciclo de vida esperado do produto (mín. 5 anos). Implemente um mecanismo de atualização seguro (por exemplo, atualizações OTA seguras com verificações de integridade).
3. Transparência e Documentação:
   
   • Documentação Técnica: Manter documentação técnica detalhada demonstrando conformidade com os requisitos essenciais. Incluir a SBOM.
   • Informações do Usuário: Forneça aos usuários instruções claras sobre uso seguro, configuração, atualizações e o ciclo de vida de suporte do produto.
   • Divulgação de Vulnerabilidades: Estabelecer uma política e um ponto de contato para receber relatórios de vulnerabilidade; divulgar publicamente as vulnerabilidades corrigidas.
4. Avaliação da Conformidade:
   
   • Classificação de Risco: Determinar se o produto se enquadra nas categorias padrão, "importante" (Classe I) ou "crítica" (Classe II) com base no Anexo III.
   • Procedimento de Avaliação: Seguir o procedimento exigido (por exemplo, controle interno/autoavaliação para o padrão, avaliação/certificação de terceiros para classes importantes/críticas).
   • Declaração e Marcação CE: Elaborar uma Declaração de Conformidade da UE e afixar a marcação CE assim que a conformidade for demonstrada.
5. Obrigações de Relato:
   
   • Vulnerabilidades Ativamente Exploradas: Reportar à ENISA em até 24 horas após a ciência.
   • Incidentes Significativos: Relate incidentes que afetam a segurança do produto à ENISA.

A implementação exige a incorporação da segurança na cultura de engenharia, nos processos e nas ferramentas, desde o design até a manutenção.

Erros Comuns a Evitar

Fabricantes que se preparam para o CRA devem evitar estes erros comuns:

1. Subestimar o Escopo: Acreditar que o CRA se aplica apenas a dispositivos IoT complexos e não a software padrão ou hardware mais simples com elementos digitais. O escopo é muito amplo.
2. Atrasar Ações: Esperar até mais perto do prazo final de 2027, subestimando as mudanças significativas necessárias em processos de design, desenvolvimento, testes, gerenciamento de vulnerabilidades e atualização.
3. Tratar a Segurança como um Item Secundário: Falhar em integrar a segurança desde a fase de design ("Security by Design") e tentar adicioná-la posteriormente, o que é menos eficaz e mais custoso.
4. Gerenciamento de Vulnerabilidades Inadequado: Falta de processos ou ferramentas robustas (SCA, SAST, DAST) para identificar vulnerabilidades, ou falha em fornecer atualizações de segurança gratuitas e em tempo hábil para o ciclo de vida exigido.
5. Imprecisão/Negligência da SBOM: Falha em gerar uma SBOM completa ou mantê-la atualizada conforme os componentes mudam, prejudicando o gerenciamento de vulnerabilidades.
6. Ignorando Mecanismos de Atualização Seguros: Não ter uma forma confiável e segura (como uma plataforma OTA robusta) para entregar atualizações "sem demora". Atualizações manuais provavelmente não serão suficientes.
7. Documentação Insuficiente: Falha em manter a documentação técnica exigida, SBOM e evidências de avaliação de conformidade necessárias para a vigilância do mercado.
8. Focar Apenas no Desenvolvimento: Negligenciar os requisitos contínuos pós-mercado para tratamento de vulnerabilidades e atualizações ao longo do ciclo de vida do produto.

O Que Avaliadores/Autoridades Podem Perguntar (Foco no Desenvolvedor)

Organismos de avaliação da conformidade (para produtos críticos) ou autoridades de fiscalização do mercado podem fazer perguntas relacionadas aos requisitos do CRA que impactam o desenvolvimento:

• (Anexo I) Design Seguro: "Como a segurança foi considerada durante a fase de design? Vocês podem mostrar modelos de ameaças ou documentos de arquitetura de segurança?"
• (Anexo I) Gerenciamento de Vulnerabilidades: "Quais ferramentas e processos são usados para identificar vulnerabilidades em código próprio e componentes de terceiros (SAST, SCA) durante o desenvolvimento?"
• (Anexo I) Codificação Segura: "Quais padrões de codificação segura são seguidos? Como a conformidade é imposta (por exemplo, linters, revisões de código, treinamento)?"
• (Anexo I) Testes de Segurança: "Apresente evidências de testes de segurança (por exemplo, testes de penetração, fuzz testing) realizados antes do lançamento."ções de segurança (controle de acesso, criptografia, gerenciamento de vulnerabilidades) são implementadas no aplicativo para proteger dados pessoais?"
• (Anexo I) Atualizações Seguras: "Descrevam o mecanismo para entrega de atualizações de segurança. Como a integridade e a autenticidade das atualizações são garantidas?"
• (Art. 10) SBOM: "Forneça a lista de materiais de software (SBOM) para esta versão do produto."
• (Art. 10) Tratamento de Vulnerabilidades: "Descreva o processo para lidar com uma vulnerabilidade relatada, desde a recepção até o lançamento do patch."
• (Anexo I) Configuração Padrão Segura: "Como o produto garante uma configuração segura de fábrica?"

Eles exigirão evidências das fases de design, desenvolvimento, teste e manutenção, incluindo documentação, relatórios de ferramentas, descrições de processos e, potencialmente, acesso a revisões de código.

Ganhos Rápidos para Equipes de Desenvolvimento

Embora a conformidade total com a CRA leve tempo, equipes de desenvolvimento podem começar a preparar o terreno:

1. Implementar Geração de SBOM: Integrar ferramentas para gerar automaticamente uma SBOM como parte do processo de build.
2. Integrar SCA e SAST: Garantir que a análise de composição de software e os testes de segurança de aplicações estáticas estejam funcionando de forma confiável no pipeline de CI/CD.
3. Adote Modelagem de Ameaças Básica: Comece a discutir ameaças potenciais durante as reuniões de design para novas funcionalidades ou produtos.
4. Revisão das Configurações Padrão: Avalie e fortaleça ativamente as configurações padrão dos produtos antes do lançamento. Remova as credenciais padrão.
5. Documente o Processo de Atualização: Documente claramente o processo atual para construir e lançar atualizações de software, mesmo que seja manual inicialmente.
6. Estabeleça um Canal de Recepção de Vulnerabilidades: Crie uma forma simples e documentada para equipes internas ou pesquisadores externos reportarem potenciais vulnerabilidades (por exemplo, um endereço de e-mail dedicado ou formulário).

Ignore Isso E... (Consequências da Não Conformidade)

A não conformidade com a CRA pode levar a sérias consequências aplicadas pelas autoridades nacionais de vigilância do mercado:

• Multas Pesadas: As multas administrativas podem chegar a €15 milhões ou 2,5% do faturamento anual global total do fabricante no exercício financeiro anterior, o que for maior, por não conformidade com os requisitos essenciais. Infrações menores acarretam multas de até €10M/2% ou €5M/1%.
• Retirada/Recolha do Mercado: As autoridades podem exigir que produtos não conformes sejam retirados do mercado da UE ou recolhidos dos usuários finais.
• Proibição/Restrição de Vendas: A colocação de produtos não conformes no mercado pode ser proibida ou restrita.
• Dano à Reputação: A divulgação pública de não conformidade, recalls ou vulnerabilidades significativas prejudica a confiança na marca e a percepção do mercado.
• Perda de Acesso ao Mercado: O não cumprimento dos requisitos da CRA bloqueia efetivamente o acesso a todo o mercado único da UE para produtos abrangidos.

FAQ

Quais produtos são cobertos pela CRA?

"Produtos com elementos digitais" (PDEs) cujo uso pretendido ou razoavelmente previsível inclui uma conexão de dados lógica ou física direta ou indireta a um dispositivo ou rede. Isso inclui a maioria dos softwares (autônomos, móveis, embarcados) e hardware com conectividade (dispositivos IoT, roteadores, eletrodomésticos inteligentes, componentes industriais, etc.). Existem exclusões específicas (por exemplo, dispositivos médicos, carros, aviação, certos SaaS).

Quando os requisitos do CRA se tornam obrigatórios?

A maioria das obrigações, incluindo avaliações de conformidade e requisitos essenciais, aplica-se 36 meses após a entrada em vigor do CRA (por volta de dezembro de 2027). No entanto, a obrigação de notificação do fabricante para vulnerabilidades e incidentes ativamente explorados aplica-se mais cedo, 21 meses após a entrada em vigor (por volta de setembro de 2026).

O CRA se aplica a software livre e de código aberto (FOSS)?

FOSS autônomo desenvolvido ou fornecido fora de uma atividade comercial é geralmente excluído. No entanto, FOSS integrado em um produto comercial é coberto, e o fabricante do produto final é responsável. Projetos FOSS com estruturas formais (por exemplo, fundações) que monetizam suporte ou versões também podem estar sujeitos a algumas obrigações do CRA (os detalhes ainda estão sendo debatidos).

O que é a marcação CE no contexto do CRA?

De forma similar a outras regulamentações de produtos da UE, os fabricantes devem afixar a marcação CE em PDEs compatíveis para indicar que atendem aos requisitos essenciais do CRA antes de colocá-los no mercado da UE. Isso exige uma avaliação de conformidade bem-sucedida.

O que é uma SBOM e por que ela é exigida?

Uma lista de materiais de software (SBOM) é um registro formal contendo os detalhes e as relações da cadeia de suprimentos de vários componentes usados na construção de software. A CRA exige que os fabricantes gerem e mantenham uma SBOM para seus produtos para melhorar a transparência e facilitar o gerenciamento de vulnerabilidades em toda a cadeia de suprimentos.

Por quanto tempo os fabricantes devem fornecer atualizações de segurança sob o CRA?

Os fabricantes devem fornecer atualizações de segurança durante a vida útil esperada do produto ou por um período mínimo de cinco anos a partir da sua colocação no mercado, o que for mais curto. A vida útil esperada precisa ser considerada durante o projeto. As atualizações devem ser gratuitas e oportunas ("sem demora").

Como o CRA se relaciona com a NIS2 ou a GDPR?

• NIS2: Foca na segurança de redes e sistemas usados por provedores de serviços essenciais/importantes. CRA foca na segurança dos próprios produtos que podem ser usados por esses provedores ou consumidores.

GDPR: Foca na proteção de dados pessoais. CRA foca na cibersegurança do produto. Um produto seguro sob o CRA ajuda a proteger os dados pessoais processados por ele (apoiando o GDPR), mas o escopo do CRA é mais amplo do que apenas dados pessoais. Eles são partes complementares da estratégia de segurança digital da UE.