Comment conserver les preuves EN 18031 valides après les mises à jour du firmware

La version 2.4 du microprogramme n'efface pas automatiquement les travaux de la version 2.3 de la norme EN 18031. mais cela crée une question plus difficile: quelles conclusions décrivent encore le produit actuellement expédié ou mis à jour?

Les notes de publication ne peuvent pas répondre à cela par elles-mêmes. Elles décrivent les changements de code. EN 18031 preuve supporte les conclusions sur les actifs, les interfaces, les flux de données, les contrôles d'accès, les mécanismes de mise à jour, les dépendances et le comportement testé. Un petit correctif peut affecter une réclamation de sécurité critique, tandis qu'un important refacteur interne peut laisser intacte cette allégation.

L'unité de travail utile est donc un delta preuve: un enregistrement versionné de ce qui a changé, dont les conclusions actuelles reposent sur les faits modifiés, et quelles preuves doivent être retenues, complétées, remplacées ou escaladées. « Preuve delta » n'est pas un terme utilisé dans la Directive sur les équipements radio ou EN 18031. C'est un moyen pratique de transformer leurs attentes de contrôle du changement en une décision de libération répétable. Le terme fournit un raccourci pour transformer les attentes de contrôle du changement RED et EN 18031 en une décision de libération répétable.

Les preuves expirent lorsque ses hypothèses changent

RED intègre le contrôle des changements de produits dans la conformité. L'article 21(2) de la Directive 2014/53/UE exige que la documentation technique soit élaborée avant que l'équipement radio ne soit mis sur le marché et qu'elle soit “mise à jour continuellement”. L'article 10(5) exige des fabricants qu'ils prennent en compte les changements dans la conception ou les caractéristiques du produit au cours des séries de production. L'annexe V exige également que les versions logicielles ou micrologicielles pertinentes soient identifiées lorsqu'elles affectent la conformité. 

L'obligation légale est de se conformer aux exigences essentielles RED applicables. EN 18031 est une norme volontaire harmonisée que les fabricants peuvent utiliser pour soutenir une présomption de conformité, sous réserve des restrictions contenues dans son Journal officiel de citation. Cette distinction est importante lorsqu'une modification affecte les normes de couverture ou la route d'évaluation de la conformité.

La Commission Européenne RED Guide le dit explicitement dans sa section « Production en série ». Il indique aux fabricants de surveiller les changements de matériel et de logiciel, l'évolution des normes applicables et de la législation, et l'état de l'art, puis enregistrer leurs considérations dans la documentation technique. Il confirme également que le fabricant reste responsable de l'évaluation de l'équipement radio avec son logiciel embarqué.

Chaque conclusion de EN 18031 repose sur des faits produits. Une évaluation de contrôle d'accès peut supposer que seuls les administrateurs locaux peuvent modifier un paramètre. Un test de communication sécurisée peut reposer sur une bibliothèque cryptographique spécifique et une configuration. Une évaluation du mécanisme de mise à jour peut dépendre du bootloader, des clés de signature, des contrôles de retour arrière et du chemin de livraison. Lorsqu'un de ces faits change, les preuves qui en dépendent nécessitent une révision. 

Commencez avec une base de référence de produit définie. Cela devrait identifier le type de produit et la révision matérielle, la construction du micrologiciel, le bootloader, les interfaces activées, la configuration radio, l'application compagne et les versions backend pertinentes, les composants de sécurité tiers, l'utilisation prévue, les rôles des utilisateurs, les catégories de données et la voie de conformité. Un nom de produit seul ne constitue pas une base. Deux variantes vendues sous le même nom peuvent exposer différentes interfaces ou activer différentes fonctions. De nombreuses lacunes courantes de EN 18031 avant le lancement commencent avec ce périmètre étant dessiné trop étroitement autour de l'appareil. 

La base de référence devrait également enregistrer la référence exacte de la norme harmonisée et les conditions du Journal Officiel utilisées pour la conformité de la revendication. EN 18031-1, EN 18031-2 et EN 18031-3 ont été cités sous RED via la Décision d'exécution de la Commission (UE) 2025/138, avec des restrictions. Un changement affectant le comportement des mots de passe, le contrôle d'accès parental ou les mises à jour sécurisées dans les équipements capables de paiement peut donc influencer plus qu'un résultat de test. Cela pourrait affecter si la voie de conformité choisie fonctionne toujours. Pour les produits connectés à Internet, l'aperçu EN 18031-1 de QIMA fournit un contexte supplémentaire sur les limites du produit et les preuves du dossier technique. 

