Updatearchitektur und Fehlerbehandlung
Ein Over-the-Air-Update (OTA) überträgt Software oder Firmware über eine drahtlose Verbindung. Fernupdates können auch kabelgebundene Netze nutzen; automatische Installation ist eine andere Eigenschaft. Ein sicherer Entwurf authentifiziert Update und Ziel, schützt Signierschlüssel, prüft Versionsregeln und behandelt Stromausfälle sicher. A/B-Partitionen sind eine Wiederherstellungsstrategie, keine allgemeine Pflicht. RFC 9019 beschreibt eine IoT-Updatearchitektur, kein fertiges verpflichtendes Manifestformat. Das Gerät benötigt Prüfmaterial, nicht den privaten Signierschlüssel der gesamten Flotte. Beschädigte Images, falsche Ziele, abgebrochene Schreibvorgänge, widerrufene Schlüssel und unzulässige ältere Versionen testen.
CRA: Anforderungen und technische Entscheidungen
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.
Unterstützung, Updates und SBOM
CRA Anhang I verlangt anwendbare Mechanismen für sichere Schwachstellenbehandlung und Updates. Automatische Sicherheitsupdates haben Bedingungen und Ausnahmen; automatisch bedeutet nicht drahtlos. Artikel 13 Absatz 8 bestimmt die Unterstützung, grundsätzlich mindestens fünf Jahre; bei kürzerer erwarteter Nutzung entspricht sie dieser, während längere Nutzung längere Unterstützung erfordern kann. Die SBOM muss maschinenlesbar sein und mindestens Abhängigkeiten der obersten Ebene abdecken.
CRA-Anwendungsbereich und Termine
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.
Praktische Checkliste
- Produkt, Verwendungszweck, Markt und rechtlichen Anwendungsbereich bestimmen.
- Genaue Vorschriften, Termine und Normausgaben einschließlich Einschränkungen erfassen.
- Zulässiges Bewertungsverfahren und erforderliche Nachweise bestimmen.
- Risiken, Prüfungen, Produktversionen und Erklärungen in der technischen Dokumentation verknüpfen.
- Verantwortung für Änderungen, Unterstützung und Behördenanfragen zuweisen.
Die Liste unterstützt die Planung; die einschlägigen gesetzlichen Anforderungen bestimmen die abschließende Bewertung.