Partager l'article
Dans son « Secure by Design and Default Playbook », l’ENISA, l’Agence de l’Union européenne pour la cybersécurité, précise pour la première fois comment les fabricants de produits comportant des éléments numériques peuvent mettre en œuvre, sur les plans technique et organisationnel, les exigences du Cyber Resilience Act (CRA).
Avec la version 1.0 (juillet 2026) du « Secure by Design and Default Playbook », l’ENISA a publié la version définitive de son guide pratique. Celle-ci tient compte des résultats de la consultation publique menée au printemps 2026, qui a recueilli 28 contributions de l’industrie, des autorités publiques et de la communauté open source. Elle contient de nombreuses précisions techniques ainsi que de nouvelles recommandations pour la mise en œuvre.
Le guide pratique s’adresse en particulier aux fabricants de logiciels et de dispositifs IoT. Son objectif est d’intégrer systématiquement la cybersécurité tout au long du cycle de vie des produits. Dans cet article, nous résumons les principaux éléments du document.
Quels sont les objectifs du « Playbook » de l'ENISA et comment est-il structuré ?
L’approche de l’ENISA repose sur l’intégration systématique de la sécurité dès les premières phases du développement, une démarche également appelée « Shift Left » dans la terminologie technique.
Les exigences de sécurité ne sont donc pas prises en compte uniquement lors des essais ou pendant l’exploitation, mais dès la définition des exigences, la conception de l’architecture et le choix des technologies.
Cette approche axée sur le cycle de vie couvre les phases suivantes :
Ces différentes phases ont également fait l’objet d’une révision technique dans la version 1.0.
L’ENISA précise par ailleurs que ces processus sont présentés comme des regroupements et non comme un modèle séquentiel obligatoire. Ils peuvent se chevaucher, être menés de manière itérative et être répétés tout au long du cycle de vie du produit.
Dans des environnements agiles, par exemple, les exigences de sécurité peuvent être identifiées puis progressivement affinées à l’aide d’éléments du backlog, de user stories, de critères d’acceptation et de la « Definition of Done ».
La terminologie s’aligne ainsi davantage sur les processus de développement classiques, notamment ceux décrits dans les séries de normes IEC 62443 ou IEC 61508.
La version définitive définit pour la première fois explicitement les résultats visés (« Intended Outcomes »), qui étaient encore totalement absents du projet soumis à consultation :
Le Playbook structure les exigences autour de 22 principes répartis dans deux catégories : « Secure by Design » et « Secure by Default ». Ces principes sont mis en œuvre au moyen de mesures techniques concrètes, d’exigences en matière de preuves et de critères de validation.
Parmi les principales exigences techniques figurent la modélisation standardisée des menaces, des architectures logicielles sécurisées fondées sur des principes établis – tels que le « Least Privilege » et la « Defense in Depth » –, des configurations par défaut sécurisées ainsi qu’une gestion continue des vulnérabilités.
S’y ajoutent des exigences relatives à la surveillance, à la réponse aux incidents (« Incident Response ») et à la capacité de rétablissement. La résilience est ainsi considérée comme une composante essentielle de l’exploitation opérationnelle.
Un élément innovant est le « Machine-Readable Security Manifest », dont le concept a été élargi dans la version 1.0 et désigné sous le terme « Machine-processable Attestation ». Il permet de documenter de manière structurée et exploitable par machine les mesures de sécurité ainsi que les preuves associées.
La conformité peut ainsi être davantage automatisée et mise à l’échelle, ce qui constitue une avancée importante pour la démonstration de la conformité réglementaire.
Outre les mesures techniques, l’ENISA met également l’accent sur des aspects organisationnels tels que la définition claire des responsabilités, l’intégration de la sécurité dans les décisions relatives aux produits et la sécurisation des chaînes d’approvisionnement.
La sécurité devient ainsi une mission interdisciplinaire impliquant le développement, l’exploitation et le management.
Dans l’ensemble, le Playbook marque un changement de paradigme : la cybersécurité évolue d’une fonction complémentaire mise en œuvre en aval vers une composante intégrée et vérifiable de l’ensemble du cycle de vie du produit.
Pour les fabricants, cela implique non seulement des exigences réglementaires accrues, mais également la nécessité d’adapter en profondeur leurs processus de développement.
Le message essentiel est le suivant : la cybersécurité est un processus continu, et non une fonctionnalité mise en œuvre une seule fois.
Quel est l’objectif des 22 principes de sécurité (« Principles ») ?
Le Playbook définit 22 principes concrets, répartis en deux catégories principales :
Chacun des 22 principes est présenté de manière détaillée au chapitre 4 du document de l’ENISA, intitulé « Playbook », selon différents critères : objectif, éléments techniques de mise en œuvre, preuves (« Evidence ») et critères de validation.
L’objectif du Playbook est de transposer les principes de sécurité du niveau conceptuel vers des pratiques concrètes et applicables en matière d’ingénierie et d’exploitation.
Pour chaque principe, des étapes de mise en œuvre claires ainsi que des critères vérifiables sont définis. La sécurité devient ainsi une composante mesurable et auditable du processus de développement.
Les 22 principes suivent une structure homogène afin de permettre une application standardisée et reproductible :
Quelles exigences spécifiques peut-on en déduire concrètement pour les systèmes OT ?
Dans la conception des architectures et des réseaux OT, la segmentation systématique des systèmes industriels occupe une place centrale.
Cette approche repose sur un modèle de zones et de conduits inspiré de la série de normes IEC 62443. Celui-ci divise les installations en zones de sécurité clairement délimitées et permet de contrôler de manière ciblée les communications entre ces différentes zones.
Une séparation stricte des réseaux IT et OT est également nécessaire afin d’empêcher les déplacements latéraux des attaquants entre les réseaux et de limiter les conséquences des incidents de sécurité.
La séparation physique souvent supposée, appelée « Air Gap », ne doit toutefois pas être considérée comme une garantie de sécurité.
Les connexions réellement nécessaires – par exemple pour la maintenance, la surveillance ou l’intégration de données – doivent au contraire être explicitement identifiées et sécurisées au moyen de passerelles contrôlées. Cela comprend notamment l’utilisation de pare-feu, de passerelles de protocoles et d’interfaces surveillées.
Une attention particulière doit également être accordée à la sécurisation des accès à distance, qui sont souvent indispensables dans les environnements industriels.
Ces accès devraient exclusivement être réalisés au moyen de mécanismes renforcés, par exemple des connexions VPN associées à une authentification multifacteur ainsi qu’à des Jump Hosts dédiés, afin d’empêcher tout accès direct aux systèmes critiques.
*Un « Jump Host » est un ordinateur spécialement sécurisé qui sert de point d’accès central et contrôlé afin de permettre un accès sécurisé à des systèmes internes protégés depuis un réseau externe, par exemple Internet.
Pourquoi la modélisation des menaces est-elle un processus obligatoire dans les environnements OT ?
Dans les environnements OT, la modélisation des menaces doit être intégrée comme une composante obligatoire du processus d’ingénierie. Les scénarios d’attaque typiques et spécifiques aux systèmes industriels doivent être pris en compte de manière systématique. Il s’agit notamment de la manipulation ciblée de la logique des automates programmables industriels (API/PLC), qui peut permettre d’influencer directement des processus physiques.
Les risques liés à des protocoles de communication industriels non sécurisés ou mal configurés, tels que Modbus ou OPC UA, doivent également être pris en compte, car ceux-ci peuvent présenter des mécanismes de sécurité insuffisants.
Un autre scénario d’attaque important concerne les mouvements latéraux via les postes de travail d’ingénierie. Ces postes jouent souvent un rôle de passerelle entre les réseaux IT et OT et représentent donc une cible particulièrement intéressante pour les attaquants. Les attaques visant la chaîne d’approvisionnement gagnent également en importance, notamment lorsqu’elles concernent des micrologiciels compromis ou des mécanismes de mise à jour manipulés.
Un point essentiel est que la modélisation des menaces dans les environnements OT doit aller au-delà des considérations classiques de sécurité informatique. Elle doit impérativement prendre en compte les conséquences possibles sur les processus physiques ainsi que sur les fonctions liées à la sécurité fonctionnelle (« Safety »).
Ce n’est qu’à cette condition qu’il est possible d’évaluer de manière réaliste le profil de risque effectif des systèmes industriels et de prendre des mesures appropriées.
Quel rôle jouent la gestion des risques et la sécurité opérationnelle dans ce contexte ?
Le Playbook définit huit activités essentielles dans les domaines de la gestion des risques et de la sécurité opérationnelle. Celles-ci doivent être établies sous la forme de processus continus.
Elles comprennent notamment :
Des mesures complètes de surveillance de la sécurité et de journalisation sont également nécessaires afin de détecter les attaques à un stade précoce et de pouvoir les analyser de manière traçable.
La conception de la résilience qui sous-tend cette approche joue ici un rôle essentiel : la résilience n’est pas considérée comme un simple objectif de l’architecture du système, mais comme une capacité opérationnelle qui doit être activement mise en œuvre, vérifiée et améliorée en continu au cours de l’exploitation.
Adoption progressive des Playbooks : comment les entreprises peuvent-elles introduire progressivement le « Secure by Design » ?
L’une des principales nouveautés de la version 1.0 de l’ENISA est le nouveau chapitre intitulé « Progressive Adoption of the Playbooks ».
L’ENISA y décrit pour la première fois une approche pragmatique permettant aux entreprises – et notamment aux petites et moyennes entreprises (PME) – d’intégrer progressivement les 22 principes « Secure by Design » et « Secure by Default » dans leurs processus de développement.
Il est important de souligner que, selon l’ENISA, cette introduction progressive concerne uniquement la mise en œuvre pratique des différentes mesures.
Les obligations légales, notamment celles découlant du Cyber Resilience Act (CRA), ne peuvent en aucun cas être retardées ou reportées. L’ordre proposé constitue uniquement une orientation permettant une mise en œuvre structurée et adaptée aux ressources disponibles.
L’ENISA recommande une approche en trois phases successives :
Dans un premier temps, les fabricants devraient analyser le contexte du produit, les conditions d’utilisation prévues ainsi que les principaux cyberrisques.
Des analyses de risques et des activités de Threat Modelling permettent d’identifier les menaces pertinentes, les limites de confiance (« Trust Boundaries ») et les objectifs de sécurité.
Sur cette base, les mesures de sécurité requises peuvent être hiérarchisées et le périmètre de mise en œuvre défini de manière appropriée.
Dans un deuxième temps, l’ENISA recommande de mettre en place une base d’ingénierie fondamentale.
Celle-ci comprend notamment :
Selon le type de produit, certaines fonctionnalités essentielles de « Secure by Default » devraient également être mises en œuvre.
Il peut s’agir, par exemple, de droits d’accès restrictifs par défaut, de protocoles de communication sécurisés, d’identités uniques pour les appareils ou encore de mises à jour de sécurité automatisées.
Les autres Playbooks doivent être hiérarchisés en fonction des risques identifiés et du contexte du produit.
Une fois une base solide établie, d’autres principes « Secure by Design » et « Secure by Default » devraient être progressivement mis en œuvre.
L’objectif est d’augmenter continuellement le niveau de maturité des mesures de sécurité, d’améliorer leur cohérence et d’automatiser autant de processus que possible.
Parallèlement, l’ENISA recommande d’évaluer régulièrement les progrès réalisés à l’aide d’indicateurs et de preuves appropriés.
En résumé, avec le concept de « Progressive Adoption », l’ENISA fournit pour la première fois un guide de mise en œuvre pratique pour l’introduction du « Secure by Design ».
Au lieu de devoir mettre en œuvre toutes les mesures de sécurité simultanément, les entreprises peuvent adopter une approche fondée sur les risques et développer progressivement leurs processus de sécurité.
Pour les PME en particulier, cette approche constitue une possibilité réaliste d’intégrer systématiquement et durablement les exigences du Cyber Resilience Act dans le processus de développement des produits, sans toutefois remettre en question l’obligation de conformité complète.
La version 1.0 recommande également pour la première fois explicitement l’utilisation de l’OWASP Software Assurance Maturity Model (SAMM) comme modèle de maturité adapté à la mise en œuvre organisationnelle du « Secure by Design ».
Ce modèle permet de structurer systématiquement les activités de sécurité tout au long du cycle de développement logiciel et de les faire évoluer en continu.
Les domaines « Threat Assessment » et « Security Requirements », en particulier, montrent de manière exemplaire comment les menaces identifiées peuvent être transformées en exigences de sécurité vérifiables.
Qu’est-ce qu’une « Machine-processable Attestation » et comment est-elle utilisée pour assurer la traçabilité ?
Dans la version 1.0, le concept de « Machine-Readable Security Manifest » (MRSM) a été élargi et complété par celui de « Machine-processable Attestation ». Dans la version définitive, l’ENISA s’éloigne donc partiellement du terme MRSM et décrit plus généralement des preuves de sécurité pouvant être traitées par machine.
Le concept devient ainsi plus neutre sur le plan technologique et permet à l’avenir d’utiliser d’autres formats qu’un simple Security Manifest. Il s’agit d’une approche visant à représenter les preuves de sécurité sous une forme structurée et exploitable par machine. L’objectif est de documenter les exigences de sécurité de manière systématique et traçable.
Dans son principe, le MRSM associe des déclarations de sécurité (« Security Claims ») à des preuves techniques concrètes telles que des données de configuration, des résultats d’essais ou des journaux. Il en résulte une base fiable et automatisable pour évaluer le niveau de sécurité d’un produit.
L’un des principaux avantages réside dans la possibilité de réaliser des contrôles automatisés de conformité, par exemple dans le cadre d’audits. La « Machine-processable Attestation » répond ainsi à un enjeu majeur des exigences réglementaires : fournir une documentation de conformité à la fois vérifiable et évolutive, allant au-delà de preuves purement statiques ou manuelles.
Comment les exigences du Cyber Resilience Act (CRA) sont-elles concrètement mises en œuvre dans le Playbook ?
L’annexe C du Playbook établit une correspondance directe entre les 22 principes de sécurité et les exigences de l’annexe I du Cyber Resilience Act (CRA).
Il en découle des obligations claires pour les fabricants :
La cybersécurité devient ainsi une exigence réglementaire contraignante et ne constitue plus une option.
Le « Secure by Design and Default Playbook » de l’ENISA fournit un cadre à la fois pratique et structuré permettant d’intégrer systématiquement la cybersécurité tout au long du cycle de vie des produits.
Il convient notamment de souligner son approche résolument pratique de la mise en œuvre des exigences de sécurité. Plutôt que de se limiter à des orientations abstraites, le Playbook met l’accent sur des mesures concrètes, des preuves vérifiables et des critères de validation clairs.
Pour les fabricants – notamment dans le contexte du Cyber Resilience Act –, cela représente un véritable changement de paradigme.
La sécurité n’est plus considérée comme une mesure complémentaire, mais comme une composante intégrante du développement, de l’exploitation et de l’organisation.
La mise en place de processus standardisés tels que la modélisation des menaces, la gestion continue des vulnérabilités et les preuves de conformité automatisables permet d’améliorer à la fois le niveau de sécurité et la traçabilité.
Le Playbook constitue en particulier un cadre d’orientation précieux pour les environnements industriels et OT, car il associe les exigences réglementaires à des conditions opérationnelles réalistes.
Sa mise en œuvre nécessite toutefois une collaboration étroite entre l’ingénierie, l’exploitation et l’organisation, ainsi qu’une adaptation des processus de développement et d’exploitation existants.
Dans l’ensemble, le Playbook de l’ENISA constitue ainsi une base solide permettant de mettre en œuvre et d’ancrer la cybersécurité de manière efficace, durable et vérifiable.
La version définitive poursuit de manière cohérente le développement du projet initial soumis à consultation.
Alors que ce dernier proposait déjà un guide pratique pour le « Secure by Design », la version 1.0 le complète notamment par :
Le Playbook devient ainsi de plus en plus un modèle de référence pratique pour la mise en œuvre technique des exigences du Cyber Resilience Act.
Téléchargement du Playbook
Vous pouvez consulter et télécharger la version 1.0 du « ENISA Secure by Design and Default Playbook » via le lien suivant :
ENISA « Secure by Design and Default Playbook »
Publié le : 04/08/2026 (dernière mise à jour)
Wolfgang Reich Conférencier spécialisé en marquage CE et Safexpert HTL électrotechnique, spécialité technique énergétique (Dipl.-HTL-Ing.); 20 ans d'expérience dans le domaine du marquage CE, de la sécurité des machines, de la transformation de machines, de l'électrotechnique et de la protection contre les explosions, dont 10 ans chez TÜV Austria et Intertek Deutschland GmbH. Président de la commission d'examen de maîtrise à la Chambre économique de Styrie pour la mécatronique (technique d'automatisation et électronique).
E-Mail: wolfgang.reich@ibf-solutions.com
Logiciel CE pour une ingénierie de sécurité systématique et professionnelle
Séminaires pratiques sur le thème de la sécurité des produits
Mit dem CE-InfoService bleiben Sie informiert bei wichtigen Entwicklungen im Bereich Produktsicherheit