Cyber Resilience Act: la sécurité “by design” s’impose au cœur des matériels informatiques

Le Cyber Resilience Act remet la sécurité au centre du matériel informatique, pas en “couche” ajoutée. La logique “security by design” devient un choix d’architecture, qui engage le silicium, le firmware et la chaîne d’approvisionnement. Pour les industriels, le coût de la non-sécurité se déplace vers la conception.

Pendant des années, l’industrie a traité la sécurité comme une surcouche logicielle, patch après patch, au rythme des vulnérabilités et des mises à jour. Or la multiplication des objets connectés, des équipements industriels numérisés et des systèmes embarqués a fait émerger une réalité plus rude: quand la racine du risque se situe dans le matériel ou dans le firmware, corriger après coup devient lent, partiel, parfois impossible.

Le Cyber Resilience Act (CRA) introduit une pression réglementaire qui change la hiérarchie des décisions techniques. La question n’est plus seulement “comment réagir à une faille”, mais “comment empêcher qu’elle existe” dans les composants et les fonctions les plus profondes du produit. Autrement dit, la sécurité “by design” n’est viable que si elle est pensée comme un élément de conception du matériel informatique, au même titre que la performance, la consommation énergétique ou la fiabilité.

Le Cyber Resilience Act pousse la sécurité dans l’architecture matérielle

Le CRA vise à faire de la cybersécurité un attribut intrinsèque des produits numériques, et pas un service optionnel. Dans le matériel informatique, cela se traduit par un déplacement des arbitrages: les choix de composants, d’interfaces, de mécanismes de démarrage et d’isolation ne relèvent plus seulement de l’optimisation technique, mais d’une stratégie de conformité et de réduction du risque.

Ce basculement a une conséquence directe: la sécurité se joue dans des zones où les équipes “produit” et “cyber” ne se parlaient pas toujours. Les ingénieurs hardware, les concepteurs de cartes, les architectes systèmes et les responsables firmware deviennent des acteurs de premier rang. Les fonctions de protection ne peuvent plus être ajoutées tardivement sans dégrader le produit, car elles touchent à des éléments structurants, comme la manière de stocker des secrets, de vérifier l’intégrité du code ou de limiter les privilèges.

Le texte pousse aussi à considérer l’équipement dans sa durée de vie: un matériel déployé dans une usine, un réseau, un bâtiment ou un véhicule doit rester maintenable, observable et capable de recevoir des correctifs sans introduire de nouveaux risques. Cette exigence favorise des conceptions qui intègrent dès le départ des mécanismes de mise à jour sécurisée, de journalisation et de contrôle d’intégrité, plutôt que de s’en remettre à des procédures manuelles.

Pourquoi “security by design” échoue quand elle arrive après le schéma électronique

Dans l’industrie, la tentation reste forte de traiter la sécurité comme une étape de validation finale, au même titre que certains tests de conformité. Or sur le matériel, cette approche se heurte à des limites physiques. Une fois la carte figée, un composant mal choisi, une interface de debug exposée, un schéma de confiance fragile ou un stockage de clés mal conçu deviennent des dettes difficiles à rembourser.

La sécurité “by design” suppose de raisonner en amont sur la surface d’attaque: quelles interfaces sont nécessaires, lesquelles doivent être désactivées en production, comment empêcher l’extraction de secrets, comment limiter les escalades de privilèges. Elle suppose aussi de définir un modèle de menace réaliste: attaque physique, compromission de la chaîne d’approvisionnement, exploitation à distance via une pile réseau, ou détournement d’un mécanisme de mise à jour.

Autrement dit, la sécurité n’est pas un ensemble de “bonnes pratiques” ajoutées au dernier moment. C’est une propriété systémique. Si l’architecture ne prévoit pas de racine de confiance, d’isolations claires, de mécanismes d’authentification robustes et d’une stratégie de mise à jour, les équipes se retrouvent à bricoler des protections logicielles sur un socle matériel qui n’a pas été conçu pour les supporter.

À cela s’ajoute un point souvent sous-estimé: la sécurité matérielle ne concerne pas seulement la confidentialité. Elle touche aussi la disponibilité et la sûreté de fonctionnement. Un équipement qui redémarre en boucle après une tentative de mise à jour, ou qui devient impossible à restaurer après une corruption, crée un risque opérationnel. La robustesse, ici, est une composante de la sécurité.

Du silicium au firmware: les briques techniques qui deviennent centrales

Le CRA met en lumière une chaîne technique continue, qui va du silicium au firmware, puis au logiciel. Dans ce continuum, certaines briques prennent un poids particulier.

