RED, EN 18031 e Guia de Preparação da CRA: Respostas Práticas do QIMA Webinar

A parte mais útil do webinar da QIMA, Navegar pela conformidade de segurança virtual da UE com os Produtos Conectados, foi a Q&A.

Fabricantes perguntaram sobre padrões, escopo, variantes de produto, relatório de CRA, períodos de suporte, e documentação. Estas são as questões que surgem quando o RED cibernético e CRA começam a afetar produtos reais, prazos de lançamento e arquivos técnicos.

Este artigo transforma essas questões em orientações práticas para as equipes de produtos, engenharia, conformidade, qualidade e certificação.

QIMA construído Cyberexpert para o trabalho de prontidão descrito neste artigo: escopo, mapeamento de requisitos, preparação de evidências, E. suporte nfo e revisão de especialistas antes de um produto chegar a uma avaliação formal. O artigo explica pela primeira vez as decisões que os fabricantes precisam tomar.

Trata-se de um recapitulação educacional e não de aconselhamento jurídico. Os fabricantes devem verificar as obrigações específicas dos produtos contra o texto jurídico oficial, normas harmonizadas e a rota de avaliação de conformidade escolhida.

A lição principal: não comece com o padrão

Um erro comum é perguntar primeiro: qual padrão devemos usar?

É demasiado tarde na lógica.

A melhor primeira pergunta é: O que esse produto precisa provar?

A resposta depende da borda do produto, uso intencional, conectividade, tratamento de dados, assets, interfaces, funcionalidade central e se RED, CRA, ou ambos se aplicam.

Os requisitos cibernéticos do RED vêm da Diretiva de Equipamentos de Rádio e seus requisitos essenciais relacionados à cibersegurança sob Artigo 3(3)(d), (e), e (f), cobrindo proteção de rede, dados pessoais e privacidade, e proteção contra fraude. O Regulamento Delegado (UE) 2022/30 ativa esses requisitos para classes específicas de equipamentos de rádio, e a Decisão de Implementação (UE) 2025/138 trata das normas harmonizadas que apoiam esses requisitos de cibersegurança do RED.

CRA é mais larga. aplica-se a produtos com elementos digitais colocados no mercado da UE quando o seu propósito ou uso razoavelmente previsível inclui uma conexão de dados lógicos ou físicos direta ou indirectos a um dispositivo ou rede. Cria também obrigações de fabricante ao longo da concepção, desenvolvimento, produção, manutenção, documentação técnica, avaliação de conformidade, períodos de suporte e manipulação de vulnerabilidades.

Isso significa que o primeiro entregável deve ser um mapa de conformidade específico do produto.

1. A EN 18031 será substituída por EN 40000?

Pergunta do webinar: A norma EN 18031 será substituída pela EN 40000?

Resposta curta: Não necessariamente.

Gergely Bakos explicado na Q&A que EN 18031 e a EN 40000 série têm um escopo e cobertura diferentes. A EN 18031 é central para a conformidade com a segurança virtual RED. A EN 40000 traz outras áreas, incluindo a manipulação de vulnerabilidade, o que é importante para a prontidão em CRA.

Por conseguinte, os fabricantes não devem partir do princípio de que uma norma substitui simplesmente a outra.

Para um produto de rádio no escopo de cyber VERMELHO, EN 18031 ainda pode ser o caminho central para RED. Mas as obrigações CRA podem exigir trabalho adicional, especialmente em relação ao tratamento de vulnerabilidades, relatórios e atualizações de segurança e planejamento do período de suporte.

Prática tirada: seleção padrão deve seguir a análise do produto.

Um fabricante deve ser capaz de explicar:

• porque EN 18031 se aplica, ou não se aplica

• se a orientação EN 40000 é necessária para o trabalho adicional de CRA

• onde a manipulação de vulnerabilidade é coberta

• onde o envolvimento de um Corpo Notificado pode ser necessário

• que evidência apoia cada decisão

Se a resposta é apenas "utilizamos EN 18031", a seleção padrão não está documentada suficientemente bem.

2. Scoping RED é onde os fabricantes podem atrasar mais cedo

A seção de escopo de Ceredric Le├vy-Bencheton foi uma das partes mais práticas do webinar. O ponto dele foi claro: escopo cibernético VERMELHO nem sempre é óbvio.

