Lei de resiliência cibernética: um guia de conformidade para fabricantes e distribuidores de produtos conectados

O que a Lei de Resiliência Cibernética cobre

A Lei de Resiliência Cibernética (CRA) preenche uma lacuna de longa data na regulamentação de produtos da UE. Antes disso, os fabricantes podiam vender legalmente produtos com falhas de segurança conhecidas ou sem qualquer processo de gestão de vulnerabilidades. A partir de dezembro de 2027, colocar um produto conectado inseguro no mercado da UE, ou não gerir sua segurança ao longo da sua vida útil, será uma violação legal sujeita a multas substanciais.

A lei aplica-se a produtos com elementos digitais (PDEs): qualquer produto, hardware ou software que contenha componentes digitais e possa se conectar a outro dispositivo ou rede. Essa definição é intencionalmente ampla. Dispositivos domésticos inteligentes, controladores industriais, roteadores, câmeras de rede, gerenciadores de senhas, clientes VPN, sistemas operacionais, software empresarial, ferramentas de desenvolvimento e aplicativos móveis de consumo, todos serão abrangidos pelo escopo se forem vendidos ou licenciados comercialmente na UE.

Software como serviço (SaaS) puro, em que o software é executado inteiramente na infraestrutura de um provedor e nenhum componente de software é transferido ou instalado pelo cliente, geralmente é excluído do escopo. A lei visa software enviado ao cliente – baixado, instalado ou implantado na infraestrutura do cliente. No entanto, as plataformas SaaS cuja função principal é permitir a capacidade remota de um produto de hardware permanecem no escopo, e a fronteira entre SaaS e PDE é algo que os reguladores estarão observando cuidadosamente.

As três funções: fabricante, importador, distribuidor

A lei atribui obrigações diferentes dependendo do seu papel na cadeia de fornecimento do produto.

Fabricantes são empresas que desenvolvem ou projetam um produto com elementos digitais e o colocam no mercado com seu próprio nome ou marca. Os fabricantes assumem a maior parte das obrigações CRA: o conjunto completo de requisitos essenciais de segurança cibernética, tratamento de vulnerabilidades, avaliação de conformidade, marcação CE, documentação técnica e manutenção SBOM. Se você cria e vende software ou hardware conectado com sua própria marca, você é um fabricante de acordo com o CRA.

Importadores colocar no mercado da UE produtos fabricados fora da UE. Os importadores devem verificar se o fabricante realizou a avaliação de conformidade exigida, se a marcação CE e a documentação técnica estão em ordem e se o fabricante possui processos de tratamento de vulnerabilidades em vigor. Os importadores não devem colocar produtos no mercado onde tenham motivos para acreditar que esses requisitos não são cumpridos.

Distribuidores disponibilizar produtos no mercado da UE sem os colocarem lá. Os distribuidores devem verificar a marcação CE, verificar se as informações exigidas acompanham o produto e não fornecer produtos que saibam não estar em conformidade. As obrigações dos distribuidores são as mais leves, mas não são triviais – é necessária a devida diligência na conformidade do fornecedor.

As três classes de produtos

A Lei categoriza os PDEs por nível de risco. A categoria determina qual rota de avaliação de conformidade está disponível.

Os requisitos essenciais de segurança cibernética

Todos os fabricantes devem conceber, desenvolver e manter seus produtos em conformidade com os requisitos essenciais de segurança cibernética constantes do Anexo I. Estes abrangem tanto o produto no momento do lançamento como os processos contínuos de tratamento de vulnerabilidades do fabricante.

Segurança do produto no momento da colocação no mercado

• Nenhuma vulnerabilidade explorável conhecida: Os produtos devem ser colocados no mercado sem vulnerabilidades conhecidas e exploráveis ​​nos seus componentes. Isso não significa zero vulnerabilidades – significa que não há vulnerabilidades exploráveis ​​conhecidas e não mitigadas.
• Seguro por padrão: Os produtos devem ser entregues com uma configuração padrão segura e, quando aplicável, com a capacidade de serem redefinidos para esse estado seguro.
• Proteção de dados: Os produtos devem proteger a confidencialidade, integridade e disponibilidade dos dados armazenados, transmitidos ou processados, utilizando criptografia apropriada quando relevante.
• Superfície de ataque mínima: Os produtos devem minimizar as superfícies de ataque, inclusive desabilitando ou restringindo interfaces e serviços não necessários para a funcionalidade pretendida.
• Resiliência contra negação de serviço: Os produtos devem ser concebidos para resistir a ataques de negação de serviço e para limitar o impacto na disponibilidade de outros serviços e redes que utilizam.
• Limitar o impacto dos incidentes: Os produtos devem ser projetados para limitar o impacto de um incidente de segurança em outros produtos e no ambiente de rede mais amplo.