D’abord, la notion de racine de confiance matérielle. Elle vise à ancrer des fonctions critiques, comme la protection des clés cryptographiques ou la vérification d’intégrité, dans un composant ou une zone difficile à altérer. L’objectif est de réduire la dépendance à des protections purement logicielles, plus exposées à des attaques de type injection, corruption mémoire ou contournement de contrôles.

Ensuite, le démarrage sécurisé et la chaîne de confiance: si le système ne peut pas vérifier, étape après étape, que le code exécuté est authentique et non modifié, toute la pile devient vulnérable. Sur des équipements déployés longtemps, cette question se combine avec la mise à jour: comment accepter un nouveau firmware, comment gérer la révocation, comment éviter qu’une version ancienne et vulnérable puisse être réinstallée.

Troisième brique, l’isolation. Les architectures modernes cherchent à compartimenter: séparer les fonctions critiques, limiter les privilèges, réduire l’impact d’une compromission. Dans le monde embarqué, cela peut prendre la forme de zones d’exécution distinctes, de mécanismes de séparation mémoire ou de coprocesseurs dédiés à certaines fonctions de sécurité. Le but est simple: empêcher qu’une faille dans une fonction périphérique ouvre la porte au contrôle total.

Enfin, la visibilité et la capacité de diagnostic. Un matériel conçu pour être sécurisé doit aussi pouvoir être observé, sans exposer de portes dérobées. Les interfaces de debug, utiles en développement, deviennent un risque en production si elles ne sont pas verrouillées. La traçabilité des événements de sécurité, elle, devient un outil de gestion du risque et de maintenance.

Chaîne industrielle: achats, sous-traitants, documentation, la sécurité devient un livrable

La contrainte du CRA ne s’arrête pas au bureau d’études. Elle s’étend à la chaîne industrielle: sélection des composants, gestion des dépendances, sous-traitance du firmware, intégration de bibliothèques, et documentation. Le point clé est que la sécurité “by design” n’existe pas sans preuves, ni sans capacité à expliquer comment le produit a été conçu, testé, maintenu.

Pour les fabricants, cela signifie intégrer des exigences de conformité dans les appels d’offres, exiger des garanties sur certaines pratiques de développement, et organiser la traçabilité des éléments livrés par des tiers. La sécurité devient un livrable contractuel, au même titre qu’un niveau de performance ou une certification de compatibilité.

Cette logique change aussi la relation entre équipes: la cybersécurité ne peut plus être un “contrôle qualité” en bout de chaîne. Elle doit être une fonction qui participe aux arbitrages, qui valide des choix de composants, qui influence les calendriers, et qui s’assure que la maintenance est possible. Or, dans le matériel, les cycles sont plus longs, les modifications plus coûteuses, et les stocks rendent les changements tardifs encore plus complexes.

D’après L’Usine Digitale, l’idée centrale est que la sécurité “by design” n’est viable que si elle est positionnée au cœur de la conception du matériel informatique, ce qui implique de la traiter comme une contrainte d’ingénierie fondamentale et non comme une étape de conformité tardive.^[1]

Points clés sur la sécurité matérielle

• La sécurité se décide dans l’architecture, avant l’industrialisation.
• Le firmware et les mécanismes de mise à jour deviennent des fonctions critiques.
• La chaîne d’approvisionnement et la documentation pèsent autant que le code.
• L’isolation limite l’impact d’une compromission inévitable.

Cartes de synthèse: impacts du CRA sur le hardware

FAQ Cyber Resilience Act et sécurité by design

Le Cyber Resilience Act concerne-t-il aussi le matériel, ou seulement les logiciels?
Il vise les produits numériques, ce qui inclut des équipements où le matériel, le firmware et le logiciel forment un tout. Sur ces produits, les choix matériels conditionnent la sécurité globale.

Pourquoi la sécurité “by design” est-elle plus difficile sur le hardware?
Parce qu’une fois la conception figée et industrialisée, corriger une faiblesse matérielle est complexe. Les protections ajoutées après coup sont souvent moins efficaces que celles prévues dans l’architecture.

Quels sujets techniques deviennent prioritaires pour les fabricants?
La racine de confiance, le démarrage sécurisé, l’isolation des fonctions, la gestion des secrets, et la mise à jour sécurisée du firmware font partie des briques structurantes.

Quel impact sur la chaîne d’approvisionnement et les sous-traitants?
La sécurité devient un livrable: exigences contractuelles, traçabilité des éléments fournis, et capacité à documenter les choix et les contrôles réalisés.

La conformité peut-elle être traitée comme un simple dossier documentaire?
Non, car la documentation doit refléter une réalité d’ingénierie. Si la sécurité n’est pas intégrée au design, le produit accumule une dette difficile à corriger.