CRA : Secure by Design pour PME, quelles mesures mettre en place concrètement ?

Mis à jour le 14 septembre 2026

Le Secure by Design du CRA consiste à intégrer les exigences de cybersécurité dès la conception d'un produit comportant des éléments numériques, puis à maintenir cette sécurité pendant son cycle de vie.

Pour une PME, cela ne signifie pas nécessairement construire immédiatement un programme DevSecOps complexe.

Il faut d'abord savoir :

1. quels risques le produit doit maîtriser ;
2. quelles exigences de sécurité en découlent ;
3. comment livrer une configuration sûre par défaut ;
4. comment contrôler les dépendances ;
5. comment sécuriser les mises à jour ;
6. comment organiser la gestion des vulnérabilités ;
7. comment conserver les preuves permettant de démontrer que ces pratiques sont réellement appliquées.

Fin juillet 2026, l'ENISA a publié son Secure by Design and Default Playbook, un guide spécifiquement conçu pour rendre ces principes applicables aux contraintes des PME.

Le guide propose 22 playbooks couvrant notamment :

1. la conception ;
2. le développement ;
3. le déploiement ;
4. la maintenance ;
5. la gestion des vulnérabilités ;
6. les mises à jour ;
7. la fin de vie du produit.

La logique générale peut être résumée ainsi :

risque produit -> exigence de sécurité -> conception -> développement -> vérification -> livraison -> maintenance -> preuve

Pourquoi le Secure by Design devient-il important avec le CRA ?

Le Cyber Resilience Act ne demande pas uniquement aux fabricants de corriger les vulnérabilités après la commercialisation.

Son objectif est également d'intégrer la sécurité dans la manière dont les produits comportant des éléments numériques sont :

1. conçus ;
2. développés ;
3. produits ;
4. maintenus ;
5. mis à jour.

Selon le contexte et les risques, cela implique notamment de :

1. réduire les vulnérabilités dès la conception ;
2. limiter les fonctions inutiles ;
3. appliquer des configurations sûres par défaut ;
4. protéger les données et fonctions sensibles ;
5. réduire la surface d'attaque ;
6. gérer les composants tiers ;
7. fournir des mises à jour de sécurité ;
8. organiser le traitement des vulnérabilités pendant la période de support.

Pour un fabricant, la question n'est donc plus seulement :

Avons-nous sécurisé notre produit avant sa sortie ?

Elle devient :

Pouvons-nous démontrer que la sécurité a été intégrée aux décisions de conception, à chaque version importante et pendant la période de support du produit ?

Le calendrier CRA à connaître en septembre 2026

Le CRA est entré dans une phase d'application progressive.

Depuis le 11 septembre 2026, les fabricants concernés doivent notamment être capables de traiter les obligations de signalement applicables aux vulnérabilités activement exploitées et aux incidents graves affectant la sécurité de leurs produits.

Pour les PME éditant des logiciels, équipements connectés ou autres produits comportant des éléments numériques, attendre fin 2027 pour structurer le Secure by Design serait donc risqué.

Les pratiques de conception, de gestion des dépendances, de gestion des vulnérabilités ou de mise à jour nécessitent souvent plusieurs cycles de développement avant de devenir réellement maîtrisées.

Secure by Design et Secure by Default : quelle différence ?

Les deux concepts sont complémentaires.

Secure by Design

Le produit est conçu de manière à réduire les risques dès les premières décisions d'architecture.

Cela concerne notamment :

1. le modèle de menace ;
2. les frontières de confiance ;
3. l'authentification ;
4. l'autorisation ;
5. les privilèges ;
6. l'architecture ;
7. les dépendances ;
8. les pratiques de développement ;
9. les mécanismes de mise à jour ;
10. la journalisation ;
11. la récupération du produit.

Le principe consiste à intégrer les protections pendant la conception et le développement plutôt qu'à les ajouter uniquement à la fin.

Secure by Default

Le produit doit être livré dans l'état le plus sûr raisonnablement possible.

L'utilisateur ne devrait pas avoir à connaître toutes les bonnes pratiques de cybersécurité pour désactiver lui-même une configuration dangereuse.

Cela peut notamment impliquer :

