1. Delimitar o produto e o operador responsável
Um consultor CRA deve esclarecer o âmbito do produto, o papel jurídico e a via de avaliação da conformidade antes de encomendar ensaios ou preparar declarações. O resultado útil é uma decisão fundamentada por família de produtos, não uma oferta genérica de certificação.
O Regulamento (UE) 2024/2847 já vigora. A comunicação pelos fabricantes de vulnerabilidades exploradas ativamente e incidentes graves é obrigatória desde 11 de setembro de 2026; a maioria das restantes obrigações aplica-se a partir de 11 de dezembro de 2027. São fases distintas.
1. Delimitar o produto e o operador responsável
Determine o que é efetivamente disponibilizado no mercado da UE e por quem. Designações como «plataforma» ou «IoT» não decidem o âmbito do CRA.
- Inventarie produtos físicos e software, componentes vendidos separadamente, versões, finalidade prevista, interfaces e tratamento remoto de dados necessário às funções.
- Identifique fabricante, titular da marca, importador e distribuidor; examine desenvolvimento contratado e alterações substanciais sem atribuir automaticamente tudo à fábrica.
- Verifique atividade comercial, exclusões e legislação setorial da UE; no código aberto importa o modelo real de disponibilização, não apenas a licença.
2. Matriz das vias: categoria não é intensidade dos ensaios
Compare a função principal com os anexos III (importantes) e IV (críticos), incluindo descrições técnicas da Comissão, antes de escolher o procedimento do artigo 32.º.
| Categoria do produto | Via estratégica de avaliação |
|---|---|
| Categoria geral | É possível o controlo interno do módulo A; laboratório externo não é automaticamente obrigatório. |
| Importante, classe I | O módulo A pode aplicar-se quando estejam integralmente cumpridas as condições pertinentes relativas a normas harmonizadas, especificações comuns ou certificação elegível; caso contrário, é necessário B+C ou H com organismo notificado, salvo se for aplicável a derrogação específica do artigo 32.º, n.º 5, para software livre e de código aberto. |
| Importante, classe II | Preveja B+C ou H com organismo notificado, ou um sistema europeu de certificação de cibersegurança expressamente aplicável e legalmente disponível; verifique ainda a derrogação do artigo 32.º, n.º 5, para software livre e de código aberto. |
| Crítico (anexo IV) | Considere a participação de organismo notificado como regra de partida; verifique o artigo 32.º e eventuais alternativas de certificação legalmente disponíveis. |
Exceção para os produtos que se qualifiquem como software livre e de código aberto: nos termos do artigo 32.º, n.º 5, os fabricantes de produtos do anexo III podem utilizar um procedimento previsto no n.º 1, incluindo o módulo A, desde que a documentação técnica prevista no artigo 31.º esteja publicamente disponível aquando da colocação no mercado. Não se trata de uma isenção geral do CRA.
Na classe I, citar um projeto de norma ou ensaiar uma cláusula não comprova acesso ao módulo A. Registe categoria precisa, fundamento técnico e pressupostos pendentes.
3. Factos que podem alterar a recomendação
A via resulta da classificação, não do nome comercial nem de uma marcação CE já existente.
- Função essencial de segurança: uma função de firewall pode prevalecer sobre o nome do equipamento; a integração de um componente não reclassifica automaticamente o produto final.
- Modelo de disponibilização: componente vendido isoladamente, firmware, dependência da nuvem, código aberto não comercial e alteração substancial posterior exigem avaliações distintas.
- Estado das normas: distinga normas harmonizadas publicadas com cobertura adequada de projetos, normas voluntárias e provas insuficientes para a condição jurídica da via.
4. Análise de lacunas: associar cada falha a uma decisão
Compare os requisitos aplicáveis do anexo I com controlos existentes e provas utilizáveis. Um processo inexistente difere de um documento em falta.
| Lacuna ou fator | Prova e decisão |
|---|---|
| Classificação indefinida | Suspender a escolha da via; obter primeiro arquitetura, utilização prevista e análise da categoria nos anexos. |
| Risco de conceção segura | Relacionar modelo de ameaças, definições seguras por defeito, controlo de acesso e ensaios com a avaliação de risco do produto. |
| Gestão de vulnerabilidades não demonstrada | Verificar responsabilidade de comunicação, receção de alertas, divulgação coordenada, correções, atualizações e justificação do período de suporte. |
| Cadeia de provas fraca | Conciliar lista de componentes/SBOM, documentação de fornecedores, âmbito dos testes, versões e dossier técnico; determinar o que renovar. |
Priorize lacunas que alteram a via jurídica ou impedem controlos de risco. Registe separadamente lacuna, responsável, prova, decisão e incerteza residual.
5. Reutilizar provas sem herdar conclusões não demonstradas
Testes de intrusão, materiais ISO/IEC 27001, relatórios de fornecedores e documentação CE podem evitar repetição, mas não comprovam isoladamente conformidade com o CRA.
- Reutilize relatórios apenas para produto/versão, risco, requisito e método comparáveis; identifique cobertura desatualizada e novos testes necessários.
- Associe componentes externos e dependências de software à avaliação do próprio fabricante; certificados do fornecedor não transferem automaticamente responsabilidades legais.
- Alinhe avaliação de riscos, documentação técnica e processos de vulnerabilidades com a via selecionada.
6. Ordenar decisões antes da execução
A consultoria estratégica deve deixar um plano verificável, não prometer aprovação automática.
- Criar registo por produto do âmbito, papéis e exclusões; assinalar questões de classificação.
- Preparar parecer escrito da via com referências aos anexos, estado das normas e procedimento, incluindo necessidade de organismo notificado.
- Priorizar lacunas do anexo I, documentação e processos de suporte; atribuir equipas e regras de reutilização de provas.
- Ativar separadamente o mecanismo de comunicação obrigatório desde 11 de setembro de 2026; planear a conformidade para 11 de dezembro de 2027 revendo transições e alterações por produto.
7. Onde termina a consultoria e começa a implementação
Esta página trata da escolha prévia da via. Implementação, coordenação de ensaios e dossier técnico pertencem a outro serviço; o orçamento exige análise autónoma dos fatores de custo. Antes de contratar, peça uma classificação fundamentada e pressupostos em aberto.
Fontes oficiais primárias
Perguntas frequentes
Um backend SaaS para a UE fica automaticamente abrangido?
Não. Determine se o tratamento remoto integra o produto com elementos digitais e é necessário às funções; um serviço autónomo não equivale automaticamente a equipamento. Analise arquitetura e contratos.
A classe I permite sempre autoavaliação?
Não. Verifique as condições do artigo 32.º, n.º 2, relativas a normas harmonizadas, especificações comuns ou certificação aplicável. Se não estiverem preenchidas, é necessário um procedimento com organismo notificado, salvo se for aplicável a derrogação específica do artigo 32.º, n.º 5, para software livre e de código aberto.
O código aberto exclui o produto final?
Não. Contam a colocação comercial do produto e o papel da organização. A atividade não comercial ligada ao software livre e de código aberto e as entidades que apoiam de forma continuada o seu desenvolvimento exigem análise separada.
E quanto a dispositivos já vendidos na UE?
A comunicação dos fabricantes é obrigatória desde 11 de setembro de 2026, incluindo produtos abrangidos já disponíveis. Para 2027, examine primeira colocação no mercado, alterações substanciais posteriores e regime transitório.
Um teste de intrusão ou certificado ISO substitui a avaliação CRA?
Não. Reutilize provas relevantes, mas documente em separado âmbito, riscos, condições da via, conformidade e obrigações do ciclo de vida.