« Le CRA, on verra en 2027. » C'est la phrase que nous entendons le plus souvent chez les fabricants. Elle repose sur une erreur de calendrier : une partie des obligations du Cyber Resilience Act s'applique déjà depuis le 11 septembre 2026. Pour le reste, quatorze mois, c'est très court quand il faut revoir un cycle de développement, outiller la gestion des vulnérabilités et constituer une documentation technique.
Plutôt qu'une lecture juridique du règlement, cet article s'appuie sur nos missions récentes d'audit d'objets connectés. Elles montrent concrètement où se situent les écarts, et par où commencer.
Le CRA en bref
Le Cyber Resilience Act (règlement (UE) 2024/2847) impose des exigences de cybersécurité à tous les produits comportant des éléments numériques mis sur le marché européen : objets connectés, logiciels, équipements réseau, composants. Sa logique est celle du marquage CE. Un produit ne pourra être vendu dans l'Union que s'il respecte des exigences essentielles, démontrées par une évaluation de conformité et une documentation technique.
Le calendrier comporte deux échéances :
- 11 septembre 2026 : obligations de signalement des vulnérabilités activement exploitées et des incidents graves (déjà applicables) ;
- 11 décembre 2027 : application de l'ensemble des obligations, dont les exigences essentielles et le marquage CE.
Les sanctions peuvent atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial.
Retour d'expérience n° 1 : le bâtiment d'élevage connecté, ou quand la cybersécurité devient vitale
Un fabricant de systèmes de pilotage de bâtiments d'élevage nous a sollicités pour un test d'intrusion de son boîtier de régulation, ainsi que des flux vers sa plateforme distante.
Le vrai risque n'était pas la donnée
Lors du cadrage, l'équipe pensait d'abord à la confidentialité : les données de production de l'exploitation, les identifiants de connexion de l'éleveur. En construisant les scénarios de menace, une autre priorité est apparue. Le boîtier pilote la ventilation et la température du bâtiment. Un attaquant capable de modifier les consignes peut, en quelques heures, mettre en danger la vie des animaux.
Le scénario redouté n'était donc pas une fuite de données, mais une atteinte à l'intégrité du pilotage. C'est exactement ce que demande le CRA : une analyse de risques propre au produit et à son usage, et non une liste de contrôles génériques.
Trois points d'attention dès le cadrage
L'architecture technique a immédiatement soulevé trois questions, chacune liée à une exigence de l'annexe I du règlement :
- des données stockées sans protection sur l'équipement, accessibles à quiconque dispose d'un accès physique ;
- des mises à jour locales et à distance, dont il faut vérifier qu'elles sont authentifiées et que leur intégrité est contrôlée ;
- un mode de configuration dédié à l'installation, qui ne doit pas devenir une porte d'entrée permanente.
Le logiciel embarqué était construit sur mesure. C'est un bon point de départ, mais il ne garantit rien par lui-même : sans bonnes pratiques de construction (système minimal, comptes par défaut supprimés, services inutiles retirés), un équipement embarque facilement plus que nécessaire.
Retour d'expérience n° 2 : les capteurs de la chaîne du froid, ou l'acheteur qui prend les devants
Un grand groupe de distribution nous a confié l'audit des capteurs connectés qui surveillent la température de ses entrepôts frigorifiques. L'audit s'est déroulé sur quatre jours, entièrement en laboratoire, sans accès au site de déploiement.
Quand le client audite à la place du fabricant
Ce projet illustre une tendance de fond. Aujourd'hui, c'est souvent l'acheteur qui finance l'évaluation de sécurité des produits qu'il déploie. Demain, avec le CRA, cette charge de preuve repose sur le fabricant. Les grands donneurs d'ordre, publics comme privés, exigeront la documentation technique, la déclaration de conformité et les engagements de support de sécurité dans leurs appels d'offres.
Pour un fabricant de capteurs, c'est un changement de posture commerciale : la conformité CRA deviendra un critère de sélection, au même titre que la précision de mesure ou l'autonomie.
Tester sans le terrain
L'audit en laboratoire impose une préparation rigoureuse : disposer d'échantillons représentatifs du parc déployé, avec les mêmes versions logicielles et une configuration conforme à la production. Sans cela, on audite un produit qui n'est pas celui qui fonctionne sur le terrain.
C'est aussi un argument pour la nomenclature logicielle (SBOM) exigée par le CRA : savoir exactement quelle version tourne sur quel équipement est la condition pour évaluer, puis corriger, un parc de milliers d'objets.
Retour d'expérience n° 3 : l'équipement embarqué et la question du chiffrement
Dernier cas, hors du champ du CRA mais très instructif. Pour un équipementier automobile, nous avons audité un équipement de maintenance embarqué, doté d'une interface locale utilisée notamment pour exporter des données. Les véhicules relèvent de leur propre cadre réglementaire (règlement ONU R155), mais les questions techniques sont identiques à celles des produits concernés par le CRA.
Lors du cadrage, le client nous a posé une question que nous entendons souvent : « Faut-il chiffrer ? »
La réponse dépend du risque. Ici, le scénario prioritaire était une atteinte à l'intégrité du code via cette interface locale. Or le chiffrement protège la confidentialité, pas l'intégrité. Un système chiffré mais dépourvu de démarrage sécurisé (secure boot) et de vérification de signature des mises à jour peut toujours exécuter un code modifié.
Et la santé connectée ?
Pour nos clients du secteur santé, une précision s'impose. Les dispositifs médicaux relevant des règlements MDR et IVDR sont exclus du champ du CRA, car leur cybersécurité est déjà encadrée par ces textes.
Mais cette exclusion est plus étroite qu'on ne le pense. Une passerelle domestique qui remonte les mesures, une application de bien-être non qualifiée de dispositif médical, un portail destiné aux aidants ou un équipement réseau installé à l'hôpital peuvent tous relever du CRA. Le bon réflexe est de qualifier chaque produit individuellement, et non de présumer qu'une gamme entière est exclue parce qu'elle s'adresse au monde de la santé.
Ce que le règlement exige, en pratique
Nos missions recoupent largement les exigences du CRA :
| Exigence CRA | Ce que nous vérifions en audit |
|---|---|
| Aucune vulnérabilité exploitable connue à la mise sur le marché | Composants obsolètes, bibliothèques vulnérables, services inutiles |
| Configuration sécurisée par défaut | Mots de passe par défaut, interfaces de debug actives, modes de configuration ouverts |
| Protection contre les accès non autorisés | Authentification des interfaces locales et distantes, gestion des secrets |
| Confidentialité et intégrité des données | Chiffrement du stockage et des flux, signature des mises à jour, démarrage sécurisé |
| Mises à jour de sécurité | Mécanisme OTA authentifié, capacité de retour arrière, délai de correction |
| Journalisation | Traces des événements de sécurité exploitables en cas d'incident |
À ces exigences produit s'ajoutent des obligations de processus :
- une SBOM pour chaque version ;
- une politique de divulgation coordonnée des vulnérabilités ;
- une période de support d'au moins cinq ans, sauf durée d'utilisation plus courte ;
- le signalement des vulnérabilités activement exploitées, avec une alerte précoce sous 24 heures et une notification sous 72 heures via la plateforme de l'ENISA.
Quelle évaluation de conformité ?
| Catégorie | Exemples | Évaluation |
|---|---|---|
| Produits par défaut | La majorité des objets connectés et logiciels | Auto-évaluation par le fabricant |
| Importants – classe I | Routeurs, VPN, gestionnaires d'identité, objets domotiques de sécurité | Auto-évaluation si une norme harmonisée est appliquée intégralement, sinon tierce partie |
| Importants – classe II | Pare-feu, systèmes de détection d'intrusion, hyperviseurs | Organisme notifié |
| Critiques | Cartes à puce, boîtiers de sécurité matériels | Certification européenne lorsqu'elle est exigée |
L'auto-évaluation n'est pas une formalité. Elle engage la responsabilité du fabricant, qui doit pouvoir produire sa documentation technique à la demande des autorités.
Par où commencer ?
- Cartographier votre portefeuille : quels produits entrent dans le champ du CRA, et dans quelle catégorie.
- Organiser le signalement dès maintenant : responsables, procédure, accès à la plateforme et exercice de simulation. Cette obligation s'applique déjà.
- Générer les SBOM automatiquement dans votre chaîne de build.
- Construire l'analyse de risques produit à partir des usages réels, comme la ventilation d'un bâtiment d'élevage ou l'intégrité du code d'un équipement embarqué.
- Réaliser une analyse d'écart par rapport aux exigences de l'annexe I, appuyée sur un audit technique.
- Sécuriser la chaîne de mise à jour : signature, démarrage sécurisé et retour arrière.
- Constituer la documentation technique, à conserver dix ans.
En résumé
Nos audits le montrent : les écarts les plus fréquents ne viennent pas d'une méconnaissance de la sécurité, mais de choix d'architecture faits trop tôt et jamais réinterrogés. Des données stockées sans protection, une mise à jour non signée ou un système trop riche se corrigent bien plus facilement à la conception qu'au moment du marquage CE.
Décembre 2027 se prépare maintenant.
← Tous les articles