1. des fonctions sensibles désactivées par défaut ;
2. des droits initiaux limités ;
3. des accès d'administration protégés ;
4. des communications sécurisées ;
5. des secrets uniques ;
6. un onboarding sécurisé ;
7. des mises à jour sécurisées ;
8. des services inutiles non exposés.

Le Secure by Default répond donc à une question simple :

Dans quel état de sécurité le client reçoit-il réellement le produit ?

Les 9 mesures prioritaires pour une PME

L'ENISA propose un ensemble plus large de playbooks.

Une PME ne doit pas pour autant transformer immédiatement cette documentation en 200 procédures.

Une première feuille de route peut être organisée autour de neuf mesures structurantes.

Cette synthèse n'est pas une checklist juridique exhaustive du CRA.

Elle fournit une architecture de mise en œuvre adaptée à une PME.

1. Évaluer les risques dès la conception

La première mesure ne consiste pas à installer un scanner de code.

Elle consiste à comprendre :

1. ce que fait le produit ;
2. quelles données il traite ;
3. quelles fonctions sont critiques ;
4. quelles interfaces sont exposées ;
5. où sont les frontières de confiance ;
6. quelles dépendances externes existent ;
7. quelles conséquences aurait une compromission.

L'évaluation doit tenir compte de l'utilisation prévue du produit mais aussi, lorsque cela est pertinent, des utilisations raisonnablement prévisibles et de son environnement d'exploitation.

Une approche PME réaliste

Un premier modèle de menace peut commencer avec un schéma simple représentant :

1. utilisateurs ;
2. administrateurs ;
3. application ou équipement ;
4. backend ;
5. API ;
6. base de données ;
7. services tiers ;
8. principaux flux ;
9. points d'entrée ;
10. frontières de confiance ;
11. actifs sensibles.

L'objectif est ensuite d'identifier quelques scénarios de menace importants.

Exemple

Actif critique : comptes administrateurs

Menace : compromission d'un compte

Conséquence : accès aux données clients

Mesures :

1. MFA ;
2. séparation des privilèges ;
3. limitation des sessions ;
4. journalisation ;
5. alertes.

La sécurité devient ainsi une décision de conception plutôt qu'une checklist ajoutée juste avant la mise en production.

2. Transformer les risques en exigences de sécurité

Un modèle de menace qui reste dans une présentation n'améliore pas le produit.

Chaque risque important doit produire une exigence vérifiable.

Exemple

Risque

Un utilisateur non authentifié pourrait appeler une API d'administration.

Exigence de sécurité

Toutes les interfaces d'administration doivent nécessiter une authentification forte et une autorisation explicite.

Contrôle

Test d'accès non authentifié.

Résultat attendu

Requête refusée.

Preuve

Résultat du test automatique ou manuel.

La chaîne devient :

risque -> exigence -> contrôle -> test -> preuve

Ce lien est essentiel.

Il permet de savoir pourquoi un contrôle existe et ce qu'il doit réellement démontrer.

3. Livrer une configuration sûre par défaut

Le Secure by Default ne doit pas être compris comme :

« Nous fournissons une documentation expliquant comment sécuriser le produit. »

Le principe est plus exigeant :

le produit doit être livré dans un état raisonnablement sûr avant intervention de l'utilisateur.

Preuves à conserver

Une PME peut conserver :

1. configuration initiale ;
2. scénario de première installation ;
3. résultats des tests des privilèges initiaux ;
4. résultat des tests d'accès ;
5. preuve de l'absence d'identifiants génériques ;
6. checklist de release.

La documentation utilisateur reste utile.

Mais le test du produit dans son état réellement livré est généralement plus probant.

4. Sécuriser le développement et les revues de code

Le CRA n'impose pas un outil SAST particulier ni un modèle DevSecOps unique.

Le fabricant doit néanmoins être capable de démontrer que ses pratiques de développement permettent de maîtriser les risques de cybersécurité identifiés.

Une PME peut notamment structurer :

1. des règles de codage sécurisé ;
2. des revues sur les changements sensibles ;
3. des scans de code ;
4. des scans de dépendances ;
5. des tests négatifs ;
6. une gestion des secrets ;
7. des règles d'exception ;
8. des critères de release.