Requisitos de tratamento de vulnerabilidades (em andamento)

• Política de divulgação de vulnerabilidades: Os fabricantes devem ter uma política de divulgação de vulnerabilidades coordenada, documentada e publicamente disponível.
• Identificação de vulnerabilidade: Os fabricantes devem identificar e documentar vulnerabilidades e componentes de software em seus produtos, incluindo a manutenção de um SBOM.
• Correção imediata: Os fabricantes devem resolver as vulnerabilidades sem demora injustificada, inclusive fornecendo atualizações de segurança.
• Entrega de atualização de segurança: As atualizações de segurança devem ser disponibilizadas separadamente das atualizações de funcionalidade e entregues durante o período de suporte, sem custos.
• Relatórios de incidentes e vulnerabilidades: As vulnerabilidades ativamente exploradas e os incidentes graves devem ser comunicados à ENISA e à CSIRT nacional. Veja o cronograma abaixo para saber quando isso se aplica.

Lista de materiais de software (SBOM)

O CRA exige que os fabricantes mantenham uma lista de materiais de software – um inventário formal e estruturado de cada componente de software incluído no produto. Isso inclui código próprio, bibliotecas de terceiros, componentes de código aberto e suas respectivas versões e vulnerabilidades conhecidas.

O SBOM não necessita de ser divulgado publicamente, mas deve ser disponibilizado às autoridades de fiscalização do mercado, mediante pedido. Deve ser mantido atualizado durante todo o período de suporte ativo do produto e deve ser produzido em um formato legível por máquina (a lei aponta para formatos estabelecidos na indústria, como SPDX ou CycloneDX).

Para muitos fabricantes, a obrigação SBOM exigirá investimento em ferramentas de análise de composição de software (SCA) e um processo para rastrear continuamente atualizações de componentes e novos CVEs. Se você ainda não possui um inventário completo das bibliotecas de código aberto e de terceiros em seus produtos, construir esse inventário é a etapa preparatória mais urgente.

Período de apoio e obrigações de fim de vida

Os fabricantes devem definir e publicar um período de suporte para cada produto. O mínimo é de cinco anos ou a vida útil esperada do produto, se for menor. Durante o período de suporte, os fabricantes devem fornecer atualizações de segurança gratuitamente e manter o processo de tratamento de vulnerabilidades.

Ao final do suporte, os fabricantes devem notificar os usuários de forma clara e antecipada, e devem disponibilizar publicamente o estado final de segurança do produto. Os produtos não devem ser projetados para expirar repentinamente, os usuários devem ter tempo suficiente para migrar ou planejar o fim do suporte.

Isso tem implicações significativas para o planejamento do produto. O lançamento de um produto que não pretende apoiar durante pelo menos cinco anos, ou cujo modelo de negócio não permite apoio durante esse período, já não é viável ao abrigo da legislação da UE se vender esse produto no mercado da UE.

Relatórios de vulnerabilidade: o que se aplica a partir de setembro de 2026

As obrigações de comunicação de vulnerabilidades previstas no Artigo 14 da Lei tornam-se aplicáveis ​​a partir de 11 de setembro de 2026, antes do prazo de conformidade total. A partir dessa data:

• Os fabricantes devem notificar a ENISA e sua CSIRT nacional sobre qualquer vulnerabilidade ativamente explorada num produto que tenham colocado no mercado dentro de 24 horas de tomar consciência disso.
• Uma notificação mais detalhada deve seguir dentro de 72 horas, incluindo uma avaliação inicial da gravidade e do impacto.
• Um relatório final deve ser apresentado dentro de 14 dias após a disponibilização de uma medida corretiva, ou no prazo de 14 dias após o encerramento do incidente, se nenhuma solução estiver disponível.
• Os fabricantes também devem notificar os usuários afetados sobre incidentes graves sem demora injustificada.

