Atualizado em 15 de setembro de 2026: as obrigações de notificação do Cyber Resilience Act (CRA) para fabricantes aplicam-se desde 11 de setembro de 2026. Um fornecedor de microinversores Wi-Fi para a UE precisa agora de um processo operacional, não apenas de um plano para os requisitos gerais aplicáveis em 11 de dezembro de 2027.
Uma vulnerabilidade ativamente explorada ou incidente grave pode começar na nuvem, gateway, aplicativo, biblioteca ou firmware. Sem produto, cadeia de suporte e decisor mapeados, as primeiras 24 horas serão gastas procurando registros. Este checklist apoia diligência B2B e não substitui classificação jurídica, autoridade ou avaliação de conformidade.
Confirme o limite do produto e o operador econômico
O CRA cobre amplamente hardware e software oferecidos na União cujo uso previsto ou razoavelmente previsível inclua conexão direta ou indireta de dados com dispositivo ou rede. Congele modelo, hardware, firmware, rádio/gateway, app, portais, APIs, processamento remoto necessário, serviços de atualização, dono da marca, fabricante, importador UE, distribuidores e fornecedores de software.
Um microinversor sem rádio não fica necessariamente fora quando gateway, nuvem ou atualização obrigatórios integram a oferta. Também não classifique cada acessório como produto CRA separado sem documentar comercialização e função.
Importador ou distribuidor pode ser considerado fabricante ao vender sob seu nome ou marca ou realizar modificação substancial de cibersegurança. Em marca própria, defina autoridade de firmware, nuvem e responsabilidades antes da aprovação.
Separe a notificação de 2026 dos requisitos de 2027
| Marco | Data | Significado para compras |
|---|---|---|
| Notificação de organismos | 11 junho 2026 | Planejamento de capacidade de avaliação |
| Notificação do fabricante | 11 setembro 2026 | Relato de vulnerabilidades ativas e incidentes graves |
| Obrigações gerais CRA | 11 dezembro 2027 | Produto, processo, documentação e conformidade em geral |
A Comissão informa que a obrigação de 2026 alcança produtos já disponibilizados antes de dezembro de 2027. Não adie a preparação para a próxima geração.
Organize os prazos de 24, 72 horas e encerramento
Fabricantes notificam pela Single Reporting Platform (SRP) da ENISA.
| Gatilho | Alerta | Notificação | Relatório final |
|---|---|---|---|
| Vulnerabilidade ativamente explorada | 24 h do conhecimento | 72 h | Até 14 dias após correção ou mitigação disponível |
| Incidente grave que afeta segurança | 24 h | 72 h | Um mês após a notificação de 72 h |
“Conhecimento” não espera reunião gerencial. Defina quem recebe alertas, avalia limiar, envia ao SRP e comunica usuários e parceiros. Cadastre representantes e backups antes do incidente e teste internamente sem criar notificação falsa.
Mantenha um registro por produto afetado
Ligue marca, modelos, séries/lotes e mercados às versões de hardware, firmware, gateway, app, nuvem e bibliotecas. Registre descoberta e conhecimento em UTC, decisão, evidência, impacto, mitigação, update, rollback, validação, IDs do SRP, comunicações, causa e mudanças no arquivo técnico. Marque hipóteses: um ticket pode ter escopo menor que a telemetria.
Alinhe o contrato ao relógio regulatório
O fabricante não cumpre 24 horas se OEM, nuvem ou componente escalam em vários dias. Contrate prazos menores e contatos permanentes.
| Evidência | Pergunta RFQ | Resposta fraca |
|---|---|---|
| Contato de segurança | Quem atende fora do horário comercial? | “Seu gerente de conta” |
| Vulnerabilidades | Como fazem triagem, reprodução e escalada? | Política sem responsável |
| Componentes | Quais versões há em cada release? | BOM sem versão |
| Atualização | Como controlam autenticidade, rollout e recovery? | Update remoto sem registros |
| Incidente | Quais dados chegam no prazo? | Apoio conforme disponibilidade |
| Base instalada | Quais clientes/lotes exigem ação? | Apenas total embarcado |
Defina retenção de logs, acesso legal à telemetria, troca confidencial e aprovação de correções para perfis de rede afetados.
Prepare o arquivo técnico de 2027
Inclua risco e arquitetura, requisitos com testes, inventário versionado, decisões de vulnerabilidade, configuração segura, autenticidade de updates, instalação automática, recuperação/rollback, divulgação, fim do suporte por mês e ano, informação ao usuário, desativação e documentos de conformidade.
O suporte deve refletir uso esperado, expectativas razoáveis e natureza do produto; não copie automaticamente a garantia. Para equipamento de telhado de longa vida, questione suporte cibernético curto.
O CRA exige SBOM em formato comum legível por máquina, ao menos para dependências de nível superior, mas não publicação geral a todos os usuários. Defina manutenção, vínculo com releases e acesso controlado do importador.
Separe CRA, RED e segurança operacional
| Rota | Finalidade | Controle do comprador |
|---|---|---|
| CRA | Segurança horizontal e vulnerabilidades | Limite, ciclo, relato e papéis |
| RED / EN 18031 | Rádio e conformidade | Configuração, normas, relatórios, declaração |
| GDPR | Tratamento legal de dados | Papéis, avisos, retenção, acesso |
| Código de rede | Conexão e comportamento | Modelo, firmware/perfil, operadora |
| SLA cloud | Disponibilidade e suporte | Resposta, recovery, propriedade, saída |
O checklist RED EN 18031 cobre rádio; o guia de firmware, releases e recuperação. Para UK use o checklist PSTI.
Aplique seis bloqueios: escopo, fornecedor, amostra, release, incidente e embarque. Em compras públicas revise também as cláusulas de cibersegurança para leilões UE.
Envie Estados-alvo, marca, modelos, conectividade, nuvem, suporte, volume e fluxo de incidentes pelo TMG Contact. A TMG pode estruturar a matriz; classificação, relato e conformidade permanecem com os responsáveis. Para marca própria revise a solução OEM.