Commencer simplement

Règle 1

Tout changement touchant :

1. l'authentification ;
2. l'autorisation ;
3. la cryptographie ;
4. les mécanismes de mise à jour ;
5. les interfaces externes ;

fait l'objet d'une revue adaptée.

Règle 2

Aucun secret ne doit être stocké directement dans le dépôt de code.

Règle 3

Les contrôles de sécurité définis par l'organisation sont exécutés avant la livraison.

Règle 4

Les vulnérabilités importantes sont corrigées ou font l'objet d'une exception explicitement analysée et acceptée.

Le processus peut rester simple.

L'objectif est surtout d'éviter que la décision repose uniquement sur la mémoire individuelle du développeur.

5. Maîtriser les dépendances et la chaîne logicielle

Une PME développe rarement 100 % de son produit elle-même.

Elle utilise généralement :

1. bibliothèques open source ;
2. frameworks ;
3. images de conteneurs ;
4. SDK ;
5. composants matériels ;
6. services cloud ;
7. outils de build ;
8. services tiers.

Le CRA renforce donc fortement l'importance de la visibilité sur les composants qui entrent dans le produit.

La SBOM fait partie de cette logique.

La SBOM n'est pas une preuve de sécurité

Une SBOM répond à :

De quoi mon produit dépend-il ?

Elle ne répond pas automatiquement à :

Ces composants sont-ils sûrs ?

Il faut encore :

1. identifier leurs vulnérabilités ;
2. connaître les versions affectées ;
3. suivre leur maintenance ;
4. corriger ou remplacer les composants ;
5. gérer les exceptions ;
6. relier les composants aux versions du produit.

La valeur de la SBOM vient donc du processus qui l'exploite.

6. Organiser la gestion des vulnérabilités

La gestion des vulnérabilités ne commence pas avec le signalement réglementaire.

Elle commence par un processus interne capable de :

1. recevoir l'information ;
2. identifier les produits concernés ;
3. qualifier le problème ;
4. évaluer son risque ;
5. décider d'une correction ;
6. développer le correctif ;
7. tester ;
8. livrer ;
9. vérifier le déploiement ;
10. conserver l'historique.

Le workflow peut rester relativement simple :

détection -> qualification -> priorité -> correction -> test -> livraison -> déploiement -> clôture

Registre minimal

Ce registre doit permettre de retrouver rapidement :

1. ce qui est affecté ;
2. qui pilote la correction ;
3. où en est le traitement ;
4. quelles versions corrigent le problème.

Les obligations de signalement CRA sont désormais applicables

Depuis le 11 septembre 2026, certaines obligations de signalement prévues par le CRA sont applicables.

Les fabricants concernés doivent notamment être capables de traiter le signalement des :

1. vulnérabilités activement exploitées dont ils ont connaissance ;
2. incidents graves affectant la sécurité de leurs produits.

Le processus interne doit donc permettre de conserver :

1. la date de connaissance ;
2. le produit concerné ;
3. les versions affectées ;
4. la qualification ;
5. la décision de notification ;
6. les informations transmises ;
7. les correctifs ;
8. les mises à jour ultérieures du dossier ;
9. la preuve du dépôt.

Le Secure by Design et le processus réglementaire de notification ne sont donc pas indépendants.

Plus une organisation maîtrise :

1. ses produits ;
2. ses versions ;
3. ses composants ;
4. ses vulnérabilités ;
5. ses responsabilités ;

plus elle peut réagir rapidement lorsqu'un signalement CRA devient nécessaire.

7. Sécuriser le mécanisme de mise à jour

Corriger une vulnérabilité n'est utile que si le fabricant peut distribuer le correctif de manière fiable.

Le mécanisme de mise à jour doit donc être considéré comme une fonction de sécurité du produit.

Une organisation peut notamment vérifier :

1. comment le produit détecte les mises à jour ;
2. comment leur origine est vérifiée ;
3. comment leur intégrité est contrôlée ;
4. comment une mise à jour incorrecte est refusée ;
5. comment un échec est géré ;
6. comment l'utilisateur est informé ;
7. comment le fabricant sait quelles versions restent déployées.