Um produto pode levantar questões sobre o RED cibernético quando possui uma interface sem fio e conectividade habilitada para Internet, mesmo que a conexão habilitada para Internet não seja sem fio.

Exemplo 1:

Um dispositivo tem Bluetooth para instalação e Ethernet para comunicação de rede. O Bluetooth pode ser local, mas a conexão Ethernet ainda pode ser importante para o escopo cibernético RED.

Exemplo 2:

Um produto usa o Zigbee e se conecta através de um aplicativo de gateway ou móvel. Chamá-lo de "rádio local" não é suficiente. Se o aplicativo ou gateway pode controlar o produto remotamente, a conectividade indireta precisa ser revisada.

Aviso útil: o processamento de dados pessoais não significa que haja um efeito de privacidade em todos os casos. Um microfone sem fio ou amplificador pode processar o áudio, mas não armazená-lo. A análise de privacidade ainda depende de o que o produto faz com os dados.

Teste prático de escopo

Antes de decidir o âmbito, os fabricantes devem responder a quatro questões:

1. O produto tem alguma interface do rádio?

2. O produto tem conectividade direta ou indireta habilitada na Internet?

3. Pode outro sistema, app, gateway ou serviço de nuvem controlar o produto?

4. O processo do produto, armazenar, transmitir ou expor dados relevantes à proteção de rede, privacidade ou proteção de fraude?

Um arquivo de escopo útil deve incluir um diagrama de conectividade. Ele deve mostrar interfaces sem fio, interfaces Wi-Fi, apps móveis, gateways, nuvem ou processamento remoto, canais de atualização e serviço ou interfaces de depuração.

Isto não tem de ser complicado, tem de ser rigoroso.

3. Avaliação de risco RED e avaliação de risco de segurança virtual são documentos diferentes

Pergunta do webinar: A norma EN 18031 não fornece uma metodologia de avaliação de risco. A EN 40000 preenche essa lacuna?

Resposta curta: parcialmente, mas não completamente.

Ce➲ dric explicou que EN 18031 inclui árvores de decisão e menciona ESTRIDE, mas não dá aos fabricantes um método completo de modelagem da ameaça ou de avaliação do risco da cibersegurança. A EN 40000-1-2 foi discutida como orientação para as etapas de gestão de riscos, mas não como um método pronto que pode ser copiado em todos os arquivos do produto.

A distinção é importante.

Uma avaliação de risco cibernético VERMELHA ajuda a determinar quais requisitos legais RED se aplicam.

A avaliação de risco de segurança virtual analisa o risco real do produto: usuários, dados, interfaces, contexto de uso, cenários de ataque, impacto, controles e risco residual.

O exemplo da câmera de Ceric torna esta simples câmera. A mesma câmera conectada pode transportar riscos diferentes em um quarto, um jardim ou um estacionamento. O hardware pode ser similar. O contexto não.

Uma entrada de risco fraca diz:

★O risco é baixo.

Uma entrada de risco útil diz:

✓ A interface de serviço Ethernet é usada apenas durante a instalação e manutenção em um ambiente físico controlado. Não é exposto durante a operação normal do usuário. Esta suposição é suportada pelo procedimento de serviço, configuração de interface e documentação de instalação. Com base neste contexto de uso, o controle de acesso é tratado como não aplicável para este ativo e interface.

Esse tipo de entrada ajuda a engenharia, conformidade e avaliadores a entender a decisão.

4. A EN 18031 é difícil porque é baseada em ativos

EN 18031 não é uma lista plana. Ele pede aos fabricantes que pensem em termos de ativos, interfaces, entidades, mecanismos de segurança, categorias de implementação e árvores de decisão.

Ativos podem incluir parâmetros confidenciais, parâmetros sensíveis, funções, parâmetros de dados, ativos de segurança, ativos de rede, ativos de privacidade e ativos financeiros.

Isto se torna rapidamente um produto específico.

Uma função de atualização segura, por exemplo, pode incluir recuperar a atualização, verificá-la, instalando-a, revertendo após falha e registrando o resultado. Um fabricante pode decidir agrupá-los como uma única função de atualização segura. Isso pode ser razoável, mas o agrupamento não deve ocultar os pormenores que devem ser objecto de avaliação.

