Diese fünfzehn Kategorien überschneiden sich. Die folgenden Szenarien sind illustrative technische Beispiele, keine Behauptungen über benannte Vorfälle. Maßnahmen reduzieren bestimmte Risiken; kein Chip und kein Startmechanismus verhindert alle Angriffe. Ein dokumentierter Vorfall wird getrennt mit Quelle bezeichnet.
1. Malware
Ein ausgenutzter Dienst startet unerwünschten Code auf einem Gateway.
Software patchen, Rechte begrenzen und Ausführung überwachen.
2. Ransomware
Ein Angreifer verschlüsselt Speicher oder deaktiviert einen Dienst.
Zugang begrenzen, Offline-Sicherungen erstellen und Wiederherstellung testen.
3. Man-in-the-Middle
Ein falscher Endpunkt verändert Befehle oder Updates.
Gegenstellen prüfen und Befehle sowie Updates authentifizieren.
4. DDoS
Ein kompromittiertes Gerät überlastet ein Ziel mit Verkehr.
Dienste begrenzen, Netze segmentieren und Verkehr überwachen.
5. Physische Manipulation
Jemand untersucht einen Debugport oder externen Speicher.
Debugzugang kontrollieren und physischen Schutz bewerten.
6. Seitenkanäle
Zeit- oder Leistungsmerkmale verraten Informationen über Geheimnisse.
Geeignete Kryptografie verwenden und Implementierungslecks bewerten.
7. Geräte-Spoofing
Ein fremder Endpunkt nutzt die Identität eines anderen Geräts.
Eindeutige Zugangsdaten, sichere Provisionierung und Widerruf nutzen.
8. Injection
Unvertrauenswürdige Eingaben werden als Befehle oder gefährliche Parseraktionen verarbeitet.
Eingaben prüfen, unsichere Interpreter vermeiden und Parser testen.
9. Replay
Ein Angreifer sendet einen früher gültigen Befehl erneut.
Aktualität prüfen und doppelte Transaktionen ablehnen.
10. Firmware-Austausch
Ein unzulässiges Image ersetzt freigegebene Firmware.
Images authentifizieren sowie Start- und Wiederherstellungsregeln schützen.
11. Abhören
Unbefugte erhalten private Sensordaten.
Zugang schützen, Erfassung minimieren und Kommunikation absichern.
12. Informationspreisgabe
Logs oder Diagnose-APIs zeigen Zugangsdaten oder sensible Informationen.
Diagnose beschränken, Geheimnisse entfernen und Speicher schützen.
13. API-Autorisierungsfehler
Ein gültiger Nutzer steuert das Gerät eines anderen Kunden.
Objektberechtigungen bei jeder Anfrage prüfen.
14. Zugangsdatenangriffe
Standard- oder wiederverwendete Passwörter ermöglichen Zugang.
Gemeinsame Standards entfernen, Versuche begrenzen und Fernzugriff schützen.
15. Cryptojacking
Unerwünschtes Mining verbraucht Ressourcen eines Edge-Rechners.
Dienste patchen, ausführbare Aufgaben begrenzen und Nutzung überwachen.
Dokumentiertes Beispiel: Mirai
Das FBI beschreibt, wie Mirai 2016 internetexponierte IoT-Geräte mit gemeinsamen Standardzugangsdaten infizierte und für DDoS nutzte. FBI-Bericht. Das zeigt Zugangs- und Zugangsdatenrisiken; es beweist nicht, dass ein Hardwareanker jede Phase verhindert hätte.
CRA-Termine und Anwendungsbereich
Der CRA trat am 10. Dezember 2024 in Kraft. Artikel 14 gilt für Meldungen seit 11. September 2026; die Hauptanforderungen gelten ab 11. Dezember 2027. Artikel 69 enthält Übergangsregeln für früher in Verkehr gebrachte Produkte. Produkte unter MDR oder IVDR sind nach Artikel 2 Absatz 2 ausgeschlossen; weitere Ausnahmen und nichtkommerzielle freie/Open-Source-Software sind ebenfalls zu prüfen.
CRA und Technologiewahl
CRA-Anforderungen sind ergebnisorientiert und technologieneutral, abhängig von Risikobewertung und Anwendbarkeit. Secure Boot, Hardware-Vertrauensanker, TPM, TrustZone und drahtloses OTA können geeignete technische Maßnahmen sein; sie sind keine allgemeinen gesetzlichen Pflichten für jedes Produkt. Dokumentieren, warum die gewählten Maßnahmen die Anforderungen erfüllen, statt eine Architektur mit Konformität gleichzusetzen.
Häufige Fragen
Verlangt der CRA immer Secure Boot?
CRA-Anforderungen sind ergebnisorientiert und technologieneutral, abhängig von Risikobewertung und Anwendbarkeit. Secure Boot, Hardware-Vertrauensanker, TPM, TrustZone und drahtloses OTA können geeignete technische Maßnahmen sein; sie sind keine allgemeinen gesetzlichen Pflichten für jedes Produkt. Dokumentieren, warum die gewählten Maßnahmen die Anforderungen erfüllen, statt eine Architektur mit Konformität gleichzusetzen.
Garantiert ein Secure Element Konformität?
Nein. Es kann bestimmte Schlüssel und Vorgänge schützen; Konformität betrifft das gesamte Produkt samt Anforderungen, Prozessen und Nachweisen.