Checklist PME

L'objectif est de vérifier tout le chemin :

correctif produit -> package -> distribution -> installation -> résultat.

8. Maintenir la documentation et les preuves

Le Secure by Design n'est pas uniquement une activité d'ingénierie.

Le fabricant doit aussi être capable d'expliquer comment les décisions prises permettent de satisfaire les exigences de cybersécurité applicables.

La documentation utile peut notamment comprendre :

1. description du produit ;
2. architecture ;
3. modèle de menace ;
4. évaluation des risques ;
5. exigences de sécurité ;
6. processus de gestion des vulnérabilités ;
7. SBOM ;
8. politique de divulgation coordonnée ;
9. point de contact vulnérabilités ;
10. mécanisme de mise à jour ;
11. rapports de tests ;
12. décisions d'exception ;
13. éléments de release.

Une logique particulièrement pertinente consiste à associer à chaque mesure :

1. son objectif ;
2. son propriétaire ;
3. la checklist associée ;
4. les preuves attendues ;
5. le contrôle réalisé avant release.

Le Secure by Design devient ainsi démontrable.

Exemple de registre de preuves Secure by Design

Le point essentiel est de conserver la relation :

mesure -> preuve

Un dossier contenant des centaines de résultats CI mais aucune relation avec les contrôles attendus devient difficile à exploiter lors d'une évaluation.

9. Définir clairement les responsabilités

Le Secure by Design échoue facilement lorsqu'il devient :

« le sujet du RSSI ».

La sécurité produit concerne plusieurs fonctions.

Dans une PME, une même personne peut cumuler plusieurs rôles.

Le problème n'est pas le cumul.

Le problème apparaît lorsqu'aucune responsabilité n'est explicitement attribuée.

Un contrôle doit avoir un propriétaire

Exemple :

Mesure : produire une SBOM à chaque release

Responsable : DevOps

Validation : responsable sécurité

Preuve : SBOM rattachée à la release

KPI : pourcentage des releases disposant d'une SBOM

Cette structure permet de piloter le contrôle sans créer une gouvernance disproportionnée.

Faut-il mettre en place les 22 playbooks ENISA immédiatement ?

Pas nécessairement de la même manière ni avec le même niveau de profondeur.

Une PME peut prioriser les pratiques en fonction :

1. du produit ;
2. de son exposition ;
3. des données traitées ;
4. de ses interfaces ;
5. des dépendances utilisées ;
6. des scénarios de menace ;
7. du niveau de maturité de son processus de développement.

Une adoption progressive ne signifie toutefois pas que les obligations réglementaires applicables peuvent être repoussées.

Exemple de socle initial

Pour une PME logicielle, une première base peut réunir :

1. modèle de menace ;
2. règles de codage sécurisé ;
3. scan de dépendances ;
4. gestion des secrets ;
5. SBOM ;
6. processus de vulnérabilités ;
7. mécanisme de mise à jour ;
8. configuration sécurisée par défaut ;
9. release gate.

Les autres pratiques peuvent ensuite être renforcées en fonction des risques.

Comment utiliser un release gate sans ralentir toutes les livraisons ?

Un release gate n'est pas nécessairement un comité de deux heures.

Pour une PME, il peut être une checklist directement intégrée au workflow de release.

Exemple de release gate PME

L'objectif est d'éviter une logique informelle :

« Je crois que nous avions vérifié ça sur la release précédente. »

Quel plan d'action Secure by Design pour une PME ?

Une PME partant de zéro peut organiser sa trajectoire en quatre phases.

Phase 1 - Connaître le produit

1. identifier le périmètre ;
2. réaliser l'évaluation des risques ;
3. documenter l'architecture ;
4. identifier les principaux scénarios de menace ;
5. inventorier les composants.

Phase 2 - Sécuriser le développement

1. définir les règles minimales de codage ;
2. protéger les secrets ;
3. ajouter les revues sensibles ;
4. intégrer les scans ;
5. générer une SBOM.

Phase 3 - Sécuriser la livraison

1. tester les configurations par défaut ;
2. protéger la chaîne de build ;
3. sécuriser les mises à jour ;
4. établir un release gate ;
5. conserver les résultats.

