Le Cyber Resilience Act exige que les produits soient conçus, développés et fabriqués avec un niveau de cybersécurité approprié, et livrés avec une configuration par défaut sécurisée. Il ne dit pas comment. En juillet 2026, l’ENISA, l’Agence de l’Union européenne pour la cybersécurité, a publié le Secure by Design and Default Playbook pour combler en partie ce manque à l’intention des petits et moyens fabricants.
C’est l’un des documents les plus pratiques publiés jusqu’ici autour du CRA. Cet article résume son contenu et la façon de l’utiliser.
Ce qu’il est, et ce qu’il n’est pas
Le playbook en est à la version 1.0, publiée après une consultation publique en avril et mai 2026 qui a recueilli 28 contributions de fabricants, de praticiens et de la communauté open source. Il est gratuit et publié sous licence CC BY 4.0.
Il s’adresse aux PME qui fabriquent des produits comportant des éléments numériques : logiciels embarqués, objets connectés IoT, systèmes connectés, logiciels autonomes et matériel doté de composants programmables. Il est écrit pour ceux qui font le travail : développeurs, chefs de produit techniques, architectes et le responsable sécurité qui porte souvent plusieurs autres casquettes.
L’ENISA est claire sur ses limites. Le playbook n’est pas un avis juridique ni un manuel de conformité. Le suivre ne rend pas à lui seul un produit conforme au CRA ou certifiable selon une norme. C’est un point de départ pratique qui traduit des principes en actions d’ingénierie reproductibles, et une annexe relie ces principes aux exigences essentielles du CRA.
Comment il est organisé
Le document comporte cinq parties :
- Secure by design et par défaut tout au long du cycle de vie du produit, y compris une gestion des risques et un threat modeling allégés.
- Les principes de secure by design et de secure by default.
- Un playbook par principe, 22 au total. C’est le cœur du document.
- L’attestation lisible par machine : comment exprimer des déclarations de sécurité et des preuves dans un format vérifiable par des outils.
- Des annexes listant les exigences essentielles du CRA et reliant chaque principe à celles-ci.
Cycle de vie et gestion des risques, version légère
Le playbook suit un produit à travers six processus du cycle de vie : exigences, conception, implémentation, vérification, déploiement, et maintenance et mise au rebut. Pour chacun, il liste des actions et un livrable concret, et ces livrables sont volontairement modestes : un contexte de sécurité d’une page, un schéma d’architecture avec les frontières de confiance, une courte liste d’exigences, une liste de contrôle de sécurité pour les releases, un processus d’une page pour les vulnérabilités et les correctifs.
Trois règles le traversent pour les PME :
- Utilisez des artefacts petits et réutilisables : notes d’une page, schémas simples, listes de contrôle.
- Préférez les contrôles automatisés en CI/CD aux revues manuelles, et réservez les revues approfondies aux changements à haut risque.
- Ajoutez des security gates rapides aux rituels que vous avez déjà, comme la definition of done, les contrôles de pull request et la liste de contrôle de release.
La gestion des risques reçoit le même traitement. Au lieu d’un cadre formel, le playbook propose une courte série d’activités : un contexte de sécurité produit d’une ou deux pages, une liste des actifs clés et des effets indésirables, un registre des risques vivant de 10 à 30 risques, une politique d’acceptation des risques d’une page, une revue des risques avant la release, et une réévaluation lorsqu’un changement important survient. La politique d’acceptation comprend des points non négociables, comme ne jamais accepter un détournement du mécanisme de mise à jour, un accès administrateur non autorisé ou des identifiants par défaut exploitables.
Le threat modeling pour les équipes sans expert
Le threat modeling est au centre de l’approche. Le playbook l’organise autour des quatre questions de Shostack :
- Sur quoi travaillons-nous ?
- Qu’est-ce qui peut mal tourner ?
- Qu’allons-nous faire ?
- Avons-nous fait du bon travail ?
Pour la plupart des produits de PME, l’objectif est un “minimum viable model” : un schéma avec les frontières de confiance et les chemins privilégiés, les 5 à 10 principaux scénarios de menace avec une priorité, pour chacun une atténuation et un réglage par défaut sécurisé, pour chaque mesure une méthode de vérification, et des déclencheurs définis pour mettre le modèle à jour, comme une nouvelle interface exposée à Internet ou un changement du modèle d’authentification. STRIDE est proposé comme une façon de trouver les menaces, pas la seule.
Deux points que je soulignerais. L’ENISA dit qu’un threat modeling léger ne demande pas de spécialistes, mais des personnes qui connaissent bien le produit. Et elle nomme les écueils : traiter le threat modeling comme un exercice de conformité ponctuel, construire des modèles qui n’influencent aucune décision de conception, et ne jamais les mettre à jour. Pour les produits intégrant de l’IA, elle demande de prendre en compte les attaques propres à l’IA, comme l’injection de prompt et l’empoisonnement de modèle.
22 principes en quatre groupes
Les principes se répartissent entre secure by design (la façon dont le produit est conçu) et secure by default (la façon dont il arrive et se comporte quand l’utilisateur l’allume pour la première fois), chacun en deux groupes :
| Groupe | Principes |
|---|---|
| Secure by design : fondations architecturales | Frontières de confiance et threat modeling ; moindre privilège ; architecture solide d'identité et d'authentification ; réduction de la surface d'attaque ; défense en profondeur ; conception ouverte |
| Secure by design : intégrité opérationnelle | Gestion du cycle de vie ; conception centrée sur l'utilisateur ; développement sécurisé et vérification ; journalisation, surveillance et alertes ; gestion de la configuration et des changements ; réponse aux incidents et reprise ; gestion des vulnérabilités et des correctifs ; contrôles de la chaîne d'approvisionnement |
| Secure by default : durcissement par défaut | Services par défaut réduits au minimum ; accès initial restrictif ; communication sécurisée par défaut ; identité d'appareil et secrets uniques par défaut |
| Secure by default : protection guidée | Intégration de sécurité obligatoire ; maintenance et mises à jour automatisées ; posture de sécurité transparente ; cycle de vie sécurisé pour la récupération et la propriété |
La plupart sont familiers à quiconque a travaillé en sécurité applicative. C’est sur le secure by default que beaucoup de produits pèchent encore en pratique : pas d’identifiants admin/admin partagés, des clés uniques par appareil, du chiffrement dès la première connexion, des mises à jour de sécurité automatiques activées, un assistant d’installation qui impose les choix de sécurité importants, et un avertissement clair avec un retour en un clic quand un utilisateur affaiblit la configuration.
Les playbooks : liste de contrôle, preuves, release gate
Chacun des 22 playbooks tient sur environ une page et suit les mêmes cinq rubriques :
- le principe mis en œuvre
- l’objectif, y compris les défaillances qu’il évite
- une liste des actions les plus efficaces pour une petite équipe
- les preuves minimales montrant que la liste a été appliquée
- une release gate : des critères de réussite ou d’échec à reprendre dans une revue de release ou un pipeline CI/CD
Le playbook sur la gestion des vulnérabilités et des correctifs montre à quel point cela devient concret. Sa liste couvre les canaux de signalement avec un responsable unique, un tri avec les indicateurs “exposé à Internet” et “exploitation connue”, un rythme régulier de mise à jour des dépendances, la connaissance des délais de notification, et la publication d’avis lisibles par machine avec CSAF et VEX lorsque c’est proportionné. Les preuves minimales comprennent un registre des vulnérabilités, des SLA définis, les résultats d’analyse de la CI, une SBOM par release et un journal des exceptions avec responsables et dates d’expiration. La release gate vérifie ensuite, entre autres, que les constats critiques et élevés sont corrigés ou font l’objet d’une exception documentée et limitée dans le temps, et que la SBOM de la release existe.
La partie sur les preuves est la plus précieuse pour préparer le CRA. L’ENISA insiste : les preuves n’exigent pas de documents distincts. Une SBOM, un résultat d’analyse ou un compte rendu de release peut servir plusieurs playbooks, et les traces d’ingénierie existantes, comme les schémas, tickets, résultats de tests et sorties de CI, doivent être réutilisées. C’est exactement l’état d’esprit qui évite que la documentation technique devienne un projet à part.
Par où commencer
Inutile d’adopter tous les playbooks à la fois. L’ordre suggéré :
- Établir le contexte et les priorités avec les activités de gestion des risques et de threat modeling et le playbook sur les frontières de confiance.
- Construire un socle d’ingénierie : développement sécurisé et vérification, journalisation et surveillance, gestion des vulnérabilités et des correctifs, et contrôles de la chaîne d’approvisionnement. Ajoutez les playbooks secure by default qui s’appliquent à votre produit : accès initial restrictif s’il comporte un accès utilisateur ou administrateur, communication sécurisée s’il communique par un réseau, identités et secrets uniques s’il utilise des identifiants, et mises à jour automatisées s’il peut être mis à jour.
- Élargir et renforcer le reste au fil du temps, en augmentant la couverture, la cohérence et l’automatisation.
L’ENISA ajoute une réserve importante : une adoption progressive ne signifie pas reporter ce que le CRA exige. L’ordre sert à répartir l’effort, pas à fixer des échéances.
L’attestation lisible par machine
La partie la plus prospective du playbook porte sur des preuves que les machines peuvent lire. Au lieu de rapports PDF, un fabricant publie des déclarations de sécurité structurées, par exemple en JSON, reliées aux preuves qui les fondent et aux résultats de vérification. L’exemple illustratif, un contrôleur de portail d’usine baptisé SafeGate-X1, utilise trois couches :
- une couche de contrôle avec les objectifs de sécurité, comme la protection contre les accès non autorisés
- une couche d’implémentation avec les déclarations sur la façon dont chaque objectif est atteint et les outils, versions et configurations concernés
- une couche d’évaluation et de vérification qui renvoie aux résultats de tests, aux synthèses SAST et aux empreintes des artefacts de build
Le playbook ne propose pas de nouveau format. Il renvoie à des travaux existants : OSCAL du NIST, les attestations CycloneDX (CDXA), le profil sécurité de SPDX 3.0, OpenSSF Security Insights et Scorecard, la provenance SLSA avec in-toto et Sigstore, et la Transparency Exchange API d’Ecma TC54. Il suggère aussi de séparer les déclarations publiques et signées d’une couche technique restreinte, accessible aux seules parties autorisées.
L’ENISA reste prudente ici aussi : une attestation du fabricant ne prouve pas qu’un produit est sûr. Attestation, vérification et évaluation indépendante sont des activités distinctes. La direction est pourtant claire. Une documentation technique générée par le pipeline reste à jour, et un build incapable de produire ses preuves peut être arrêté automatiquement.
La correspondance avec le CRA
L’annexe C relie chaque principe aux exigences essentielles de l’annexe I du CRA. Les frontières de confiance et le threat modeling soutiennent par exemple l’évaluation des risques, la protection contre les accès non autorisés, la confidentialité et l’intégrité, et la limitation de la surface d’attaque. La gestion des vulnérabilités et des correctifs correspond à l’identification et la documentation des composants et à la correction sans délai des vulnérabilités.
Cette correspondance est indicative et ne donne pas de présomption de conformité. Celle-ci viendra des normes harmonisées une fois citées au Journal officiel ; notre panorama des normes harmonisées du CRA indique où elles en sont. Elle reste un bon moyen de vérifier que vos pratiques de développement sécurisé couvrent chaque exigence essentielle, et de trouver les preuves dont vous aurez besoin pour la documentation technique.
Comment il s’articule avec OWASP SAMM
Le playbook cite OWASP SAMM comme une façon d’organiser et de faire mûrir les activités de sécurité tout au long du cycle de vie, et ses practices threat assessment et security requirements comme exemple de traduction des menaces en exigences testables. Les deux se complètent bien. SAMM vous dit quel est le niveau de maturité de chaque practice et à quoi ressemble l’étape suivante ; le playbook vous donne des listes de contrôle, des preuves et des release gates concrètes pour chaque principe. Nos articles sur le choix entre SAMM et BSIMM et sur les indicateurs SAMM traitent du volet maturité.
Notre avis
Pour une PME qui se prépare au CRA, c’est le document que je donnerais en premier au responsable de l’ingénierie. Il est court quand il peut l’être, concret là où cela compte, et il traite les preuves comme un sous-produit du travail d’ingénierie normal plutôt que comme un effort de conformité séparé. Les release gates, en particulier, peuvent passer directement dans une definition of done ou un pipeline CI.
Deux choses à garder à l’esprit. C’est une introduction, pas une méthode complète : les produits destinés à des usages critiques ou à haut risque demandent plus de profondeur que les versions minimales décrites ici. Et il ne remplace pas l’évaluation des risques que le CRA exige pour chaque produit ; il vous aide à la réaliser.
Si vous souhaitez de l’aide pour mettre les playbooks en pratique, notre formation au threat modeling couvre les activités de conception, notre SSDLC Maturity Assessment montre où en est votre processus de développement, et le lot 6 de l’EU CRA Compliance Journey met en pratique le secure by design et par défaut.