Um registo prático de activos deve capturar apenas os campos que são importantes:

Se o registro de ativos for fraco, E.Info, E.Just, e as respostas das árvore de decisão também serão fracas.

5. Árvores de decisão precisam de provas, não de adivinhos.

Árvores de decisão são centrais para EN 18031. Os fabricantes as usam para decidir se um requisito se aplica. Avaliadores os usam para determinar se o resultado é PASS, FALHAou NÃO APLICÁVEL.

Isso significa que um caminho de árvore de decisão deve ser documentado como um registro de decisão.

Um registro de decisão deve responder:

• qual exigência foi avaliada

• que ativos e interface estavam envolvidos

• qual caminho foi seguido

• por que o resultado é PASS, FALHA ou NÃO APLICÁVEL

• que prova apoia o resultado

• se esta decisão afeta outros requisitos

Exemplo: Ethernet e comunicação segura

Cerec explicou que a rede Ethernet pode ser difícil porque normalmente não é criptografada e não tem um controle inerente ao acesso. Se o controle de acesso se aplicar a essa interface Ethernet, os requisitos de comunicação seguros podem seguir.

Uma justificação fraca seria a seguinte:

A Ethernet é usada apenas pelos técnicos.

Uma justificação mais forte diria:

✓ A interface Ethernet é apenas acessível durante a instalação e manutenção em um ambiente físico controlado. Não é exposta aos usuários finais durante a operação normal. As condições de acesso são descritas na documentação do usuário e de serviço. A interface é desativada ou restringida fora das condições de serviço. Com base nesse contexto de uso, o caminho da árvore de decisão de controle de acesso leva a NÃO APLICÁVEL para este recurso e interface. Evidências de apoio são fornecidas no procedimento de serviço, configuração de interface e documentação de arquitetura do produto.

É essa a diferença entre uma assunção e provas prontas para a avaliação.

6. Informações e E. Just deve explicar claramente o produto

A documentação EN 18031 não é apenas uma pasta de documentos do produto.

Precisa de explicar o que é implementado, por que razão é relevante, qual o activo que protege, que caminho de decisão foi seguido e onde é que as provas podem ser verificadas.

Ce├dric destacou que E.Info e E.Just são utilizados durante a avaliação, portanto eles precisam de entradas de engenharia, desenvolvimento, firmware, produto e partes interessadas em conformidade.

Resposta fraca:

(ES) O produto usa criptografia.

Resposta mais forte:

✓ O produto utiliza TLS 1.3 para comunicação entre o dispositivo e o serviço em nuvem. Isso protege os dados de configuração transmitidos e as informações de status do dispositivo contra divulgação e modificação não autorizadas. O mecanismo se aplica à interface de rede usada para comunicação em nuvem. A implementação é descrita na arquitetura de comunicação e verificada no relatório de teste de segurança. O manuseio de certificados é descrito na seção de gerenciamento de chaves. Referências de evidência: diagrama de arquitetura A-03, relatório de teste T-12, extrato de configuração de firmware F-07.

A resposta mais forte é melhor porque diz ao avaliador o que é protegido, como é protegido, por que é importante e onde verificá-lo.

7. As variantes de produtos podem reutilizar o trabalho, mas apenas com uma lógica

Pergunta do webinar: Se os dispositivos tiverem a mesma funcionalidade, mas formatos diferentes, precisam de verificações de conformidade separadas?

Resposta curta: você pode não precisar começar do zero, mas precisa avaliar as diferenças.

Os fabricantes devem começar com a funcionalidade central do produto. Se as variantes compartilharem a mesma função de núcleo, alguns trabalhos podem ser reutilizáveis. Mas as diferenças de factor de formulário ainda podem afetar os requisitos de segurança virtual ou a conformidade com a CRA.

Por exemplo, uma carta e um anel podem compartilhar a funcionalidade do firmware e do núcleo. Mas eles podem diferir na exposição física, comportamento de antena, restrições de bateria, processo de atualização, probabilidade de perda, interação do usuário ou contexto de privacidade.

Uma mesa curta de reutilização é suficiente:

O objectivo é evitar o trabalho repetido sem copiar provas que não se enquadrem no produto.

8. O relatório CRA começa antes da aplicação completa do CRA