Phase 4 - Maintenir le produit

1. gérer les vulnérabilités ;
2. suivre les composants ;
3. publier les correctifs ;
4. contrôler le déploiement ;
5. traiter les signalements ;
6. mettre à jour les risques et preuves.

Le Secure by Design devient ainsi un cycle, et non un projet ponctuel de mise en conformité.

Quels KPI suivre sans créer une usine à gaz ?

Une PME n'a pas besoin de 50 indicateurs.

Quelques KPI peuvent suffire à savoir si le dispositif fonctionne.

Ces KPI ne constituent pas des indicateurs officiels du CRA.

Ils servent à détecter les dérives.

Quelles preuves conserver pour préparer la conformité CRA ?

L'objectif n'est pas de produire des documents uniquement pour l'audit.

L'objectif est de conserver les traces naturelles des activités de sécurité réellement intégrées au cycle produit.

Les erreurs fréquentes des PME

Ajouter la sécurité juste avant la release

Un problème d'architecture découvert deux jours avant la livraison coûte généralement plus cher à corriger.

Le modèle de menace et les exigences de sécurité doivent intervenir suffisamment tôt.

Confondre Secure by Design et pentest

Un test d'intrusion est utile.

Il ne remplace pas :

1. la conception ;
2. les exigences ;
3. la gestion des dépendances ;
4. les mises à jour ;
5. la gestion des vulnérabilités ;
6. les configurations par défaut.

Produire une SBOM sans processus derrière

Une SBOM ancienne ou jamais analysée ne suffit pas à maîtriser les composants.

Scanner sans traiter

Un rapport contenant 400 vulnérabilités n'est pas un processus de remédiation.

Les sujets importants doivent avoir :

1. un responsable ;
2. une décision ;
3. une échéance ;
4. une preuve de clôture.

Laisser les utilisateurs sécuriser eux-mêmes le produit

C'est précisément ce que cherche à éviter le Secure by Default.

Les options initiales doivent être aussi sûres que raisonnablement possible.

Oublier les versions déjà livrées

La sécurité produit continue après la mise sur le marché.

Le fabricant doit savoir :

1. quelles versions existent ;
2. lesquelles sont supportées ;
3. quels composants elles contiennent ;
4. quelles vulnérabilités les affectent ;
5. quels correctifs ont été publiés.

Mélanger sécurité produit et sécurité du SI interne

Les deux sont liées mais différentes.

La sécurité du poste d'un développeur ou de GitHub est importante.

Le CRA porte toutefois sur la sécurité des produits comportant des éléments numériques et sur les processus permettant de maintenir cette sécurité.

Produire les preuves artificiellement après coup

Une capture créée juste avant une évaluation est moins utile qu'une preuve naturellement générée par le processus :

1. résultat CI ;
2. pull request ;
3. SBOM ;
4. rapport de test ;
5. ticket de vulnérabilité ;
6. release ;
7. décision d'exception.

Comment CompliKey aide à piloter le Secure by Design

CompliKey ne remplace pas les outils d'ingénierie nécessaires au Secure by Design.

La plateforme intervient sur une autre couche :

le pilotage des mesures, responsabilités, preuves et remédiations.

Traduire les exigences CRA en mesures suivies

Une organisation peut structurer des mesures telles que :

1. réaliser et maintenir une évaluation des risques produit ;
2. maintenir un modèle de menace ;
3. générer une SBOM ;
4. effectuer des scans de dépendances ;
5. appliquer une configuration sûre par défaut ;
6. gérer les vulnérabilités ;
7. sécuriser les mises à jour ;
8. maintenir la documentation technique.

Chaque mesure peut ensuite être suivie avec :

1. un niveau ;
2. des commentaires ;
3. des tâches ;
4. des coûts ;
5. des preuves ;
6. des remédiations.

Décomposer une mesure en sous-actions

Prenons :

Maintenir une SBOM pour chaque release.

Les actions peuvent être :

1. choisir le format ;
2. automatiser la génération ;
3. rattacher la SBOM à la release ;
4. définir son propriétaire ;
5. vérifier sa présence avant livraison.

La mesure reste stable.

Les tâches permettent de la mettre en œuvre puis de la maintenir.

