Embedded Security & Cyber Resilience Act.
Die 4 wichtigsten Praxisfragen verständlich beantwortet.
Der Cyber Resilience Act stellt Hersteller von Embedded- und IoT-Systemen vor eine neue Realität: Security wird verpflichtend und Sicherheitsvorfälle werden meldepflichtig.
In unserem Webinar mit Tributech haben uns genau dazu zahlreiche Fragen erreicht. Vier davon zeigen besonders klar, wo Unternehmen aktuell stehen:
➡️ Wie funktionieren sichere Updates ohne permanente Internetverbindung?
➡️ Wie lässt sich Device Management auf Microcontrollern umsetzen?
➡️ Was passiert mit Zertifikaten bei selten verbundenen Geräten?
➡️ Wer muss Sicherheitsvorfälle künftig melden und wie schnell?
Genau diese Fragen greifen wir in diesem Beitrag auf und geben konkrete Antworten aus der Praxis.
🎥 Webinar verpasst?
Die vollständige Aufzeichnung können Sie hier anfordern.
1. Sichere Updates bei Embedded- und IoT-Geräte ohne Internet, ohne Verschlüsselung, über unsichere Protokolle wie IO-Link?
Der Cyber Resilience Act macht hier eine klare Vorgabe: Geräte mit Kommunikationsschnittstellen müssen updatefähig sein.
Das bedeutet aber nicht zwingend, das alles über die Cloud laufen muss.
In der Praxis gibt es zwei Wege:
Netzwerkbasierte Updates
Wenn möglich, über gesicherte Kommunikation mit lokalem Backend-System.
Lokale Updates
z. B. über USB-Stick oder SD-Karte
Der entscheidende Punkt ist nicht der Transportweg, sondern die Vertrauenswürdigkeit des Updates
Das bedeutet konkret:
✅ Firmware muss signiert sein
✅ Integrität muss geprüft werden
✅ Quelle muss eindeutig verifizierbar sein
Auch kleine Systeme sind hier nicht „ausgenommen“.
Selbst Microcontroller können Signaturen prüfen.
Wichtige Erkenntnis:
Der Cyber Resillience Act fordert keine bestimmte Architektur, aber er fordert sichere Prozesse.
2. Sichere Updates und Device Management bei Microcontroller-Systemen ohne Linux?
Auch reine Microcontroller-Systeme ohne OS müssen die CRA-Anforderungen erfüllen.
Die Herausforderung:
- Weniger Ressourcen
- Keine Trennung zwischen OS und Applikation
- Oft nur monolithisches Firmware-Image
Trotzdem sind sichere Konzepte möglich:
Variante 1: Mit Netzwerkanbindung
-
Schlankes Fleet Management
-
Sichere Kommunikation zum Server
-
Zentrale Steuerung von Updates und Konfigurationen
Variante 2: Ohne Netzwerk
-
Updates über Datenträger (z.B. USB-Stick oder SD-Karte)
-
Nutzung bestehender Schnittstellen wie UART oder IO-Link
Unabhängig vom Ansatz gilt:
- Signaturen und Verifikation sind Pflicht
- Security muss von Anfang an berücksichtigt werden
Nachträgliche Absicherung ist bei Microcontrollern deutlich aufwendiger und oft nur eingeschränkt möglich.
Stehen Sie vor ähnlichen Herausforderungen?
Sprechen wir darüber, wie sich Embedded Security und Device Management in Ihrer bestehenden Systemarchitektur sinnvoll umsetzen lassen.
3. Wie geht man mit Zertifikaten um, wenn Embedded- und IoT-Geräte nicht dauerhaft mit dem Internet verbunden sind?
Zertifikatsbasierte Sicherheit lebt davon, dass Zertifikate regelmäßig erneuert und überprüft werden. In der Praxis sind viele Geräte jedoch nur sporadisch online.
Das führt zu einer zentralen Frage: Wie bleibt ein System sicher, wenn es nicht dauerhaft verbunden ist?
Es gibt mehrere Strategien, die sich in der Praxis bewährt haben.
-
Angepasste Laufzeiten
Die Gültigkeitsdauer wird so gewählt, dass sie zum Verbindungsverhalten passen. -
Erneuerung bei Verbindung
Sobald das Gerät online geht, wird automatisch ein neues Zertifikat angefordert. -
Revocation-Mechanismen
Alte Zertifikate können gezielt ungültig gemacht werden. -
Zero-Trust Enrollment
Auch ohne gültiges Zertifikat kann ein Gerät sich neu authentifizieren z. B. über Produktionsnachweise.
Wichtig ist dabei vor allem eines: Security darf nicht davon abhängen, dass ein Gerät permanent online ist.
Systeme müssen auch mit unregelmäßiger Verbindung sicher funktionieren.
Offline bedeutet nicht unsicher. Es braucht jedoch ein durchdachtes Zertifikatskonzept.
4. Wer muss Sicherheitsvorfälle melden und wie funktioniert das CRA Reporting?
Mit dem Cyber Resilience Act wird Reporting verpflichtend.
Ab September 2026 gelten klare Vorgaben für Hersteller von Embedded- und IoT-Systemen.
72 Stunden.
So viel Zeit bleibt künftig, um Sicherheitsvorfälle zu melden.
Verantwortlich ist der Hersteller.
Nicht der Betreiber. Nicht der Integrator.
Die Meldung erfolgt über die sogenannte Single Reporting Platform, die von ENISA betrieben wird.
Diese Plattform dient als zentrale Schnittstelle für alle Meldungen im Rahmen des CRA.
Auch automatisierte Meldungen sind möglich. Über APIs können Vorfälle direkt aus bestehenden Systemen heraus gemeldet werden.
Welche Fristen gelten konkret?
Der CRA unterscheidet mehrere Meldezeitpunkte:
- Early Warning
Innerhalb von 24 Stunden nach Bekanntwerden einer aktiv ausgenutzten Schwachstelle oder eines schwerwiegenden Vorfalls - Full Notification
Innerhalb von 72 Stunden nach Bekanntwerden - Final Report bei Schwachstellen
Innerhalb von 14 Tagen nach Bereitstellung einer Gegenmaßnahme - Final Report bei Vorfällen
Innerhalb eines Monats nach einem schwerwiegenden Sicherheitsvorfall
Hersteller müssen künftig in der Lage sein:
✅ Sicherheitsvorfälle zuverlässig zu erkennen
✅ die Relevanz intern zu bewerten
✅ Meldungen fristgerecht zu erstellen
✅ und klare Prozesse dafür zu etablieren
Die eigentliche Herausforderung liegt nicht im Reporting.
Die technische Meldung selbst ist selten das Problem. Die Herausforderung liegt in den Strukturen dahinter.
- Wie werden Incidents überhaupt erkannt?
- Wer bewertet, ob eine Meldepflicht besteht?
- Welche Daten sind verfügbar und ausreichend dokumentiert?
Viele Unternehmen stehen hier noch am Anfang.
Der CRA zwingt dazu, Security nicht nur technisch zu denken, sondern organisatorisch zu verankern.
Fazit: Security ist kein Feature
Die Fragen aus unserem Webinar zeigen deutlich, wo Unternehmen aktuell stehen. Es geht längst nicht mehr nur um einzelne Maßnahmen, sondern um ganzheitliche Konzepte.
- Updates müssen sicher und nachvollziehbar sein
- Auch kleine Systeme müssen integriert gedacht werden
- Zertifikatsstrategien müssen zur Realität passen
- Prozesse für Security müssen etabliert sein
Der Cyber Resilience Act gibt dafür den Rahmen vor. Die konkrete Umsetzung liegt bei den Herstellern.
Weiterführende Inhalte
Tributech & Danube Dynamics
Cyber Resilience Act Knowledge Hub
Welche konkreten Anforderungen stellt der Cyber Resilience Act an Hersteller von Embedded- und IoT-Systemen?
Bei unserem Partner Tributech finden Sie eine strukturierte Übersicht zu Pflichten, Fristen und Umsetzung.
Embedded Security richtig umsetzen
Security muss von Anfang an mitgedacht werden.
Erfahren Sie, worauf es bei der Umsetzung in der Praxis ankommt.
Geräte sicher betreiben & verwalten
Sichere Updates und Geräteverwaltung sind zentrale Bausteine moderner Embedded- und IoT-Systeme.
Entdecken Sie, wie sich Security und Betrieb sinnvoll verbinden lassen.
Jetzt Aufzeichnung unseres Webinars
Embedded Security & Device Management anfordern.
Ein TechInsights Webinar von Danube Dynamics & Tributech.
Embedded Security. CRA. Device Management.