Zijn beveiligingscamera's belangrijke producten onder de CRA?
Samenvatting
Een verbonden smart-home camera die voor fysieke beveiliging wordt verkocht, moet worden gepland als een Belangrijk Klasse I-product. De klasse kan veranderen wanneer dezelfde camerahardware voor een ander doel wordt verkocht: videogesprekken, professionele CCTV, opname-infrastructuur, toegangscontrole of een ander beveiligingsproduct.
Het eerste record dat u opstelt, is een classificatie- en grensnotitie voor de exacte cameravariant. Deze moet de beoogde beveiligingsfunctie, de verkoopcontext, de meegeleverde digitale elementen, de ondersteuningsperiode en de routemotivatie benoemen.
Het record van de ondersteuningsperiode moet uitgaan van het verwachte gebruik van de camera, de redelijke verwachtingen van de gebruiker, de aard van het product, het beoogde doel en de relevante componentondersteuning. De CRA-ondergrens is minstens vijf jaar tenzij van het product wordt verwacht dat het korter dan vijf jaar wordt gebruikt, en de einddatum, ten minste maand en jaar, moet duidelijk worden vermeld bij aankoop.
Hoe classificeert u een camerarelease?
Begin bij het aanbod, niet bij de camerabehuizing. De route hangt af van de verkoopclaim, de functie waarop de koper steunt en de digitale elementen die met die release worden meegeleverd.
Verkocht voor videogesprekken, vergaderingen of algemene communicatie.
Communicatierandapparaat; geen huishoudelijke beveiligingsbewaking.
Apparaatfirmware, driver of integratie met een vergaderapp. Geen meegeleverde bewakingscloud of alarmworkflow.
Verkocht voor woningbewaking, babymonitoring, deurbelbeveiliging of alarmintegratie.
Huishoudelijke beveiliging of monitoring is de functie waarop de koper steunt.
Firmware, lokale opslag, app, cameramaker-cloud, updateservice en kwetsbaarheidsafhandeling wanneer die voor die functie worden geleverd.
Verkocht als professionele bewaking, opname-infrastructuur of onderdeel van een ander beveiligingsproduct.
De recorder, VMS, firewall, VPN, toegangscontrole, biometrische of identiteitsfunctie kan het echte product zijn.
Camera plus recorder, beheerserver, installateurscloud, toegangscontroledienst of beveiligingsappliance.
Gebruik het diagram als routinghulpmiddel, niet als definitief classificatierecord. De geschreven notitie heeft nog steeds de exacte claim, het beoogde gebruik en de geleverde grens nodig. Voor een smart-home camera is de sleutelterm smart-home producten met beveiligingsfunctionaliteiten. Een camera die wordt verkocht voor woningbewaking, inbraakdetectie, babymonitoring of alarmintegratie valt in die categorie. Een algemene webcam meestal niet.
Test daarna of een andere vermelde functie het sturende werk doet. Belangrijke classificatie volgt de kernfunctionaliteit van het product, niet de onderdelen die toevallig meeliften: het inbouwen van een beveiligingsrelevante component trekt de rest van het aanbod niet de Belangrijke route in. Wordt de camera in werkelijkheid verkocht als firewall, VPN-gateway, toegangscontrolelezer, biometrisch authenticatieapparaat, identiteitsbeheersysteem of privileged access management-product dat toevallig een lens bevat, classificeer dan eerst die kernfunctie.
Voor professionele bewaking dwingt u de smart-homecategorie niet af. Een professionele CCTV-camera, VMS of NVR kan nog steeds een product met digitale elementen onder de CRA zijn en heeft nog steeds beveiligingseisen, planning van de ondersteuningsperiode, kwetsbaarheidsafhandeling en technische documentatie nodig. De klasse hangt af van het beoogde gebruik, de geleverde grens en de kernfunctie.
De classificatienotitie moet vier vragen beantwoorden:
- Wordt de camera verkocht voor woningbewaking, babymonitoring, deurbelbeveiliging of alarmintegratie?
- Is de camera de kernfunctie van het product, of doet een firewall, VPN, toegangscontrole, biometrische of identiteitsfunctie het echte werk?
- Welke digitale elementen worden geleverd voor de beoogde functie: firmware, lokale opslag, app, fabrikantencloud, updateservice en kwetsbaarheidsafhandeling?
- Welke systemen vallen buiten het aanbod van de fabrikant: router van de klant, recorder van derden, installateursnetwerk, externe identity provider of bewakingscentrale?
Productgrens en geleverde elementen
Voor een cameramaker is de nalevingsgrens zelden alleen de plastic behuizing. Die moet het op de markt aangeboden product volgen en de digitale elementen die nodig zijn voor de beoogde beveiligingsfunctie.
Binnen de grens van de cameramaker, standaard: apparaatfirmware en elke draaiende dienst daarop, de netwerkinterface-stack, opslag op het apparaat, de companion app die de koper wordt verteld te installeren, elke door de cameramaker gehoste cloud die de gedocumenteerde productfuncties levert, de OTA-update-infrastructuur en het kwetsbaarheidsafhandelingsproces erachter.
Buiten die grens tenzij de cameramaker de laag daadwerkelijk verkoopt: de thuisrouter van de koper, een VMS of NVR van derden die de klant heeft gekozen, het netwerk van een installateur, een externe identity provider die voor SSO wordt gebruikt en een professionele bewakingscentrale onder een afzonderlijk contract.
Geen, wanneer deze producten van andere fabrikanten komen. Verkoopt de cameramaker ook de recorder, VMS, identiteitsdienst of cloudbridge als onderdeel van het aanbod, dan kan elk een afzonderlijk CRA-product zijn met een eigen productdossier.
Productdossier · EU-conformiteitsverklaring · CE-markering · Verklaring ondersteuningsperiode · Gebruiksaanwijzing · Conformiteitsbeoordelingsdossier
Door de cameramaker bewaard tot tien jaar nadat de camera op de markt is aangeboden, of gedurende de ondersteuningsperiode, afhankelijk van wat langer is. Wordt een beoordelingsroute met een derde partij gebruikt, bewaar de uitkomst daarvan dan in hetzelfde dossier.
Ontwerpdossier cyberweerbaarheid · Componenteninventaris · Kwetsbaarheidsafhandelingsproces · Openbaarmakingsbeleid · Veilig updatemechanisme
Neem het gepubliceerde centrale contactpunt op, het testbewijs voor veilige standaardinstellingen, de verificatie van gesigneerde updates en de motivering van de ondersteuningsperiode.
Component-due-diligencedossier · Conformiteitsverklaring van de leverancier · Beveiligingsadviezen van leveranciers
De cameramaker blijft verantwoordelijk voor de chipkeuze. Wanneer een chip, module of secure element zelf een CRA-product is, ondersteunt de conformiteitsverklaring en de adviezen van de leverancier de due diligence van de cameramaker, zonder die te vervangen.
De componenteninventaris wordt bewaakt op nieuwe kwetsbaarheden; het kwetsbaarheidsproces triageert bevindingen; gratis beveiligingsupdates leveren oplossingen met adviezen, waar haalbaar automatisch.
Een actief misbruikte camerakwetsbaarheid start een klok: een vroege waarschuwing binnen 24 uur, de kwetsbaarheidsmelding binnen 72 uur en het definitieve kwetsbaarheidsrapport binnen 14 dagen nadat een corrigerende of beperkende maatregel beschikbaar is. Een ernstig beveiligingsincident loopt op een aparte klok met dezelfde 24-uurs- en 72-uursstappen, plus een definitief incidentrapport binnen één maand na de incidentmelding.
Huishoudens die de getroffen camera's gebruiken, horen ook van de cameramaker. De cameramaker laat de getroffen eigenaren, en de bredere klantenkring waar de blootstelling dat verdient, weten wat er mis is en welke stappen zij zelf kunnen toepassen: geforceerde firmware-update, app-upgrade, wachtwoord opnieuw instellen, optionele dienst uitschakelen of fabrieksreset vóór doorverkoop.
Architectuurcontrolepunten voor de camera
Het camerareleasedossier moet het feitelijke videoproduct volgen, niet een generieke IoT-checklist. Een Wi-Fi-camera op batterij, een PoE-domecamera, een mobiele buitencamera en een camera die met een NVR wordt verkocht, kunnen één klassediscussie delen en toch verschillende engineeringdossiers vragen.
Lees het diagram als kaart van het releasedossier, niet als verplicht uitrolpatroon. De fabrikant moet nog steeds de exacte variantgrens schrijven voor zijn eigen camera, app, clouddienst, updatepad en ondersteuningsmodel.
- Video- en bedieningspad. Identificeer elk pad dat video kan bekijken, opslaan, exporteren of besturen: lokale stream, web-UI, app-sessie, cloudrelais, deellink, support-export en compatibiliteitsclaim met NVR of VMS.
- Lokale blootstelling. Scan de camera na inbedrijfstelling en na update. Toon welke diensten bereikbaar zijn, welke authenticatie vragen en welke stream- of admin-paden uitgeschakeld blijven.
- Systemen van de klant. Behandel de router, het installateursnetwerk, recorder van derden, externe identity provider en bewakingscentrale als buiten het product van de cameramaker, tenzij de cameramaker die laag als onderdeel van het aanbod levert.
- Backends die door de cameramaker worden geleverd. Bepaal in of uit: de accountdienst, ondertekeningspipeline, event- of meldingsdienst, supportportaal, feature-flagdienst voor betaalde functies en elk cloud-ML-pad.
- Updatebevoegdheid. Behandel updatebevoegdheid als een tweezijdige uitwisseling: de camera controleert of ontvangt update-metadata, en de updatedienst stuurt een gesigneerd firmware- of app-pakket terug voor exact die variant. Bewaar dossiers van gesigneerde updates, herstelsleuf, downgrade-afwijzing en gebruikersmeldingen bij de release.
- Leveranciersinputs. Geef de SoC, Wi-Fi-module, mediastack, AI-model, P2P SDK en bootloader een verantwoordelijke, versie, advisory watch en releasebesluit.
- Post-market-lus. Kwetsbaarheidsmeldingen, ernstige incidenten, leveranciersadviezen en veldfouten moeten het dreigingsmodel, het restrisicodossier, het technisch dossier en het volgende release-gate bijwerken.
Uitgewerkte camerarisicobeoordeling
Lees de rest van deze sectie als één uitgewerkt cameravoorbeeld, niet als een checklist om over te nemen. Het doel is om de mate van besluitvorming te tonen die een cameramaker moet kunnen verdedigen voor één specifieke variant: de chipset- en modulekeuzes, de firmware-build, het cloudrelais, het OTA-kanaal, de leveranciersadviezen die u daadwerkelijk volgt, het verkoopkanaal waarvoor u zich heeft aangemeld en het ondersteuningsvenster waaraan u zich heeft verbonden.
Welk product beoordelen we?
Illustratief voorbeeldproduct, geen echt apparaat: ExampleCo IndoorCam X1, een binnenshuis smart-home camera die in de EU wordt verkocht voor huishoudelijke beveiligingsbewaking. Hij neemt 1080p-video en audio op, slaat clips op een microSD-kaart op, streamt live video via een mobiele app naar de eigenaar, biedt tijdens inbedrijfstelling een lokale web-admin-interface, gebruikt BLE voor de eerste onboarding, verbindt via Wi-Fi en ontvangt gesigneerde firmware-updates van de fabrikant.
De productgrens in dit voorbeeld omvat de camerahardware, embedded firmware, microSD-opname, koppelflow van de mobiele app, cloudrelais van de fabrikant, accountdienst, OTA-updatedienst, beveiligingsadviesproces en contactpunt voor kwetsbaarheidsmelding. Erbuiten vallen de router van de klant, VMS/NVR van derden, woningautomatiseringsplatform en een professionele bewakingscentrale.
Het product is bedoeld voor niet-technische huishoudelijke gebruikers in een binnenshuisomgeving. Het is niet bedoeld voor industriële CCTV, bewaking van openbare ruimtes, toegangscontrole, biometrische authenticatie of identiteitsverificatie, werkplekbewaking of beveiligingsoperaties voor kritieke infrastructuur.
Voordat u de dreigingstabel schrijft, test u de drie camerapaden die de risicobeoordeling meestal sturen: videobeheer, apparaatidentiteit en blootstelling na inbedrijfstelling. Deze diagrammen vertalen het uitgewerkte voorbeeld naar engineeringvragen in plaats van een generieke dreigingslijst.
Details videobeheer: de bron is de camerasensor, microfoon en encoder, met beeldtuningblobs, audiopad, privacymasker, AI-detectie-inputs en streamprofielen die aan een firmware-build zijn gekoppeld. Het lokale bekijkpad omvat ONVIF, RTSP, webpreview of browser en wordt geverifieerd door een authenticatie- en blootstellingsscan. Het remote bekijkpad omvat cloudrelais, P2P SDK of eigenaar-app en wordt geverifieerd door een tokenscope- en relaistest. Het lokale mediapad omvat microSD-clips en verwijderbare opslag en wordt geverifieerd door reset- en kaartverwijderingstests. Het supportpad omvat supportbundle en diagnostiekexport en wordt geverifieerd door een redactiechecklist.
Reset-, unbind- en RMA-wipetests bewijzen welke video, tokens en accountkoppelingen worden verwijderd vóór doorverkoop, refurbishment of supportoverdracht.
Eigendom is een aparte controle van videobeheer. Een camera kan een beschermde stream hebben en toch falen wanneer een oude eigenaar, gedeelde gebruiker of teruggevonden telefoon na overdracht toegang houdt.
Details identiteitslevenscyclus: provisioning maakt de camerasleutel of het certificaat aan, legt de hardware-identiteit vast en vergrendelt de productiedebugtoegang. Eigenaarinbedrijfstelling gebruikt een geverifieerd account plus een eenmalig kortlevend QR-, BLE- of app-claimtoken en sluit het eerste-gebruiksvenster nadat de camera is gekoppeld. Normaal gebruik hanteert hetzelfde herroepingsmodel voor wachtwoordreset, accountherstel, herstel na verloren telefoon, familiedeling, gastkijkers en browsersessies. Eigenaarsoverdracht vereist een geautoriseerd unbind-pad, verwijdert het oude account, herroept gedeelde gebruikers en beëindigt actieve sessies voordat de camera opnieuw kan worden geclaimd. Fabrieksreset, RMA en refurbishment verwijderen de accountkoppeling, credentials, clips en diagnostiek volgens het productontwerp; RMA-afhandeling mag geen kanaal voor witwassen van diefstal worden.
Misbruiktests: een inbedrijfstellingstoken verloopt, is eenmalig en kan niet worden hergebruikt door een nabije aanvaller na de eigenaarsclaim; een oude telefoon, gastgebruiker of browsersessie kan na herstel geen live of opgenomen toegang behouden; en lokale reset laat geen cloudbinding, accounttokens of clips achter.
Nadat eigendom is getest, controleert u wat nog steeds bereikbaar is vanaf het netwerk, de app, verwijderbare media en supportworkflows. Zo blijft de blootstellingsreview gekoppeld aan het feitelijk geleverde gedrag in plaats van een generiek poortscanresultaat.
Details toegangsoppervlak: lokale LAN-diensten omvatten RTSP, ONVIF, web-UI en discovery-endpoints, en het releaserecord is de blootstellingsscan. Remote bekijken omvat cloudrelais, delen en apparaatidentiteit, en het releaserecord is de cloud-tokenscope-test. Verwijderbare media omvat microSD-clips, resetgedrag en opslagbeslissingen, en het releaserecord is het microSD-resetresultaat. Supportdiagnostiek omvat logs, crash dumps en supportmodus, en het releaserecord is de audit-steekproef van de supportmodus.
Welke assets beschermen we?
Camera's beschermen heel verschillende dingen in dezelfde behuizing. Een opgenomen clip van een kinderkamer, een eigenaarsaccount dat de lens kan draaien en een firmware-ondertekeningssleutel die elk apparaat aanstuurt dat dit jaar is verzonden, leven allemaal achter één product. Vermeld ze eerst als afzonderlijke assets, want de controleset, het testbewijs en het releaserecord lopen scherp uiteen.
| Asset | Waarom dit telt | Waar het staat |
|---|---|---|
| Live en opgenomen video/audio | Onthult privéruimtes, routines, bezoekers, kinderen, huisdieren en gesprekken | Sensor, RAM, encoder, microSD, streambuffer, cloudrelais |
| Eigenaarsaccount en herstelfactor | Een overname kan toegang tot bekijken op afstand, apparaatreset en wijzigingen in delen verlenen | Mobiele app, identiteitsdienst, e-mail-/SMS-herstelpad |
| Device-to-cloud credential | Persistente vertrouwenstoken; moeilijk te roteren over een uitgerold vlootbestand | Secure element of beschermde opslag, accountbindingdienst |
| Vertrouwensanker voor firmware-ondertekening | Bij compromis kan het updatekanaal een malwarekanaal worden | Bootketen, keystore, ondertekeningsdienst, releasepipeline |
| Lokale netwerkpositie | De camera zit in het huishoudelijk LAN en kan lokale peers zien | Wi-Fi-interface, DHCP-lease, mDNS/SSDP-zicht |
| Diagnose- en supportbundle | Kan serienummers, account-ID's, netwerknamen en crashtraces lekken | Apparaatlogs, supportportaal, interne supporttooling |
| Gebruiksaanwijzing en supportdatum | Stuurt veilige inbedrijfstelling, updateverwachtingen en afhandeling einde ondersteuning | Verpakking, webhandleiding, app-UI, productvermelding |
Waar liggen de belangrijkste vertrouwensgrenzen?
Een camera zit tegelijk op vijf plaatsen: het apparaat zelf, de microSD-kaart die iedereen in de ruimte kan verwijderen, het thuisnetwerk dat hij deelt met telefoons en onbekende IoT-peers, de fabrikantbackend die elke camera in het veld raakt, en de eigenaarstelefoon of -browser die de live sessie vasthoudt. Elk verandert de aanvallerskans en vraagt om een ander controleoppervlak, dus het vertrouwensgrensmodel vermeldt ze afzonderlijk, ook al verbinden ze elkaar.
| Omgeving | Verwachte bescherming | Waarom de waarschijnlijkheid verandert |
|---|---|---|
| In de camera | Fysieke toegang is beperkt, maar reparatie, diefstal, doorverkoop en debugpads bestaan | Lagere kans op afstand, hogere impact wanneer sleutels uitleesbaar zijn |
| microSD/lokale media | Iedereen met toegang tot de ruimte kan de kaart verwijderen of kopiëren | Lokale toegang is aannemelijk in huizen met gasten, schoonmakers, huurders of doorverkoop |
| Thuisnetwerk | Gedeeld met laptops, telefoons, tv's, printers en onbekende IoT-apparaten | Een gecompromitteerde peer kan lokale admin-, discovery- of streamdiensten aanvallen |
| Fabrikantbackend | Internet-facing en gedeeld over het geïnstalleerde vlootbestand | Een backendfout schaalt van één huishouden naar vele |
| Eigenaarsendpoint | Telefoons en browsers staan bloot aan phishing, malware en hergebruik van accounts | Accountcompromis omzeilt vaak de apparaatharding |
Welke dreigingen worden eerst beoordeeld?
Dit voorbeeld start met zestien productspecifieke dreigingen. Het doel is niet volledigheid; het doel is het niveau van traceerbaarheid tonen dat een fabrikant moet kunnen verdedigen.
| ID | Dreigingsscenario | Asset onder risico | Ingangspunt |
|---|---|---|---|
| T1 | Een gedeeld of voorspelbaar eerste-gebruiksgeheim laat een aanvaller de camera claimen voordat de eigenaar de inbedrijfstelling afrondt | Eigenaarsaccount, videostream | BLE-onboarding / lokale inbedrijfstelling |
| T2 | De lokale web-admin-interface accepteert zwakke credentials of blijft na inbedrijfstelling open | Configuratie, streamtoegang | Thuisnetwerk |
| T3 | Een gestolen mobiele-app-token blijft geldig na wachtwoordreset en blijft de camerafeed openen | Eigenaarsaccount, live video/audio | Eigenaarsendpoint / cloudrelais |
| T4 | P2P-fallback, STUN/TURN/ICE-afhandeling, UPnP of hole punching stelt de camera direct bloot wanneer het relaispad faalt of wordt geblokkeerd | Firmware-diensten, streamtoegang | Internet-aangrenzend relaispad |
| T5 | ONVIF/RTSP antwoordt op het LAN met zwakke authenticatie of vindbare stream-URL's | Live video/audio | Thuisnetwerk |
| T6 | De herstelsleuf accepteert een ongesigneerd, oud of gedowngraded firmware-image | Firmware-integriteit, vertrouwensanker voor ondertekening | OTA / herstelpad |
| T7 | UART/JTAG-pads laten boot-time-toegang toe bij diefstal, reparatie of doorverkoop | Apparaatgeheimen, firmware, logs | Fysieke debugtoegang |
| T8 | microSD-clips zijn leesbaar na kaartverwijdering of nadat de camera is doorverkocht | Opgenomen video/audio | Lokale media |
| T9 | BLE-onboarding stelt de Wi-Fi-credential of het apparaatkoppelingsgeheim bloot aan een nabije aanvaller | Wi-Fi-credential, eigenaarsaccount | BLE-inbedrijfstellingsvenster |
| T10 | Supportbundles bevatten serie-, account-, SSID-, tokenfragmenten of privé-crashtraces | Diagnostische gegevens, accountkoppelbaarheid | Support-upload |
| T11 | Een leverancierskwetsbaarheid in de Wi-Fi-module of mediastack wordt tijdens de ondersteuningsperiode niet gedetecteerd | Firmware, beschikbaarheid, streamvertrouwelijkheid | Hiaat in leveranciersadviezen |
| T12 | RMA- of doorverkoopreset wist accountbinding, clips of apparaatcredentials niet | Eigenaarsaccount, opgenomen media, device-to-cloud credential | Retourpad |
| T13 | Discovery-diensten onthullen model, firmware, serie of streammetadata aan elk apparaat op het LAN | Apparaatfingerprint, streamblootstelling | ONVIF / WS-Discovery / mDNS |
| T14 | De RTSP-streamer wordt anders beschermd dan de web-UI, waardoor een live stream na admin-harding bereikbaar blijft | Live video/audio | Lokale streamdienst |
| T15 | Een fout in een P2P- of media-SDK van derden laat voorspelling of enumeratie van device-UID, apparaatimpersonatie of compromis van streamsessies toe | Live video/audio, apparaatcredential | Cloudrelais / SDK |
| T16 | Camera-firmware gebruikt een ISP-, Wi-Fi- of AI-blob van een leverancier die niet in het SBOM-watchproces zit | Firmware-integriteit, kwetsbaarheidsafhandeling | Leveranciersfirmware |
Hoe moeten de initiële risico's worden gerangschikt?
Gebruik een eenvoudige interne rubriek voordat u controles kiest. In dit voorbeeld is waarschijnlijkheid gebaseerd op blootstelling en aanvallerskans; impact is gebaseerd op privacyschade, vlootomvang, persistentie en de vraag of de dreiging een beveiligingsmechanisme compromitteert. De exacte labels tellen minder dan de motivering die naast elke beslissing wordt geschreven.
Gebruik een release-gate-ladder, zodat niet elk camerarisico dezelfde beslissing krijgt:
| Gate-beslissing | Betekenis voor deze camerarelease |
|---|---|
| Release blokkeren | De camera wordt pas verzonden wanneer de falende test slaagt: koppeling, streamauthenticatie, verificatie van gesigneerde updates, RMA-wipe of blootstellingsscan na inbedrijfstelling, afhankelijk van de dreiging. |
| Blokkeren tenzij gedocumenteerd | Release mag alleen doorgaan wanneer een compenserende controle, variant-specifieke beperking of installateursmodusmotivering wordt geschreven, beoordeeld en aan het camerareleasedossier wordt gehecht. |
| Vrijgeven met monitoring | De camera wordt verzonden, maar het releasedossier benoemt het actieve monitoringssignaal (leveranciers-CVE-feed, P2P-SDK-adviezen, misbruik-telemetrie) en de engineer die er tijdens de ondersteuningsperiode verantwoordelijk voor is. |
| Doorzetten naar richtlijn | De blootstelling hangt af van het thuisnetwerk, de eigenaarstelefoon of recorder van derden buiten het aanbod van de cameramaker, dus het dossier bewaart installateur- of gebruikersrichtlijnen in plaats van de klantkant te willen besturen. |
| Accepteren | Sommige cameraoppervlakken (gedocumenteerde discovery-antwoorden, LAN-metadata) dragen inherent restrisico, dus het dossier legt het minimalisatiebewijs en de motivering vast voor wat overblijft. |
| ID | Waarschijnlijkheid | Impact | Gate-beslissing | Waarom |
|---|---|---|---|---|
| T1 | Middel | Hoog | Release blokkeren | Eerste-gebruiksovername is realistisch en ondermijnt eigendom |
| T2 | Hoog | Middel | Release blokkeren | Thuis-LAN's bevatten niet-vertrouwde peers en hergebruikte wachtwoorden |
| T3 | Middel | Hoog | Release blokkeren | Diefstal van accounttoken geeft bekijken op afstand zonder de camera aan te raken |
| T4 | Laag | Hoog | Blokkeren tenzij gedocumenteerd | Zeldzaam pad, maar directe blootstelling kan schalen; een geleverd product heeft een gedocumenteerd relais- en NAT-traversal-besluit nodig |
| T5 | Middel | Hoog | Release blokkeren | Lokale streamblootstelling is een directe privacyfout |
| T6 | Laag | Hoog | Release blokkeren | Updatecompromis is persistent en vlootbreed |
| T7 | Middel | Middel | Blokkeren tenzij gedocumenteerd | Fysieke debug is aannemelijk bij diefstal, reparatie of doorverkoop; de release heeft een debug-lock- of servicemotivering nodig |
| T8 | Hoog | Middel | Blokkeren tenzij gedocumenteerd | Lokale kaartverwijdering is gangbaar; bescherm clips of documenteer duidelijk de beperking van verwijderbare media |
| T9 | Middel | Hoog | Release blokkeren | Onboarding is kortlevend, maar stelt de credential van het thuisnetwerk bloot |
| T10 | Middel | Middel | Blokkeren tenzij gedocumenteerd | Lekken van supportgegevens zijn moeilijk te merken; support-export moet worden geminimaliseerd, geredigeerd of expliciet uitgeschakeld |
| T11 | Middel | Hoog | Vrijgeven met monitoring | Leveranciers-CVE's zijn tijdens de ondersteuningsperiode te verwachten; de release heeft een verantwoordelijke en advisory watch nodig |
| T12 | Middel | Hoog | Release blokkeren | Retour- en doorverkooppaden zijn voorzienbaar voor consumentenapparaten |
| T13 | Middel | Middel | Accepteren | Sommige LAN-metadata zijn inherent aan gedocumenteerde discovery-protocollen; het restrisico wordt alleen geaccepteerd met blootstellingminimalisatie en gebruikersrichtlijn voor optionele discovery waar ondersteund |
| T14 | Middel | Hoog | Release blokkeren | Streamauthenticatie mag niet zwakker zijn dan het gedocumenteerde toegangsmodel |
| T15 | Laag | Hoog | Vrijgeven met monitoring | SDK- of relais-zwakheden kunnen veel apparaten raken, dus de release heeft eigenaarschap van versie en misbruik-monitoring nodig |
| T16 | Middel | Hoog | Blokkeren tenzij gedocumenteerd | Gesloten of door leveranciers onderhouden blobs hebben een release-verantwoordelijke, adviezenkanaal en updatepad nodig, of een geschreven restrisicobeslissing |
Welke ontwerpcontroles veranderen het risicobeeld?
Koppel elke controlerij aan een specifieke cameratest, niet aan een generieke secure-development-checklist. Het releasedossier moet vanaf een dreigings-ID kunnen verwijzen naar de exacte koppelingstest, streamauthenticatiescan, verificatielog van gesigneerde updates, dienstinventaris na inbedrijfstelling of RMA-wiperecord die bewijst dat de controle op de geleverde camera-build draait.
| Dreigingen | Ontwerpcontrole | Bewijs dat de fabrikant moet bewaren |
|---|---|---|
| T1, T2 | Per-apparaat inbedrijfstellingsgeheim, geforceerde eigenaarinschrijving, geen gedeeld standaardwachtwoord, inbedrijfstellingsinterface sluit na inschrijving | Inbedrijfstellingstestlog, credentialbeleid, negatieve test op ongeauthenticeerde admin-toegang |
| T3 | Kortlevende app-tokens, apparaatgebonden sessies, server-side herroeping bij wachtwoordreset, login-anomalie-monitoring | Beleid tokenlevensduur, herroepingstests, misbruiktests accountherstel |
| T4, T5 | UPnP standaard uitschakelen, geauthenticeerd relais, geauthenticeerd ONVIF/RTSP, dienstinventaris na inbedrijfstelling | Netwerkblootstellingsscan, streamauthenticatietests, review relaisconfiguratie |
| T6 | Secure boot, gesigneerde OTA, monotone versieteller, handtekeningcontrole op de herstelsleuf, rollbackbeleid | Bootketenbewijs, updateverificatietests, downgrade-afwijzingstests |
| T7 | Productiefuses voor debug, verzegelde of gedocumenteerde debugpads, geen geheimen in leesbare UART-output | Hardware-productiechecklist, verificatie debug-lock, teardown-risiconotitie |
| T8 | Versleutelde microSD-opname waar de cameravariant dat ondersteunt (Eufy, TP-Link Tapo op ondersteunde modellen); veilige erase bij fabrieksreset; duidelijke gebruikerswaarschuwing in de handleiding en in de app voor varianten die onversleuteld opnemen | Opslagontwerpnotitie, resettest, screenshot gebruiksaanwijzing, in-app-waarschuwingsopname |
| T9 | Geauthenticeerde BLE-koppeling, kort koppelingsvenster, Wi-Fi-geheim nooit in plaintext verzonden, koppelingsratelimieten | Review koppelingsprotocol, RF-test, faalmodustest |
| T10 | Minimalisatie supportbundle, tokenredactie, gebruikersconsent vóór upload, retentielimiet | Supportschema, redactietests, supportworkflowbewijs |
| T11 | SBOM-monitoring, leveranciersadvisory watch, triage van getroffen componenten, gesigneerd update-releaseproces | SBOM-difflog, record leveranciersadvies, triagebesluiten |
| T12 | RMA-wipeworkflow, cloud-unbind, credentialrotatie bij reset, refurbished-apparaatchecklist | Retourlijnchecklist, resetbewijs, audit cloud-unbind |
| T13, T14 | Dienstinventaris na inbedrijfstelling, geauthenticeerde stream-URL's, minimalisatie van discovery-antwoorden, profiel-/versietestbewijs | Blootstellingsscans, ONVIF/RTSP-authenticatietests, audit discovery-antwoorden |
| T15 | P2P-SDK-inventaris, scope sessietoken, entropie device-UID, SDK-advisory watch, impersonatie- en misbruikcase-tests | Record SDK-versie, UID-enumeratietest, apparaatimpersonatietest |
| T16 | Leveranciersfirmware-inventaris voor ISP-, Wi-Fi-, encoder- en AI-componenten; componentverantwoordelijke en updatepad | Bill of materials leveranciers, record advisory watch, logboek releasebesluit |
Welk restrisico blijft over na controles?
Controles sluiten het dossier niet. Nadat de camera is verzonden, draait de cameramaker nog steeds de actief beheerde risico's: het firmware-updatekanaal, paden voor accountovername en de lange staart van leveranciers-CVE's in de Wi-Fi-stack, mediabibliotheken en P2P-SDK's die gedurende de ondersteuningsperiode opduiken. Het restrisicodossier is alleen geloofwaardig wanneer de cameramaker kan wijzen op live monitoring van die signalen, triagebesluiten voor nieuwe adviezen, gesigneerde updates die de geïnstalleerde camera's daadwerkelijk hebben bereikt, eigenaarsmeldingen die zijn uitgegaan en een vastgelegde corrigerende actie achter elk daarvan.
| Restrisicogebied | Waarom het blijft | Operationeel bewijs |
|---|---|---|
| Gecompromitteerd eigenaarsendpoint | De fabrikant kan de telefoon, browser, e-mail of wachtwoordhygiëne van de gebruiker niet volledig beheersen | MFA-ondersteuning, tokenherroeping, verdachte-login-alerting, gebruikersrichtlijn |
| Leverancierskwetsbaarheid ontdekt na release | Mediabibliotheken, Wi-Fi-firmware, kernels en TLS-bibliotheken blijven CVE's ontvangen | SBOM-watch, intake leveranciersadviezen, impactanalyse, patchrecord |
| Lokale fysieke toegang | Een camera in een huis kan worden gestolen, doorverkocht, gerepareerd of door gasten worden benaderd | Resetworkflow, debug-lock-bewijs, opslagwaarschuwing, RMA-wiperecord |
| Drift in netwerkblootstelling | Firmware-updates, relaiswijzigingen of feature flags kunnen diensten heropenen | Blootstellingsscan per release, dienstinventaris, wijzigingsgoedkeuring |
Het release-gate is het risicoregister zelf. Voeg geen aparte "beveiliging beoordeeld"-kaart toe die hetzelfde werk herhaalt. Bij sign-off moet de release-verantwoordelijke vanaf de geblokkeerde of voorwaardelijke dreigingen kunnen verwijzen naar het afsluitend bewijs: koppelings- en streamtests voor T1/T2/T5/T14, tokenherroeping voor T3, tests voor gesigneerde updates voor T6, opslag-/resetbewijs voor T8, RMA-wipebewijs voor T12, en leveranciersmonitoring voor T11/T16.
Camera-ontwikkelingseigendom van concept tot ondersteuning
Het hoofdeigendom verschuift terwijl de camera zich beweegt van productdefinitie naar live ondersteuning. Gebruik deze overdracht om in elke fase, terwijl het product verandert, één verantwoordelijke, één bijgehouden record en één review-gate toe te wijzen.
Eigendomsdetails: Product en security beheren de variantgrensnotitie in het concept. Product security samen met firmware en cloud beheren de vertrouwensgrenskaart, het dreigingsregister en de gate-ladder in de architectuur. Firmware-, cloud-, app- en leveranciersverantwoordelijken onderhouden tijdens implementatie de regels voor gesigneerde updates, token- en sessiecontroles, het componentmanifest, leveranciersadviezenfeeds en feature-flagbesluiten. QA samen met product security onderhoudt tijdens verificatie blootstellingsscans, streamauthenticatietests, videobeheertests, reset- of RMA-wipeoefeningen en restrisicobesluiten. Compliance en de release-verantwoordelijke onderhouden het release-pakket, de index van het technisch dossier, de instructies, de verklaring van de ondersteuningsperiode, de gesigneerde verklaring, het importeurspakket en de meldingsbereidheid. PSIRT, support en engineering onderhouden na release de intake, triage van leveranciersadviezen, gebruikersmeldingen, gesigneerde fixes, endpointuitfasering, regressietests en records van corrigerende actie.
Overdrachtsdetails: bevries de grens vóór architectuurwerk, bevries de ontwerpintentie vóór implementatie, bevries de kandidaat vóór verificatie, bevries het besluit vóór release en laat de release operationeel blijven gedurende de ondersteuningsperiode. Inkomende meldingen, leveranciersadviezen, incidentuitkomsten en regressieresultaten heropenen de volgende grensnotitie, het dreigingsregister en het componentmanifest.
Bewijskaart voor de fabrikant
Een reviewer of beoordelaar van een aangemelde instantie loopt een cameratechnisch dossier zoals een installateur de doos doorloopt: van het gelabelde product, via de meegeleverde digitale elementen, naar het ondersteuningsbewijs dat de koper wordt beloofd. De onderstaande rijen benoemen de records die cameramakers actueel houden voor die rondgang; elke rij moet een bijgehouden bestand in de productmap zijn, geen steekproefscreenshot dat vóór sign-off wordt opgehaald.
| Bewijsgebied | Wat vast te leggen voor een beveiligingscamera |
|---|---|
| Productidentiteit | Model, firmware-versies, companion app, clouddienst, hardware-revisies |
| Beoogd doel | Of het product wordt verkocht voor woningbeveiliging, babymonitoring, deurbelbeveiliging of professionele bewaking |
| Risicobeoordeling | Cameratoegang, video-vertrouwelijkheid, credential-inbedrijfstelling, blootstelling van lokaal netwerk, blootstelling van cloud-API |
| SBOM en bewijs hardwarecomponenten | Firmware-pakketten, embedded Linux/RTOS-componenten, beeldverwerkingsbibliotheken, Wi-Fi/Ethernet-modulefirmware, SoC en secure element waar aanwezig |
| Veilige standaardinstellingen | Geen gedeeld standaardwachtwoord, veilige eerste-gebruiks-inbedrijfstelling, geauthenticeerde admin-toegang, beschermde toegang op afstand |
| Updatemechanisme | Gesigneerde firmware-updates, rollbackstrategie, beschikbaarheid van updates gedurende de ondersteuningsperiode |
| Kwetsbaarheidsafhandeling | CVD-beleid, meldingscontact, triageworkflow, beveiligingsadviesproces |
| Gebruiksaanwijzing | Veilige installatie, accountinbedrijfstelling, update-instellingen, openbaarmaking einde ondersteuning |
| Traceerbaarheid en contact | Cameramodel en serienummerschema, batchidentifier, verpakkingsmarkeringen, contact EU-fabrikant of importeur, einddatum van de ondersteuningsperiode gedrukt op een plek waar de koper die vóór aankoop kan lezen, en een gepubliceerd meldingsadres voor kwetsbaarheden dat door een menselijk securityteam wordt beantwoord |
Conformiteitsbeoordelingsroute
Kies de conformiteitsroute nadat de cameragrens, risicobeoordeling, controles en restrisico's duidelijk zijn. Anders kan het routebesluit het engineeringrecord voorbijstreven.
Belangrijk Klasse I vereist niet automatisch een aangemelde instantie in elk geval. De interne-controleroute is alleen beschikbaar wanneer de vereiste normen, specificaties of regelingen volledig worden toegepast voor de toepasselijke eisen.
Bevestig of relevante geharmoniseerde normen, gemeenschappelijke specificaties of EU-certificeringsregelingen op een zekerheidsniveau van minstens substantieel bestaan en de toepasselijke essentiële vereisten dekken. Bestaan deze niet, worden ze slechts deels toegepast of dekken ze niet alle relevante eisen, gebruik dan Module B+C of Module H.
Voor een echte camerarelease bereidt u het releasedossier voor alsof een review door een derde partij nodig kan zijn, en bevestigt u vervolgens de route zodra de toepasselijke normen en regelingen voor het exacte cameraproduct duidelijk zijn.
Bewaar de gekozen route bij het release-sign-off-record, inclusief de gehanteerde referenties, de eisen die ze dekken en eventuele hiaten die een route met een derde partij hebben afgedwongen.
Sign-off van de fabrikant voor release
Voordat de camera voor de EU-markt wordt vrijgegeven, moet de sign-off de classificatie, grens, het dreigingsmodel, de controles, het updatepad en het post-market-proces in één besluit samenbrengen. De onderstaande tabel is het korte releasedossier waarin een reviewer moet kunnen navigeren.
| Releasevraag | Cameraspecifiek bewijs |
|---|---|
| Waarom wordt dit product geclassificeerd als smart-home beveiligingscamera? | Verklaring van beoogd gebruik, verkoopkanaal, installatiecontext, productvarianten en de classificatiemotivering |
| Wat is precies het product met digitale elementen? | Camerabehuizing, firmware, lokale interfaces, mobiele app, cloudverwerking die met het product wordt geleverd, updateservice en uitgesloten uitrolsystemen van derden |
| Wat zijn de hoogste-risico toegangspaden? | Admin-UI, ONVIF/RTSP, lokale netwerkdiscovery, cloud-API's, accountherstel, bekijken op afstand, microSD-toegang, debugpoorten en servicecredentials |
| Wat is standaard beveiligd? | Geen gedeeld standaardwachtwoord, beschermde eerste-gebruiks-inbedrijfstelling, geauthenticeerde admin-toegang, review van blootgestelde diensten, encryptiebesluiten en beveiligde toegang op afstand |
| Hoe wordt de camera veilig bijgewerkt? | Gesigneerde firmware, sleutelbeheer, rollbackgedrag, gedeeltelijke-flashherstel, beschikbaarheid van updates, gebruikersmelding en gratis beveiligingsupdates gedurende de ondersteuningsperiode |
| Hoe worden kwetsbaarheden na levering afgehandeld? | Openbaar contact, CVD-beleid, triageworkflow, SBOM-monitoring, leveranciersadvisory watch, beveiligingsadviesproces, gereedheid 24-uurs vroege waarschuwing, gereedheid 72-uurs melding en bewijs van het eindrapport |
Overdrachtschecks voor economische actoren
Het releasedossier moet de overdracht van fabrikant naar importeur, distributeur en private-label verkoper toetsbaar maken. Voor camera's is het zwakke punt meestal niet de CE-markering alleen; het is de vraag of de zending, vermelding, app, clouddienst en updatekanaal nog steeds overeenkomen met de beoordeelde release.
Details overdracht economische actoren: de fabrikant of private-label maker beheert het fabrikantsdossier voor de exacte camerarelease. De importeur verifieert de classificatiemotivering, verklaring, controle CE-markering, index van het technisch dossier, verklaring van de ondersteuningsperiode, contactpunt voor kwetsbaarheidsmelding, afhandeling van de componenteninventaris, instructies in de bestemmingstaal en importeursidentiteit voordat de zending op de EU-markt wordt geplaatst. De distributeur controleert vóór verkoop zichtbare due-care-signalen, inclusief CE-markering, meegeleverde documenten, traceerbaarheid van fabrikant en importeur, instructies in de bestemmingstaal, ondersteunings- en updateverklaringen, consistentie van de online vermelding en bekende non-conformiteitssignalen.
Stopvoorwaarden: pauzeer de zending of vermelding wanneer het releasedossier, de traceerbaarheid, de ondersteuningsverklaring, de app- of cloudafhankelijkheid, het updatekanaal of een bekende kwetsbaarheid reden geeft om aan te nemen dat de release non-conform is. Lees een mandaat voor de gemachtigde vertegenwoordiger los van de due care van importeur of distributeur. Triggerregel fabrikantsrol: voer een verse fabrikantsrolanalyse uit wanneer eigen branding, firmware, app, cloud, updatekanaal, bridge, NVR-bundle of beoogd-gebruikwijzigingen de conformiteit of het beoogde doel kunnen beïnvloeden. Houd vragen over AVG, cyberbeveiliging onder de Radioapparatuurrichtlijn, biometrie, AI-verordening en NIS2 los van het CRA-classificatieantwoord.
Gebruik de volgende figuur als rolchecklist. Het eerste overdrachtsdiagram toont de zendings- en vermeldingsflow; deze scheidt de checks die in handen zijn van de importeur, distributeur, gemachtigde vertegenwoordiger, private-label verkoper en reviewer voor aangrenzende regelgeving.
Elk rolpaneel koppelt de verificaties die de actor moet uitvoeren aan de stopvoorwaarde die zending, vermelding of release pauzeert. De importeur en distributeur zitten op de CRA-flow zelf. De gemachtigde vertegenwoordiger geldt alleen wanneer de fabrikant buiten de EU is gevestigd en wordt los van de due care van importeur of distributeur gelezen. Checks voor private-label verkopers kunnen een fabrikantsrol creëren wanneer een wijziging de conformiteit of het beoogde doel kan beïnvloeden; classificatie, conformiteitsverklaring, technische documentatie, meldingsproces en plan voor de ondersteuningsperiode kunnen niet als een informele leveranciersbelofte worden overgenomen. Aangrenzende regelgeving (AVG, cyberbeveiliging onder de Radioapparatuurrichtlijn, AI-verordening, NIS2) blijft buiten het CRA-classificatieantwoord en vraagt om eigen afzonderlijke beoordelingen.
Veelgestelde vragen
Zijn slimme beveiligingscamera's Klasse I of Kritiek onder de CRA?
Smart-home beveiligingscamera's zijn doorgaans Belangrijk Klasse I wanneer hun kernfunctie smart-home fysieke beveiliging is. Een camera is niet Kritiek louter omdat hij video verwerkt of op een gevoelig netwerk zit.
Classificatierecord: een notitie die de exacte cameravariant, verkoopclaim, beoogde beveiligingsfunctie, meegeleverde digitale elementen en routemotivering benoemt.
Heeft een smart-home beveiligingscamera een aangemelde instantie nodig?
Niet altijd. De praktische test is of de fabrikant volledig kan steunen op de toepasselijke normen, gemeenschappelijke specificaties of dekking door een kwalificerende cyberbeveiligingscertificeringsregeling voor de essentiële cyberbeveiligingseisen van de camera. Ontbreekt die dekking of is die slechts gedeeltelijk, plan dan de derde-partij-route in plaats van interne controle aan te nemen.
Record conformiteitsroute: vermeld de referenties die voor het exacte cameraproduct zijn gehanteerd, de eisen die ze dekken, eventuele hiaten en de geselecteerde route.
Valt een professionele CCTV-camera of NVR automatisch in dezelfde categorie?
Nee. Classificeer professionele bewaking niet op het woord "camera" alleen. Een CCTV-camera, VMS of NVR kan nog steeds een product met digitale elementen zijn en nog steeds CRA-beveiligingswerk vereisen, maar de route hangt af van het beoogde gebruik, de geleverde elementen en de functie waarop de klant steunt.
Grensrecord: een variantnotitie voor professionele bewaking die de camera, recorder, VMS, installateurscloud, pad voor toegang op afstand en eventuele afzonderlijke producten die met het aanbod worden geleverd, dekt.
Wat als de camera gezichtsherkenning, toegangscontrole, firewall- of VPN-functies bevat?
Behandel dat als een classificatiewaarschuwing. Is de camera vooral een smart-home beveiligingscamera, dan kunnen die functies deel zijn van de camera-risicobeoordeling. Is het product vooral een toegangscontrolelezer, biometrisch authenticatieapparaat, VPN-gateway, firewall, IDS/IPS of een ander vermeld cyberbeveiligingsproduct, classificeer dan eerst die kernfunctie en dwing het product niet in de cameracategorie. Dit telt omdat sommige categorieën een strengere route dragen; firewalls en IDS/IPS zijn bijvoorbeeld Klasse II.
Hercheck-trigger: open een afzonderlijke kernfunctiecheck wanneer de camera identiteit, toegang, netwerkfiltering, VPN-toegang of inbraakdetectie aanstuurt in plaats van alleen videobewaking.
Verandert cloud-videoopslag de productgrens?
Cloudopslag verandert de klasse niet automatisch. Is de door de fabrikant geleverde cloudverwerking ontworpen door of onder verantwoordelijkheid van de fabrikant, en zou de camera zonder die verwerking een van zijn functies niet uitvoeren, behandel die verwerking dan als deel van de productgrens, het bewijs en de risicobeoordeling. De productclassificatie volgt nog steeds de kernfunctionaliteit van de camera, tenzij een andere vermelde functie de primaire is.
Grensrecord: een kaart van cloudafhankelijkheden die toont welke clouddiensten met de camera worden geleverd, welke functies zonder ze falen, welke gegevens ze verwerken en welke systemen buiten het aanbod van de fabrikant vallen.
Moeten ONVIF, RTSP of de lokale web-admin na inbedrijfstelling ingeschakeld blijven?
Alleen wanneer de release een gedocumenteerd toegangsmodel voor dat oppervlak heeft. Een consumentencamera kan lokale streaming of administratie blootstellen voor rechtmatig inbedrijfstellings-, installateur- of recordergebruik, maar het releasedossier moet tonen of het oppervlak na inschrijving bereikbaar blijft, welke authenticatie het beschermt, of transportencryptie wordt gebruikt en welke gebruikersinstelling of variantclaim het rechtvaardigt.
Testartefact: dienstscans na inbedrijfstelling en na update, ONVIF/RTSP-authenticatietests, review van discovery-antwoorden en het releasebesluit voor elk lokaal oppervlak.
Wanneer moet de risicobeoordeling worden bijgewerkt?
Werk haar bij telkens wanneer de uitgeleverde camerastatus verandert op een manier die het vertrouwen raakt: een nieuw ONVIF-profiel, modus voor bekijken op afstand, accountherstelflow, cloudrelais, OTA-kanaal, chipset, firmware-basis, wijziging in mobiele app-authenticatie, supportbundleveld of fabrieksresetgedrag. Een releasenotitie volstaat niet wanneer de gewijzigde functie een aanvalspad heropent.
Hercheck-trigger: elke wijziging in functie of leverancier die toegang, updatebevoegdheid, opgeslagen video, accountbinding, supportgegevens of resetgedrag verandert, heropent de grens en de risicobeoordeling.