Construire un Delta de preuves pour chaque version du microprogramme

Placez l'examen de la preuve entre le jeu de changement d'ingénierie et la publication finale de l'approbation. À ce stade, l'équipe sait ce qui a changé, mais il est encore temps de mettre à jour la documentation, exécuter des tests ciblés ou impliquer un spécialiste de la conformité avant que la construction atteigne la production ou les appareils déployés.

L’examen devrait retracer le changement à travers le produit plutôt que de classer la publication comme « mineure » ou « majeure ». Les exemples suivants montrent où cette trace mène habituellement.

Chaque élément affecté reçoit alors l'une des quatre dispositions.  

Utilisez un delta de preuve pour chaque configuration publiée. Il devrait enregistrer :

1. La version firmware et les variantes de produit ou de matériel affectées.

2. Les fonctions , composantes, interfaces et hypothèses qui ont changé.

3. Les conclusions EN 18031 et les enregistrements de fichiers techniques affectés par ces changements.

4. La disposition de chaque élément de preuve existant : conservée, complétée, remplacée ou escaladée.

5. Nouveaux tests, décisions de vulnérabilité, contributions des fournisseurs et références de preuves. 

6. Le réviseur, date d'approbation et décision finale de sortie. 

Ces champs transforment une discussion d'impact sur le changement en un enregistrement qu'une autre personne peut reconstruire plus tard.

Une décision conservée est toujours une preuve. Elle devrait être liée à l'artefact précédent et expliquer pourquoi ses hypothèses restent vraies. Une case à cocher a marqué « aucun impact» sans raisonnement sera difficile à défendre des mois plus tard, surtout après que les personnes impliquées se soient déplacées vers un autre projet.

Changer la taille est un proxy pauvre pour l'impact des preuves

Considérez un contrôleur de construction connecté à . Le microprogramme 2.3.1 met à jour sa bibliothèque TLS pour corriger la vulnérabilité. Les protocoles supportés, la gestion des clés, les flux de données, les interfaces externes et les chemins de mise à jour restent les mêmes. L'équipe peut seulement avoir besoin de mettre à jour les enregistrements des composants et vulnérabilités, préservez le nouvel identifiant de compilation, vérifiez la cryptographie configurée et exécutez des tests de régression ciblés. La preuve de l'architecture et du contrôle d'accès peut rester applicable, si la conclusion est documentée et si l'intégration réelle la supporte.

Le micrologiciel 3.0 ajoute alors l'administration à distance via une nouvelle API cloud. Ce changement rouvre les limites du produit, le diagramme de flux de données, l'inventaire des interfaces externes, les scénarios de menace, les rôles d'administrateur, l'authentification, la journalisation, la dépendance aux services backend et éventuellement l'évaluation des données personnelles. Le besoin de nouvelles preuves provient de l'exposition modifiée, pas du numéro de version majeur. 

Les directives de la Commission européenne de juillet 2026 sur la Cyber Resilience Act suivent la même logique basée sur les risques pour des modifications substantielles. Il invite les fabricants à examiner si une mise à jour logicielle introduit de nouveaux vecteurs de menace ou des scénarios d'attaque ou modifie la probabilité ou l'impact des mises à jour existantes. Elle explique également qu'une mise à jour de sécurité n'est généralement pas substantielle lorsqu'elle laisse le but visé inchangé et n'introduit aucun nouveau risque de cybersécurité, même si le changement technique est significatif.

Ce sont des considérations CRA, et non une substitution à une évaluation EN 18031 sous RED. Elles sont utiles maintenant car elles montrent pourquoi les étiquettes telles que “correctif de sécurité”, “nouvelle fonctionnalité” ou “mise à jour mineure” ne suffisent pas. L'effet du produit doit être examiné. 

Garder les preuves anciennes au lieu de les écraser

La documentation technique devrait rester à jour, mais « actuelle » ne signifie pas que le dossier précédent devrait disparaître. RED exige des fabricants qu'ils conservent la documentation technique et la déclaration de conformité de l'UE pendant dix ans après la mise sur le marché de l'équipement radio. Si un produit reste en série sur plusieurs versions, le fabricant peut avoir besoin de reconstruire quelle configuration supportait un lot ou une unité de production particulière.

