Security by design est l’un des concepts les plus cités dans les discussions autour du CRA — et l’un des moins bien compris. Pour beaucoup d’équipes, c’est une notion floue qui ressemble à « penser à la sécurité pendant le développement ». Le CRA en donne une définition bien plus concrète, assortie d’exigences vérifiables.

1. Définition — ce que le CRA entend par security by design

Le CRA définit le security by design (sécurité dès la conception) comme l’obligation d’intégrer la cybersécurité dans chaque phase du cycle de vie du produit — de la conception initiale jusqu’à la fin de vie, en passant par le développement, les tests, le déploiement et la maintenance.

Concrètement, cela signifie que la sécurité ne peut pas être une couche ajoutée sur un produit déjà conçu. Elle doit être une contrainte de conception au même titre que la performance, la fiabilité ou la consommation énergétique.

2. Les 12 exigences essentielles de l’Annexe I

L’Annexe I du CRA liste les exigences essentielles de sécurité auxquelles tout produit connecté doit répondre. Ce sont ces exigences qui définissent opérationnellement ce que « security by design » signifie dans le texte :

3. Ce que ça change concrètement pour les équipes R&D

La liste ci-dessus peut sembler abstraite. Voici ce qu’elle implique en pratique dans le quotidien des équipes de développement produit :

Threat modeling obligatoire en phase de conception

Pour respecter l’exigence de surface d’attaque minimale et de résilience, les équipes doivent conduire une analyse de menaces (threat modeling) avant de coder — pas après. L’outil standard est STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege). Ce document devient une pièce du dossier technique CRA.

Secure defaults dans les spécifications produit

Chaque fonctionnalité réseau, chaque port, chaque service doit être désactivé par défaut dans les spécifications. Activer une fonctionnalité est une décision documentée — pas le comportement par défaut. Cela impacte directement les specs produit et les cas de test d’acceptance.

Cryptographie — fin des implémentations maison

L’exigence de chiffrement des données interdit implicitement les protocoles propriétaires non vérifiés. TLS 1.2 minimum pour les communications réseau, algorithmes standards (AES-256, RSA-2048+, ECDSA) pour le stockage. Les équipes embarquées qui utilisaient des schémas de chiffrement simplifiés « suffisants pour ce cas d’usage » devront migrer.

Pipeline de mise à jour sécurisé dès le départ

L’exigence de mise à jour pendant toute la durée de support signifie que le mécanisme OTA (Over-The-Air) doit être conçu et testé dès la v1 — pas ajouté à la v3 quand le premier incident se produit. Signature cryptographique des firmwares, vérification d’intégrité avant installation, rollback en cas d’échec.

4. Security by design vs security by default

Le CRA distingue deux notions complémentaires que les équipes confondent souvent :

• Security by design — la sécurité est intégrée dans l’architecture et les décisions de conception. Elle concerne la structure du produit : comment les composants communiquent, comment les données sont stockées, comment les accès sont contrôlés.
• Security by default — le produit est livré dans la configuration la plus sécurisée possible. Tous les services non nécessaires sont désactivés. Les fonctionnalités moins sécurisées mais optionnelles peuvent exister mais ne sont pas actives à la livraison.

Un produit peut être bien conçu (security by design) mais mal configuré par défaut (absence de security by default) — et vice versa. Le CRA exige les deux.

5. Comment le démontrer lors d’un audit

Le CRA ne demande pas seulement que vous respectiez ces principes — il demande que vous puissiez le démontrer. Voici ce qu’un auditeur ou une autorité de surveillance de marché va vérifier :

• Analyse de risque cybersécurité documentée — par produit, avec identification des menaces, des vecteurs d’attaque et des mesures de mitigation retenues.
• Threat model — diagrammes d’architecture avec les flux de données et les points de confiance identifiés.
• Tests de sécurité tracés — résultats de tests de pénétration, de fuzzing ou d’analyse statique de code (SAST), avec date et version testée.
• Décisions de conception documentées — pourquoi tel protocole a été choisi, pourquoi telle fonctionnalité est désactivée par défaut, pourquoi tel composant a été retenu.
• SBOM à jour — preuve que vous connaissez tous les composants de votre produit et leur état de sécurité.

6. Par où commencer si vous partez de zéro

Pour les équipes qui n’ont pas de processus security by design en place, voici un chemin pragmatique :

• Semaines 1-2 — Threat model sur le produit prioritaire : organisez un atelier de 2-3h avec les architectes et les développeurs seniors. Utilisez un template STRIDE. Le résultat est un diagramme de flux de données annoté avec les menaces identifiées.
• Semaines 3-4 — Audit de la configuration par défaut : inventoriez tous les services, ports et fonctionnalités actifs par défaut. Désactivez ce qui n’est pas strictement nécessaire au fonctionnement de base.
• Mois 2 — Politique de cryptographie : définissez les algorithmes et protocoles autorisés dans votre organisation. Inventoriez les endroits où des schémas non conformes sont encore utilisés.
• Mois 3 — Pipeline OTA sécurisé : si ce n’est pas déjà en place, c’est le chantier le plus long — commencez tôt. La signature des firmwares et la vérification d’intégrité sont les deux priorités.