Les caméras de sécurité sont-elles des produits importants au titre du CRA ?
Résumé
Une caméra connectée pour la maison vendue pour assurer la sécurité physique doit être planifiée comme produit Classe I Important. La classe peut changer lorsque le même matériel de caméra est vendu pour un autre usage : appels vidéo, vidéosurveillance professionnelle, infrastructure d'enregistrement, contrôle d'accès ou autre produit de sécurité.
Le premier enregistrement à créer est une note de classification et de périmètre pour la variante exacte de caméra. Elle doit nommer la fonction de sécurité prévue, le contexte de vente, les éléments numériques fournis, la période d'assistance et la justification de la voie choisie.
L'enregistrement de la période d'assistance doit partir de l'usage attendu de la caméra, des attentes raisonnables de l'utilisateur, de la nature du produit, de la destination prévue et de l'assistance des composants concernés. Le plancher du CRA est d'au moins cinq ans, sauf si le produit est destiné à être utilisé moins de cinq ans, et la date de fin, au moins mois et année, doit être clairement précisée à l'achat.
Comment classer une version de caméra ?
Partez de l'offre, pas de la coque de la caméra. La voie dépend de l'argument commercial, de la fonction sur laquelle l'acheteur s'appuie, et des éléments numériques fournis avec cette version.
Vendue pour les appels vidéo, les réunions ou la communication générale.
Périphérique de communication ; pas de surveillance de sécurité domestique.
Firmware de l'appareil, pilote ou intégration à l'application de réunion. Aucun cloud de surveillance ni flux d'alarme fourni.
Vendue pour la surveillance du domicile, la surveillance de bébé, la sécurité de sonnette ou l'intégration d'alarme.
La sécurité ou la surveillance du foyer est la fonction sur laquelle l'acheteur s'appuie.
Firmware, stockage local, application, cloud du fabricant, service de mise à jour et gestion des vulnérabilités lorsqu'ils sont fournis pour cette fonction.
Vendue comme vidéosurveillance professionnelle, infrastructure d'enregistrement ou partie d'un autre produit de sécurité.
L'enregistreur, le VMS, le firewall, le VPN, le contrôle d'accès, la biométrie ou la fonction d'identité peuvent être le vrai produit.
Caméra plus enregistreur, serveur de gestion, cloud installateur, service de contrôle d'accès ou appliance de sécurité.
Utilisez le schéma comme aide au routage, pas comme enregistrement final de classification. La note écrite doit toujours préciser l'argument exact, l'usage prévu et le périmètre expédié. Pour une caméra pour la maison connectée, l'expression clé est produits de la maison connectée avec fonctionnalités de sécurité. Une caméra vendue pour la surveillance du domicile, la détection d'intrusion, la surveillance de bébé ou l'intégration d'alarme entre dans cette catégorie. Une webcam généraliste n'y entre généralement pas.
Vérifiez ensuite si une autre fonction listée fait le vrai travail de contrôle. La classification Important suit la fonctionnalité principale du produit, pas les composants qui circulent avec : intégrer un composant pertinent pour la sécurité ne fait pas basculer le reste de l'offre dans la voie Important. Si la caméra est en réalité vendue comme firewall, passerelle VPN, lecteur de contrôle d'accès, dispositif d'authentification biométrique, système de gestion des identités ou produit de gestion des accès privilégiés qui inclut un objectif, classez d'abord cette fonction principale.
Pour la vidéosurveillance professionnelle, ne forcez pas la catégorie maison connectée. Une caméra CCTV professionnelle, un VMS ou un NVR peut tout de même être un produit comportant des éléments numériques au sens du CRA et avoir besoin d'exigences de sécurité, d'une planification de la période d'assistance, d'une gestion des vulnérabilités et d'une documentation technique. La classe dépend de l'usage prévu, du périmètre expédié et de la fonction principale.
La note de classification doit répondre à quatre questions :
- La caméra est-elle vendue pour la sécurité domestique, la surveillance de bébé, la sécurité de sonnette ou l'intégration d'alarme ?
- La caméra est-elle la fonction principale du produit, ou une fonction de firewall, VPN, contrôle d'accès, biométrie ou identité fait-elle le vrai travail ?
- Quels éléments numériques sont fournis pour la fonction prévue : firmware, stockage local, application, cloud du fabricant, service de mise à jour et gestion des vulnérabilités ?
- Quels systèmes restent hors de l'offre du fabricant : routeur du client, enregistreur tiers, réseau de l'installateur, fournisseur d'identité externe ou centre de télésurveillance ?
Périmètre du produit et éléments expédiés
Pour un fabricant de caméra, le périmètre de conformité n'est presque jamais limité au boîtier plastique. Il doit suivre le produit mis sur le marché et les éléments numériques nécessaires à la fonction de sécurité prévue.
Dans le périmètre du fabricant de caméra par défaut : firmware de l'appareil et chaque service qui y tourne, pile d'interface réseau, stockage embarqué, application compagnon que l'acheteur est invité à installer, tout cloud hébergé par le fabricant qui assure les fonctionnalités documentées du produit, l'infrastructure de mises à jour OTA et le processus de gestion des vulnérabilités qui se trouve derrière.
Hors de ce périmètre sauf si le fabricant vend réellement la couche : le routeur domestique de l'acheteur, un VMS ou NVR tiers choisi par le client, le réseau du site d'un installateur, un fournisseur d'identité externe utilisé pour le SSO, et un centre de télésurveillance professionnel sous contrat séparé.
Aucune lorsque ces produits proviennent d'autres fabricants. Si le fabricant de la caméra vend aussi l'enregistreur, le VMS, le service d'identité ou le pont cloud dans son offre, chacun peut être un produit CRA distinct avec son propre dossier produit.
Dossier produit · Déclaration UE de conformité · Marquage CE · Déclaration de période d'assistance · Instructions utilisateur · Dossier d'évaluation de la conformité
Conservé par le fabricant de la caméra pendant dix ans après la mise sur le marché de la caméra, ou pendant la période d'assistance, la plus longue des deux. Si une voie d'évaluation par tierce partie est utilisée, conservez ce résultat avec le même dossier.
Dossier de risques cybersécurité · Inventaire des composants · Processus de gestion des vulnérabilités · Politique de divulgation · Mécanisme de mise à jour sécurisée
Incluez le point de contact unique publié, les preuves de test pour la configuration sécurisée par défaut, la vérification de mise à jour signée et la justification de la période d'assistance.
Registre de diligence sur les composants · Déclaration de conformité du fournisseur · Avis de sécurité fournisseurs
Le fabricant de la caméra reste responsable du choix de la puce. Lorsqu'une puce, un module ou un élément sécurisé est lui-même un produit CRA, la déclaration de conformité du fournisseur et ses avis viennent en appui de la diligence du fabricant, sans la remplacer.
L'inventaire des composants est suivi face aux nouvelles vulnérabilités ; le processus de vulnérabilités trie les signalements ; les mises à jour de sécurité gratuites déploient les correctifs avec des avis, automatiquement lorsque c'est possible.
Une vulnérabilité de caméra activement exploitée déclenche une horloge : une alerte précoce est due dans les 24 h, la notification de vulnérabilité dans les 72 h, et le rapport final de vulnérabilité dans les 14 jours après la mise à disposition d'une mesure corrective ou d'atténuation. Un incident de sécurité grave suit une horloge distincte avec les mêmes étapes à 24 h et 72 h, plus un rapport final d'incident dans un délai d'un mois après la notification d'incident.
Les foyers qui utilisent les caméras concernées sont aussi informés par le fabricant. Le fabricant indique aux propriétaires concernés, et à la base de clients plus large lorsque l'exposition le justifie, ce qui ne va pas et les étapes qu'ils peuvent appliquer eux-mêmes : mise à jour forcée du firmware, mise à jour de l'application, réinitialisation du mot de passe, désactivation d'un service optionnel ou réinitialisation d'usine avant revente.
Points de contrôle d'architecture de la caméra
Le dossier de version de la caméra doit suivre le vrai produit vidéo, pas une checklist IoT générique. Une caméra Wi-Fi sur batterie, une caméra dôme PoE, une caméra cellulaire extérieure et une caméra vendue avec un NVR peuvent partager une discussion de classe tout en exigeant des enregistrements d'ingénierie différents.
Lisez le schéma comme une carte du dossier de version, pas comme un schéma de déploiement obligatoire. Le fabricant doit toujours écrire le périmètre exact de variante pour sa propre caméra, application, service cloud, voie de mise à jour et modèle d'assistance.
- Voie vidéo et de contrôle. Identifiez chaque voie qui permet de visualiser, stocker, exporter ou contrôler la vidéo : flux local, interface web, session d'application, relais cloud, lien de partage, export d'assistance et compatibilité revendiquée avec un NVR ou un VMS.
- Exposition locale. Scannez la caméra après l'installation et après mise à jour. Montrez quels services sont joignables, lesquels exigent une authentification, et quelles voies de flux ou d'administration restent désactivées.
- Systèmes du client. Traitez le routeur, le réseau de l'installateur, l'enregistreur tiers, le fournisseur d'identité externe et le centre de télésurveillance comme étant hors du produit du fabricant de caméra, sauf si le fabricant fournit cette couche dans le cadre de l'offre.
- Backends fournis par le fabricant. Confirmez ou excluez le service de comptes, le pipeline de signature, le service d'événements ou de notifications, le portail d'assistance, le service de flags de fonctionnalités payantes et toute voie cloud ML.
- Autorité de mise à jour. Traitez l'autorité de mise à jour comme un échange bidirectionnel : la caméra vérifie ou reçoit les métadonnées de mise à jour, et le service de mise à jour renvoie un paquet de firmware ou d'application signé pour cette variante exacte. Conservez avec la version les enregistrements de mise à jour signée, de slot de récupération, de rejet de version antérieure et de notification utilisateur.
- Entrées fournisseurs. Affectez au SoC, au module Wi-Fi, à la pile média, au modèle IA, au SDK P2P et au bootloader un responsable, une version, une veille d'avis et une décision de version.
- Boucle post-commercialisation. Les signalements de vulnérabilité, incidents graves, avis fournisseurs et défaillances terrain doivent mettre à jour le modèle de menaces, l'enregistrement de risque résiduel, le dossier technique et la prochaine barrière de version.
Évaluation des risques travaillée pour une caméra
Lisez la suite de cette section comme un exemple travaillé pour une caméra, pas comme une checklist à copier. L'intention est de montrer la profondeur de décision qu'un fabricant de caméra devrait pouvoir défendre pour une variante précise : les choix de chipset et de modules, la version du firmware, le relais cloud, le canal OTA, les avis fournisseurs que vous suivez réellement, le canal de vente que vous avez signé et la fenêtre d'assistance à laquelle vous vous êtes engagé.
Quel produit évaluons-nous ?
Exemple illustratif, pas un appareil réel : ExampleCo IndoorCam X1, une caméra de sécurité d'intérieur pour la maison connectée vendue dans l'UE pour la surveillance de sécurité domestique. Elle enregistre de la vidéo 1080p et de l'audio, stocke des clips sur une carte microSD, diffuse en direct la vidéo au propriétaire via une application mobile, expose une interface web d'administration locale pendant l'installation, utilise le BLE pour l'appairage initial, se connecte en Wi-Fi et reçoit des mises à jour de firmware signées du fabricant.
Le périmètre du produit pour cet exemple inclut le matériel de la caméra, le firmware embarqué, l'enregistrement microSD, le flux d'appairage de l'application mobile, le relais cloud du fabricant, le service de comptes, le service de mise à jour OTA, le processus d'avis de sécurité et le contact de signalement des vulnérabilités. Il n'inclut pas le routeur du client, un VMS/NVR tiers, une plateforme de domotique ni un centre de télésurveillance professionnel.
Le produit est destiné à des utilisateurs domestiques non techniciens dans un environnement intérieur domestique. Il n'est pas destiné à la vidéosurveillance industrielle, à la surveillance d'espaces publics, au contrôle d'accès, à l'authentification biométrique ou à la vérification d'identité, à la surveillance des salariés, ni aux opérations de sécurité d'infrastructures critiques.
Avant d'écrire le tableau de menaces, testez les trois voies de caméra qui pilotent généralement l'évaluation des risques : custodie de la vidéo, identité de l'appareil et exposition après installation. Ces schémas transforment l'exemple travaillé en questions d'ingénierie au lieu d'une liste générique de menaces.
Détails de la custodie vidéo : la source est le capteur de la caméra, le micro et l'encodeur, avec les blobs de réglage d'image, la voie audio, le masque de confidentialité, les entrées de détection IA et les profils de flux liés à une version de firmware. La voie de visualisation locale inclut ONVIF, RTSP, l'aperçu web ou le navigateur, et est vérifiée par un scan d'authentification et d'exposition. La voie de visualisation distante inclut le relais cloud, le SDK P2P ou l'application du propriétaire, et est vérifiée par un test de portée de jeton et de relais. La voie média locale inclut les clips microSD et le stockage amovible, et est vérifiée par des tests de réinitialisation et de retrait de carte. La voie d'assistance inclut le pack d'assistance et l'export de diagnostics, et est vérifiée par une checklist de rédaction.
Les tests de réinitialisation, dissociation et effacement RMA prouvent quelles vidéos, jetons et liens de compte sont supprimés avant revente, reconditionnement ou transfert d'assistance.
La propriété est un contrôle séparé de la custodie vidéo. Une caméra peut avoir un flux protégé et tout de même échouer si un ancien propriétaire, un utilisateur partagé ou un téléphone récupéré conserve l'accès après transfert.
Détails du cycle de vie de l'identité : l'approvisionnement crée la clé ou le certificat de la caméra, enregistre l'identité matérielle et verrouille l'accès de débogage en production. L'installation du propriétaire utilise un compte vérifié plus un jeton de revendication QR, BLE ou application à usage unique et courte durée, et ferme la fenêtre de premier usage après l'association de la caméra. Le fonctionnement normal utilise le même modèle de révocation pour la réinitialisation de mot de passe, la récupération de compte, la récupération de téléphone perdu, le partage familial, les visiteurs invités et les sessions de navigateur. Le transfert du propriétaire nécessite une voie de dissociation autorisée, supprime l'ancien compte, révoque les utilisateurs partagés et tue les sessions actives avant que la caméra puisse être revendiquée à nouveau. La réinitialisation d'usine, le RMA et le reconditionnement suppriment le lien de compte, les identifiants, les clips et les diagnostics conformément à la conception du produit ; la gestion RMA ne doit pas devenir une voie de blanchiment de vol.
Tests d'abus : un jeton d'installation expire, est à usage unique et ne peut pas être réutilisé par un attaquant proche après revendication du propriétaire ; un ancien téléphone, un utilisateur invité ou une session de navigateur ne peut pas conserver l'accès en direct ou enregistré après récupération ; et la réinitialisation locale ne laisse pas derrière elle d'association cloud, de jetons de compte ni de clips.
Une fois la propriété testée, vérifiez ce qui reste joignable depuis le réseau, l'application, les supports amovibles et les flux d'assistance. Cela maintient la revue d'exposition liée au comportement réel expédié, plutôt qu'à un résultat générique de scan de ports.
Détails des surfaces d'accès : les services LAN locaux incluent RTSP, ONVIF, l'interface web et les points de découverte, et l'enregistrement de version est le scan d'exposition. La visualisation distante inclut le relais cloud, le partage et l'identité de l'appareil, et l'enregistrement de version est le test de portée de jeton cloud. Les supports amovibles incluent les clips microSD, le comportement de réinitialisation et les décisions de stockage, et l'enregistrement de version est le résultat de réinitialisation microSD. Les diagnostics d'assistance incluent les journaux, dumps de crash et mode d'assistance, et l'enregistrement de version est l'échantillon d'audit du mode d'assistance.
Quels actifs protégeons-nous ?
Les caméras protègent des choses très différentes dans le même boîtier. Un clip enregistré de la chambre d'un enfant, un compte propriétaire qui peut orienter l'objectif et une clé de signature de firmware qui contrôle chaque appareil expédié cette année vivent tous derrière un seul produit. Listez-les comme des actifs distincts d'abord, parce que l'ensemble des contrôles, les preuves de test et l'enregistrement de version divergent fortement entre eux.
| Actif | Pourquoi cela importe | Où il vit |
|---|---|---|
| Vidéo/audio en direct et enregistrés | Exposent des pièces privées, des routines, des visiteurs, des enfants, des animaux et des conversations | Capteur, RAM, encodeur, microSD, tampon de flux, relais cloud |
| Compte propriétaire et facteur de récupération | Une prise de contrôle peut donner accès à la visualisation à distance, à la réinitialisation de l'appareil et au changement de partages | Application mobile, service d'identité, voie de récupération par e-mail/SMS |
| Identifiant appareil-vers-cloud | Jeton de confiance persistant ; difficile à faire tourner sur un parc déployé | Élément sécurisé ou stockage protégé, service d'association de comptes |
| Ancre de confiance de signature de firmware | Si elle est compromise, le canal de mise à jour peut devenir un canal de malware | Chaîne de démarrage, magasin de clés, service de signature, pipeline de version |
| Position dans le réseau local | La caméra se trouve dans le LAN du foyer et peut voir ses pairs locaux | Interface Wi-Fi, bail DHCP, vue mDNS/SSDP |
| Pack de diagnostics et d'assistance | Peut fuiter numéros de série, identifiants de compte, noms de réseau et traces de crash | Journaux appareil, portail d'assistance, outillage d'assistance interne |
| Instructions utilisateur et date d'assistance | Pilote l'installation sûre, les attentes de mise à jour et la gestion de la fin d'assistance | Emballage, manuel web, interface de l'application, fiche produit |
Où sont les principales frontières de confiance ?
Une caméra est dans cinq endroits à la fois : l'appareil lui-même, la carte microSD que toute personne dans la pièce peut retirer, le réseau domestique qu'elle partage avec des téléphones et des pairs IoT inconnus, le backend du fabricant qui touche chaque caméra du terrain, et le téléphone ou le navigateur du propriétaire qui détient la session en direct. Chacun change l'opportunité de l'attaquant et exige une surface de contrôle différente, donc le modèle de frontières de confiance les liste séparément même s'ils sont connectés.
| Environnement | Protection attendue | Pourquoi cela change la probabilité |
|---|---|---|
| À l'intérieur de la caméra | L'accès physique est limité, mais réparation, vol, revente et plots de débogage existent | Probabilité distante plus faible, conséquence plus élevée si les clés sont extractibles |
| microSD / média local | Toute personne ayant accès à la pièce peut retirer ou copier la carte | L'accès local est plausible dans les foyers avec invités, employés de ménage, locataires ou en cas de revente |
| Réseau domestique | Partagé avec ordinateurs portables, téléphones, télés, imprimantes et appareils IoT inconnus | Un pair compromis peut attaquer l'administration locale, la découverte ou les services de flux |
| Backend du fabricant | Exposé à Internet et partagé sur l'ensemble du parc installé | Une erreur de backend passe d'un foyer à beaucoup |
| Terminal du propriétaire | Téléphones et navigateurs sont exposés au phishing, malware et réutilisation de comptes | La compromission de compte contourne souvent le durcissement de l'appareil |
Quelles menaces évaluer en premier ?
Cet exemple démarre avec seize menaces propres au produit. L'objectif n'est pas l'exhaustivité ; c'est de montrer le niveau de traçabilité qu'un fabricant devrait pouvoir défendre.
| ID | Scénario de menace | Actif en risque | Point d'entrée |
|---|---|---|---|
| T1 | Un secret de premier usage partagé ou prévisible permet à un attaquant de revendiquer la caméra avant que le propriétaire ne termine l'installation | Compte propriétaire, flux vidéo | Onboarding BLE / installation locale |
| T2 | L'interface web d'administration locale accepte des identifiants faibles ou reste ouverte après l'installation | Configuration, accès au flux | Réseau domestique |
| T3 | Un jeton d'application mobile volé reste valide après la réinitialisation du mot de passe et continue d'ouvrir le flux de la caméra | Compte propriétaire, vidéo/audio en direct | Terminal du propriétaire / relais cloud |
| T4 | Le repli P2P, la gestion STUN/TURN/ICE, UPnP ou le hole punching exposent la caméra directement quand la voie relais échoue ou est bloquée | Services firmware, accès au flux | Voie relais adjacente à Internet |
| T5 | ONVIF/RTSP répond sur le LAN avec une authentification faible ou des URL de flux découvrables | Vidéo/audio en direct | Réseau domestique |
| T6 | Le slot de récupération accepte une image firmware non signée, ancienne ou déclassée | Intégrité du firmware, ancre de confiance de signature | OTA / voie de récupération |
| T7 | Les plots UART/JTAG permettent un accès au démarrage lors d'un vol, d'une réparation ou d'une revente | Secrets de l'appareil, firmware, journaux | Accès physique de débogage |
| T8 | Les clips microSD sont lisibles après retrait de la carte ou après revente de la caméra | Vidéo/audio enregistrés | Média local |
| T9 | L'onboarding BLE expose l'identifiant Wi-Fi ou le secret d'appairage de l'appareil à un attaquant proche | Identifiant Wi-Fi, compte propriétaire | Fenêtre d'installation BLE |
| T10 | Les packs d'assistance contiennent numéros de série, identifiants de compte, SSID, fragments de jetons ou traces de crash privées | Données de diagnostics, traçabilité de compte | Upload d'assistance |
| T11 | Une vulnérabilité fournisseur dans le module Wi-Fi ou la pile média n'est pas détectée pendant la période d'assistance | Firmware, disponibilité, confidentialité du flux | Lacune d'avis fournisseur |
| T12 | La réinitialisation RMA ou de revente ne supprime pas l'association de compte, les clips ou les identifiants de l'appareil | Compte propriétaire, médias enregistrés, identifiant appareil-vers-cloud | Voie de retour |
| T13 | Les services de découverte révèlent le modèle, le firmware, le numéro de série ou les métadonnées de flux à chaque appareil du LAN | Empreinte de l'appareil, exposition du flux | ONVIF / WS-Discovery / mDNS |
| T14 | Le streamer RTSP est protégé différemment de l'interface web, laissant un flux en direct joignable après durcissement de l'administration | Vidéo/audio en direct | Service de flux local |
| T15 | Un défaut du SDK P2P ou média tiers permet la prédiction ou l'énumération d'UID d'appareils, l'usurpation de l'appareil ou la compromission de session de flux | Vidéo/audio en direct, identifiant de l'appareil | Relais cloud / SDK |
| T16 | Le firmware de la caméra utilise un blob fournisseur d'ISP, Wi-Fi ou IA qui n'est pas dans le processus de veille SBOM | Intégrité du firmware, gestion des vulnérabilités | Firmware fournisseur |
Comment hiérarchiser les risques initiaux ?
Utilisez une grille interne simple avant de choisir les contrôles. Dans cet exemple, la probabilité repose sur l'exposition et l'opportunité de l'attaquant ; l'impact repose sur le préjudice à la vie privée, l'échelle du parc, la persistance et le fait que la menace compromette ou non un mécanisme de sécurité. Les étiquettes exactes importent moins que la justification écrite à côté de chaque décision.
Utilisez une échelle de barrières de version pour que chaque risque de caméra ne reçoive pas la même décision :
| Décision de barrière | Sens pour cette version de caméra |
|---|---|
| Bloquer la version | La caméra n'est pas expédiée tant que le test échoué n'est pas passé : appairage, authentification de flux, vérification de mise à jour signée, effacement RMA ou scan d'exposition des services après installation, selon la menace. |
| Bloquer sauf documentation | La version ne peut avancer que si un contrôle compensatoire, une limitation propre à la variante ou une justification de mode installateur est écrite, revue et épinglée au dossier de version de la caméra. |
| Expédier avec suivi | La caméra est expédiée, mais le dossier de version nomme le signal de suivi actif (flux CVE fournisseur, avis SDK P2P, télémétrie d'abus) et l'ingénieur qui en est responsable pendant la période d'assistance. |
| Transférer vers les consignes | L'exposition dépend du réseau domestique, du téléphone du propriétaire ou d'un enregistreur tiers hors de l'offre du fabricant de caméra, donc le dossier conserve des consignes installateur ou utilisateur au lieu de tenter de contrôler le côté client. |
| Accepter | Certaines surfaces de caméra (réponses de découverte documentées, métadonnées LAN) portent un risque résiduel inhérent, donc le dossier consigne les preuves de minimisation et la justification d'accepter ce qui reste. |
| ID | Probabilité | Impact | Décision de barrière | Pourquoi |
|---|---|---|---|---|
| T1 | Moyenne | Élevé | Bloquer la version | La prise de contrôle au premier usage est réaliste et compromet la propriété |
| T2 | Élevée | Moyen | Bloquer la version | Les LAN domestiques contiennent des pairs non fiables et des mots de passe réutilisés |
| T3 | Moyenne | Élevé | Bloquer la version | Le vol de jeton de compte donne la visualisation à distance sans toucher la caméra |
| T4 | Faible | Élevé | Bloquer sauf documentation | Voie rare, mais l'exposition directe peut s'étendre ; un produit expédié a besoin d'une décision documentée de relais et de traversée NAT |
| T5 | Moyenne | Élevé | Bloquer la version | L'exposition du flux local est une défaillance directe de la vie privée |
| T6 | Faible | Élevé | Bloquer la version | La compromission de mise à jour est persistante et touche tout le parc |
| T7 | Moyenne | Moyen | Bloquer sauf documentation | Le débogage physique est plausible lors d'un vol, d'une réparation ou d'une revente ; la version a besoin d'une justification de verrouillage du débogage ou d'un mode service |
| T8 | Élevée | Moyen | Bloquer sauf documentation | Le retrait local de carte est courant ; protéger les clips ou documenter clairement la limitation des supports amovibles |
| T9 | Moyenne | Élevé | Bloquer la version | L'onboarding est bref mais expose l'identifiant du réseau domestique |
| T10 | Moyenne | Moyen | Bloquer sauf documentation | Les fuites de données d'assistance peuvent passer inaperçues ; l'export d'assistance doit être minimisé, rédigé ou explicitement désactivé |
| T11 | Moyenne | Élevé | Expédier avec suivi | Les CVE fournisseurs sont attendus pendant la période d'assistance ; la version a besoin d'un responsable et d'une veille d'avis |
| T12 | Moyenne | Élevé | Bloquer la version | Les voies de retour et de revente sont prévisibles pour les appareils grand public |
| T13 | Moyenne | Moyen | Accepter | Certaines métadonnées LAN sont inhérentes aux protocoles de découverte documentés ; le risque résiduel n'est accepté qu'avec minimisation d'exposition et consignes utilisateur pour la découverte optionnelle là où elle est prise en charge |
| T14 | Moyenne | Élevé | Bloquer la version | L'authentification du flux ne peut pas être plus faible que le modèle d'accès documenté |
| T15 | Faible | Élevé | Expédier avec suivi | Les faiblesses de SDK ou de relais peuvent affecter de nombreux appareils, donc la version a besoin d'une responsabilité de version et d'un suivi des abus |
| T16 | Moyenne | Élevé | Bloquer sauf documentation | Les blobs fermés ou maintenus par fournisseur ont besoin d'un responsable de version, d'un canal d'avis et d'une voie de mise à jour, ou d'une décision de risque résiduel écrite |
Quels contrôles de conception changent l'image du risque ?
Reliez chaque ligne de contrôle à un test caméra précis, pas à une checklist générique de développement sécurisé. Le dossier de version doit pouvoir pointer d'un ID de menace vers le test d'appairage exact, le scan d'authentification de flux, le journal de vérification de mise à jour signée, l'inventaire des services après installation ou l'enregistrement d'effacement RMA qui prouve que le contrôle tourne sur la version expédiée de la caméra.
| Menaces | Contrôle de conception | Preuve que le fabricant doit conserver |
|---|---|---|
| T1, T2 | Secret d'installation par appareil, enrôlement forcé du propriétaire, pas de mot de passe partagé par défaut, l'interface d'installation se ferme après enrôlement | Journal de test d'installation, politique d'identifiants, test négatif pour accès administrateur non authentifié |
| T3 | Jetons d'application de courte durée, sessions liées à l'appareil, révocation côté serveur à la réinitialisation du mot de passe, suivi des anomalies de connexion | Politique de durée de vie des jetons, tests de révocation, tests d'abus de récupération de compte |
| T4, T5 | Désactivation d'UPnP par défaut, relais authentifié, ONVIF/RTSP authentifié, inventaire des services après installation | Scan d'exposition réseau, tests d'authentification de flux, revue de configuration de relais |
| T6 | Boot sécurisé, OTA signé, compteur de version monotone, vérification de signature du slot de récupération, politique de retour arrière | Preuves de chaîne de démarrage, tests de vérification de mise à jour, tests de rejet de version antérieure |
| T7 | Fusibles de production pour le débogage, plots de débogage scellés ou documentés, pas de secrets dans la sortie UART lisible | Checklist matérielle de production, vérification du verrouillage de débogage, note de risque sur le teardown |
| T8 | Enregistrement microSD chiffré lorsque la variante de caméra le prend en charge (Eufy, TP-Link Tapo sur modèles compatibles) ; effacement sécurisé à la réinitialisation d'usine ; avertissement utilisateur clair imprimé dans le manuel et dans l'application pour les variantes qui enregistrent sans chiffrement | Note de conception du stockage, test de réinitialisation, capture d'écran des instructions utilisateur, capture de l'avertissement dans l'application |
| T9 | Appairage BLE authentifié, fenêtre d'appairage courte, identifiant Wi-Fi jamais transmis en clair, limites de débit d'appairage | Revue du protocole d'appairage, test RF, test des modes d'échec |
| T10 | Minimisation du pack d'assistance, rédaction des jetons, consentement utilisateur avant upload, limite de rétention | Schéma d'assistance, tests de rédaction, preuves de flux d'assistance |
| T11 | Suivi SBOM, veille d'avis fournisseur, tri des composants affectés, processus de version de mise à jour signé | Journal de diff SBOM, enregistrement d'avis fournisseur, décisions de tri |
| T12 | Flux d'effacement RMA, dissociation cloud, rotation des identifiants à la réinitialisation, checklist d'appareil reconditionné | Checklist de chaîne de retour, preuves de réinitialisation, audit de dissociation cloud |
| T13, T14 | Inventaire des services après installation, URL de flux authentifiées, minimisation des réponses de découverte, preuves de tests de profil/version | Scans d'exposition, tests d'authentification ONVIF/RTSP, audit des réponses de découverte |
| T15 | Inventaire du SDK P2P, portée des jetons de session, entropie des UID d'appareil, veille d'avis SDK, tests d'usurpation et de cas d'abus | Enregistrement de version SDK, test d'énumération d'UID, test d'usurpation d'appareil |
| T16 | Inventaire du firmware fournisseur pour les composants ISP, Wi-Fi, encodeur et IA ; responsable de composant et voie de mise à jour | Nomenclature fournisseur, enregistrement de veille d'avis, journal de décision de version |
Quel risque résiduel reste après les contrôles ?
Les contrôles ne ferment pas le dossier. Après l'expédition de la caméra, le fabricant gère encore activement les risques : le canal de mise à jour du firmware, les voies de prise de contrôle du compte propriétaire et la longue queue de CVE fournisseurs dans la pile Wi-Fi, les bibliothèques média et les SDK P2P qui apparaissent tout au long de la période d'assistance. L'enregistrement résiduel n'est crédible que lorsque le fabricant peut pointer vers le suivi en direct de ces signaux, les décisions de tri des nouveaux avis, les mises à jour signées qui ont effectivement atteint les caméras installées, les avis aux propriétaires qui sont partis et une mesure corrective enregistrée derrière chacun.
| Zone résiduelle | Pourquoi elle subsiste | Preuves d'exploitation |
|---|---|---|
| Terminal propriétaire compromis | Le fabricant ne peut pas contrôler totalement le téléphone, le navigateur, l'e-mail ou l'hygiène de mot de passe de l'utilisateur | Prise en charge MFA, révocation de jetons, alertes de connexion suspecte, consignes utilisateur |
| Vulnérabilité fournisseur découverte après la version | Bibliothèques média, firmware Wi-Fi, noyaux et bibliothèques TLS continueront de recevoir des CVE | Veille SBOM, prise d'avis fournisseur, analyse d'impact, enregistrement de correctif |
| Accès physique local | Une caméra dans un foyer peut être volée, revendue, réparée ou accédée par des invités | Flux de réinitialisation, preuves de verrouillage du débogage, avertissement de stockage, enregistrement d'effacement RMA |
| Dérive de l'exposition réseau | Les mises à jour de firmware, changements de relais ou flags de fonctionnalités peuvent rouvrir des services | Scan d'exposition version par version, inventaire des services, approbation de changement |
La barrière de version est le registre de risques lui-même. N'ajoutez pas une carte « sécurité revue » séparée qui répète le même travail. Lors de la signature, le responsable de version doit pouvoir pointer des menaces bloquées ou conditionnelles vers les preuves de clôture : tests d'appairage et de flux pour T1/T2/T5/T14, révocation de jetons pour T3, tests de mise à jour signée pour T6, preuves de stockage/réinitialisation pour T8, preuves d'effacement RMA pour T12 et suivi fournisseur pour T11/T16.
Responsabilité du développement de la caméra, du concept à l'assistance
La responsabilité principale change à mesure que la caméra passe de la définition du produit à l'assistance en direct. Utilisez ce transfert pour affecter un responsable, un enregistrement maintenu et une barrière de revue à chaque étape pendant que le produit évolue.
Détails de responsabilité : produit et sécurité possèdent la note de périmètre de variante au concept. La sécurité produit avec firmware et cloud possède la carte des frontières de confiance, le registre de menaces et l'échelle de barrières en architecture. Les responsables firmware, cloud, application et fournisseur maintiennent les règles de mise à jour signée, les contrôles de jeton et de session, le manifeste des composants, les flux d'avis fournisseurs et les décisions de flags de fonctionnalités pendant l'implémentation. La QA avec la sécurité produit maintient les scans d'exposition, les tests d'authentification de flux, les tests de custodie vidéo, les exercices de réinitialisation ou d'effacement RMA et les décisions de risque résiduel pendant la vérification. La conformité et le responsable de version maintiennent le pack de version, l'index du dossier technique, les instructions, la déclaration de période d'assistance, la déclaration signée, le pack importateur et la préparation au signalement. PSIRT, assistance et ingénierie maintiennent la prise en charge, le tri des avis fournisseurs, les avis utilisateurs, les correctifs signés, le retrait des terminaux, les tests de régression et les enregistrements de mesures correctives après la version.
Détails de transfert : gelez le périmètre avant le travail d'architecture, gelez l'intention de conception avant l'implémentation, gelez le candidat avant la vérification, gelez la décision avant la version et maintenez la version en exploitation pendant la période d'assistance. Les signalements entrants, les avis fournisseurs, les résultats d'incidents et les résultats de régression rouvrent la prochaine note de périmètre, le registre de menaces et le manifeste des composants.
Carte des preuves du fabricant
Un évaluateur ou un assesseur d'organisme notifié parcourt un dossier technique de caméra comme un installateur parcourt la boîte : depuis le produit étiqueté, en passant par les éléments numériques fournis, jusqu'aux preuves d'assistance promises à l'acheteur. Les lignes ci-dessous nomment les enregistrements que les fabricants de caméras maintiennent à jour pour ce parcours ; chaque ligne doit être un enregistrement maintenu dans le dossier produit, pas une capture d'écran prise au moment de la signature.
| Zone de preuves | Ce qu'il faut capturer pour une caméra de sécurité |
|---|---|
| Identité du produit | Modèle, versions de firmware, application compagnon, service cloud, révisions matérielles |
| Destination prévue | Si le produit est vendu pour la sécurité domestique, la surveillance de bébé, la sécurité de sonnette ou la vidéosurveillance professionnelle |
| Évaluation des risques | Accès à la caméra, confidentialité de la vidéo, installation des identifiants, exposition réseau local, exposition API cloud |
| Preuves SBOM et composants matériels | Paquets firmware, composants Linux embarqué/RTOS, bibliothèques de traitement d'image, firmware des modules Wi-Fi/Ethernet, SoC et élément sécurisé lorsqu'il est présent |
| Configuration sécurisée par défaut | Pas de mot de passe partagé par défaut, installation initiale sécurisée, accès administrateur authentifié, accès distant protégé |
| Mécanisme de mise à jour | Mises à jour de firmware signées, stratégie de retour arrière, disponibilité des mises à jour pendant la période d'assistance |
| Gestion des vulnérabilités | Politique de CVD, contact de signalement, flux de tri, processus d'avis de sécurité |
| Instructions utilisateur | Installation sécurisée, configuration du compte, paramètres de mise à jour, divulgation de fin d'assistance |
| Traçabilité et contact | Schéma de modèle et de numéro de série de la caméra, identifiant de lot, marquages d'emballage, contact fabricant ou importateur UE, date de fin de la période d'assistance imprimée à un endroit où l'acheteur peut la lire avant l'achat, et adresse de signalement des vulnérabilités publiée et répondue par une équipe de sécurité humaine |
Voie d'évaluation de la conformité
Choisissez la voie de conformité après avoir clarifié le périmètre de la caméra, l'évaluation des risques, les contrôles et les risques résiduels. Sinon, la décision de voie peut devancer l'enregistrement d'ingénierie.
Classe I Important n'exige pas automatiquement un organisme notifié dans tous les cas. La voie du contrôle interne n'est disponible que lorsque les normes, spécifications ou schémas requis sont pleinement appliqués pour les exigences applicables.
Confirmez si des normes harmonisées pertinentes, des spécifications communes ou des schémas européens de certification d'au moins niveau d'assurance substantiel existent et couvrent les exigences essentielles applicables. S'ils n'existent pas, ne sont que partiellement appliqués ou ne couvrent pas toutes les exigences pertinentes, utilisez le module B+C ou le module H.
Pour une vraie version de caméra, préparez le dossier de version comme si une revue par tierce partie pouvait être nécessaire, puis confirmez la voie une fois les normes et schémas applicables clairs pour le produit caméra exact.
Conservez la voie choisie avec l'enregistrement de signature de version, y compris les références sur lesquelles on s'appuie, les exigences qu'elles couvrent et les éventuelles lacunes qui ont imposé une voie par tierce partie.
Signature de version du fabricant
Avant que la caméra ne soit mise sur le marché de l'UE, la signature doit réunir la classification, le périmètre, le modèle de menaces, les contrôles, la voie de mise à jour et le processus post-commercialisation en une seule décision. Le tableau ci-dessous est le court dossier de version à partir duquel un évaluateur doit pouvoir naviguer.
| Question de version | Preuves spécifiques à la caméra |
|---|---|
| Pourquoi ce produit est-il classé comme caméra de sécurité pour la maison connectée ? | Énoncé de destination prévue, canal de vente, contexte d'installation, variantes du produit et justification de la classification |
| Qu'est-ce exactement que le produit comportant des éléments numériques ? | Corps de la caméra, firmware, interfaces locales, application mobile, traitement cloud fourni avec le produit, service de mise à jour, et systèmes de déploiement tiers exclus |
| Quelles sont les voies d'accès à plus haut risque ? | Interface d'administration, ONVIF/RTSP, découverte réseau local, API cloud, récupération de compte, visualisation à distance, accès microSD, ports de débogage et identifiants de service |
| Qu'est-ce qui est sécurisé par défaut ? | Pas de mot de passe partagé par défaut, installation initiale protégée, accès administrateur authentifié, revue des services exposés, décisions de chiffrement et accès distant sécurisé |
| Comment la caméra sera-t-elle mise à jour en toute sécurité ? | Firmware signé, garde des clés, comportement de retour arrière, récupération par flash partiel, disponibilité des mises à jour, notification utilisateur et mises à jour de sécurité gratuites pendant la période d'assistance |
| Comment les vulnérabilités seront-elles gérées après l'expédition ? | Contact public, politique de CVD, flux de tri, suivi SBOM, veille d'avis fournisseur, processus d'avis de sécurité, préparation à l'alerte précoce de 24 h, préparation à la notification de 72 h et preuves de rapport final |
Vérifications de transfert d'opérateurs économiques
Le dossier de version doit rendre testable le transfert du fabricant à l'importateur, au distributeur et au revendeur sous marque propre. Pour les caméras, le point faible n'est généralement pas le marquage CE seul ; c'est de savoir si l'expédition, l'annonce, l'application, le service cloud et le canal de mise à jour correspondent toujours à la version évaluée.
Détails du transfert d'opérateurs économiques : le fabricant ou le revendeur sous marque propre possède le dossier du fabricant pour la version exacte de la caméra. L'importateur vérifie la justification de classification, la déclaration, le contrôle du marquage CE, l'index du dossier technique, la déclaration de période d'assistance, le contact de signalement des vulnérabilités, la gestion de l'inventaire des composants, les instructions dans la langue de destination et l'identité de l'importateur avant de mettre l'expédition sur le marché de l'UE. Le distributeur vérifie les signaux de diligence visibles avant la vente, y compris le marquage CE, les documents fournis, la traçabilité fabricant et importateur, les instructions dans la langue de destination, les déclarations d'assistance et de mise à jour, la cohérence de l'annonce en ligne et les signaux connus de non-conformité.
Conditions d'arrêt : suspendez l'expédition ou l'annonce si le dossier de version, la traçabilité, la déclaration d'assistance, la dépendance à l'application ou au cloud, le canal de mise à jour ou une vulnérabilité connue donne raison de croire que la version est non conforme. Lisez tout mandat de mandataire séparément de la diligence d'importateur ou de distributeur. Déclencheur de rôle de fabricant : lancez une nouvelle analyse de rôle de fabricant lorsque la marque propre, le firmware, l'application, le cloud, le canal de mise à jour, le pont, le bundle NVR ou les changements d'usage prévu peuvent affecter la conformité ou la destination prévue. Conservez les questions RGPD, cybersécurité de la directive Équipements radio, biométrie, règlement IA et NIS2 séparées de la réponse de classification CRA.
Utilisez la figure suivante comme checklist de rôle. Le premier diagramme de transfert montre le flux d'expédition et d'annonce ; celui-ci sépare les vérifications possédées par l'importateur, le distributeur, le mandataire, le revendeur sous marque propre et le relecteur de régime connexe.
Chaque panneau de rôle associe les vérifications que l'opérateur doit exécuter à la condition d'arrêt qui suspend l'expédition, l'annonce ou la version. L'importateur et le distributeur se situent sur le flux CRA lui-même. Le mandataire ne s'applique que lorsque le fabricant est hors UE et est lu séparément de la diligence d'importateur ou de distributeur. Les vérifications du revendeur sous marque propre peuvent créer un rôle de fabricant si un changement peut affecter la conformité ou la destination prévue ; la classification, la déclaration de conformité, la documentation technique, le processus de signalement et le plan de période d'assistance ne peuvent pas être hérités d'une promesse informelle d'un fournisseur. Les régimes connexes (RGPD, cybersécurité de la directive Équipements radio, règlement IA, NIS2) restent hors de la réponse de classification CRA et nécessitent leurs propres évaluations séparées.
Questions fréquentes
Les caméras de sécurité connectées sont-elles en Classe I ou en Critique au titre du CRA ?
Les caméras de sécurité pour la maison connectée sont généralement en Classe I Important lorsque leur fonction principale est la sécurité physique pour la maison connectée. Une caméra n'est pas Critique simplement parce qu'elle traite de la vidéo ou se trouve sur un réseau sensible.
Enregistrement de classification : une note qui nomme la variante exacte de caméra, l'argument commercial, la fonction de sécurité prévue, les éléments numériques fournis et la justification de la voie choisie.
Une caméra de sécurité pour la maison connectée a-t-elle besoin d'un organisme notifié ?
Pas toujours. Le test pratique est de savoir si le fabricant peut pleinement s'appuyer sur les normes applicables, les spécifications communes ou la couverture d'un schéma de certification cybersécurité qualifiant pour les exigences essentielles de cybersécurité de la caméra. Si cette couverture est manquante ou seulement partielle, prévoyez la voie par tierce partie au lieu de supposer le contrôle interne.
Enregistrement de voie de conformité : listez les références sur lesquelles on s'appuie pour le produit caméra exact, les exigences qu'elles couvrent, les éventuelles lacunes et la voie choisie.
Une caméra CCTV professionnelle ou un NVR sont-ils automatiquement dans la même catégorie ?
Non. Ne classez pas la vidéosurveillance professionnelle uniquement sur le mot « caméra ». Une caméra CCTV, un VMS ou un NVR peut tout de même être un produit comportant des éléments numériques et nécessiter du travail CRA de sécurité, mais la voie dépend de l'usage prévu, des éléments fournis et de la fonction sur laquelle le client s'appuie.
Enregistrement de périmètre : une note de variante de vidéosurveillance professionnelle couvrant la caméra, l'enregistreur, le VMS, le cloud installateur, la voie d'accès distant et tout produit distinct fourni avec l'offre.
Et si la caméra inclut reconnaissance faciale, contrôle d'accès, firewall ou fonctions VPN ?
Traitez cela comme un signal d'alerte de classification. Si la caméra est principalement une caméra de sécurité pour la maison connectée, ces fonctions peuvent faire partie de l'évaluation des risques de la caméra. Si le produit est principalement un lecteur de contrôle d'accès, un dispositif d'authentification biométrique, une passerelle VPN, un firewall, un IDS/IPS ou un autre produit de cybersécurité listé, classez d'abord cette fonction principale et ne forcez pas le produit dans la catégorie caméra. Cela importe parce que certaines catégories ont une voie plus stricte ; par exemple, les firewalls et IDS/IPS sont en Classe II.
Déclencheur de revérification : ouvrez une vérification distincte de fonction principale lorsque la caméra contrôle l'identité, l'accès, le filtrage réseau, l'accès VPN ou la détection d'intrusion plutôt que seulement la surveillance vidéo.
Le stockage vidéo dans le cloud change-t-il le périmètre du produit ?
Le stockage cloud ne change pas automatiquement la classe. Si le traitement cloud fourni par le fabricant est conçu par ou sous la responsabilité du fabricant, et que la caméra n'assurerait pas l'une de ses fonctions sans lui, traitez ce traitement comme faisant partie du périmètre, des preuves et de l'évaluation des risques du produit. La classification du produit suit toujours la fonctionnalité principale de la caméra, sauf si une autre fonction listée est primaire.
Enregistrement de périmètre : une carte de dépendances cloud montrant quels services cloud sont fournis avec la caméra, quelles fonctions échouent sans eux, quelles données ils traitent et quels systèmes sont hors de l'offre du fabricant.
ONVIF, RTSP ou l'interface web d'administration locale doivent-ils rester activés après l'installation ?
Uniquement si la version a un modèle d'accès documenté pour cette surface. Une caméra grand public peut exposer le streaming local ou l'administration pour un usage légitime d'installation, d'installateur ou d'enregistreur, mais le dossier de version doit montrer si la surface reste joignable après enrôlement, quelle authentification la protège, si le chiffrement de transport est utilisé et quel paramètre utilisateur ou revendication de variante le justifie.
Artéfact de test : scans de services après installation et après mise à jour, tests d'authentification ONVIF/RTSP, revue des réponses de découverte et décision de version pour chaque surface locale.
Quand l'évaluation des risques doit-elle être mise à jour ?
Mettez-la à jour chaque fois que l'état publié de la caméra change d'une manière qui affecte la confiance : un nouveau profil ONVIF, un mode de visualisation à distance, un flux de récupération de compte, un relais cloud, un canal OTA, un chipset, une base firmware, un changement d'authentification de l'application mobile, un champ du pack d'assistance ou un comportement de réinitialisation d'usine. Une note de version ne suffit pas si la fonctionnalité modifiée rouvre une voie d'attaque.
Déclencheur de revérification : toute fonctionnalité ou changement fournisseur qui modifie l'accès, l'autorité de mise à jour, la vidéo stockée, l'association de compte, les données d'assistance ou le comportement de réinitialisation rouvre le périmètre et l'évaluation des risques.