Cyber Resilience Act (CRA) e Fabricantes de Software: O que Muda

Contexto: o que é o CRA

O Cyber Resilience Act é o Regulamento (UE) 2024/2847, publicado no Jornal Oficial da União Europeia em 20 de novembro de 2024 e em vigor desde 10 de dezembro de 2024. É a primeira legislação horizontal do bloco que impõe requisitos cibernéticos a fabricantes de produtos com elementos digitais — software embarcado, software standalone, hardware conectado e suas dependências — como condição para entrada no mercado europeu.

A motivação declarada pelos legisladores europeus é direta: a maior parte dos produtos digitais chega ao mercado com vulnerabilidades exploráveis conhecidas, sem suporte de segurança previsível e sem transparência sobre composição. Incidentes como SolarWinds, Log4Shell e MOVEit demonstraram que o ônus do risco recai sobre operadores, governos e cidadãos — não sobre quem fabrica. O CRA reverte essa lógica: a obrigação primária de produzir software seguro é do fabricante.

A maioria das obrigações entra em vigor em 11 de dezembro de 2027 — 36 meses após a entrada em vigor do regulamento, com 24 meses dedicados à transição operacional dos fabricantes. Há uma data intermediária crítica: a obrigação de notificar vulnerabilidades ativamente exploradas e incidentes graves passa a valer em 11 de setembro de 2026, 21 meses após entrada em vigor. Fabricantes que esperarem 2027 para começar perderão essa janela.

Para fabricantes brasileiros de software, o CRA não é assunto exclusivamente europeu. Empresas que distribuem produto baixável globalmente (ferramentas SaaS com agente, dispositivos IoT, bibliotecas comerciais, firmware para hardware embarcado, plugins, SDKs) provavelmente colocam seu produto no mercado da UE — e portanto se enquadram. O modelo de negócio "vendo de qualquer lugar para qualquer um" precisa de uma camada de governance regulatória que a maioria das empresas BR ainda não tem.

Escopo: produtos com elementos digitais

O CRA define product with digital elements (PDE) como qualquer produto de software ou hardware e suas soluções de processamento de dados remoto, cuja utilização pretendida ou razoavelmente previsível inclui conexão direta ou indireta a um dispositivo ou rede. A definição é ampla intencionalmente. Em prática:

• Software standalone — sistemas operacionais, suítes de produtividade, ferramentas de desenvolvimento, antivírus, plataformas locais;
• Software embarcado — firmware de dispositivos, sistemas embedded, RTOS, bootloaders;
• Hardware conectado — IoT consumer e industrial, roteadores, smart cards, smart meters, wearables, controladores industriais;
• Bibliotecas e componentes comerciais — SDKs, middleware, frameworks distribuídos sob licença comercial;
• Aplicativos móveis instalados em dispositivos do cliente final.

Fora do escopo: produtos cobertos por regulações setoriais específicas (dispositivos médicos sob MDR/IVDR, aeronaves sob EASA, veículos sob UNECE WP.29, certos itens de defesa), SaaS puro sem componente entregue ao cliente (que continua sob NIS2 quando aplicável), e — pontualmente importante — free and open-source software developed or supplied outside the course of a commercial activity.

A exceção do open source é mais sutil do que parece. Quando o componente open source é monetizado, integrado em um produto comercial ou suportado profissionalmente, o fabricante que o coloca no mercado é responsável pelo cumprimento — não pode "esconder atrás" da licença upstream. O CRA cria a figura do open-source software steward, com regime mais leve para fundações e mantenedores que organizam comunidades em base não lucrativa, mas isso não desonera o vendor downstream.

Sobre SaaS puro: a distinção operacional é se há componente entregue ao ambiente do cliente. Plataforma 100% browser-based, sem agente, plugin, mobile app ou CLI, fica fora do CRA — sujeita a NIS2 enquanto provedor de serviços. Mas a maioria dos SaaS B2B modernos tem componentes locais: agente de log, conector on-premises, extensão de IDE, mobile companion, CLI. Cada componente entregue é um PDE que precisa ser avaliado individualmente.

Classes de produto e conformity assessment

O CRA classifica produtos em quatro níveis de criticidade, e o nível determina o procedimento de avaliação de conformidade exigido antes da entrada no mercado:

A Comissão Europeia tem poder delegado para atualizar as listas das classes Important e Critical via acts of execution, e isso vai acontecer. Fabricantes de produtos em zona cinzenta (gerência de identidades, observability, ferramentas de DevOps) precisam acompanhar a lista oficial — produtos podem subir de classe sem que o fabricante tenha desenhado o produto para o assessment correspondente.

