Sind Sicherheitskameras wichtige Produkte unter dem CRA?
Zusammenfassung
Eine vernetzte Smart-Home-Kamera, die für die physische Sicherheit verkauft wird, sollte als Wichtig Klasse I geplant werden. Die Klasse kann sich ändern, wenn dieselbe Kamera-Hardware für einen anderen Zweck verkauft wird: Videoanrufe, professionelle CCTV-Anlagen, Aufzeichnungsinfrastruktur, Zutrittskontrolle oder ein anderes Sicherheitsprodukt.
Der erste Eintrag, der angelegt werden muss, ist ein Klassifizierungs- und Abgrenzungsmemo für die genaue Kameravariante. Es muss die beabsichtigte Sicherheitsfunktion, den Verkaufskontext, die gelieferten digitalen Elemente, den Supportzeitraum und die Begründung des gewählten Wegs benennen.
Der Eintrag zum Supportzeitraum sollte sich aus der erwarteten Nutzung der Kamera, den angemessenen Erwartungen der Nutzer, der Produktart, dem Verwendungszweck und dem einschlägigen Komponentensupport ableiten. Die CRA-Untergrenze beträgt mindestens fünf Jahre, sofern die voraussichtliche Nutzungsdauer nicht kürzer als fünf Jahre ist; das Enddatum, mindestens Monat und Jahr, muss beim Kauf eindeutig angegeben sein.
Wie klassifizieren Sie eine Kameraversion?
Beginnen Sie mit dem Angebot, nicht mit dem Kameragehäuse. Der Weg hängt von der Verkaufsaussage, der Funktion, auf die der Käufer vertraut, und den mit dieser Version gelieferten digitalen Elementen ab.
Verkauf für Videoanrufe, Besprechungen oder allgemeine Kommunikation.
Kommunikationsperipherie; keine Haushaltsüberwachung zur Sicherheit.
Geräte-Firmware, Treiber oder Integration in eine Meeting-App. Keine gelieferte Überwachungscloud und kein Alarm-Workflow.
Verkauf zur Heimüberwachung, Babyüberwachung, Türklingelsicherheit oder Alarmintegration.
Sicherheit oder Überwachung des Haushalts ist die Funktion, auf die der Käufer vertraut.
Firmware, lokaler Speicher, App, Hersteller-Cloud, Aktualisierungsdienst und Schwachstellen-Handhabung, soweit für diese Funktion geliefert.
Verkauf als professionelle Überwachung, Aufzeichnungsinfrastruktur oder Teil eines anderen Sicherheitsprodukts.
Der Rekorder, das VMS, die Firewall, das VPN, die Zutrittskontrolle, die biometrische oder die Identitätsfunktion kann das eigentliche Produkt sein.
Kamera plus Rekorder, Managementserver, Installateurs-Cloud, Zutrittskontrolldienst oder Sicherheitsappliance.
Nutzen Sie das Diagramm als Wegweiser, nicht als endgültigen Klassifizierungseintrag. Der schriftliche Eintrag braucht weiterhin die genaue Aussage, den Verwendungszweck und die gelieferte Grenze. Bei einer Smart-Home-Kamera ist die Schlüsselformulierung Smart-Home-Produkte mit Sicherheitsfunktionen. Eine Kamera, die zur Heimüberwachung, Einbruchsüberwachung, Babyüberwachung oder Alarmintegration verkauft wird, fällt in diese Kategorie. Eine universell einsetzbare Webcam in der Regel nicht.
Prüfen Sie anschließend, ob eine andere gelistete Funktion die Steuerung übernimmt. Die Einstufung als Wichtig folgt der Kernfunktion des Produkts, nicht den Bestandteilen, die zufällig mitlaufen: Das Einbetten einer sicherheitsrelevanten Komponente zieht den Rest des Angebots nicht in den Weg für Wichtig. Wird die Kamera in Wahrheit als Firewall, VPN-Gateway, Zutrittskontroll-Lesegerät, biometrisches Authentifizierungsgerät, Identitätsmanagementsystem oder Privileged-Access-Management-Produkt verkauft, das zufällig eine Linse enthält, klassifizieren Sie zuerst diese Kernfunktion.
Bei professioneller Überwachung erzwingen Sie nicht die Smart-Home-Kategorie. Eine professionelle CCTV-Kamera, ein VMS oder ein NVR kann weiterhin ein Produkt mit digitalen Elementen unter dem CRA sein und benötigt weiterhin Sicherheitsanforderungen, die Planung des Supportzeitraums, die Schwachstellen-Handhabung und die technische Dokumentation. Die Klasse hängt vom Verwendungszweck, der gelieferten Grenze und der Kernfunktion ab.
Das Klassifizierungsmemo sollte vier Fragen beantworten:
- Wird die Kamera für Haushaltssicherheit, Babyüberwachung, Türklingelsicherheit oder Alarmintegration verkauft?
- Ist die Kamera die Kernfunktion des Produkts oder übernimmt eine Firewall-, VPN-, Zutrittskontroll-, biometrische oder Identitätsfunktion die eigentliche Arbeit?
- Welche digitalen Elemente werden für die beabsichtigte Funktion geliefert: Firmware, lokaler Speicher, App, Hersteller-Cloud, Aktualisierungsdienst und Schwachstellen-Handhabung?
- Welche Systeme liegen außerhalb des Angebots des Herstellers: Kundenrouter, Drittanbieter-Rekorder, Installateursnetz, externer Identitätsanbieter oder Überwachungszentrale?
Produktgrenze und gelieferte Elemente
Bei einem Kamerahersteller fällt die Compliance-Grenze selten mit dem Kunststoffgehäuse zusammen. Sie sollte dem Produkt folgen, das in Verkehr gebracht wird, und den digitalen Elementen, die für die beabsichtigte Sicherheitsfunktion erforderlich sind.
Innerhalb der Grenze des Kameraherstellers standardmäßig: Geräte-Firmware und jeder darauf laufende Dienst, der Netzwerkschnittstellen-Stack, der geräteinterne Speicher, die Companion-App, deren Installation dem Käufer empfohlen wird, jede vom Hersteller gehostete Cloud, die die dokumentierten Funktionen des Produkts liefert, die OTA-Aktualisierungsinfrastruktur und der Prozess zur Schwachstellen-Handhabung dahinter.
Außerhalb dieser Grenze, sofern der Hersteller die Ebene nicht selbst verkauft: der Heimrouter des Käufers, ein Drittanbieter-VMS oder -NVR, das der Kunde gewählt hat, das Standortnetz eines Installateurs, ein externer Identitätsanbieter für SSO und eine professionelle Überwachungszentrale unter einem separaten Vertrag.
Keiner, wenn diese Produkte von anderen Herstellern stammen. Verkauft der Kamerahersteller auch den Rekorder, das VMS, den Identitätsdienst oder die Cloud-Bridge als Teil seines Angebots, kann jedes davon ein eigenes CRA-Produkt mit eigener Produktakte sein.
Produktakte · EU-Konformitätserklärung · CE-Kennzeichnung · Erklärung zum Supportzeitraum · Bedienungsanleitung · Konformitätsbewertungsprotokoll
Vom Kamerahersteller zehn Jahre nach dem Inverkehrbringen der Kamera aufzubewahren oder für den Supportzeitraum, je nachdem, welcher Zeitraum länger ist. Wird ein Bewertungsweg durch Dritte genutzt, halten Sie dessen Ergebnis in derselben Akte vor.
Cybersicherheits-Risikoakte · Komponenteninventar · Prozess zur Schwachstellen-Handhabung · Offenlegungsrichtlinie · Sicherer Aktualisierungsmechanismus
Nehmen Sie den veröffentlichten einzigen Kontaktpunkt, den Testnachweis für sichere Standardeinstellungen, die Prüfung signierter Aktualisierungen und die Begründung des Supportzeitraums auf.
Sorgfaltsprotokoll Komponente · Konformitätserklärung des Lieferanten · Sicherheitshinweise des Herstellers
Der Kamerahersteller bleibt für die Chipauswahl verantwortlich. Wenn ein Chip, ein Modul oder ein Sicherheitselement selbst ein CRA-Produkt ist, unterstützen die Konformitätserklärung und die Sicherheitshinweise des Lieferanten die Sorgfaltspflicht des Herstellers, ersetzen sie aber nicht.
Das Komponenteninventar wird auf neue Schwachstellen überwacht; der Schwachstellenprozess klassifiziert Funde; kostenlose Sicherheitsupdates verteilen Korrekturen mit Hinweisen, automatisiert, wo machbar.
Eine aktiv ausgenutzte Kamera-Schwachstelle startet eine Uhr: Eine Frühwarnung ist innerhalb von 24 Stunden fällig, die Schwachstellenmeldung innerhalb von 72 Stunden und der abschließende Schwachstellenbericht innerhalb von 14 Tagen, nachdem eine Korrektur- oder Minderungsmaßnahme verfügbar ist. Ein schwerwiegender Sicherheitsvorfall läuft auf einer separaten Uhr mit denselben Schritten nach 24 Stunden und 72 Stunden, plus einem Abschlussbericht zum Vorfall innerhalb eines Monats nach der Vorfallsmeldung.
Haushalte, die die betroffenen Kameras betreiben, hören ebenfalls vom Hersteller. Der Hersteller informiert die betroffenen Besitzer und, wenn die Exposition es verdient, auch den weiteren Kundenkreis darüber, was schiefläuft und welche Schritte sie selbst anwenden können: erzwungenes Firmware-Update, App-Upgrade, Passwort-Reset, optionale Abschaltung eines Dienstes oder Werksreset vor dem Wiederverkauf.
Architektur-Prüfpunkte der Kamera
Die Akte zur Kameraversion sollte dem tatsächlichen Videoprodukt folgen, nicht einer generischen IoT-Checkliste. Eine Batterie-WLAN-Kamera, eine PoE-Dome-Kamera, eine Mobilfunk-Außenkamera und eine Kamera, die mit einem NVR verkauft wird, können sich eine Klassendiskussion teilen, brauchen aber unterschiedliche Ingenieurnachweise.
Lesen Sie das Diagramm als Karte der Versionsakte, nicht als vorgeschriebenes Einsatzmuster. Der Hersteller muss weiterhin die genaue Variantengrenze für seine eigene Kamera, App, Cloud-Dienst, Aktualisierungsweg und Supportmodell schreiben.
- Video- und Steuerpfad. Identifizieren Sie jeden Pfad, der Video ansehen, speichern, exportieren oder steuern kann: lokaler Stream, Web-UI, App-Sitzung, Cloud-Relay, Sharing-Link, Support-Export und Kompatibilitätsaussage zu NVR oder VMS.
- Lokale Exposition. Scannen Sie die Kamera nach der Einrichtung und nach einer Aktualisierung. Zeigen Sie, welche Dienste erreichbar sind, welche eine Authentifizierung verlangen und welche Stream- oder Admin-Pfade deaktiviert bleiben.
- Kundensysteme. Behandeln Sie Router, Installateursnetz, Drittanbieter-Rekorder, externen Identitätsanbieter und Überwachungszentrale als außerhalb des Produkts des Kameraherstellers, sofern der Hersteller diese Ebene nicht als Teil des Angebots liefert.
- Vom Hersteller gelieferte Backends. Schließen Sie Kontodienst, Signaturpipeline, Ereignis- oder Benachrichtigungsdienst, Support-Portal, Dienst für kostenpflichtige Feature-Flags und jeden Cloud-ML-Pfad ein oder aus.
- Aktualisierungsautorität. Behandeln Sie die Aktualisierungsautorität als beidseitigen Austausch: Die Kamera prüft oder empfängt Update-Metadaten, und der Aktualisierungsdienst liefert ein signiertes Firmware- oder App-Paket für genau diese Variante zurück. Halten Sie Nachweise zu signierten Updates, Recovery-Slot, Ablehnung von Downgrades und Benutzerbenachrichtigung mit der Version vor.
- Lieferanten-Inputs. Geben Sie SoC, WLAN-Modul, Media-Stack, KI-Modell, P2P-SDK und Bootloader einen Verantwortlichen, eine Version, eine Hinweisüberwachung und eine Versionsentscheidung.
- Post-Market-Schleife. Schwachstellenmeldungen, schwerwiegende Vorfälle, Lieferantenhinweise und Feldfehler sollten das Bedrohungsmodell, den Eintrag zum Restrisiko, die technische Akte und das nächste Versionsgate aktualisieren.
Beispielhafte Risikobewertung einer Kamera
Lesen Sie den Rest dieses Abschnitts als ein durchgearbeitetes Kamerabeispiel und nicht als Checkliste zum Abhaken. Die Absicht ist, die Tiefe der Entscheidung zu zeigen, die ein Kamerahersteller für eine konkrete Variante verteidigen können sollte: die Chipsatz- und Modulwahl, den Firmware-Build, das Cloud-Relay, den OTA-Kanal, die Lieferantenhinweise, die Sie tatsächlich beobachten, den Vertriebskanal, für den Sie sich entschieden haben, und das Supportfenster, das Sie zugesagt haben.
Welches Produkt bewerten wir?
Veranschaulichendes Beispielprodukt, kein reales Gerät: ExampleCo IndoorCam X1, eine Smart-Home-Innenkamera, die in der EU für die Haushaltssicherheit verkauft wird. Sie zeichnet 1080p-Video und -Audio auf, speichert Clips auf einer microSD-Karte, streamt Live-Video über eine Mobile-App an den Besitzer, stellt während der Einrichtung eine lokale Web-Admin-Oberfläche bereit, nutzt BLE für das erstmalige Onboarding, verbindet sich per WLAN und empfängt signierte Firmware-Updates vom Hersteller.
Die Produktgrenze für dieses Beispiel umfasst die Kamera-Hardware, die eingebettete Firmware, die microSD-Aufzeichnung, den Pairing-Ablauf der Mobile-App, das Cloud-Relay des Herstellers, den Kontodienst, den OTA-Aktualisierungsdienst, den Prozess für Sicherheitshinweise und den Kontakt für Schwachstellenmeldungen. Sie umfasst nicht den Router des Kunden, ein Drittanbieter-VMS/NVR, eine Heimautomatisierungsplattform oder eine professionelle Überwachungszentrale.
Das Produkt ist für nicht-technische Haushaltsnutzer in einer Innenwohnumgebung bestimmt. Es ist nicht für industrielle CCTV-Anlagen, die Überwachung öffentlicher Räume, die Zutrittskontrolle, die biometrische Authentifizierung oder Identitätsprüfung, die Arbeitsplatzüberwachung oder Sicherheitsoperationen für kritische Infrastrukturen bestimmt.
Bevor Sie die Bedrohungstabelle schreiben, prüfen Sie die drei Kamerapfade, die die Risikobewertung meist bestimmen: Video-Verwahrung, Geräteidentität und Exposition nach der Einrichtung. Diese Diagramme verwandeln das durchgearbeitete Beispiel in Ingenieurfragen statt in eine generische Bedrohungsliste.
Details zur Video-Verwahrung: Die Quelle ist der Kamerasensor, das Mikrofon und der Encoder, mit Bildabstimmungs-Blobs, Audiopfad, Privatsphärenmaske, KI-Erkennungs-Inputs und Stream-Profilen, die an einen Firmware-Build gebunden sind. Der lokale Ansichtspfad umfasst ONVIF, RTSP, Web-Vorschau oder Browser und wird durch einen Authentifizierungs- und Expositionsscan verifiziert. Der Remote-Ansichtspfad umfasst Cloud-Relay, P2P-SDK oder Besitzer-App und wird durch einen Test zum Token-Geltungsbereich und Relay-Test verifiziert. Der lokale Medienpfad umfasst microSD-Clips und Wechselspeicher und wird durch Reset- und Kartenentnahme-Tests verifiziert. Der Support-Pfad umfasst Support-Bundle und Diagnose-Export und wird durch eine Schwärzungs-Checkliste verifiziert.
Reset-, Unbind- und RMA-Wipe-Tests belegen, welche Videos, Token und Kontoverknüpfungen vor Wiederverkauf, Aufarbeitung oder Support-Übergabe entfernt werden.
Eigentum ist eine separate Prüfung neben der Video-Verwahrung. Eine Kamera kann einen geschützten Stream haben und dennoch versagen, wenn ein alter Besitzer, ein geteilter Nutzer oder ein wiederhergestelltes Telefon nach der Übertragung weiterhin Zugriff behält.
Details zum Identitäts-Lebenszyklus: Die Provisionierung erstellt den Kameraschlüssel oder das Zertifikat, erfasst die Hardware-Identität und sperrt den Produktions-Debug-Zugang. Die Besitzereinrichtung nutzt ein verifiziertes Konto plus ein einmaliges, kurzlebiges QR-, BLE- oder App-Claim-Token und schließt das Erstnutzungsfenster, nachdem die Kamera gebunden ist. Der Normalbetrieb verwendet dasselbe Widerrufsmodell für Passwort-Reset, Kontowiederherstellung, Wiederherstellung verlorener Telefone, Familien-Sharing, Gast-Zuschauer und Browser-Sitzungen. Eine Besitzerübertragung erfordert einen autorisierten Unbind-Pfad, entfernt das alte Konto, widerruft geteilte Nutzer und beendet aktive Sitzungen, bevor die Kamera erneut beansprucht werden kann. Werksreset, RMA und Aufarbeitung entfernen Kontoverknüpfung, Zugangsdaten, Clips und Diagnose gemäß dem Produktdesign; die RMA-Handhabung darf nicht zum Pfad für Diebstahls-Wäsche werden.
Missbrauchstests: Ein Setup-Token läuft ab, ist einmal nutzbar und kann von einem nahegelegenen Angreifer nach der Besitzeranforderung nicht erneut verwendet werden; ein altes Telefon, ein Gastnutzer oder eine Browser-Sitzung kann nach der Wiederherstellung keinen Live- oder Aufzeichnungszugriff behalten; und ein lokaler Reset hinterlässt keine Cloud-Bindung, keine Konto-Token und keine Clips.
Nachdem das Eigentum getestet wurde, prüfen Sie, was vom Netzwerk, der App, Wechselmedien und Support-Workflows aus weiterhin erreichbar ist. Damit bleibt die Überprüfung der Exposition an das tatsächlich gelieferte Verhalten gebunden statt an ein generisches Port-Scan-Ergebnis.
Details zu Zugriffsflächen: Lokale LAN-Dienste umfassen RTSP, ONVIF, Web-UI und Discovery-Endpunkte, und der Versionseintrag ist der Expositionsscan. Die Remote-Ansicht umfasst Cloud-Relay, Sharing und Geräteidentität, und der Versionseintrag ist der Test zum Geltungsbereich des Cloud-Tokens. Wechselmedien umfassen microSD-Clips, Reset-Verhalten und Speicherentscheidungen, und der Versionseintrag ist das microSD-Reset-Ergebnis. Die Support-Diagnose umfasst Logs, Crash-Dumps und Support-Modus, und der Versionseintrag ist die Stichprobe des Support-Modus-Audits.
Welche Assets schützen wir?
Kameras schützen sehr unterschiedliche Dinge im selben Gehäuse. Ein aufgezeichneter Clip aus dem Kinderzimmer, ein Besitzerkonto, das die Linse schwenken kann, und ein Firmware-Signaturschlüssel, der jedes in diesem Jahr ausgelieferte Gerät steuert, leben alle hinter einem Produkt. Listen Sie sie zuerst als separate Assets auf, denn der Kontrollsatz, der Testnachweis und der Versionseintrag unterscheiden sich stark.
| Asset | Warum es zählt | Wo es lebt |
|---|---|---|
| Live- und aufgezeichnetes Video/Audio | Legt private Räume, Routinen, Besucher, Kinder, Haustiere und Gespräche offen | Sensor, RAM, Encoder, microSD, Stream-Puffer, Cloud-Relay |
| Besitzerkonto und Wiederherstellungsfaktor | Eine Übernahme kann Remote-Ansicht, Geräte-Reset und Sharing-Änderungen ermöglichen | Mobile-App, Identitätsdienst, E-Mail-/SMS-Wiederherstellungspfad |
| Zugangsdaten Gerät-zu-Cloud | Persistentes Vertrauens-Token; in einer ausgelieferten Flotte schwer zu rotieren | Sicherheitselement oder geschützter Speicher, Kontobindungsdienst |
| Vertrauensanker für die Firmware-Signatur | Wenn gebrochen, kann der Aktualisierungskanal zum Malware-Kanal werden | Boot-Chain, Keystore, Signaturdienst, Versions-Pipeline |
| Position im lokalen Netzwerk | Die Kamera sitzt im LAN des Haushalts und sieht lokale Peers | WLAN-Schnittstelle, DHCP-Lease, mDNS-/SSDP-Sicht |
| Diagnose- und Support-Bundle | Kann Seriennummern, Konto-IDs, Netzwerknamen und Crash-Spuren preisgeben | Geräte-Logs, Support-Portal, interne Support-Werkzeuge |
| Benutzeranleitung und Support-Datum | Bestimmt sichere Einrichtung, Aktualisierungserwartungen und Umgang mit Support-Ende | Verpackung, Web-Handbuch, App-UI, Produktanzeige |
Wo liegen die wichtigsten Vertrauensgrenzen?
Eine Kamera sitzt an fünf Orten gleichzeitig: im Gerät selbst, auf der microSD-Karte, die jeder im Raum entfernen kann, im Heimnetz, das sie mit Telefonen und unbekannten IoT-Peers teilt, im Hersteller-Backend, das jede Kamera im Feld berührt, und auf dem Besitzer-Telefon oder -Browser, der die Live-Sitzung hält. Jeder Ort verändert die Angreifergelegenheit und verlangt eine andere Kontrollfläche, daher listet das Vertrauensgrenzen-Modell sie getrennt auf, auch wenn sie verbunden sind.
| Umgebung | Erwarteter Schutz | Warum sich die Wahrscheinlichkeit ändert |
|---|---|---|
| Im Inneren der Kamera | Physischer Zugriff ist begrenzt, aber Reparatur, Diebstahl, Wiederverkauf und Debug-Pads existieren | Geringere Remote-Wahrscheinlichkeit, höhere Folge bei extrahierbaren Schlüsseln |
| microSD/lokale Medien | Wer Zutritt zum Raum hat, kann die Karte entfernen oder kopieren | Lokaler Zugriff ist in Haushalten mit Gästen, Reinigungskräften, Mietern oder beim Wiederverkauf plausibel |
| Heimnetz | Geteilt mit Laptops, Telefonen, Fernsehern, Druckern und unbekannten IoT-Geräten | Ein kompromittierter Peer kann lokalen Admin, Discovery oder Stream-Dienste angreifen |
| Hersteller-Backend | Internet-zugewandt und über die installierte Flotte hinweg geteilt | Ein Backend-Fehler skaliert von einem Haushalt auf viele |
| Besitzer-Endgerät | Telefone und Browser sind Phishing, Malware und Konten-Wiederverwendung ausgesetzt | Konto-Kompromittierung umgeht oft die Geräte-Härtung |
Welche Bedrohungen sollten zuerst bewertet werden?
Dieses Beispiel beginnt mit sechzehn produktspezifischen Bedrohungen. Das Ziel ist nicht Vollständigkeit; es ist, das Maß an Nachvollziehbarkeit zu zeigen, das ein Hersteller verteidigen können sollte.
| ID | Bedrohungsszenario | Gefährdetes Asset | Einstiegspunkt |
|---|---|---|---|
| T1 | Ein geteiltes oder vorhersehbares Erstnutzungsgeheimnis lässt einen Angreifer die Kamera beanspruchen, bevor der Besitzer die Einrichtung abschließt | Besitzerkonto, Videostream | BLE-Onboarding / lokale Einrichtung |
| T2 | Die lokale Web-Admin-Oberfläche akzeptiert schwache Zugangsdaten oder bleibt nach der Einrichtung offen | Konfiguration, Stream-Zugriff | Heimnetz |
| T3 | Ein gestohlenes Mobile-App-Token bleibt nach einem Passwort-Reset gültig und öffnet weiterhin den Kamera-Feed | Besitzerkonto, Live-Video/Audio | Besitzer-Endgerät / Cloud-Relay |
| T4 | P2P-Fallback, STUN/TURN/ICE-Handhabung, UPnP oder Hole Punching legt die Kamera direkt offen, wenn der Relay-Pfad versagt oder blockiert ist | Firmware-Dienste, Stream-Zugriff | Internet-naher Relay-Pfad |
| T5 | ONVIF/RTSP antwortet im LAN mit schwacher Authentifizierung oder auffindbaren Stream-URLs | Live-Video/Audio | Heimnetz |
| T6 | Der Recovery-Slot akzeptiert ein unsigniertes, altes oder downgegradetes Firmware-Image | Firmware-Integrität, Vertrauensanker der Signatur | OTA-/Recovery-Pfad |
| T7 | UART-/JTAG-Pads erlauben Boot-Zeit-Zugriff bei Diebstahl, Reparatur oder Wiederverkauf | Geräte-Geheimnisse, Firmware, Logs | Physischer Debug-Zugang |
| T8 | microSD-Clips sind nach Kartenentnahme oder nach dem Wiederverkauf der Kamera lesbar | Aufgezeichnetes Video/Audio | Lokale Medien |
| T9 | BLE-Onboarding legt die WLAN-Zugangsdaten oder das Gerätepaarungsgeheimnis einem nahegelegenen Angreifer offen | WLAN-Zugangsdaten, Besitzerkonto | BLE-Setup-Fenster |
| T10 | Support-Bundles enthalten Seriennummer, Konto, SSID, Token-Fragmente oder private Crash-Spuren | Diagnosedaten, Konto-Verknüpfbarkeit | Support-Upload |
| T11 | Eine Lieferantenschwachstelle im WLAN-Modul oder im Media-Stack wird während des Supportzeitraums nicht erkannt | Firmware, Verfügbarkeit, Stream-Vertraulichkeit | Lücke beim Lieferantenhinweis |
| T12 | RMA- oder Wiederverkaufs-Reset versagt beim Löschen von Kontobindung, Clips oder Geräte-Zugangsdaten | Besitzerkonto, aufgezeichnete Medien, Zugangsdaten Gerät-zu-Cloud | Rücksendepfad |
| T13 | Discovery-Dienste geben Modell, Firmware, Seriennummer oder Stream-Metadaten an jedes Gerät im LAN preis | Geräte-Fingerabdruck, Stream-Exposition | ONVIF / WS-Discovery / mDNS |
| T14 | Der RTSP-Streamer ist anders geschützt als die Web-UI, sodass ein Live-Stream nach der Admin-Härtung erreichbar bleibt | Live-Video/Audio | Lokaler Stream-Dienst |
| T15 | Ein Fehler in einem P2P- oder Media-SDK eines Dritten erlaubt Geräte-UID-Vorhersage oder -Aufzählung, Geräte-Imitation oder Kompromittierung der Stream-Sitzung | Live-Video/Audio, Geräte-Zugangsdaten | Cloud-Relay / SDK |
| T16 | Die Kamera-Firmware verwendet einen Lieferanten-ISP-, WLAN- oder KI-Blob, der nicht im SBOM-Überwachungsprozess steht | Firmware-Integrität, Schwachstellen-Handhabung | Lieferanten-Firmware |
Wie sollten die initialen Risiken eingestuft werden?
Verwenden Sie vor der Auswahl von Kontrollen eine einfache interne Rubrik. In diesem Beispiel basiert die Wahrscheinlichkeit auf Exposition und Angreifergelegenheit; die Folge basiert auf Datenschutzschaden, Flottenumfang, Persistenz und ob die Bedrohung einen Sicherheitsmechanismus kompromittiert. Die genauen Bezeichnungen zählen weniger als die Begründung, die neben jeder Entscheidung steht.
Verwenden Sie eine Stufenleiter für das Versionsgate, damit nicht jedes Kamerarisiko dieselbe Entscheidung erhält:
| Gate-Entscheidung | Bedeutung für diese Kameraversion |
|---|---|
| Version blockieren | Die Kamera wird nicht ausgeliefert, bis der fehlgeschlagene Test besteht: Pairing, Stream-Authentifizierung, Verifizierung signierter Updates, RMA-Wipe oder Expositionsscan der Dienste nach der Einrichtung, je nach Bedrohung. |
| Blockieren, sofern nicht dokumentiert | Die Version darf nur fortgesetzt werden, wenn eine kompensierende Kontrolle, eine variantenspezifische Einschränkung oder eine Begründung im Installateurmodus geschrieben, geprüft und an die Kameraversionsakte geheftet wird. |
| Mit Überwachung ausliefern | Die Kamera wird ausgeliefert, aber die Versionsakte benennt das aktive Überwachungssignal (Lieferanten-CVE-Feed, P2P-SDK-Hinweise, Missbrauchstelemetrie) und den Ingenieur, der es während des Supportzeitraums verantwortet. |
| An Anleitung übertragen | Die Exposition hängt vom Heimnetz, dem Besitzer-Telefon oder einem Drittanbieter-Rekorder außerhalb des Angebots des Kameraherstellers ab, daher hält die Akte Installateurs- oder Benutzerleitfäden vor, statt zu versuchen, die Kundenseite zu kontrollieren. |
| Akzeptieren | Einige Kameraflächen (dokumentierte Discovery-Antworten, LAN-Metadaten) tragen ein inhärentes Restrisiko, daher hält die Akte den Nachweis zur Minimierung und die Begründung für die Akzeptanz des Verbleibenden fest. |
| ID | Wahrscheinlichkeit | Folge | Gate-Entscheidung | Warum |
|---|---|---|---|---|
| T1 | Mittel | Hoch | Version blockieren | Erstnutzungs-Übernahme ist realistisch und untergräbt das Eigentum |
| T2 | Hoch | Mittel | Version blockieren | Heim-LANs enthalten nicht vertrauenswürdige Peers und wiederverwendete Passwörter |
| T3 | Mittel | Hoch | Version blockieren | Konto-Token-Diebstahl gibt Remote-Ansicht, ohne die Kamera anzufassen |
| T4 | Niedrig | Hoch | Blockieren, sofern nicht dokumentiert | Seltener Pfad, aber direkte Exposition kann skalieren; ein ausgeliefertes Produkt braucht eine dokumentierte Relay- und NAT-Traversal-Entscheidung |
| T5 | Mittel | Hoch | Version blockieren | Lokale Stream-Exposition ist ein direktes Datenschutzversagen |
| T6 | Niedrig | Hoch | Version blockieren | Aktualisierungskompromittierung ist persistent und flottenweit |
| T7 | Mittel | Mittel | Blockieren, sofern nicht dokumentiert | Physischer Debug ist bei Diebstahl, Reparatur oder Wiederverkauf plausibel; die Version benötigt eine Debug-Sperre oder eine Service-Begründung |
| T8 | Hoch | Mittel | Blockieren, sofern nicht dokumentiert | Lokale Kartenentnahme ist häufig; entweder Clips schützen oder die Wechselspeicher-Einschränkung klar dokumentieren |
| T9 | Mittel | Hoch | Version blockieren | Onboarding ist kurzlebig, legt aber die Heimnetz-Zugangsdaten offen |
| T10 | Mittel | Mittel | Blockieren, sofern nicht dokumentiert | Lecks bei Support-Daten sind schwer zu bemerken; Support-Export muss minimiert, geschwärzt oder explizit deaktiviert werden |
| T11 | Mittel | Hoch | Mit Überwachung ausliefern | Lieferanten-CVEs sind im Supportzeitraum zu erwarten; die Version braucht einen Verantwortlichen und eine Hinweisüberwachung |
| T12 | Mittel | Hoch | Version blockieren | Rücksende- und Wiederverkaufspfade sind bei Verbraucher-Geräten absehbar |
| T13 | Mittel | Mittel | Akzeptieren | Einige LAN-Metadaten sind dokumentierten Discovery-Protokollen inhärent; das Restrisiko wird nur mit Expositionsminimierung und Benutzeranleitung für optionale Discovery akzeptiert, wo unterstützt |
| T14 | Mittel | Hoch | Version blockieren | Die Stream-Authentifizierung darf nicht schwächer sein als das dokumentierte Zugriffsmodell |
| T15 | Niedrig | Hoch | Mit Überwachung ausliefern | SDK- oder Relay-Schwächen können viele Geräte betreffen, daher braucht die Version Versions-Eigentum und Missbrauchsüberwachung |
| T16 | Mittel | Hoch | Blockieren, sofern nicht dokumentiert | Geschlossene oder vom Lieferanten gepflegte Blobs brauchen einen Versionsverantwortlichen, einen Hinweiskanal und einen Aktualisierungsweg oder eine schriftliche Entscheidung zum Restrisiko |
Welche Designkontrollen verändern das Risikobild?
Binden Sie jede Kontrollzeile an einen konkreten Kameratest, nicht an eine generische Secure-Development-Checkliste. Die Versionsakte sollte von einer Bedrohungs-ID auf den genauen Pairing-Test, den Scan zur Stream-Authentifizierung, das Verifikationsprotokoll signierter Updates, das Dienstinventar nach der Einrichtung oder das RMA-Wipe-Protokoll zeigen können, das belegt, dass die Kontrolle auf dem ausgelieferten Kamera-Build läuft.
| Bedrohungen | Designkontrolle | Nachweis, den der Hersteller vorhalten sollte |
|---|---|---|
| T1, T2 | Geräteindividuelles Setup-Geheimnis, erzwungene Besitzeranmeldung, kein geteiltes Standard-Passwort, Setup-Schnittstelle schließt nach Anmeldung | Setup-Testprotokoll, Zugangsdaten-Richtlinie, Negativtest für nicht authentifizierten Admin-Zugriff |
| T3 | Kurzlebige App-Token, gerätegebundene Sitzungen, serverseitiger Widerruf bei Passwort-Reset, Überwachung von Anmelde-Anomalien | Token-Lebensdauer-Richtlinie, Widerrufstests, Missbrauchstests zur Kontowiederherstellung |
| T4, T5 | UPnP standardmäßig deaktivieren, authentifiziertes Relay, authentifiziertes ONVIF/RTSP, Dienstinventar nach Einrichtung | Netzwerk-Expositionsscan, Stream-Authentifizierungstests, Überprüfung der Relay-Konfiguration |
| T6 | Secure Boot, signiertes OTA, monotoner Versionszähler, Signaturprüfung des Recovery-Slots, Rollback-Richtlinie | Boot-Chain-Nachweis, Update-Verifikationstests, Tests zur Ablehnung von Downgrades |
| T7 | Produktions-Fuses für Debug, versiegelte oder dokumentierte Debug-Pads, keine Geheimnisse in lesbarer UART-Ausgabe | Hardware-Produktions-Checkliste, Verifikation der Debug-Sperre, Risikohinweis zur Demontage |
| T8 | Verschlüsselte microSD-Aufzeichnung, wo die Kameravariante dies unterstützt (Eufy, TP-Link Tapo auf unterstützten Modellen); sicheres Löschen beim Werksreset; klare Benutzerwarnung im Handbuch und in der App für Varianten, die unverschlüsselt aufzeichnen | Speicher-Designnotiz, Reset-Test, Screenshot der Bedienungsanleitung, In-App-Warnaufnahme |
| T9 | Authentifiziertes BLE-Pairing, kurzes Pairing-Fenster, WLAN-Geheimnis niemals im Klartext übertragen, Pairing-Ratenlimits | Überprüfung des Pairing-Protokolls, RF-Test, Fehlermodus-Test |
| T10 | Minimierung des Support-Bundles, Token-Schwärzung, Nutzereinwilligung vor Upload, Aufbewahrungslimit | Support-Schema, Schwärzungstests, Support-Workflow-Nachweis |
| T11 | SBOM-Überwachung, Lieferantenhinweisüberwachung, Klassifizierung betroffener Komponenten, Veröffentlichungsprozess signierter Updates | SBOM-Diff-Protokoll, Lieferantenhinweis-Eintrag, Klassifizierungsentscheidungen |
| T12 | RMA-Wipe-Workflow, Cloud-Unbind, Rotation der Zugangsdaten beim Reset, Checkliste für aufgearbeitete Geräte | Checkliste der Rücksendelinie, Reset-Nachweis, Cloud-Unbind-Audit |
| T13, T14 | Dienstinventar nach Einrichtung, authentifizierte Stream-URLs, Minimierung der Discovery-Antworten, Profil-/Versions-Testnachweis | Expositionsscans, ONVIF-/RTSP-Authentifizierungstests, Audit der Discovery-Antworten |
| T15 | P2P-SDK-Inventar, Geltungsbereich der Sitzungs-Token, Geräte-UID-Entropie, SDK-Hinweisüberwachung, Imitations- und Missbrauchstests | SDK-Versionsprotokoll, UID-Aufzählungstest, Geräte-Imitationstest |
| T16 | Lieferanten-Firmware-Inventar für ISP-, WLAN-, Encoder- und KI-Komponenten; Komponentenverantwortlicher und Aktualisierungsweg | Lieferanten-Stückliste, Hinweisüberwachungsprotokoll, Versionsentscheidungsprotokoll |
Welches Restrisiko bleibt nach Kontrollen?
Kontrollen schließen die Akte nicht. Nach der Auslieferung der Kamera betreibt der Hersteller weiterhin die aktiv verwalteten Risiken: den Firmware-Aktualisierungskanal, die Pfade zur Übernahme des Besitzerkontos und den langen Schwanz von Lieferanten-CVEs im WLAN-Stack, in Medienbibliotheken und P2P-SDKs, die im Lauf des Supportzeitraums auftauchen. Der Resteintrag ist nur glaubwürdig, wenn der Hersteller auf die laufende Überwachung dieser Signale, Klassifizierungsentscheidungen für neue Hinweise, signierte Updates, die die installierten Kameras tatsächlich erreichten, Besitzerhinweise, die ausgingen, und eine erfasste Korrekturmaßnahme hinter jedem Eintrag zeigen kann.
| Restbereich | Warum es bleibt | Operativer Nachweis |
|---|---|---|
| Kompromittiertes Besitzer-Endgerät | Der Hersteller kann das Telefon, den Browser, die E-Mail oder die Passwort-Hygiene des Nutzers nicht vollständig kontrollieren | MFA-Unterstützung, Token-Widerruf, Warnung bei verdächtigen Anmeldungen, Benutzeranleitung |
| Nach der Auslieferung entdeckte Lieferantenschwachstelle | Medienbibliotheken, WLAN-Firmware, Kernel und TLS-Bibliotheken werden weiterhin CVEs erhalten | SBOM-Überwachung, Annahme von Lieferantenhinweisen, Auswirkungsanalyse, Patch-Eintrag |
| Lokaler physischer Zugang | Eine Kamera in einem Haushalt kann gestohlen, weiterverkauft, repariert oder von Gästen erreicht werden | Reset-Workflow, Debug-Sperr-Nachweis, Speicherwarnung, RMA-Wipe-Protokoll |
| Drift der Netzwerkexposition | Firmware-Updates, Relay-Änderungen oder Feature-Flags können Dienste wieder öffnen | Versionsweise Expositionsscans, Dienstinventar, Änderungsgenehmigung |
Das Versionsgate ist das Risikoregister selbst. Fügen Sie keine separate „Sicherheit geprüft"-Karte hinzu, die dieselbe Arbeit wiederholt. Bei der Freigabe sollte der Versionsverantwortliche von den blockierten oder bedingten Bedrohungen auf den abschließenden Nachweis zeigen können: Pairing- und Stream-Tests für T1/T2/T5/T14, Token-Widerruf für T3, Tests signierter Updates für T6, Speicher-/Reset-Nachweise für T8, RMA-Wipe-Nachweise für T12 und Lieferantenüberwachung für T11/T16.
Verantwortung in der Kameraentwicklung vom Konzept bis zum Support
Die Hauptverantwortung verschiebt sich, während die Kamera von der Produktdefinition zum Live-Support wandert. Nutzen Sie diese Übergabe, um an jeder Stelle einen Hauptverantwortlichen, einen geführten Eintrag und ein Prüfgate zuzuweisen, während sich das Produkt verändert.
Verantwortungs-Details: Produkt und Sicherheit besitzen das Variantengrenzen-Memo im Konzept. Produktsicherheit mit Firmware und Cloud besitzen die Vertrauensgrenzen-Karte, das Bedrohungsregister und die Gate-Leiter in der Architektur. Firmware-, Cloud-, App- und Lieferantenverantwortliche pflegen Regeln für signierte Updates, Token- und Sitzungskontrollen, Komponentenmanifest, Lieferantenhinweis-Feeds und Feature-Flag-Entscheidungen während der Implementierung. QA mit Produktsicherheit pflegt Expositionsscans, Stream-Authentifizierungstests, Video-Verwahrungs-Tests, Reset- oder RMA-Wipe-Übungen und Restrisiko-Entscheidungen während der Verifizierung. Compliance und der Versionsverantwortliche pflegen das Versionspaket, den technischen Akten-Index, die Anweisungen, die Erklärung zum Supportzeitraum, die signierte Erklärung, das Importeurpaket und die Bereitschaft zur Meldung. PSIRT, Support und Engineering pflegen Aufnahme, Klassifizierung von Lieferantenhinweisen, Benutzerhinweise, signierte Korrekturen, Endpunkt-Stilllegung, Regressionstests und Korrekturmaßnahmen nach der Version.
Übergabe-Details: Frieren Sie die Grenze vor der Architekturarbeit ein, frieren Sie die Designabsicht vor der Implementierung ein, frieren Sie den Kandidaten vor der Verifizierung ein, frieren Sie die Entscheidung vor der Version ein und halten Sie die Version während des Supportzeitraums in Betrieb. Eingehende Meldungen, Lieferantenhinweise, Vorfallsergebnisse und Regressionsergebnisse öffnen das nächste Grenzmemo, das Bedrohungsregister und das Komponentenmanifest erneut.
Nachweis-Karte für Hersteller
Ein Prüfer oder Auditor einer notifizierten Stelle geht eine technische Akte einer Kamera so durch, wie ein Installateur den Karton durchgeht: vom beschrifteten Produkt über die gelieferten digitalen Elemente bis zum Supportnachweis, der dem Käufer versprochen wird. Die Zeilen unten nennen die Einträge, die Kamerahersteller für diesen Rundgang aktuell halten; jede Zeile sollte ein gepflegter Eintrag im Produktordner sein, kein vor der Freigabe gezogener Screenshot.
| Nachweisbereich | Was für eine Sicherheitskamera zu erfassen ist |
|---|---|
| Produktidentität | Modell, Firmware-Versionen, Companion-App, Cloud-Dienst, Hardware-Revisionen |
| Verwendungszweck | Ob das Produkt für Haussicherheit, Babyüberwachung, Türklingelsicherheit oder professionelle Überwachung verkauft wird |
| Risikobewertung | Kamera-Zugriff, Video-Vertraulichkeit, Einrichtung der Zugangsdaten, lokale Netzwerkexposition, Cloud-API-Exposition |
| SBOM und Hardware-Komponentennachweise | Firmware-Pakete, eingebettete Linux-/RTOS-Komponenten, Bildverarbeitungsbibliotheken, WLAN-/Ethernet-Modul-Firmware, SoC und Sicherheitselement, falls vorhanden |
| Sichere Standardeinstellungen | Kein geteiltes Standard-Passwort, sichere Ersteinrichtung, authentifizierter Admin-Zugriff, geschützter Fernzugriff |
| Aktualisierungsmechanismus | Signierte Firmware-Updates, Rollback-Strategie, Update-Verfügbarkeit über den Supportzeitraum |
| Schwachstellen-Handhabung | CVD-Richtlinie, Meldekontakt, Klassifizierungsablauf, Sicherheitshinweis-Prozess |
| Benutzeranweisungen | Sichere Installation, Konto-Einrichtung, Update-Einstellungen, Offenlegung des Support-Endes |
| Rückverfolgbarkeit und Kontakt | Kameramodell- und Serien-Schema, Chargenkennung, Verpackungsmarkierungen, EU-Hersteller- oder Importeur-Kontakt, Enddatum des Supportzeitraums an einer Stelle gedruckt, an der der Käufer es vor dem Kauf lesen kann, und eine veröffentlichte Schwachstellenmelde-Adresse, die von einem menschlichen Sicherheitsteam beantwortet wird |
Konformitätsbewertungsweg
Wählen Sie den Konformitätsweg, nachdem die Kameragrenze, die Risikobewertung, die Kontrollen und die Restrisiken klar sind. Sonst kann die Wegentscheidung dem Ingenieurnachweis voreilen.
Wichtig Klasse I erfordert nicht in jedem Fall automatisch eine notifizierte Stelle. Der Weg über interne Kontrolle ist nur verfügbar, wenn die erforderlichen Normen, Spezifikationen oder Schemata für die geltenden Anforderungen vollständig angewendet werden.
Bestätigen Sie, ob einschlägige harmonisierte Normen, gemeinsame Spezifikationen oder europäische Zertifizierungsschemata für Cybersicherheit auf Vertrauensniveau mindestens substanziell existieren und die geltenden grundlegenden Anforderungen abdecken. Falls sie nicht existieren, nur teilweise angewendet werden oder nicht alle einschlägigen Anforderungen abdecken, verwenden Sie Modul B+C oder Modul H.
Bereiten Sie für eine echte Kameraversion die Versionsakte so vor, als könnte eine Prüfung durch Dritte nötig werden, und bestätigen Sie den Weg, sobald die geltenden Normen und Schemata für das genaue Kameraprodukt klar sind.
Halten Sie den gewählten Weg mit dem Freigabe-Eintrag der Version vor, einschließlich der herangezogenen Referenzen, der von ihnen abgedeckten Anforderungen und etwaiger Lücken, die einen Drittweg erzwungen haben.
Freigabe-Eintrag des Herstellers
Bevor die Kamera für den EU-Markt freigegeben wird, sollte die Freigabe Klassifizierung, Grenze, Bedrohungsmodell, Kontrollen, Aktualisierungsweg und Post-Market-Prozess in eine Entscheidung bringen. Die Tabelle unten ist die kurze Versionsakte, durch die ein Prüfer navigieren können sollte.
| Freigabefrage | Kameraspezifischer Nachweis |
|---|---|
| Warum wird dieses Produkt als Smart-Home-Sicherheitskamera klassifiziert? | Erklärung zum Verwendungszweck, Vertriebskanal, Installationskontext, Produktvarianten und Begründung der Klassifizierung |
| Was genau ist das Produkt mit digitalen Elementen? | Kameragehäuse, Firmware, lokale Schnittstellen, Mobile-App, mit dem Produkt gelieferte Cloud-Verarbeitung, Aktualisierungsdienst und ausgeschlossene Drittanbieter-Einsatzsysteme |
| Was sind die Zugriffspfade mit dem höchsten Risiko? | Admin-UI, ONVIF/RTSP, lokale Netzwerk-Discovery, Cloud-APIs, Kontowiederherstellung, Remote-Ansicht, microSD-Zugriff, Debug-Ports und Dienst-Zugangsdaten |
| Was wurde standardmäßig gesichert? | Kein geteiltes Standard-Passwort, geschützte Ersteinrichtung, authentifizierter Admin-Zugriff, Überprüfung exponierter Dienste, Verschlüsselungsentscheidungen und sicherer Fernzugriff |
| Wie wird die Kamera sicher aktualisiert? | Signierte Firmware, Schlüsselverwahrung, Rollback-Verhalten, Teil-Flash-Wiederherstellung, Update-Verfügbarkeit, Benutzerbenachrichtigung und kostenlose Sicherheitsupdates während des Supportzeitraums |
| Wie werden Schwachstellen nach der Auslieferung behandelt? | Öffentlicher Kontakt, CVD-Richtlinie, Klassifizierungsablauf, SBOM-Überwachung, Lieferantenhinweisüberwachung, Sicherheitshinweis-Prozess, Bereitschaft zur 24-Stunden-Frühwarnung, Bereitschaft zur 72-Stunden-Meldung und Nachweis des Abschlussberichts |
Prüfungen zur Übergabe zwischen Wirtschaftsakteuren
Die Versionsakte sollte die Übergabe vom Hersteller an Importeur, Händler und Eigenmarken-Verkäufer prüffähig machen. Bei Kameras ist der Schwachpunkt meist nicht die CE-Kennzeichnung allein; es ist die Frage, ob Versand, Anzeige, App, Cloud-Dienst und Aktualisierungskanal weiterhin der bewerteten Version entsprechen.
Details zur Übergabe zwischen Wirtschaftsakteuren: Der Hersteller oder Eigenmarken-Hersteller besitzt die Herstellerakte für die genaue Kameraversion. Der Importeur prüft Begründung der Klassifizierung, Erklärung, CE-Kennzeichnungs-Kontrolle, technischen Akten-Index, Erklärung zum Supportzeitraum, Schwachstellenmeldekontakt, Handhabung des Komponenteninventars, Anweisungen in der Zielsprache und Identität des Importeurs, bevor er die Sendung auf dem EU-Markt platziert. Der Händler prüft sichtbare Sorgfaltssignale vor dem Verkauf, darunter CE-Kennzeichnung, gelieferte Dokumente, Rückverfolgbarkeit von Hersteller und Importeur, Anweisungen in der Zielsprache, Support- und Update-Erklärungen, Konsistenz der Online-Anzeige und Signale bekannter Nichtkonformität.
Stop-Bedingungen: Pausieren Sie Versand oder Anzeige, wenn Versionsakte, Rückverfolgbarkeit, Support-Erklärung, App- oder Cloud-Abhängigkeit, Aktualisierungskanal oder bekannte Schwachstelle Anlass zur Annahme geben, dass die Version nicht konform ist. Lesen Sie jedes Mandat eines Bevollmächtigten getrennt von der Sorgfaltspflicht des Importeurs oder Händlers. Auslöser für die Herstellerrolle: Führen Sie eine erneute Analyse der Herstellerrolle aus, wenn eigene Markierung, Firmware, App, Cloud, Aktualisierungskanal, Bridge, NVR-Bundle oder Verwendungszweck Konformität oder Verwendungszweck beeinflussen können. Halten Sie Fragen zur DSGVO, zur Cybersicherheit der Funkanlagenrichtlinie, zu Biometrie, zur KI-Verordnung und zu NIS2 getrennt von der CRA-Klassifizierungsantwort.
Nutzen Sie die nächste Abbildung als Rollen-Checkliste. Das erste Übergabediagramm zeigt den Versand- und Anzeigefluss; dieses trennt die Prüfungen, die Importeur, Händler, Bevollmächtigter, Eigenmarken-Verkäufer und Prüfer benachbarter Regelwerke besitzen.
Jedes Rollenpanel paart die Verifizierungen, die der Akteur durchführen muss, mit der Stop-Bedingung, die Versand, Anzeige oder Version pausiert. Importeur und Händler sitzen direkt im CRA-Ablauf. Der Bevollmächtigte gilt nur, wenn der Hersteller nicht in der EU sitzt, und wird getrennt von der Sorgfaltspflicht des Importeurs oder Händlers gelesen. Prüfungen des Eigenmarken-Verkäufers können eine Herstellerrolle erzeugen, wenn eine Änderung Konformität oder Verwendungszweck beeinflussen kann; Klassifizierung, Konformitätserklärung, technische Dokumentation, Meldeprozess und Plan zum Supportzeitraum können nicht als informelles Lieferantenversprechen geerbt werden. Benachbarte Regelwerke (DSGVO, Cybersicherheit der Funkanlagenrichtlinie, KI-Verordnung, NIS2) bleiben außerhalb der CRA-Klassifizierungsantwort und benötigen eigene Bewertungen.
Häufig gestellte Fragen
Sind Smart-Sicherheitskameras Klasse I oder Kritisch unter dem CRA?
Smart-Home-Sicherheitskameras sind typischerweise Wichtig Klasse I, wenn ihre Kernfunktion die physische Smart-Home-Sicherheit ist. Eine Kamera ist nicht Kritisch, nur weil sie Video verarbeitet oder in einem sensiblen Netzwerk sitzt.
Klassifizierungseintrag: ein Memo, das die genaue Kameravariante, die Verkaufsaussage, die beabsichtigte Sicherheitsfunktion, die gelieferten digitalen Elemente und die Begründung des Wegs benennt.
Benötigt eine Smart-Home-Sicherheitskamera eine notifizierte Stelle?
Nicht immer. Der praktische Test ist, ob der Hersteller sich für die wesentlichen Cybersicherheitsanforderungen der Kamera vollständig auf die geltenden Normen, gemeinsamen Spezifikationen oder die Abdeckung durch ein qualifizierendes Cybersicherheits-Zertifizierungsschema verlassen kann. Fehlt diese Abdeckung oder ist sie nur teilweise vorhanden, planen Sie den Weg durch Dritte ein, statt interne Kontrolle anzunehmen.
Eintrag zum Konformitätsweg: Listen Sie die für das genaue Kameraprodukt herangezogenen Referenzen, die von ihnen abgedeckten Anforderungen, etwaige Lücken und den gewählten Weg auf.
Ist eine professionelle CCTV-Kamera oder ein NVR automatisch in derselben Kategorie?
Nein. Klassifizieren Sie professionelle Überwachung nicht allein nach dem Wort „Kamera". Eine CCTV-Kamera, ein VMS oder ein NVR kann weiterhin ein Produkt mit digitalen Elementen sein und weiterhin CRA-Sicherheitsarbeit benötigen, aber der Weg hängt vom Verwendungszweck, den gelieferten Elementen und der Funktion ab, auf die der Kunde vertraut.
Grenzeintrag: ein Variantenmemo zur professionellen Überwachung, das Kamera, Rekorder, VMS, Installateurs-Cloud, Fernzugriffspfad und etwaige separate Produkte abdeckt, die mit dem Angebot geliefert werden.
Was, wenn die Kamera Gesichtserkennung, Zutrittskontrolle, Firewall- oder VPN-Funktionen enthält?
Behandeln Sie das als Warnsignal für die Klassifizierung. Ist die Kamera primär eine Smart-Home-Sicherheitskamera, können diese Funktionen Teil der Risikobewertung der Kamera sein. Ist das Produkt primär ein Zutrittskontroll-Lesegerät, ein biometrisches Authentifizierungsgerät, ein VPN-Gateway, eine Firewall, ein IDS/IPS oder ein anderes gelistetes Cybersicherheitsprodukt, klassifizieren Sie zuerst diese Kernfunktion und erzwingen Sie das Produkt nicht in die Kamerakategorie. Das zählt, weil einige Kategorien einen strengeren Weg tragen; Firewalls und IDS/IPS sind beispielsweise Klasse II.
Auslöser für eine erneute Prüfung: Öffnen Sie eine separate Kernfunktionsprüfung, wenn die Kamera Identität, Zugang, Netzwerkfilterung, VPN-Zugang oder Einbruchserkennung steuert statt nur Videoüberwachung.
Verändert Cloud-Videospeicherung die Produktgrenze?
Cloud-Speicherung ändert die Klasse nicht automatisch. Wird vom Hersteller bereitgestellte Cloud-Verarbeitung vom Hersteller oder unter dessen Verantwortung entworfen und würde die Kamera ohne sie eine ihrer Funktionen nicht erfüllen, behandeln Sie diese Verarbeitung als Teil der Produktgrenze, des Nachweises und der Risikobewertung. Die Produktklassifizierung folgt weiterhin der Kernfunktion der Kamera, sofern keine andere gelistete Funktion primär ist.
Grenzeintrag: eine Cloud-Abhängigkeitskarte, die zeigt, welche Cloud-Dienste mit der Kamera geliefert werden, welche Funktionen ohne sie versagen, welche Daten sie verarbeiten und welche Systeme außerhalb des Angebots des Herstellers liegen.
Sollten ONVIF, RTSP oder die lokale Web-Admin-Oberfläche nach der Einrichtung aktiviert bleiben?
Nur wenn die Version ein dokumentiertes Zugriffsmodell für diese Fläche hat. Eine Verbraucherkamera kann lokales Streaming oder Administration für legitime Einrichtung, Installateurs- oder Rekorder-Nutzung freigeben, aber die Versionsakte sollte zeigen, ob die Fläche nach der Anmeldung erreichbar bleibt, welche Authentifizierung sie schützt, ob Transportverschlüsselung verwendet wird und welche Benutzereinstellung oder Variantenaussage dies rechtfertigt.
Testartefakt: Dienstscans nach Einrichtung und nach Aktualisierung, ONVIF-/RTSP-Authentifizierungstests, Überprüfung der Discovery-Antworten und die Versionsentscheidung für jede lokale Fläche.
Wann sollte die Risikobewertung aktualisiert werden?
Aktualisieren Sie sie immer dann, wenn sich der freigegebene Kamerazustand auf eine Weise ändert, die das Vertrauen beeinflusst: ein neues ONVIF-Profil, ein neuer Fernansichtsmodus, ein neuer Kontowiederherstellungsablauf, ein neues Cloud-Relay, ein neuer OTA-Kanal, ein neuer Chipsatz, eine neue Firmware-Basis, eine Änderung der Mobile-App-Authentifizierung, ein neues Support-Bundle-Feld oder ein neues Werksreset-Verhalten. Ein Release-Hinweis reicht nicht, wenn die geänderte Funktion einen Angriffspfad wieder öffnet.
Auslöser für eine erneute Prüfung: Jede Funktions- oder Lieferantenänderung, die Zugriff, Aktualisierungsautorität, gespeichertes Video, Kontobindung, Support-Daten oder Reset-Verhalten verändert, öffnet die Grenz- und Risikobewertung erneut.