A ENISA irá operar uma plataforma única de comunicação para estas notificações. Espera-se que a plataforma esteja operacional antes do prazo de apresentação de relatórios de setembro de 2026. As CSIRT nacionais receberão cópias das notificações relativas aos produtos colocados no seu mercado nacional.

O cronograma de implementação

O que fazer agora

Faltando menos de um ano para Setembro de 2026 e menos de 18 meses para Dezembro de 2027, o tempo disponível para preparação é mais curto do que parece. A documentação de segurança, as ferramentas SBOM e os processos de avaliação de conformidade levam tempo para serem implementados adequadamente.

Etapa 1: determine se seus produtos estão no escopo

Liste todos os produtos que sua organização desenvolve, fabrica, importa ou distribui que são vendidos ou disponibilizados no mercado da UE. Para cada um, pergunte: contém componentes digitais que podem ser conectados a outro dispositivo ou rede? Se sim, é quase certo que se trata de um produto com elementos digitais. Se você for um provedor de SaaS puro, verifique se algum componente de software é transferido ou instalado pelos clientes ou se seu SaaS permite a função principal de um produto de hardware.

Etapa 2: classifique seus produtos

Revise o Anexo I da Lei para determinar se algum de seus produtos se enquadra na Classe I Importante ou na Classe II Crítica. Se você cria sistemas de gerenciamento de identidade, VPNs, navegadores, gerenciadores de senhas, ferramentas de gerenciamento de rede ou sistemas de controle industrial, provavelmente você pertence à Classe I. Módulos de segurança de hardware e produtos similares são da Classe II. Os produtos que não estão no Anexo I são de classe padrão e podem ser autocertificados.

Etapa 3: comece seu SBOM

Se você ainda não mantém um inventário preciso de cada componente de software em cada um de seus produtos, incluindo bibliotecas de código aberto, suas versões e status CVE conhecido, comece a construí-lo agora. As ferramentas de análise de composição de software (SCA) podem automatizar grande parte disso. O SBOM também fornece a base para seu processo de monitoramento de vulnerabilidades.

Etapa 4: crie seu processo de relatório de vulnerabilidades

A obrigação de comunicação de 24 horas da ENISA significa que você precisa de um caminho de escalonamento interno claro antes de setembro de 2026. Defina quem é responsável pelo monitoramento das vulnerabilidades exploradas, como essas informações chegam às equipes jurídicas e de produto, quem tem autoridade para enviar a notificação da ENISA e como você se comunica com os clientes afetados. Documente e teste.

Etapa 5: revise os compromissos do ciclo de vida do produto

Para cada produto, avalie se você pode se comprometer e manter um período mínimo de suporte de cinco anos. Se seu produto estiver próximo do fim da vida útil, planeje as comunicações com o usuário e certifique-se de cumprir as obrigações de notificação do fim da vida útil. Os produtos lançados após o prazo de dezembro de 2027 deverão ter seu período de suporte definido e publicado no lançamento.

Nosso equipe de segurança cibernética apoia fabricantes e distribuidores com avaliações de preparação para CRA, implementação de SBOM e design de processos de gerenciamento de vulnerabilidades. Nosso prática de conformidade trabalha com organizações na Holanda e no Reino Unido na documentação de conformidade de produtos e na preparação de avaliações de conformidade.

A estrutura fina

As autoridades de fiscalização do mercado em cada Estado-Membro são responsáveis ​​pela aplicação. A estrutura fina é:

• Não conformidade com requisitos essenciais de segurança cibernética ou obrigações de tratamento de vulnerabilidades: Até 15 milhões de euros ou 2,5% do volume de negócios anual total mundial, o que for maior.
• Incumprimento de outras obrigações do CRA (avaliação da conformidade, marcação CE, documentação técnica, registo): Até 10 milhões de euros ou 2% do volume de negócios anual total a nível mundial, o que for maior.
• Fornecer informações incorretas, incompletas ou enganosas às autoridades: Até 5 milhões de euros ou 1% do volume de negócios anual total mundial, o que for maior.

As autoridades de fiscalização do mercado também têm o poder de exigir a recolha de produtos, de proibir a colocação de produtos no mercado da UE e de emitir advertências públicas. Violações persistentes ou graves podem desencadear restrições de mercado em toda a UE através do sistema de alerta RAPEX/Safety Gate.