Rattacher les preuves

CompliKey peut référencer :

1. le rapport SAST ;
2. la SBOM ;
3. le modèle de menace ;
4. le rapport de test ;
5. le registre de vulnérabilités ;
6. la documentation de release.

Les documents techniques restent dans les outils adaptés :

1. GitHub ;
2. GitLab ;
3. SharePoint ;
4. GED ;
5. outils CI/CD.

CompliKey conserve surtout la relation :

exigence -> mesure -> preuve

Auditer la maturité du dispositif

Une organisation peut ensuite évaluer :

1. si la mesure existe ;
2. si elle est appliquée ;
3. si elle est démontrée ;
4. si elle est pilotée ;
5. si elle reste pérenne.

Le score éventuel reste une méthode interne de pilotage.

Il ne constitue pas un score CRA officiel.

Transformer les écarts en actions

Si un audit constate :

« Une SBOM existe pour les releases majeures mais pas pour les releases correctives »

la remédiation peut devenir :

Automatiser la génération de la SBOM dans le pipeline de release.

Puis être suivie avec :

1. responsable ;
2. échéance ;
3. preuve attendue ;
4. statut.

Ce que CompliKey ne fait pas

CompliKey ne remplace pas :

1. SAST ;
2. DAST ;
3. SCA ;
4. scanners de dépendances ;
5. gestionnaires de secrets ;
6. génération technique d'une SBOM ;
7. plateformes CI/CD ;
8. signature d'artefacts ;
9. mécanismes OTA ;
10. fuzzing ;
11. pentests ;
12. outils de gestion du code.

Il serait contre-productif de transformer un outil GRC en chaîne DevSecOps.

Le rôle de CompliKey est différent.

Il doit permettre au responsable sécurité, au consultant ou au responsable produit de répondre à des questions de gouvernance :

1. quelles mesures devons-nous mettre en œuvre ?
2. lesquelles le sont réellement ?
3. quelles preuves existent ?
4. quelles mesures sont insuffisantes ?
5. quelles actions sont encore ouvertes ?
6. quels contrôles doivent être revus ?
7. pouvons-nous démontrer notre trajectoire ?

C'est cette couche de pilotage qui permet de connecter le CRA aux activités d'ingénierie sans dupliquer les outils des développeurs.

Exemple de cockpit CRA pour une PME logicielle

Une vue de pilotage simple pourrait contenir :

Ce tableau ne remplace pas le pipeline de développement.

Il permet simplement de savoir où concentrer les prochaines actions.

Quel effort prévoir ?

Il n'existe pas de charge standard pour mettre en œuvre le Secure by Design.

L'effort dépend notamment :

1. du type de produit ;
2. du nombre de produits ;
3. de l'architecture ;
4. des technologies ;
5. des composants tiers ;
6. du niveau de risque ;
7. de la maturité actuelle ;
8. de la capacité à automatiser certains contrôles.

Une PME disposant déjà :

1. de revues de code ;
2. d'un pipeline CI/CD ;
3. de tests automatisés ;
4. d'un scanner de dépendances ;
5. d'une gestion des vulnérabilités ;

aura principalement besoin de structurer, compléter et démontrer ce qu'elle fait déjà.

Une PME dont les releases restent largement manuelles aura probablement besoin d'un chantier plus profond.

Conclusion

Le Secure by Design dans le CRA ne doit pas être traité comme une procédure supplémentaire rédigée par le RSSI.

Il doit apparaître directement dans la façon dont le produit est conçu, développé, livré et maintenu.

Pour une PME, neuf mesures constituent un socle concret :

1. évaluer les risques dès la conception ;
2. transformer ces risques en exigences vérifiables ;
3. livrer des configurations sécurisées par défaut ;
4. appliquer des pratiques de développement et de vérification sécurisées ;
5. maîtriser les composants et dépendances ;
6. organiser la gestion des vulnérabilités ;
7. sécuriser les mises à jour ;
8. conserver la documentation et les preuves ;
9. attribuer clairement les responsabilités.

Le playbook publié par l'ENISA fin juillet 2026 apporte désormais une base particulièrement opérationnelle pour les PME.

