Depuis le 11 septembre 2026, les premières obligations contraignantes du Cyber Resilience Act sont entrées en vigueur. Elles concernent en premier lieu les fabricants et ont un impact sur tous ceux qui conçoivent, installent ou exploitent des systèmes de sécurité. La question décisive dans les projets n’est donc plus seulement : quelle caméra répond aux spécifications ? Elle devient : comment garantir que l’ensemble de l’installation puisse être exploité, mis à jour, documenté et, en cas d’incident, démontré comme sécurisé tout au long de son cycle de vie ?
La cybersécurité devient une caractéristique du produit
Le Cyber Resilience Act (CRA) définit les normes de sécurité qu’un produit connecté doit respecter avant d’être commercialisé en Europe. Presque tous les composants des systèmes de sécurité modernes sont concernés : caméras, contrôle d’accès, haut-parleurs, radars, enregistreurs, logiciels de gestion et équipements réseau.
Cette évolution est plus profonde qu’il n’y paraît au premier abord : jusqu’à présent, la cybersécurité relevait souvent d’une simple promesse du fabricant, difficile à comparer et encore plus difficile à faire valoir. À l’avenir, elle deviendra une caractéristique de produit démontrable. À l’instar du marquage CE pour la sécurité électrique, la conformité en matière de cybersécurité deviendra une condition préalable à l’accès au marché.
La mise en œuvre se fera en deux étapes :
- À partir du 11 septembre 2026 : les fabricants devront signaler les vulnérabilités exploitées et les incidents graves de sécurité.
- À partir du 11 décembre 2027 : toutes les exigences techniques applicables au produit lui-même devront être intégralement respectées.
En cas de non-respect, des amendes pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial pourront être infligées.
Quelles conséquences pour la conception ? Toute personne qui rédige aujourd’hui des cahiers des charges pour des installations destinées à fonctionner dix ans ou plus ne peut pas attendre 2027. Les bases d’une installation pérenne et conforme doivent être posées dès maintenant.
Lorsqu’une faille est exploitée, le chronomètre démarre
Lorsqu’un fabricant apprend qu’une vulnérabilité de son produit est effectivement exploitée, il dispose de 24 heures pour adresser une première alerte aux autorités. Dans un délai de 72 heures, il doit transmettre une notification détaillée. Le rapport final doit être fourni dès qu’une solution est disponible, et au plus tard un mois après la notification en cas d’incident grave de sécurité. Les destinataires sont l’autorité nationale compétente et l’agence européenne ENISA, via une plateforme commune de signalement.
L’aspect le plus important est souvent négligé : *cette obligation s’applique également aux équipements déjà installés depuis longtemps. Il ne s’agit pas uniquement des nouveaux produits, mais de chaque caméra et de chaque contrôleur de porte actuellement déployé sur le terrain.
Pour les concepteurs et les exploitants, cela impose une nouvelle manière d’évaluer les fabricants. En cas d’incident, la question n’est pas seulement de savoir s’ils peuvent corriger une faille, mais si l’ensemble du processus fonctionne : identifier, évaluer, communiquer et remédier au problème. Et surtout, si cela peut être constaté de l’extérieur.
Avant l’attribution d’un marché, il est donc pertinent de demander :
- Comment serai-je informé d’une faille de sécurité ? Existe-t-il un service de notification ?
- Où puis-je signaler moi-même une vulnérabilité et qui traite ces signalements ?
- Dans le passé, à quelle vitesse les mises à jour ont-elles été mises à disposition ?
- Quels documents recevrai-je en cas d’incident avéré ?
Un fabricant qui agit en tant que CVE Numbering Authority, qui enregistre lui-même les vulnérabilités et publie sa méthodologie, peut apporter des preuves concrètes. Chez Axis, ces éléments sont disponibles dans l’Axis Trust Center.
Les fabricants ne sont pas les seuls concernés
Le CRA répartit les responsabilités sur l’ensemble de la chaîne. Le fabricant assume la charge principale : évaluation des risques, nomenclature logicielle, mises à jour, etc. Les importateurs de produits provenant de pays hors UE doivent vérifier que le marquage CE et la documentation sont bien présents. Les distributeurs, quant à eux, ne peuvent pas commercialiser un produit s’ils ont des doutes sur sa conformité.
Un point surprend souvent. Dans le règlement, il s’agit de l’article 22, paragraphe 1 : quiconque modifie substantiellement un produit puis le remet sur le marché est considéré comme fabricant. Pour la partie modifiée, toutes les obligations du fabricant s’appliquent alors : documentation propre, déclaration de conformité propre, marquage CE propre et obligations de notification propres. Cela peut concerner un intégrateur système, un revendeur spécialisé ou, dans certains cas, même un service informatique chez le client final.
La bonne nouvelle : les activités normales d’un projet n’entrent pas dans ce cadre. Configurer des appareils, définir des paramètres réseau et des droits d’accès, installer des mises à jour prévues par le fabricant, tout cela reste sans risque.
La situation devient critique lorsqu’on intervient sur le cœur du produit : versions de firmware développées en interne, désactivation ou contournement de fonctions de sécurité, ou regroupement de plusieurs produits sous une nouvelle solution commercialisée sous sa propre marque.
Le conseil pratique pour les installateurs et intégrateurs est donc le suivant : documentez précisément ce qui a été installé, configuré et modifié dans le projet, ainsi que les fonctions de sécurité activées. En cas de doute, cette documentation constituera la preuve que vous n’avez pas endossé le rôle de fabricant.
Quelles conséquences pour la conception ?
Pour les bureaux d’études et les prescripteurs, il s’agit probablement du changement le plus important du quotidien.
Jusqu’à présent, une caméra était spécifiée sur la base de sa résolution, de sa focale, de son WDR, de sa sensibilité lumineuse, de ses indices de protection IP et IK, de sa classe PoE ou de sa plage de température. Ces critères restent pertinents, mais ils ne suffisent plus pour une installation connectée. Le CRA ajoute une seconde dimension : le cycle de vie de la cybersécurité.
Combien de temps le produit bénéficiera-t-il d’un support sécurisé ?
La durée de vie technique d’un produit et la durée de son support de sécurité sont deux choses différentes. Un équipement peut fournir des images pendant dix ans sans être exploitable en toute sécurité pendant cette même période. Le CRA impose au minimum cinq ans de support. Dans la pratique, les systèmes de sécurité restent souvent en service pendant dix à quinze ans. Cet écart constitue un véritable risque pour la planification. Un avantage important est que les fabricants devront désormais indiquer la fin de la période de support dès l’achat, avec le mois et l’année. Cette information pourra ainsi être intégrée comme critère d’attribution.
Quel est le niveau de transparence du logiciel ?
La nomenclature logicielle, ou SBOM (Software Bill of Materials), s’apparente à une liste d’ingrédients : elle indique quels composants sont intégrés au produit. Si, plusieurs années après l’installation, une vulnérabilité est découverte dans un composant open source, la SBOM permet de déterminer en quelques minutes si l’installation est concernée, au lieu de mener des recherches pendant plusieurs jours.
Quelles fonctions de sécurité sont présentes dès l’origine ?
Pas de mot de passe par défaut, chiffrement activé, services non sécurisés désactivés, stockage sécurisé des clés cryptographiques, démarrage sécurisé du système. Chaque fonction intégrée nativement au produit représente un travail de durcissement qui n’a plus besoin d’être réalisé dans le cadre du projet. Chez Axis, cela fait partie du principe Secure by Design d’AXIS OS. La plateforme matérielle Axis Edge Vault protège notamment les clés cryptographiques et le processus de démarrage.
Comment la communication s’effectue-t-elle en cas d’incident ?
Comme indiqué plus haut : service de notification, adresse de signalement, guides de durcissement et documentation destinée à l’analyse forensique.
Ces quatre questions peuvent être comparées objectivement. Une simple exigence de « cybersécurité élevée » ne le permet pas.
Une remarque qui surprend souvent : le CRA considère certains produits comme particulièrement importants, ce qui implique une évaluation de conformité plus exigeante. Cette catégorie inclut les systèmes de contrôle d’accès, non seulement les lecteurs, mais aussi les systèmes de gestion des accès lorsqu’ils contrôlent l’accès à des sites physiques. Les commutateurs administrés (managed switches), les routeurs et les points d’accès y figurent également. En revanche, les caméras réseau professionnelles n’y figurent pas. La catégorie « caméras de sécurité » vise explicitement les caméras de surveillance destinées aux consommateurs dans des environnements résidentiels.
Pour la planification, cela signifie qu’un commutateur administré installé dans une salle technique peut être soumis à davantage d’exigences réglementaires que la caméra qu’il relie au réseau.
Pour votre prochain cahier des charges
Quatre exigences pouvant être reprises directement :
- « Le fournisseur indique pour chaque produit proposé la date de fin du support de sécurité, avec mois et année. Cette information fait partie intégrante de l’offre. »
- « Le fournisseur met à disposition, pour chaque version du produit, une nomenclature logicielle (SBOM) dans un format courant lisible par machine. »
- « Les produits sont livrés sans mot de passe par défaut, avec chiffrement activé et services non sécurisés désactivés. Un guide de durcissement est fourni. »
- « Le fournisseur désigne un point de contact pour le signalement des vulnérabilités et exploite un service de notification des alertes de sécurité. »
Et une cinquième exigence déterminante : Ces exigences s’appliquent à tous les composants du système, pas uniquement aux caméras.
Le maillon le plus faible fait la différence
Un système de sécurité est rarement constitué d’un seul produit. La chaîne ressemble généralement à ceci :
Caméra → Réseau et commutateur → Enregistreur ou serveur → Logiciel de gestion → Client → Gestion des utilisateurs et des droits
Selon les projets, peuvent s’y ajouter le contrôle d’accès, l’audio, le radar ou des interfaces externes.
Dans l’optique du CRA, aucun composant de cet ensemble n’est secondaire. Chaque produit connecté doit disposer de son propre justificatif de conformité, de sa propre période de support et de son propre mécanisme de signalement. Il en découle une règle simple : La cybersécurité d’une installation n’est pas déterminée par la caméra la plus sûre, mais par son maillon le plus faible. Un enregistreur obsolète, un commutateur sans stratégie de mise à jour ou des droits utilisateurs mal configurés augmentent la surface d’attaque, indépendamment du niveau de protection de la caméra.
Les composantes cloud en font également partie. Les services logiciels purs ne sont pas directement couverts par le CRA, mais les solutions sans lesquelles un produit ne peut remplir sa fonction le sont.
Pour la planification, cela signifie que les quatre questions évoquées précédemment doivent être posées pour chaque composant connecté du système, et non uniquement pour les caméras.
Conclusion et perspectives
Le CRA transforme une promesse en preuve tangible. Les prescripteurs disposent désormais de critères objectifs pouvant être demandés et comparés. Les installateurs et intégrateurs devraient clarifier dès le début du projet où commence exactement leur responsabilité. Quant aux services informatiques des clients finaux, ils disposent enfin d’une base solide pour évaluer leurs fournisseurs.
Lors du prochain appel d’offres, la question ne sera donc plus seulement : Quelle caméra répond aux spécifications ? Mais : Quel fabricant est capable de vous accompagner de manière démontrable pendant toute la durée de vie de l’installation ?
Perspectives : À l’échelle nationale, la nécessité de fournir des preuves techniques supplémentaires continue de croître. Un projet de loi actuel visant à renforcer la cybersécurité prévoit que l’Office fédéral allemand de la sécurité des technologies de l’information (BSI) puisse à l’avenir récupérer directement des données techniques d’attaque à partir des systèmes de détection des entreprises, par exemple des adresses IP, des horodatages ou des indices de compromission. Dans sa réponse officielle de juillet 2026, le gouvernement fédéral maintient cette approche et souligne que la transmission devra être majoritairement automatisée.
Le CRA contribue directement à cet objectif, puisqu’il exige déjà que les produits enregistrent les événements liés à la sécurité. Choisir aujourd’hui des équipements capables de produire des journaux propres et exploitables permet de créer les bases nécessaires pour fournir ultérieurement ce type de preuve. Nous expliquons dans un article dédié pourquoi les journaux d’audit (audit logs) jouent un rôle central.
CRA et NIS2 : brève mise en perspective
Les deux textes réglementent la cybersécurité et sont donc souvent confondus. Pourtant, la différence est simple :
- Le CRA réglemente le produit. Il impose des obligations aux fabricants, importateurs et distributeurs.
- NIS2 réglemente l’organisation. Elle impose aux exploitants des mesures de gestion des risques, de notification et de sécurisation de la chaîne d’approvisionnement.
Les deux approches se complètent : le CRA fournit la base technique, tandis que NIS2 impose de la maîtriser d’un point de vue organisationnel. Ainsi, le choix du fabricant devient une composante à part entière de la gestion des risques.
______________________
Remarque : qu’est-ce que cela signifie concrètement pour la Suisse ?
La Suisse n’est pas membre de l’Union européenne. Par conséquent, le Cyber Resilience Act (CRA) ne s’applique pas directement dans le droit suisse et il n’existe actuellement aucune autorité suisse de surveillance du marché chargée de contrôler le respect du CRA. Néanmoins, pour les fabricants suisses qui commercialisent leurs produits sur le marché intérieur de l’Union européenne, le CRA est de facto contraignant.
La question de savoir si, et sous quelle forme, la Suisse reprendra à l’avenir certaines exigences du CRA fait actuellement l’objet de discussions. Aucun acte législatif correspondant n’a toutefois été adopté à ce jour.
Au niveau fédéral, la cybersécurité relève de la compétence de l’Office fédéral de la cybersécurité (OFCS). Son rôle diffère toutefois de celui des autorités de surveillance du marché prévues par le CRA. L’OFCS agit notamment en tant que :
- point de contact national et service de signalement pour les cyberincidents (GovCERT) ;
- autorité compétente pour l’obligation de signaler les cyberattaques visant les infrastructures critiques conformément à la loi sur la sécurité de l’information (LSI) révisée, en vigueur depuis le 1er avril 2025 ;
- éditeur de normes, de standards minimaux et de recommandations en matière de cybersécurité, notamment du standard minimal TIC.
Le CRA peut néanmoins être pertinent pour les exploitants, intégrateurs et planificateurs spécialisés en Suisse. De nombreux fabricants développeront et exploiteront désormais leurs produits dans toute l’Europe conformément aux exigences du CRA. Les preuves de conformité, les processus de support et les exigences de cybersécurité associés pourraient ainsi s’imposer progressivement sur le marché suisse comme critères d’acquisition et d’évaluation.
______________________
Conseil : tout sur NIS2, KRITIS et le CRA en un seul endroit
Le CRA n’est qu’un des nombreux textes réglementaires qui concernent actuellement le secteur.
Celles et ceux qui souhaitent conserver une vue d’ensemble peuvent consulter la page Axis Résilience, qui propose une présentation synthétique de NIS2, de la loi-cadre KRITIS et du CRA, avec des exemples concrets concernant la vidéo, l’audio, le radar et le contrôle d’accès.
Sont également regroupés sur cette page :
- l’Axis Trust Center, avec certificats, preuves et documents de conformité ;
- des informations sur le label allemand de sécurité informatique du BSI, porté désormais par plus de 240 produits Axis ;
- des webinaires et ateliers consacrés à NIS2, spécialement destinés aux installateurs et partenaires ;
un contact direct avec les experts Axis en résilience : resilience-de@axis.com.
Remarque à l’attention des opérateurs KRITIS : selon les informations figurant sur la page Résilience, les installations existantes doivent être enregistrées au plus tard le 17 octobre 2026.
Pour aller plus loin : les références
Toutes les affirmations de cet article reposent sur le Règlement (UE) 2024/2847 (Cyber Resilience Act). Pour ceux qui souhaitent approfondir :
Deux références complémentaires ne proviennent pas directement du CRA : le Règlement d’exécution (UE) 2025/2392, contenant les descriptions techniques relatives à l’annexe III ; le projet de loi visant à renforcer la cybersécurité (documents parlementaires allemands BT-Drucksachen 21/6585 et 21/7406).
Lectures complémentaires :
Weiterführend: Règlement (UE) 2024/2847, texte integral Page Axis Resilience Axis Trust Center Informations du BSI sur le Cyber Resilience Act
