Como manter a EN 18031 Evidência válida após atualizações de Firmware

Firmware versão 2.4 não apaga automaticamente o trabalho EN 18031 concluído para a versão 2.3. mas cria uma questão mais difícil: que conclusões ainda descrevem o produto que está a ser enviado ou actualizado?

As notas de lançamento não podem responder isso por conta própria. Elas descrevem as mudanças no código. EN 18031 evidências suporta conclusões sobre os ativos, interfaces, fluxos de dados, controles de acesso, mecanismos de atualização, dependências e comportamento testado dos produtos. Uma pequena atualização pode afetar uma reivindicação de segurança crítica, enquanto uma grande refatoração interna pode deixar essa reivindicação intocada.

A unidade útil de trabalho é, portanto, um delta de evidência: um registro versionado do que mudou, quais conclusões existentes dependem dos fatos alterados, e quais evidências devem ser retidas, complementadas, substituídas ou escaladas. “Delta de evidência” não é um termo usado na Diretiva de Equipamentos Radiofônicos ou EN 18031. É uma maneira prática de transformar suas expectativas de controle de mudanças em uma decisão de liberação repetível. O termo fornece uma abreviação para transformar as expectativas de controle de mudanças do RED e EN 18031 em uma decisão de liberação repetível.

A evidência expira quando suas suposições mudam

VERMELHO torna o produto alterado parte da conformidade. Artigo 21(2) da Directiva 2014/53/EU exige que a documentação técnica seja elaborada antes de os equipamentos de rádio serem colocados no mercado e serem “continuamente actualizados”. Artigo 10(5) requer que os fabricantes tenham em conta as mudanças no design do produto ou características durante a série de produções. Anexo V requer também que software relevante ou versões de firmware sejam identificadas quando elas afetam a conformidade.

A obrigação legal é a conformidade com os requisitos essenciais aplicáveis em matéria de RED. EN 18031 é uma norma harmonizada e voluntária que os fabricantes podem utilizar para apoiar uma presunção de conformidade, sujeito às restrições impostas no seu Jornal Oficial da Citação. Essa distinção é importante quando uma alteração afecta as normas de cobertura ou a rota de avaliação de conformidade.

O Guia RED da Comissão Europeia diz isso explicitamente na sua seção "Produção das Séries". Diz aos fabricantes que monitorizam as mudanças no hardware e no software, bem como a evolução das normas e da legislação aplicáveis. e o estado da arte, em seguida, registe suas considerações na documentação técnica. Confirma também que o fabricante continua a ser responsável pela avaliação do equipamento de rádio juntamente com o seu software incorporado.

A cada conclusão EN 18031 recai em fatos do produto. Uma avaliação de controle de acesso pode assumir que apenas os administradores locais podem alterar uma configuração. Um teste de comunicação seguro pode depender de uma biblioteca e configuração específicas de criptografia. Uma avaliação de mecanismo de atualização pode depender do bootloader, assinar as chaves, controles de reversão e caminho de entrega. Quando um desses factos muda, a evidência que depende dele precisa ser revista.

Comece com uma base de produto definida. Isso deve identificar o tipo de produto e a revisão de hardware, build, bootloader, interfaces ativadas, configuração de rádio, versões complementares de aplicativos e backend quando relevante, componentes de segurança de terceiros, uso intencional, papéis de usuários, categorias de dados e rota de conformidade. Um nome de produto por si só não é uma linha de base. Duas variantes vendidas sob o mesmo nome podem expor interfaces diferentes ou habilitar funções diferentes. Muitos comuns EN 18031 intervalos antes de iniciar começam com este limite sendo desenhado muito estritamente em torno do dispositivo.

A linha de base deverá também registar a referência exactamente harmonizada e as condições do Jornal Oficial utilizadas para a conformidade das alegações. EN 18031-1, EN 18031-2 e EN 18031-3 foram citados sob RED através de Decisão de implementação da Comissão (EU) 2025/138, com restrições. Uma mudança afetando comportamento de senha, O controle de acesso parental ou atualizações seguras em equipamentos passíveis de pagamento pode, portanto, afetar mais do que um resultado de teste. Poderá afectar se a via de conformidade escolhida ainda funciona. Para produtos conectados à internet, a QIMA EN 18031-1 visão geral fornece contexto adicional em limites de produtos e provas técnicas de arquivo.