Le CRA fournit quant à lui le cadre réglementaire dans lequel ces activités doivent être pensées sur l'ensemble du cycle de vie du produit.

La bonne question n'est donc pas :

« Avons-nous une politique Secure by Design ? »

mais :

« À chaque release, quelles décisions de sécurité prenons-nous, quels contrôles exécutons-nous et quelles preuves pouvons-nous conserver pour démontrer que notre produit reste sécurisé ? »

FAQ

Qu'est-ce que le Secure by Design dans le CRA ?

Le Secure by Design consiste à intégrer la cybersécurité dès la conception et le développement du produit plutôt qu'à ajouter uniquement des correctifs à la fin. Dans le contexte du CRA, l'objectif est que les produits comportant des éléments numériques soient conçus, développés et maintenus avec un niveau de cybersécurité adapté aux risques. L'ENISA propose depuis juillet 2026 un playbook destiné notamment à rendre cette approche plus opérationnelle pour les PME.

Quelle différence entre Secure by Design et Secure by Default ?

Le Secure by Design concerne les décisions prises pendant la conception et le développement : architecture, authentification, privilèges, dépendances, tests ou mécanismes de mise à jour. Le Secure by Default concerne l'état dans lequel le produit est livré. L'utilisateur doit disposer d'une configuration raisonnablement sûre sans devoir désactiver lui-même des paramètres dangereux.

Une PME doit-elle appliquer immédiatement tous les playbooks ENISA ?

Les playbooks constituent une aide opérationnelle et non une simple checklist réglementaire à cocher mécaniquement. Une PME peut prioriser leur mise en œuvre selon le produit, les risques et sa maturité actuelle. Cette progression ne dispense toutefois pas l'organisation de respecter les exigences réglementaires qui lui sont applicables.

Le CRA impose-t-il une SBOM ?

Le CRA prévoit l'identification et la documentation des composants utilisés dans les produits ainsi qu'une nomenclature logicielle couvrant au minimum les dépendances directes dans le cadre prévu par le règlement. La SBOM devient donc un élément important de la gestion des composants et des vulnérabilités. Elle n'est toutefois utile que si elle est maintenue et exploitée.

Les mises à jour automatiques sont-elles obligatoires avec le CRA ?

Le CRA prévoit des exigences relatives à la fourniture et à la sécurisation des mises à jour. La manière dont l'installation automatique s'applique dépend du produit, du contexte et des dispositions applicables. Une PME doit surtout être capable de démontrer que ses correctifs peuvent être distribués de façon sûre et que le mécanisme de mise à jour ne crée pas lui-même un risque supplémentaire.

Quelle documentation une PME doit-elle conserver pour le CRA ?

Elle doit pouvoir démontrer comment le produit a été conçu, quels risques ont été identifiés et comment les exigences essentielles sont mises en œuvre. Cela peut comprendre l'évaluation des risques, l'architecture, le modèle de menace, la SBOM, les processus de gestion des vulnérabilités, les mécanismes de mise à jour, les rapports de tests et les preuves des contrôles réalisés avant les releases.

Transformez le Secure by Design en mesures réellement pilotables

Centralisez les exigences CRA, les tâches, les preuves et les remédiations sans remplacer vos outils de développement et de DevSecOps.

Piloter les mesures Secure by Design du CRA avec CompliKey

Sources utilisées

1. ENISA - Secure by Design and Default Playbook, juillet 2026. Guide pratique consacré à l'application des principes Secure by Design et Secure by Default, avec une approche adaptée notamment aux contraintes des PME.
2. Règlement (UE) 2024/2847 - Cyber Resilience Act. Source juridique principale pour les exigences essentielles de cybersécurité, la configuration sécurisée par défaut, la gestion des composants, les vulnérabilités, les mises à jour et la documentation technique.
3. Commission européenne - Cyber Resilience Act. Ressources officielles sur les responsabilités des fabricants, la gestion des vulnérabilités et le calendrier d'application du règlement.
4. ENISA - Secure by Design and Default Playbooks. Utilisés pour les pratiques relatives au modèle de menace, au développement sécurisé, aux dépendances, à la chaîne d'approvisionnement, aux vulnérabilités et aux mises à jour.