Pergunta do webinar: Qual é a diferença prática entre setembro de 2026 e dezembro de 2027 sob CRA?

Resposta curta: Setembro de 2026 é sobre relatórios. Dezembro de 2027 é sobre aplicação completa.

A partir de 11 de Setembro de 2026, os fabricantes têm de relatar vulnerabilidades exploradas e incidentes graves que afectam a segurança dos produtos com elementos digitais. A Comissão Europeia explica que a comunicação inclui um aviso prévio no prazo de 24 horas, uma notificação completa dentro de 72 horas e relatórios finais dentro do prazo de 14 dias ou um mês aplicável. Os relatórios são elaborados uma vez através da Plataforma Única de Relatório da CRA, que a ENISA é encarregada de estabelecer.

As principais disposições das ANC aplicam-se a partir de 11 de Dezembro de 2027, ao passo que as obrigações de comunicação se aplicam a partir de 11 de Setembro de 2026. O resumo da Comissão afirma também que as obrigações de comunicação se aplicam a todos os produtos com elementos digitais disponíveis no mercado da UE. incluindo produtos já colocados no mercado antes de 11 de Dezembro de 2027.

A questão prática de Pajerich era que os relatórios não podem funcionar sem manipulação de vulnerabilidades. Um fabricante não pode relatar o que não pode detectar, receber, classificar, e escalar.

Processo mínimo antes de 2026 de setembro

Antes do início da obrigação de comunicação, os fabricantes devem ter:

1. Um formulário público de vulnerabilidade reportando contato ou web

2. Um proprietário interno para relatórios de roteamento.

3. Uma maneira de identificar produtos afetados, versões e componentes.

4. Um processo de avaliação da gravidade e da exploração.

5. Um caminho de decisão para reportabilidade.

6. Um processo para a comunicação do usuário.

7. Um modelo de registro de incidente.

Trata-se de um mínimo prático, que não precisa de ser perfeito, mas que tem de ser utilizável.

9. Várias fábricas precisam de uma palestra de decisãoh

Pergunta da webinar: Quem relata incidentes se uma empresa tem várias fábricas sob o mesmo quadro?

Nem toda fábrica deve relatar separadamente. Fábricas ou sites devem ter rotas de relatório internas. Uma função central do fabricante deve avaliar se o caso deve ser relatado através da Plataforma de Relatório Único. Se o fabricante estiver fora da UE, o representante autorizado, importador ou distribuidor pode estar envolvido, dependendo do caso.

Um teste útil é um exercício de topo.

Cenário:

Um fornecedor relata uma vulnerabilidade em um módulo de comunicação usado em três produtos. Um produto já está no mercado da UE. Um deles é a produção, um deles ainda está em desenvolvimento. A exploração activa é pouco clara. Um patch já existe, mas não foi testado em cada produto.

O fabricante deve ser capaz de responder dentro da linha do tempo reportado:

• quais produtos e versões são afetados

• se a vulnerabilidade é ativamente explorada

• se os usuários precisam de orientação de mitigação

• se a denúncia é necessária

• quem aprova a denúncia

• onde a evidência é armazenada

Se isso não puder ser feito em um teste, o processo não está pronto.

10. O planejamento do período de suporte afeta a engenharia, não apenas o cumprimento

Pergunta do webinar: Como os fabricantes devem decidir o período de suporte de segurança correto?

Gergely explicou que cinco anos é o padrão de partida, mas o tempo de vida pretendido para o produto importa. Os produtos industriais ou de TOT de longa duração podem necessitar de um planeamento mais longo.

O texto jurídico da LFC exige que os fabricantes determinem um período de apoio que reflicta o tempo previsto para a utilização do produto. Afirma ainda que o período de apoio será de, pelo menos, cinco anos. a não ser que se espere que o produto seja utilizado por menos de cinco anos. O texto oficial do EUR-Lex também refere a exigência de que as atualizações de segurança permaneçam disponíveis durante um mínimo de 10 anos ou para o restante período de apoio.

Isto afeta o planejamento de produtos.

Antes do lançamento, os fabricantes devem saber:

• como as atualizações serão enviadas

• quem mantém correções de segurança

• quais compromissos do fornecedor são necessários

