Navegando pela conformidade com a segurança cibernética da UE para produtos conectados: Respostas Especializadas para as suas perguntas RED e CRA
17 de jul. de 2026
Durante o nosso webinar, Navegar pela conformidade com a segurança virtual da UE para Produtos Conectados, Os participantes levantaram questões detalhadas sobre o Cyber Resilience Act (CRA), Requisitos de cibersegurança RED, classificação de produtos, avaliação de conformidade, relatórios de incidentes, sistemas em nuvem e períodos de suporte de segurança.
Respondemos várias perguntas durante a sessão ao vivo. Para os principais destaques do webinar, incluindo escopo do RED, avaliação de risco EN 18031, documentação, preparação de evidências e prontidão para relatório CRA, leia nosso Guia de Prontidão para RED, EN 18031 e CRA: Respostas Práticas do Webinar da QIMA.
Não foi possível cobrir todas as perguntas durante a sessão, então nossos especialistas em cibersegurança prepararam as respostas adicionais abaixo.
Este artigo reflecte o estatuto regulamentar e normativo a partir de 2026. As obrigações de comunicação da LFC aplicam-se a partir de 11 de Setembro de 2026, ao passo que os principais requisitos da LFC se aplicam a 11 de Dezembro de 2027.
Estas respostas oferecem uma orientação técnica geral. A rota de avaliação de classificação e conformidade correta para um produto específico deve ser determinada utilizando toda a documentação técnica propósito pretendido, uso razoavelmente previsível, conectividade e arquitetura de segurança.
Pergunta 1: Temos uma carteira cripto fria na forma de um cartão NFC. Suas funções principais são armazenar, enviar e receber ativos cripto sem KYC. Funciona através de um aplicativo móvel utilizando a NFC. Quais as normas e restrições harmonizadas podem ser aplicadas?
A correspondência mais próxima nos termos do Regulamento de Implementação (EU) 2025/2392 deverá ser “smartcards ou dispositivos similares, incluindo elementos seguros", que é uma categoria de produto crítico.
Isso acontece porque a funcionalidade central do cartão parece ser o armazenamento de chave de criptografia e o login de transação com um fator de formulário do cartão. No entanto, uma classificação precisa exige uma avaliação cuidadosa.
Que ficha está dentro do cartão?
A descrição técnica do Anexo IV requer que o elemento seguro forneça resistência a ataques pelo menos no AVA_VAN.4 sob critérios comuns.
Dependendo do chip, o produto pode ser classificado da seguinte forma:
Um elemento de segurança baseado em Java no AVA_VAN.4 pode ser classificado como crítico.
Um chip resistente à manipulação na AVA_VAN.2 ou AVA_VAN.3 pode ser classificado como importante classe II.
Um microcontrolador de segurança abaixo AVA_VAN.2 pode ser classificado como importante classe I.
Um simples chip de memória NFC com processamento de criptografia executado em software provavelmente permanecerá na categoria Padrão.
Qual é a verdadeira funcionalidade central do produto como um inteiro?
De acordo com o projecto de orientação da ANC, a classificação baseia-se na funcionalidade única do produto no seu conjunto.
Neste caso, a funcionalidade de núcleo é descrita com mais precisão como armazenamento de chave segura e assinatura de transações, em vez de enviar e receber ativos de cripto. A transmissão da transação para a blockchain é normalmente realizada pela aplicação móvel, não pelo cartão.
Esta distinção é importante ao comparar o produto com as descrições técnicas do Regulamento de Implementação.
Qual é a rota de avaliação de conformidade se o produto é classificado como crítico?
O artigo 32(4) do CCRA requer a certificação da cibersegurança europeia para produtos críticos. Espera-se que o regime relevante seja o EUCC, que se baseie em critérios comuns e no Perfil de Protecção aplicável para elementos seguros.
Normas harmonizadas e a certificação EUCC podem ambos proporcionar a presunção de conformidade com os requisitos de segurança cibernética essenciais da CRA, mas sua utilização depende da categoria do produto e das condições aplicáveis.
Há dois pontos que têm de ser verificados antes de se contar com um certificado EUCC para a conformidade da ANC.
1. Alinhamento entre o limite do produto e o Alvo da Avaliação
Um certificado EUCC cobre apenas o que está incluído no Alvo da Avaliação, ou TOE.
O fabricante deve verificar se a fronteira TOE abrange tudo o que está incluído na reivindicação de conformidade da CR. Dependendo do desenho do produto, isto pode incluir:
O elemento seguro
Firmware
O aplicativo de carteira executando no elemento seguro
A interface NFC
O aplicativo móvel, onde ele faz parte do produto
Qualquer processamento de backend que se qualifica como uma solução de processamento de dados remotos
2. O acto delegado CRA requerido ainda não foi emitido
O acto delegado que define as condições em que a EUCC prevê a presunção de conformidade com o SIR ainda não foi adoptado.
Até que seja aplicado, os produtos críticos devem seguir o procedimento de recurso para produtos importantes da Classe II. Isto requer uma avaliação obrigatória de terceiros usando o Módulo B plus Module C, ou Module H, com um corpo notificado.
O acto delegado definirá também o nível de segurança necessário para o EUCC. que deve ser pelo menos "substancial" e pode ser "alto", dependendo do risco identificado.
Que normas previstas poderão ser relevantes?
Tanto os padrões de plataforma quanto os padrões de aplicativo podem ser relevantes:
prEN 50764, os requisitos de cibersegurança para plataformas de smartcards e dispositivos semelhantes, incluindo elementos seguros. Isso cobre o hardware de elemento seguro e a plataforma de firmware. Normalmente será relevante para o fabricante do chip, mas também pode aplicar onde o fabricante da carteira projeta seu próprio chip.
PrEN 18330, requisitos de segurança CyberGhost para smartcards ou dispositivos semelhantes, incluindo elementos seguros, camada de aplicativo. Isso cobre a aplicação de carteira em execução no elemento seguro e é mais relevante diretamente para o fabricante da carteira.
prEN 40000-1-2, prEN 40000-1-3, e prEN 40000-1-4, padrões horizontais que abrangem princípios de resiliência virtual, conformidade baseada no risco, gerenciamento de vulnerabilidades e requisitos genéricos de segurança virtual.
No Jornal Oficial da União Europeia, estas normas não foram mencionadas no momento da redacção como normas harmonizadas da ANC. Por conseguinte, ainda não prevêem a presunção de conformidade.
O próximo passo é identificar o nível de certificação do chip e dos critérios comuns, definir a fronteira exacta do produto, documentar o papel da aplicação móvel, e mapear a funcionalidade central do produto contra as descrições técnicas no Regulamento de Aplicação (EU) 2025/2392.
Uma vez prEN 50764 e prEN 18330 são publicadas, as seções do seu âmbito devem ser revistas cuidadosamente para determinar como se aplicam ao produto específico e como as responsabilidades são divididas entre a plataforma de elementos seguros e o aplicativo que está sendo executado nele.
Nos casos em que a classificação continue a ser incerta, o fabricante deve consultar a autoridade de fiscalização do mercado ou o organismo de avaliação de conformidade antes de escolher uma rota de avaliação de conformidade.
Pergunta 2: A EN 18031 será substituída por EN 40000?
O EN 18031 não deve ser visto como substituído diretamente por EN 40000.
Nos termos da Directiva de Equipamentos de Rádio, a abordagem preferida para demonstrar o cumprimento dos requisitos de segurança virtual nos Artigos 3(3)(d), 3(3)(e) e 3(3)(f) pretendem aplicar a série harmonizada EN 18031, tendo em conta as restrições incluídas na sua citação Oficial do Jornal.
A partir de 11 de dezembro de 2027 os produtos abrangidos pela CRA terão de cumprir os requisitos de Segurança Virtual Essencial da CRA e usar normas alinhadas ou harmonizadas ao abrigo da CRA.
EN 40000 é uma série padrão mais ampla relacionada com o CRA com várias partes. Por exemplo, EN 40000-1-3 concentra-se no tratamento de vulnerabilidades, enquanto outras partes abordam processos de conformidade baseados no risco e requisitos genéricos de segurança virtual.
Os requisitos de segurança específicos do produto ainda devem ser selecionados com base na avaliação e classificação do risco do produto.
A EN 18031 pode, por conseguinte, continuar a ser uma prova técnica útil onde as suas exigências sejam relevantes. No entanto, a conformidade com a CRA exigirá que o fabricante mapeie os riscos do produto e os Requisitos Essenciais de Segurança Virtual da CRA contra as partes EN 40000 aplicáveis, padrões específicos do produto ou outras especificações técnicas justificadas.
Questão 3: Se temos vários dispositivos com a mesma funcionalidade, mas fatores de formulário diferentes, como cartões e anéis, precisamos fazer duas vezes os controlos de conformidade?
Cada tipo de produto distinto, incluindo cada factor formal, deve ser abrangido pela avaliação da conformidade e pela Declaração de Conformidade da UE. Para um cartão e um anel, isso normalmente significa avaliar ambos os tipos de produtos.
No entanto, a quantidade prática de trabalho repetido depende do módulo de avaliação de conformidade selecionado.
Módulo H, garantia de qualidade total
O módulo H pode ser a rota mais eficiente nesta situação.
O corpo notificado avalia e certifica o sistema de gestão de qualidade do fabricante que abrange os tipos de produtos relevantes. Adicionar um novo fator de formulário pode então ser tratado como uma extensão para o sistema de qualidade existente, em vez de como uma reavaliação completa desde o início.
Módulo B mais Módulo C
No Módulo B plus Module C, um certificado de exame do tipo da UE pode ser necessário para cada tipo de produto.
No entanto, os resultados dos testes, a documentação técnica e outras provas da primeira avaliação podem ser reutilizadas onde a tecnologia subjacente é idêntica, incluindo:
O elemento seguro
Firmware
Funções criptográficas
Arquitetura de segurança
Mecanismos de atualização
Quando a arquitetura central de funcionalidade e segurança são iguais, a avaliação adicional deve se concentrar nas diferenças introduzidas pelo fator de formulário, como a interface física, a integração de hardware, a resistência adulterada e a superfície de ataque.
Módulo H pode ser a rota mais eficiente para os fabricantes que planejam colocar várias variantes de produtos relacionados no mercado. O tratamento de modelos e tipos de produtos individuais deve ser confirmado com o corpo informado selecionado.
Questão 4: Um gateway, como um gateway usado para controlar lâmpadas ZigBee, seria considerado um produto padrão ou importante?
A classificação requer uma análise completa da funcionalidade central do produto com base na sua documentação completa.
Isto inclui:
Intensidade de tarefa
Documentação técnica
Instruções para uso
Materiais promocionais
Implementação técnica real
O fabricante deve fazer essa determinação. Uma classificação não pode ser assumida apenas da palavra "gateway".
De acordo com o teste de "partidas completas" descrito no projecto de orientação da CRA, a funcionalidade central do produto deve corresponder plenamente à descrição técnica de uma categoria Anexo III ou Anexo IV para se qualificar como importante ou crítico.
Para um gateway ZigBee cuja funcionalidade central documentada é o controle local de dispositivo doméstico inteligente, como alternar ou diminuir as luzes, duas categorias podem inicialmente parecer relevantes.
Roteador
A descrição técnica dos roteadores requer que o produto estabeleça e controle o fluxo de dados entre diferentes redes usando mecanismos de protocolo de roteamento e algoritmos na camada de rede.
Uma ponte de protocolo usada para controle do dispositivo pode ficar aquém desta definição, mas o resultado tem de ser verificado contra a implementação técnica real.
Produtos de casa inteligente com funcionalidades de segurança
Esta categoria se aplica a produtos smart home cuja funcionalidade principal está relacionada com a segurança física dos consumidores, como bloqueios de porta conectados, câmeras e sistemas de alarme.
Controle de luz não normalmente corresponde totalmente a essa descrição.
Se a funcionalidade central do produto não corresponder plenamente a qualquer descrição técnica do Anexo III ou do Anexo IV, geralmente permanecerá na categoria Padrão.
No entanto o resultado pode ser diferente se a documentação completa do produto mostrar que o roteamento voltado para a Internet ou uma função de segurança explícita faz parte de sua funcionalidade principal.
Pergunta 5: Quem deverá reportar incidentes através da Plataforma Única de Relato se uma empresa é constituída por várias fábricas que operam sob a mesma marca?
O relatório não deve ser apresentado separadamente por cada fábrica.
Deverá ser apresentado pela empresa ou pelo fabricante legal responsável pela colocação do produto no mercado da UE.
Na prática, todas as fábricas devem reportar internamente questões relevantes a uma única equipe central de segurança do produto ou da LFC.
Esta equipe central deveria:
Decidir se o caso atende aos requisitos de comunicação de CRA
Colete as informações necessárias
Preparar a notificação
Enviá-lo através da Plataforma Única de Relatório
Coordenar qualquer comunicação necessária com os usuários
Para efeitos de apresentação de relatórios, a localização relevante é normalmente a principal localização do fabricante na UE.
Isto significa, em geral, o estabelecimento onde são tomadas as principais decisões de cibersegurança relativas ao produto. Se isto não puder ser determinado, poderá estar ligado ao estabelecimento da UE com o maior número de trabalhadores.
Por conseguinte, a empresa deve ter um único proprietário central de comunicação e um processo de escalada interno claro que abranja todas as fábricas e sítios.
Pergunta 6: EN 18031 não explica como realizar a avaliação de riscos ou fornecer um modelo. EN 40000 preenche esta lacuna?
O CRA não exige que os fabricantes utilizem uma metodologia específica de avaliação de riscos de cibersegurança.
Os fabricantes podem selecionar sua própria abordagem, desde que isso lhes permita documentar:
Identificação do risco
Análise e avaliação de risco
Tratamento de risco
A relação entre os riscos identificados e os requisitos essenciais de segurança virtual CRA
As decisões tomadas durante a avaliação
A avaliação dos riscos deve apoiar as obrigações estabelecidas no artigo 13° da LFC e os requisitos da documentação técnica do Anexo VII.
As fontes atuais de orientação incluem:
A FAQ, nomeadamente a secção que explica o âmbito de aplicação, os resultados e a documentação exigidos pela Comissão Europeia
As orientações da Comissão em matéria de avaliação do risco de cibersegurança e de tratamento do risco
BSI TR-03183-1, que fornece uma metodologia de avaliação de risco detalhada, passo a passo, estruturada em torno da exigência do Anexo I CRA
Espera-se que o desenvolvimento do padrão prEN 40000-1-2 proporcione um processo estruturado de conformidade com base no risco. No entanto, não deve ser tratado como um modelo obrigatório que pode ser aplicado inalterado a todos os produtos.
Questão 7: A CRA aplica-se a produtos que se ligam entre si como alarmes de fumo ligados, mesmo que não se conectem à internet ou a um aplicativo?
Sim, eles podem cair no âmbito de aplicação da LFC.
O CRA define um produto com elementos digitais como um produto cujo propósito ou uso razoavelmente previsível inclui uma direta ou indireta, conexão lógica ou física de dados a um dispositivo ou rede.
Por conseguinte, não é necessária uma conexão com a internet ou aplicativo móvel.
Alarmes de fumaça vinculados que trocam dados diretamente entre si podem encontrar esta definição porque têm uma conexão direta com outro dispositivo ou rede.
Se o produto é Padrão, Importante ou Crítico deve ser avaliado separadamente com base em sua funcionalidade principal.
Pergunta 8. Como o CRA afeta os distribuidores que adicionam valor instalando uma imagem personalizada de sistema operacional Windows ou Linux?
A instalação de uma imagem personalizada do sistema operacional provavelmente exigirá que o distribuidor avalie se assumiu as obrigações do fabricante sob a ANC.
Há duas situações principais em que um distribuidor se torna fabricante ao abrigo do artigo 21:
O distribuidor coloca o produto no mercado com seu próprio nome ou marca.
O distribuidor procede a uma modificação substancial do produto.
Uma modificação substancial é a seguinte alteração:
Afeta o cumprimento dos requisitos essenciais de segurança virtual da CRA, ou
Altera o objetivo para o qual o produto foi originalmente avaliado
Uma imagem de sistema operacional personalizada pode mudar:
Configurações de segurança
Componentes de software instalados ou removidos
Configurações padrão de segurança
Serviços de rede
Mecanismos de atualização
Permissões
Registro
A superfície de ataque geral
Estas alterações provavelmente afetarão a conformidade com os requisitos de segurança virtual essencial da CRA e, portanto, poderão ser qualificadas como uma alteração substancial.
Nos casos em que a modificação é substancial, o distribuidor torna-se o fabricante do produto modificado e assume as obrigações pertinentes da ANC.
Estas podem incluir:
Avaliação do risco da cibersegurança
Documentação técnica
Avaliação de conformidade
Marca CE
Manipulação de vulnerabilidades
Atualizações de segurança
Relatório do incidente e vulnerabilidade
O distribuidor não pode depender apenas da conformidade da Microsoft, um distribuidor Linux, ou do fabricante original do dispositivo com CRA. A conformidade tem de ser avaliada e demonstrada para o produto que foi configurado finalmente no mercado.
Pergunta 9. Como os sistemas de nuvem são avaliados sob a CRA se não usamos AWS, Azure ou a infraestrutura do Google Cloud?
O provedor de nuvem não é o factor decisivo.
O que importa é se o processamento da nuvem ou backend se qualifica como um Solução de Processamento de Dados Remotos, ou RDPS.
A CRA inclui um RDPS dentro da definição de um produto com elementos digitais quando atendidas as seguintes condições:
Os dados são processados à distância, fora do dispositivo do usuário ou ambiente local.
A solução de transformação foi concebida ou desenvolvida pelo fabricante, ou sob a sua responsabilidade.
Sem esse processamento, o produto não poderia desempenhar uma das suas funções.
Quando estas condições são cumpridas, o back-end faz parte do produto com elementos digitais e tem de cumprir os requisitos aplicáveis do Anexo I da CIA.
Um RDPS não precisa de operar em infraestruturas de nuvem pública de terceiros.
O processamento remoto pode se qualificar como um RDPS quando é executado em:
Servidores do próprio fabricante
Uma nuvem privada
infraestrutura no local
Infraestrutura operada por outro provedor
Não usar o AWS, Azure ou Google Cloud não cria uma isenção.
Os serviços de SaaS, PaaS e IaaS foram concebidos e desenvolvidos independentemente de um produto específico geralmente estão fora da definição do produto da CRA. Outra legislação, incluindo a NIS2, poderá ainda aplicar-se a estes serviços.
Os fabricantes têm de avaliar os seus sistemas de backend de acordo com os critérios RDPS numa base casuística. Nos casos em que se qualificam, devem ser incluídos no limite dos produtos, na avaliação dos riscos, na documentação técnica e na avaliação da conformidade.
Pergunta 10. Os controladores multimídia da indústria de entretenimento usam portos Wi-Fi e ethernet para controlar produtos. O protocolo usado, Art-Net, é diferente da internet. Esses produtos são dentro do escopo da segurança virtual RED ou da CRA?
Para o CRA, o ponto relevante é a definição de um produto com elementos digitais.
Um produto está dentro do escopo geral da CRA quando seu propósito ou uso razoavelmente previsível inclui uma direta ou indireta, conexão lógica ou física de dados a um dispositivo ou rede.
Um controlador multimídia que comunica por Wi-Fi ou Ethernet pode, portanto, estar dentro do âmbito de aplicação da CRA, mesmo que o protocolo do aplicativo seja Art-Net.
O nome de protocolo específico não determina se o produto está no escopo.
Para segurança virtual RED, é necessária uma avaliação mais detalhada.
O fabricante deve avaliar se o equipamento de rádio pode comunicar através da Internet, quer directamente quer através de outros equipamentos.
O uso da Art-Net não coloca automaticamente o produto fora do escopo de cibersegurança VERMELHO. O fabricante deve rever a arquitetura completa de conectividade, incluindo gateways, roteadores, sistemas de controle remoto e qualquer possível acesso à internet.
Pergunta 11. Você pode fornecer orientação sobre a seleção do período de suporte de segurança correto?
O período de apoio por incumprimento ao abrigo da LFC é, pelo menos, de cinco anos.
No entanto, o fabricante tem também de considerar a duração previsível do produto.
Pode justificar-se um período mais curto em que se espera que o produto seja utilizado durante menos de cinco anos. É necessário um período mais longo onde se espera que o produto continue a ser utilizado por mais tempo.
O período de apoio deve considerar:
O propósito do produto
Sua esperada vida operativa
Expectativas do usuário
O ambiente em que é usado
A disponibilidade de produtos de substituição
Os períodos de suporte dos componentes incorporados
Dependências de sistemas operacionais, aplicativos ou serviços externos
Requisitos legais e contratuais relevantes
Os produtos utilizados em tecnologias operacionais, sistemas industriais, construção de infra-estruturas ou outros ambientes de longa duração podem exigir um período de apoio significativamente superior a cinco anos.
O período de suporte seleccionado deve ser justificado na avaliação de riscos, documentado na documentação técnica e comunicado aos usuários.
Questão 12. A CRA requer relatórios separados da mesma vulnerabilidade para diferentes dispositivos, como um cartão e um anel disponível em várias cores?
Um relatório pode cobrir a mesma vulnerabilidade em todas as variantes de produtos afectados.
O artigo 14 da CRA exige que os fabricantes informem vulnerabilidades exploradas ativamente contidas em um produto com elementos digitais. A notificação deve incluir informações gerais sobre os produtos em causa.
A CRA não requer relatórios separados para todos:
Cor
Código
Fator de formulário
Variante comercial
Se a mesma vulnerabilidade afeta tanto o cartão quanto o anel porque eles compartilham o mesmo firmware, software, elemento seguro, ou outro componente vulnerável, uma notificação cobrindo todas as variantes afetadas é apropriada.
A notificação deve identificar claramente todos os afetados:
Tipos de Produtos
Modelos
Versões de hardware
Versão de firmware ou software
Se o cartão e anel usam diferentes firmware ou implementações de segurança e apenas um for afetado, A informação separada pode ser adequada, uma vez que os produtos são tecnicamente diferentes.
O fabricante deve listar todas as variantes afetadas explicitamente na notificação. Isto permite que o mesmo relatório cubra a família dos produtos totalmente afetados sem duplicações desnecessárias.
Pergunta 13. O Cyberexpert é uma plataforma baseada em nuvem? Ele usa uma API pública, e como a consistência de seus resultados é assegurada?
Sim. Cyberexpert é uma plataforma SaaS baseada em nuvem.
Os usuários acessam-no por meio de uma interface web segura onde as informações, avaliações, requisitos e provas do produto são gerenciadas centralmente.
Isso permite que os times em:
Colaborar nas atividades de conformidade
Acompanhar progresso
Gerenciar evidência do produto
Manter uma trilha de auditoria consistente
Cyberexpert é projetado como uma plataforma extensível em vez de uma aplicação autônoma de IA.
Pode integrar serviços externos, tais como:
Provedores de identidade
Sistemas de gerenciamento de vulnerabilidades
Repositórios de documentos
Plataformas de conformidade empresariais
A resposta do especialista confirma que as integrações externas são apoiadas. A disponibilidade de uma API pública e de opções específicas de integração devem ser confirmadas diretamente com a equipe do Cyberexpert.
Consistência de saídas é suportada através de várias camadas:
Workflows estruturados
Razão de avaliação determinística
Quando necessário, o especialista em análise
Uma base de conhecimento controlada e controlada
Orquestração AI padronizada
Geração Retrieval-Aumentado usando fontes controladas
O valor central do Cyberexpert vem da sua lógica de conformidade e do fluxo de trabalho estruturado. AI auxilia o processo, mas as saídas estão ancoradas em fontes controladas, informação do produto e regras de avaliação definidas.
Pergunta 14. Um rádio inteligente usado principalmente para rádio de internet, Spotify, e reprodução de mídia cai dentro do CRA?
Sim.
Um rádio inteligente está dentro do escopo CRA porque seu objetivo pretendido inclui uma conexão direta a uma rede.
O dispositivo inicia e mantém a comunicação de IP bidirecional. Por exemplo, ele envia solicitações de conexão e sessão e recebe dados de fluxo de áudio.
Isto constitui uma conexão lógica direta a uma rede.
O facto de o principal objetivo do produto ser ouvir rádio ou reproduzir mídia não o remove do âmbito geral da CRA.
Sua classificação como padrão importante, ou produto crítico deve ser avaliado separadamente com base na sua funcionalidade principal e nas descrições técnicas do Regulamento de Aplicação (UE) 2025/2392.
Onde o produto usa Wi-Fi, Bluetooth ou outra tecnologia de rádio. poderá também ser abrangida pela Directiva relativa aos Equipamentos Radioeléctricos e exigir uma avaliação separada da cibersegurança RED.
Preparando-se para conformidade RED e CRA
Os nomes dos produtos e as etiquetas de conectividade não são suficientes para determinar as obrigações RED ou CRA.
Os fabricantes precisam definir a borda do produto, documentar a funcionalidade central do produto, identificar todos os caminhos de conectividade, determinar a categoria de produto aplicável e ligar cada conclusão de conformidade às evidências técnicas.
Cyberexpert ajuda os fabricantes a estruturar este trabalho, identificar requisitos aplicáveis, preparar provas e determinar onde é necessária a revisão especializada ou avaliação formal de conformidade.
Compartilhe isso no