Construa um Delta de Evidência para Cada Lançamento de Firmware

Coloque a revisão de provas entre o conjunto de mudança de engenharia e o lançamento final da aprovação. Até esse ponto, a equipe sabe o que mudou, mas ainda há tempo para atualizar a documentação, realize testes focalizados ou envolva um especialista de conformidade antes que a compilação chegue à produção ou dispositivos implementados.

A revisão deve rastrear a mudança através do produto, em vez de classificar a versão como "menor" ou "maior". Os exemplos a seguir mostram onde esse vestígio geralmente leva.

Cada item afetado recebe, então, uma das quatro disposições.

Use um delta de prova para cada configuração lançada. Deve registar:

1. O firmware constrói e afetou variantes de produtos ou hardware.

2. As funções , componentes, interfaces e suposições que mudaram.

3. EN 18031 conclusões e registros de arquivos técnicos afetados por essas alterações.

4. A disposição de cada item de evidência existente: retida, suplementada, substituída ou escalada.

5. Novos testes, decisões de vulnerabilidade, entradas de fornecedores e referências de evidências.

6. O revisor, a data de aprovação e a decisão final de lançamento.

Esses campos transformam uma discussão de impacto de mudança em um registro que outra pessoa pode reconstruir mais tarde.

Uma decisão mantida ainda é evidência. Ela deveria ligar ao artefato anterior e explicar por que suas suposições permanecem verdadeiras. Uma caixa de seleção marcada "sem impacto" sem raciocínio será difícil de defender meses depois, especialmente depois de as pessoas envolvidas terem mudado para outro projeto.

Tamanho da Mudança é um Proxy Pobre para Impacto de Evidência

Considere um controlador de construção conectado. O Firmware 2.3.1 atualiza sua biblioteca TLS para corrigir a vulnerabilidade. Os protocolos suportados, gestão de chave, fluxos de dados, interfaces externas e caminhos de atualização permanecem os mesmos. A equipe só pode precisar atualizar os registros do componente e vulnerabilidades, preservar o novo identificador de compilação, verificar a criptografia configurada e executar testes de regressão focados. A arquitectura e o controlo de acessos podem permanecer aplicáveis, se a conclusão estiver documentada, e a integração real a apoiar.

Firmware 3.0 e adiciona administração remota através de uma nova API de nuvem. Essa alteração reabre o limite de produtos, diagrama de dados, inventário de interface externa, cenários de ameaça, funções de administrador, autenticação, log, dependência de backend e possivelmente avaliação de dados pessoais. A necessidade de novas provas provém da alteração da exposição, não do número da versão principal.

A orientação da Comissão Europeia de 2026 sobre o Cyber Resilience Act segue a mesma lógica baseada no risco para modificações substanciais. Ele leva os fabricantes a considerar se uma atualização de software introduz novos vetores de ameaça ou cenários de ataque ou muda a probabilidade ou o impacto de outros existentes. Também explica que uma atualização de segurança geralmente não é substancial quando deixa o propósito pretendido inalterado e não introduz nenhum novo risco de cibersegurança, mesmo que a alteração técnica seja significativa.

Essas são considerações CRA, não um substituto para uma avaliação EN 18031 sob RED. São úteis agora porque mostram por que etiquetas como “patch de segurança”, “liberação de recurso” ou “atualização menor” não são suficientes. O efeito do produto precisa ser examinado.

Mantenha as provas antigas em vez de substituí-las

A documentação técnica deve permanecer atual, mas "atual" não significa que o registro anterior deve desaparecer. A RED exige que os fabricantes retenham a documentação técnica e a declaração de conformidade da UE durante dez anos após a colocação no mercado do equipamento de rádio. Se um produto permanecer em série de produções através de vários lançamentos de firmware, o fabricante pode precisar reconstruir qual configuração suporta um determinado lote de produção ou unidade.