• como vulnerabilidades de componentes de terceiros serão monitoradas

• como o fim do suporte será comunicado

• por quanto tempo as atualizações de segurança emitidas permanecerão disponíveis

Para produtos de longa duração, esta decisão deve envolver produtos, engenharia, apoio, proprietários legais e comerciais.

Onde o Cyberexpert se encaixa

A parte difícil não é ler a regulamentação. A parte mais difícil é coletar informações do produto, requisitos de mapeamento, escrita utilizável E. nfo e E.Just, relatar provas a reclamações e saber quando é necessária uma revisão por peritos.

Esse é o trabalho de preparação que Cyberexpert está construído para apoiar.

Cyberexpert ajuda os fabricantes a estruturar informações sobre os produtos, identificar requisitos aplicáveis, mapear expectativas E.Info, preparar provas, envolver fornecedores e preparar para auto avaliação, análise especializada ou avaliação do laboratório.

Se você está se preparando para o RED cibernético agora, ou relatório CRA a seguir, use o Cyberexpert para verificar o que se aplica ao seu produto, identificar lacunas de documentação e preparar suas evidências antes da avaliação formal.

Um plano de preparação de 30 dias

Semana 1: Escopo do produto

Crie um limite de produto, mapa de conectividade, mapa de dados, lista de interfaces, descrição intencional, nota de escopo RED e nota de escopo CRA.

Resultado: a equipe sabe que produto está sendo avaliado e por que pode estar no escopo.

Semana 2: Construa a base EN 18031

Criar o registrador de ativos, lista de entidades, mapa da interface, mapeamento inicial do mecanismo de segurança e suposições da árvore de decisão que precisam de provas.

Resultado: a equipe pode ver onde EN 18031 trabalho está claro e onde a informação do produto está faltando.

Semana 3: Verificar lacunas de evidência

Analise E.Info, E.Just, SBOM, HBOM, manual de usuário, documentação de configuração, serviços expostos, processo de atualização, log, provas de teste e diagramas de arquitetura.

Resultado: a equipa sabe que provas existem e o que ainda precisa de ser trabalhado.

Semana 4: Prepare a prontidão de vulnerabilidade CRA

Configure o contato de relatório de vulnerabilidade, o projeto de política CVD, processo de tomada de decisões, inventário de componentes, método de avaliação de gravidade, relatório de proprietário, processo de notificação de usuário e modelo de registro de incidente

Resultado: o fabricante tem um processo básico antes do início da obrigação de relatório da CRA.

O que é importante lembrar

As perguntas de webinar apontam para uma conclusão prática:

Os fabricantes precisam mover a conformidade com a segurança virtual antes do desenvolvimento de produtos.

A cibernética RED pode afetar o acesso ao mercado agora. Os relatórios CRA começam antes da aplicação completa da CRA. A EN 18031 requer provas específicas do produto, não reivindicações genéricas. A EN 40000 pode ajudar com áreas adicionais, mas não remove a necessidade de compreender o produto primeiro.

Antes da próxima reunião de planeamento do RED ou do SIR, os fabricantes deverão poder responder:

• O produto está no escopo da cibernética RED?

• O produto está no escopo da CR?

• Quais são os limites do produto?

• Qual é a funcionalidade principal do produto?

• Quais interfaces e caminhos de conectividade existem?

• Quais os activos que precisam de protecção?

• Quais caminhos de árvore de decisão EN 18031 foram seguidos?

• Os resultados PASS, FALHA e NÃO O APLICÁVEL podem ser justificados?

• Existem E.Info e E.just validados pela engenharia?

• Existe algum SBOM ou inventário de componentes?

• Existe alguma vulnerabilidade pública reportando contato?

• Quem possui relatórios de CRA internamente?

• Qual é o período de apoio?

• Que provas podem ser reutilizadas entre as variantes de produtos?

• O produto está pronto para a auto-avaliação, avaliação de especialistas ou avaliação de laboratório?

Se várias respostas estiverem obscuras, o produto ainda está na fase de prontidão.

Este é o momento certo para corrigir as lacunas antes de afectarem a avaliação, a certificação ou o acesso ao mercado.

Para colocar essas etapas em prática, baixe abaixo a lista de verificação prática e use-a para revisar sua cibernética RED e aptidão para a CRA.