O notified body é um organismo independente autorizado pelos Estados-Membros para certificar produtos contra os requisitos do CRA. Ele cobra, leva meses para auditar e tem capacidade limitada. Não dá para começar a buscar notified body em outubro de 2027 — fabricantes de Class II precisam iniciar o engajamento agora.

Requisitos essenciais de segurança

O Anexo I do CRA lista requisitos essenciais que se dividem em dois blocos: (1) propriedades de segurança do produto, e (2) requisitos sobre o processo de vulnerability handling do fabricante. Os requisitos do bloco 1 são:

Os demais requisitos do bloco 1: proteção contra acessos não autorizados, integridade de dados, minimização de dados, disponibilidade de funções essenciais incluindo resistência a DoS, redução do impacto de incidentes em outros serviços, logs de segurança, e capacidade de aplicar updates de segurança incluindo automatic updates quando apropriado.

O bloco 2 — processo de vulnerability handling — é onde a maioria dos fabricantes precisará investir mais. Inclui:

• Identificação e documentação de vulnerabilidades e componentes contidos no produto, com SBOM em formato machine-readable;
• Tratamento sem atraso de vulnerabilidades, incluindo fornecimento de patches gratuitos para vulnerabilidades durante o período de suporte;
• Testes regulares e revisões de segurança do produto;
• Política de vulnerability disclosure pública, com canal de contato e processo coordenado;
• Distribuição de informações sobre vulnerabilidades corrigidas (advisories, CVE quando aplicável), incluindo descrição, impacto, severidade — preferencialmente alinhada a CVSS — e remediação;
• Mecanismos seguros de distribuição de updates, com integridade verificável, sem atraso.

Vulnerability handling e notificação

O CRA estabelece um regime de notificação assimétrico ao que existe em LGPD ou GDPR: a obrigação primária é para com a ENISA e o CSIRT nacional do Estado-Membro coordenador, não para titulares de dados. Os marcos temporais são:

O período de suporte deve ser ao menos equivalente ao expected product lifetime e em geral não inferior a 5 anos, exceto quando a expectativa de uso seja comprovadamente menor. Durante esse período, o fabricante é obrigado a fornecer atualizações de segurança gratuitamente. Para produtos de hardware com longo lifecycle (equipamentos industriais, controladores), o período pode chegar a 10 ou 15 anos — algo que precisa ser planejado financeiramente no momento da venda.

Existe um princípio crítico embutido: updates de segurança devem ser separados de updates de funcionalidade. O cliente que opta por não atualizar features novas continua tendo direito ao patch de segurança. Isso colide com o modelo de muitos vendors que entregam tudo em release única — exige refatoração do pipeline de delivery.

Documentação técnica, declaração UE e marca CE

Antes de colocar o produto no mercado, o fabricante elabora a technical documentation exigida pelo Anexo VII do CRA. O conteúdo mínimo inclui:

• Descrição geral do produto, sua utilização pretendida e funcionalidades cibersegurança-relevantes;
• Design, especificações de desenvolvimento e fabricação, incluindo documentação arquitetural;
• Avaliação de risco cibernético formal, ligando riscos identificados aos controles implementados;
• Lista das normas harmonizadas aplicadas (total ou parcialmente) ou esquemas de certificação;
• Resultados dos testes de segurança realizados pelo fabricante ou por laboratórios independentes;
• Cópia da declaração UE de conformidade;
• SBOM em formato machine-readable;
• Descrição do processo de vulnerability handling e do período de suporte.

A documentação técnica deve ser mantida pelo fabricante por 10 anos após colocar o produto no mercado e disponibilizada à autoridade competente sob solicitação. Não é exigido envio prévio — mas o fabricante precisa conseguir entregar em tempo razoável (geralmente dias) sob pena de presunção de não conformidade.

A declaração UE de conformidade é um documento assinado pelo fabricante (ou representante autorizado) afirmando que o produto atende a todos os requisitos aplicáveis do CRA. Para produtos físicos, a marca CE é aposta no produto, embalagem ou documentação. Para software puramente digital, a indicação CE pode estar embarcada nos metadados do produto, na tela "Sobre" ou no site oficial — desde que claramente associada à versão específica.

O SBOM merece atenção especial. Não é um documento opcional ou um nice-to-have. O Anexo I exige que o fabricante documente as vulnerabilidades e componentes contidos no produto, e a interpretação operacional alinhada com as melhores práticas internacionais e com os recentes Executive Orders dos EUA é entregar SBOM em SPDX (ISO/IEC 5962) ou CycloneDX. Esses são os formatos padronizados que sustentam o ecossistema de ferramentas de análise. Geração manual não escala — precisa estar integrada ao pipeline de build. Para uma introdução prática ao tema, veja nosso comparativo de técnicas de teste de segurança em SAST vs DAST vs IAST.