Maintenir un registre de version qui connecte chaque version au modèle et aux révisions matérielles applicables, à la production ou aux gammes séries, le déploiement de la population, le delta des preuves, les versions des documents, les résultats des tests, les approbations et toute communication du corps notifié. Pour une mise à jour en direct, préservez également les enregistrements de déploiement et de retour en arrière. Cela crée un échéancier de ce qui a été évalué, de ce qui a changé et des éléments de preuve qui ont appuyé chaque décision.

Ne pas éditer un seul fichier appelé EN18031_Assessment_Final en place. Lorsque les anciennes hypothèses sont remplacées silencieusement, le fichier peut décrire la version la plus récente tout en ne laissant aucun enregistrement fiable pour les anciennes unités. Les notes de publication ne sont pas un substitut, elles montrent ce que l'ingénierie a changé, mais pas pourquoi une conclusion de conformité antérieure tient toujours.

La même discipline s'applique à la preuve du fournisseur. Un nouveau rapport de bibliothèque, une déclaration de module ou une feuille de données de sécurité ne prouvent pas automatiquement que le produit final reste couvert. Le fabricant doit encore identifier la version et la configuration exactes utilisées, vérifier les hypothèses qui comptent pour le produit et relier le document du fournisseur à des preuves au niveau du produit.

Utilisez le dossier RED pour vous préparer à la gestion de vulnérabilité de l'ARC

Cette histoire de mise à jour a une valeur immédiate au-delà de la prochaine révision RED. Le règlement délégué sur la cybersécurité RED reste applicable jusqu'au 10 décembre 2027. Le règlement délégué (UE) 2026/339 le révoque à partir du 11 décembre 2027, lorsque les principales obligations CRA s'appliquent. L'aperçu de CRA de QIMA explique sa relation avec RED et d'autres règles de l'UE. 

Les obligations de déclaration CRA sont déjà en vigueur. Depuis le 11 septembre 2026, les fabricants sont tenus de signaler les vulnérabilités exploitées activement et les incidents de sécurité graves affectant les produits concernés. Les directives officielles de déclaration de la Commission imposent un délai d'alerte précoce de 24 heures et un délai de notification complète de 72 heures. Ses directives d'application de juillet 2026 indiquent également que l'obligation de déclaration couvre les produits concernés mis sur le marché avant la date d'application principale de la CRA. 

Une piste de preuve spécifique à une version donne un début à l'équipe de vulnérabilité. Il montre quelles versions publiées contiennent un composant affecté, comment ce composant est configuré, quelles interfaces le exposent et quels périphériques ont reçu le firmware concerné. Il ne décide pas si un événement est rapportable, mais il réduit le temps passé à reconstruire le produit pendant que l'horloge du rapport est en cours d'exécution.

Les lignes directrices de l'ARC de juillet 2026 indiquent également des essais axés sur des événements. Les fabricants devraient examiner si de nouvelles menaces, vulnérabilités ou modifications de produits nécessitent que le test soit modifié, puis exécuter les tests pertinents. Il ne demande pas la répétition mécanique d'une campagne d'essai inchangée à intervalles fixes. Les mêmes lignes directrices permettent de réutiliser la documentation existante et les résultats des tests pour les parties non affectées d'un produit modifié de façon substantielle. C'est la valeur à plus long terme d'un delta de preuves: il préserve la réutilisation sans permettre à de vieilles preuves de dériver du produit.

Pour un point de départ structuré, utilisez le cahier de tâches RED et CRA pour les produits connectés pour cartographier la portée du produit, EN 18031, preuves, lacunes des fournisseurs, rapport de vulnérabilité et plan d’action de 30 jours.

Lors de la révision de la publication, remplacez la question « Le document EN 18031 a-t-il été mis à jour ? avec “Quelles conclusions de conformité ont changé, et où est la preuve de cette décision?”

La carte des exigences spécifiques aux produits de Cyberexpert, la liste de contrôle des preuves et l'espace de travail de gestion des vulnérabilités fournissent des produits, , QA et les équipes de conformité sont partagées pour relier les exigences, les risques, les propriétaires de preuves et les changements de publication. Cyberexpert prend en charge la préparation de la préparation des preuves. Il ne certifie pas le produit et la responsabilité de la conformité demeure avec le fabricant. Étendez votre produit connecté gratuitement pour identifier quelle preuve EN 18031 votre prochaine version de firmware devrait rouvrir.