Se você fabrica um dispositivo conectado e o vende na UE, o Cyber Resilience Act (CRA) se aplica a você. Ponto final. Não importa onde você fabrica, onde sua empresa está registrada ou se você tem um escritório na Europa.
A regulamentação entrou em vigor em 10 de dezembro de 2024. A maioria das equipes marcou 2027 como o prazo e ainda não se mexeu. O problema é que 2027 é a data final de aplicação, não a única. O primeiro prazo rígido é 11 de setembro de 2026, quando o relato obrigatório de vulnerabilidades começa a valer. Você não consegue montar os processos que esse relato exige em uma sprint. Você precisa deles funcionando meses antes do prazo, para ter a evidência operacional que mostrará às autoridades quando elas pedirem.
Este guia cobre o que você realmente precisa fazer, na ordem em que precisa fazer.
Seu produto está no escopo?
O CRA se aplica a qualquer hardware ou software que se conecte, direta ou indiretamente, a um dispositivo ou rede, e que seja colocado no mercado da UE em um contexto comercial.
Seu sensor inteligente, gateway industrial, atualizador de firmware e o sistema operacional embarcado do seu termostato estão todos cobertos. O teste é simples: se vai para a UE e se conecta a qualquer coisa, está no escopo.
O que está excluído:
- Dispositivos médicos e veículos automotores (cobertos por suas próprias regulamentações setoriais)
- Software open source não monetizado
- SaaS e PaaS puros que não sejam parte essencial da função de um dispositivo no escopo
- Sites que não dão suporte a processamento remoto para um dispositivo no escopo
Se você é importador ou distribuidor, e não o fabricante original, ainda tem obrigações. Você pode precisar verificar a marcação CE, reter a documentação e, em alguns casos, assumir as responsabilidades completas do fabricante caso modifique substancialmente o produto antes de colocá-lo no mercado.
Mais uma coisa que muitas equipes deixam passar: os requisitos de cibersegurança da Radio Equipment Directive (RED) já se aplicam desde 1 de agosto de 2025 para equipamentos de rádio conectados à internet. Se o seu dispositivo usa Wi-Fi ou Bluetooth e o prazo de agosto de 2025 já passou sem uma avaliação RED, resolva isso antes de qualquer outra coisa. A lista da RED é mais curta que a do CRA, mas já está vencida.
Passo 1: classifique seu produto
O CRA separa os produtos em quatro categorias de risco. Sua categoria determina como você comprova a conformidade.
Padrão (cerca de 90% de todos os produtos) Dispositivos conectados comuns, a maior parte da IoT de consumo, sensores industriais de menor risco. A autoavaliação é permitida. Você avalia seu próprio produto em relação aos requisitos essenciais e assina uma Declaração de Conformidade.
Importante: Classe I Produtos de maior risco, incluindo navegadores, gerenciadores de senhas, VPNs e softwares de gerenciamento de rede. É permitida a autocertificação em relação a uma norma harmonizada, ou você pode usar um organismo notificado.
Importante: Classe II Produtos com risco de segurança significativo: firewalls industriais, sistemas de detecção de intrusão, microprocessadores, roteadores, modems, gateways de medidores inteligentes. Na maioria dos casos, é exigida avaliação por um organismo notificado terceirizado.
Crítico Produtos dos quais a infraestrutura crítica depende. Exige um esquema europeu de certificação de cibersegurança. O regulamento de execução adotado em novembro de 2025 esclareceu quais produtos se enquadram aqui.
Consulte o Anexo III e o Anexo IV do Regulamento (UE) 2024/2847 para as listas definitivas.
Um problema prático com Classe II e Crítico: a capacidade dos organismos notificados na UE é limitada. As equipes que esperarem até o fim de 2026 ou 2027 para começar vão enfrentar filas. A meta da Comissão Europeia é ter os organismos notificados em operação até 11 de dezembro de 2026, mas a disponibilidade pode não acompanhar a demanda. Comece cedo.
Passo 2: monte agora seu Software Bill of Materials
O requisito de SBOM está no Anexo I, Parte II do CRA. Os fabricantes precisam identificar e documentar todos os componentes de seus produtos, incluindo um software bill of materials em formato legível por máquina e de uso comum, cobrindo no mínimo as dependências de primeiro nível.
A razão para fazer isso antes de setembro de 2026 é operacional, não burocrática. Quando uma vulnerabilidade ativamente explorada é divulgada publicamente, você tem 24 horas para reportar à ENISA e ao seu CSIRT nacional. Para cumprir esse prazo, você precisa saber em minutos se o seu produto usa o componente afetado. Sem um SBOM e rastreamento automatizado de vulnerabilidades, você vai gastar essas 24 horas vasculhando imagens de firmware manualmente.
O que o seu SBOM precisa cobrir:
- Cada componente de software, do sistema operacional aos módulos de firmware
- Componentes proprietários e open source
- Números de versão e informações de licenciamento
- Vulnerabilidades conhecidas mapeadas para cada componente
- No mínimo as dependências de primeiro nível; rastreamento completo de dependências transitivas onde for viável
O CRA ainda não obriga um formato específico, mas exige que seja “de uso comum e legível por máquina”. Tanto o SPDX quanto o CycloneDX atendem a isso. A expectativa é que a Comissão Europeia especifique os formatos por meio de atos de execução em 2026. Escolha um agora e integre-o ao seu pipeline de CI/CD.
Você não precisa publicar seu SBOM. As autoridades de fiscalização de mercado podem solicitá-lo, e você precisa conseguir fornecê-lo rapidamente. Mantenha-o no seu arquivo de documentação técnica.
Para dispositivos que recebem atualizações OTA, o processo de SBOM precisa se manter atualizado. Cada release de firmware que adiciona ou atualiza um componente exige um SBOM atualizado antes de ser distribuído.
Passo 3: construa a segurança desde o início
A maioria das equipes de IoT tem mais terreno a cobrir aqui. O CRA exige segurança por design, não segurança acoplada na correria pouco antes de uma auditoria de marcação CE.
No momento do design:
- Sem senhas padrão. Os dispositivos precisam ser entregues exigindo que o usuário defina uma credencial única ou usando credenciais únicas de hardware geradas por dispositivo.
- Minimize a superfície de ataque. Limite as interfaces, serviços e portas expostas ao que o produto de fato precisa para funcionar.
- Modelagem de ameaças antes da ativação do hardware, não depois.
- Secure boot para verificar a integridade do firmware a partir da energização.
- Criptografe os dados em trânsito e em repouso quando o modelo de ameaças do produto justificar.
Durante o desenvolvimento:
- Secure Software Development Lifecycle (SSDL) com portões de segurança em code review, análise estática e varredura de dependências integrados ao CI/CD.
- Sem vulnerabilidades conhecidas de severidade crítica ou alta nos componentes no momento do release. O CRA exige que os produtos sejam colocados no mercado “sem vulnerabilidades exploráveis conhecidas”.
- Teste em relação ao seu próprio modelo de ameaças antes de distribuir.
Pós-mercado:
- As atualizações de segurança precisam ficar disponíveis aos usuários por pelo menos 5 anos a partir da colocação do produto no mercado, ou pelo período de uso esperado, se for maior.
- Uma vez lançada, uma atualização de segurança precisa permanecer disponível por pelo menos 10 anos a partir da data desse lançamento, ou pelo período de suporte restante.
- Mecanismos de atualização automática, ou notificação clara aos usuários quando houver atualizações disponíveis.
- Uma data de fim de suporte publicada, para que os usuários saibam quando os patches vão parar.
Passo 4: estabeleça o tratamento de vulnerabilidades e o relato de incidentes
Este é o prazo de setembro de 2026. A partir de 11 de setembro de 2026, os fabricantes precisam reportar à ENISA e ao CSIRT nacional competente em até 24 horas após descobrirem uma vulnerabilidade ativamente explorada em qualquer produto que esteja no mercado da UE.
O cronograma de relato:
| Gatilho | Prazo | O que enviar |
|---|---|---|
| Vulnerabilidade ativamente explorada descoberta | 24 horas | Aviso prévio à ENISA e ao CSIRT nacional |
| Incidente grave de cibersegurança que afete a segurança do produto | 24 horas | Notificação de aviso prévio |
| Após o aviso prévio | 72 horas | Notificação da vulnerabilidade com avaliação inicial de impacto |
| Quando a mitigação estiver disponível | 14 dias | Relatório completo: descrição, versões afetadas, passos de mitigação |
Isso cobre produtos legados. Se você distribuiu um gateway de IoT em 2019 e ele ainda está no mercado da UE em 11 de setembro de 2026, você é responsável por reportar as vulnerabilidades dele dentro desses prazos.
Os relatos vão para o banco de dados europeu de vulnerabilidades da ENISA e para o CSIRT nacional do estado membro (ou estados membros) onde o produto é vendido. Em geral, eles são encaminhados aos CSIRTs de todos os estados membros onde o produto é comercializado.
O que você precisa ter no lugar antes de setembro de 2026:
- Uma política de divulgação coordenada de vulnerabilidades (CVD), publicada e fácil de encontrar
- Um contato de segurança monitorado e um arquivo security.txt
- Fluxos internos de triagem com responsabilidades claras e caminhos de escalonamento
- SBOM e rastreamento de dependências para que você consiga responder “estamos afetados?” em horas, não em dias
- Uma relação de trabalho com o seu CSIRT nacional antes de precisar acioná-lo
Passo 5: prepare sua documentação técnica
Todo fabricante precisa manter um arquivo de documentação técnica. As autoridades de fiscalização de mercado podem solicitá-lo a qualquer momento. Os requisitos de conteúdo estão no Anexo VII do CRA.
Seu arquivo técnico precisa incluir:
- Descrição do produto: nome, versão, tipo, faixa de número de série
- Avaliação de risco: seu modelo de ameaças de cibersegurança e como suas escolhas de design o endereçam
- Arquitetura de segurança: como o produto atende aos requisitos essenciais
- SBOM
- Descrição do processo de desenvolvimento seguro: padrões de código, processo de revisão, metodologia de testes
- Procedimento de tratamento de vulnerabilidades
- Resultados de testes e verificação
- Referência à Declaração de Conformidade
Retenha a documentação por 10 anos após o produto sair do mercado. Atualize-a quando emitir atualizações de segurança.
Passo 6: faça a marcação CE do jeito certo
A marcação CE sob o CRA não é a mesma coisa que a marcação CE sob diretivas mais antigas. Você não pode autodeclarar conformidade e aplicar uma marca CE em um produto de Classe II.
Para produtos da categoria padrão: a autoavaliação é permitida. Conclua a avaliação de conformidade, produza uma Declaração de Conformidade e aplique a marca CE.
Para produtos importantes de Classe I: autocertifique-se em relação a uma norma harmonizada, ou use um organismo notificado.
Para produtos importantes de Classe II e produtos críticos: na maioria dos casos, é exigida a avaliação por um organismo notificado.
Sua Declaração de Conformidade precisa incluir:
- Identificação do produto (nome, tipo, lote, número de série)
- Nome e endereço do fabricante
- Declaração de conformidade com o Regulamento (UE) 2024/2847
- Nome e número do organismo notificado, se aplicável
- Dados do signatário autorizado
A marca CE precisa aparecer no produto, em sua embalagem ou na documentação que o acompanha, caso o produto seja pequeno demais para portá-la.
O que mais derruba as equipes
Tratar como um checkbox de uma vez só. O CRA exige processos contínuos. Monitoramento de vulnerabilidades, atualizações de SBOM e relato de incidentes acontecem de forma contínua enquanto o seu produto estiver no mercado.
Ignorar produtos já distribuídos. Se ainda estiver à venda na UE em 11 de setembro de 2026, está no escopo do relato de vulnerabilidades. Isso inclui produtos de 2019.
Subestimar o escopo do SBOM. Uma imagem de firmware típica contém dezenas ou centenas de componentes. O inventário manual não escala. Automatize a geração de SBOM no seu pipeline de build desde o início.
Ignorar as obrigações da cadeia de suprimentos. Componentes de terceiros carregam um risco que recai sobre você como fabricante. Seus contratos com fornecedores precisam de obrigações de SBOM e termos de divulgação de vulnerabilidades. Uma vulnerabilidade em uma biblioteca que o seu fornecedor de chips distribui ainda é responsabilidade sua de relatar.
Presumir que as normas harmonizadas vão chegar a tempo. A padronização do CEN/CENELEC para o CRA está em andamento. Para produtos que exigem avaliação de terceiros, as normas ainda podem estar incompletas quando você precisar certificar. Envolva um organismo notificado cedo para combinar quais evidências eles vão aceitar no intervalo.
Uma observação sobre a sua plataforma de IoT
Uma pergunta que aparece com frequência: a plataforma de nuvem à qual o seu dispositivo se conecta afeta a sua conformidade com o CRA?
Se você usa uma plataforma de IoT de propósito geral que não foi desenvolvida por você ou em seu nome, ela não cai diretamente sob o CRA. SaaS e PaaS puros estão excluídos da regulamentação. O que importa para o seu arquivo técnico do CRA é documentar a plataforma como parte da sua cadeia de suprimentos, entender os controles de segurança que ela aplica e ter evidências que você possa apresentar às autoridades de fiscalização de mercado.
Ao avaliar plataformas, procure por criptografia documentada em repouso e em trânsito, controles de acesso, registro de auditoria, processos publicados de divulgação de vulnerabilidades e validação de segurança por terceiros. A certificação ISO/IEC 27001, pontuações de segurança independentes e um portal de segurança publicado com documentação disponível são as coisas a pedir. Plataformas que não conseguem produzir essas evidências rapidamente vão atrasar o seu processo de documentação do CRA.
A TagoIO mantém certificação ISO/IEC 27001, conformidade com o GDPR e um Security Portal público em security.tago.io com relatórios de auditoria, autoavaliações de segurança e documentação completa disponível mediante solicitação. Se você usa a TagoIO como parte do pipeline de dados do seu dispositivo, a documentação de segurança que você precisa para a avaliação da sua cadeia de suprimentos está lá.
Cronograma
| Data | Marco |
|---|---|
| 10 de dezembro de 2024 | CRA entrou em vigor |
| 1 de agosto de 2025 | Requisitos de cibersegurança da RED passam a valer para equipamentos de rádio conectados à internet |
| 11 de junho de 2026 | As notificações dos organismos de avaliação de conformidade precisam estar em vigor |
| 11 de setembro de 2026 | Começam as obrigações de relato de vulnerabilidades e incidentes |
| 11 de dezembro de 2027 | Todos os requisitos do CRA totalmente aplicáveis |
Recursos
- Regulamento (UE) 2024/2847: o texto do CRA. Comece pelo Anexo I (requisitos de segurança), Anexo III/IV (categorias de produtos), Anexo VII (documentação técnica).
- Orientações da ENISA sobre o CRA: enisa.europa.eu
- IoT Security Foundation: recursos de conformidade e mapeamento das normas da ENISA em iotsecurityfoundation.org
- ETSI EN 303 645: a norma de segurança de IoT de consumo já existente, fortemente alinhada com os requisitos do Anexo I do CRA
- Orientações da Comissão Europeia sobre o CRA: publicadas para feedback em março de 2026, cobrem a interpretação do escopo e o apoio a PMEs
Este artigo reflete o estado do CRA em abril de 2026. Atos de execução e normas harmonizadas ainda estão sendo finalizados. Consulte as páginas de estratégia digital da Comissão Europeia para atualizações. O Regulamento (UE) 2024/2847 é a fonte oficial.