Atores: fabricante, importador, distribuidor

O CRA reconhece três atores principais na cadeia, com obrigações graduadas. Entender em qual papel sua empresa atua (frequentemente, em vários simultaneamente) é o ponto de partida da análise:

Para a empresa brasileira média, o enquadramento é claro: é fabricante. Vende sob sua marca, controla o ciclo de desenvolvimento, integra componentes próprios e third-party. A pergunta operacional é: quem será o authorized representative na UE? Opções práticas incluem subsidiária europeia (se existir), empresa de relacionamento (lawyer, consultoria, parceiro comercial estabelecido) com mandato formal, ou serviço especializado de EU rep. Sem esse representante designado por escrito, o produto não pode ser legalmente colocado no mercado europeu — importadores e distribuidores são proibidos de disponibilizá-lo.

Atenção: integrar componente third-party num produto e vendê-lo sob sua marca faz de você o fabricante daquele produto integrado, mesmo que o componente subjacente seja de outro vendor. O upstream não absorve sua responsabilidade. Por outro lado, o CRA estabelece que se você integra componente substantialmente modificado, é fabricante do produto modificado.

Como fabricantes BR se preparam

A preparação operacional para o CRA atravessa engenharia, jurídico, suporte e governance. Plano sugerido em três horizontes, partindo de hoje:

Práticas auxiliares fundamentais e leituras complementares:

• SBOM como produto da build — gerado automaticamente, versionado junto com o release, publicado para clientes regulados sob NDA ou abertamente. Ver SBOM e segurança de supply chain;
• Secure SDLC e shift-left — SAST, SCA, DAST no pipeline; threat modeling em design; security gates antes do release. Ver DevSecOps shift-left prático;
• Gestão estruturada de vulnerabilidades — triagem com CVSS, priorização por exploitability, SLA por severidade, métricas para diretoria. Ver processo de gestão de vulnerabilidades;
• PSIRT funcional — pessoas treinadas, runbook, FIRST PSIRT Services Framework como referência, comunicação coordenada com pesquisadores;
• Capacidade de notificação rápida — não dá para descobrir como notificar a ENISA no momento do incidente; pré-cadastros, modelos, escalada definida;
• Cláusulas contratuais com fornecedores upstream que permitam cumprir suas obrigações: SBOM, vulnerability advisories tempestivos, patches gratuitos, suporte alinhado ao seu period.

Perguntas frequentes

Conclusão

O Cyber Resilience Act é a regulação cibernética mais ambiciosa já aplicada a fabricantes de software e hardware, e tem efeito extraterritorial real sobre empresas brasileiras que vendem no mercado europeu. Não se trata de mais um checklist de compliance — é uma redefinição da responsabilidade do fabricante sobre o ciclo de vida do produto, sustentada por sanções financeiras significativas e pela capacidade das autoridades europeias de retirar produtos do mercado.

O fabricante BR que quiser manter ou expandir presença na UE tem três tarefas centrais nos próximos meses: (1) mapear quais produtos da sua linha são PDE no escopo do CRA e em qual classe se encaixam; (2) instalar — não documentar, instalar — os processos de vulnerability handling, SBOM e secure SDLC que sustentarão o cumprimento; (3) resolver a representação jurídica europeia. A janela de 11 de setembro de 2026, quando começa a obrigação de notificação de vulnerabilidades exploradas, é curta demais para tratamentos reativos. Quem começa hoje chega; quem espera 2027 vira case de remediação acelerada — ou perde o mercado.

Para aprofundar termos relacionados, consulte o glossário; para o ecossistema de testes de segurança aplicado ao secure SDLC, veja o comparativo SAST vs DAST vs IAST; para gestão estruturada de descobertas de segurança, o guia de gestão de vulnerabilidades.

Referências

• União Europeia. Regulation (EU) 2024/2847 — Cyber Resilience Act. EUR-Lex. Disponível em: eur-lex.europa.eu/eli/reg/2024/2847/oj.
• European Commission. Cyber Resilience Act — policy page. Disponível em: digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act.
• European Union Agency for Cybersecurity (ENISA). Guidance on coordinated vulnerability disclosure and incident notification. Disponível em: enisa.europa.eu/topics/vulnerabilities-and-exploits.
• Linux Foundation / SPDX. Software Package Data Exchange — SBOM specification. Disponível em: spdx.dev.
• OWASP. CycloneDX — SBOM Standard. Disponível em: cyclonedx.org.
• Eclipse Foundation. Open Source Stewards under the CRA — guidance and recommendations. Disponível em: eclipse.org/policy.
• National Institute of Standards and Technology (NIST). Secure Software Development Framework (SSDF) — SP 800-218. Disponível em: csrc.nist.gov/Projects/ssdf.