Manter um livro de versão que conecta cada lançamento de firmware aos modelos aplicáveis e revisões de hardware, produção ou intervalos de série, campo implanta população, delta de provas, versões de documentos, resultados de testes, aprovações e qualquer comunicação do corpo notificado. Para uma atualização sobre o ar, preserve também os registros de implantação e reversão. Isto cria um calendário para o que foi avaliado, o que mudou, e que provas apoiaram cada decisão.

Não edite um único arquivo chamado EN18031_Assessment_Final no lugar. Quando suposições antigas são substituídas silenciosamente, o arquivo pode descrever a compilação mais recente sem deixar nenhum registro confiável para unidades anteriores. As notas de lançamento não são um substituto. Elas mostram o que a engenharia mudou, mas não por que razão uma conclusão de conformidade anterior ainda mantém.

A mesma disciplina se aplica a provas de fornecedores. Um novo relatório de biblioteca, declaração de módulo ou ficha técnica de segurança não prova automaticamente que o produto final permaneça protegido. O fabricante ainda precisa identificar a versão exata e a configuração usada, verifique as suposições que interessam ao produto, e conecte o material do fornecedor às evidências de nível do produto.

Use o registro RED para se preparar para o gerenciamento de vulnerabilidades CRA

Este histórico de liberação tem valor imediato além da próxima revisão do RED. O regulamento delegado de cibersegurança do RED permanece aplicável até 10 de dezembro de 2027. O Regulamento Delegado (EU) 2026/339 o revoga a partir de 11 de dezembro de 2027, quando as principais obrigações CRA se aplicam. A visão geral mais ampla da CRA da QIMA explica sua relação com o RED e outras regras da UE.

As obrigações de comunicação das ANC já estão em vigor. Desde 11 de setembro de 2026, os fabricantes têm sido obrigados a relatar vulnerabilidades exploradas e incidentes de segurança graves que afetam produtos no escopo. O oficial que emite as orientações estabelece um prazo de alerta precoce de 24 horas e um prazo de 72 horas para a notificação completa. A sua orientação de 2026 de Julho afirma também que o direito de apresentação de relatórios abrange os produtos colocados no mercado antes da data principal de candidatura da ANC.

Um rastro de evidência específico de versão dá à equipe de vulnerabilidade um início principal. Ele mostra quais compilações lançadas contêm um componente afetado, como esse componente é configurado, quais interfaces o expõem e quais dispositivos receberam o firmware relevante. Não decide se um evento é reportável, mas reduz o tempo gasto a reconstruir o produto enquanto o relógio reportado está em execução.

A orientação da CRA de 2026 de julho também aponta para testes orientados por eventos. Os fabricantes devem rever se novas ameaças, vulnerabilidades ou alterações nos produtos requerem que o teste seja alterado e, em seguida, execute os testes relevantes. Não exige a repetição mecânica de uma campanha de ensaio inalterada a intervalos fixos. A mesma orientação permite que a documentação existente e os resultados dos testes sejam reutilizados para partes não afectadas de um produto substancialmente modificado. Este é o valor a mais longo prazo de um delto de prova: preserva a reutilização sem permitir que provas antigas se afastem do produto.

Para um ponto de partida estruturado, use QIMA RED e CRA Readiness Workbook para Produtos Conectados para mapear o escopo do produto, EN 18031 evidências, lacunas do fornecedor, relatórios de vulnerabilidade e um plano de ação de 30 dias.

Na revisão do lançamento, substitua a pergunta “O documento EN 18031 foi atualizado? com "Quais conclusões de conformidade mudaram e onde estão as evidências para essa decisão?"

Mapa de requisitos específicos do produto Cyberexpert, lista de verificação de provas e gestão de vulnerabilidades dão produto firmware, controle de qualidade e equipes de conformidade um lugar compartilhado para conectar requisitos, riscos, proprietários de provas e liberar alterações. Cyberexpert apoia a preparação de preparação de preparação e provas. Não certifica o produto, e a responsabilidade pela conformidade continua a recair sobre o fabricante. Escopo seu produto conectado de graça para identificar qual EN 18031 prova a sua próxima versão do firmware deverá reabrir.