CRA-Compliance- und Cyberresilienz-Plattform für Embedded-Geräte
Die Software in Ihrem Produkt kennen, das Risiko im Feld sehen, fristgerecht melden und die Korrektur sicher ausliefern. Vier Module arbeiten mit demselben Datensatz, vom MCU bis zum Embedded-Linux-Gateway.
Was heute verfügbar ist
Wir nennen den aktuellen Stand jeder Funktion offen. Module mit dem Status Pilot bieten wir im Rahmen unseres Pilotprogramms für Unternehmen an.
| Funktion | Status | Umfang |
|---|---|---|
| Web-SBOM-Scanner mit OSV-Abgleich | Verfügbar | Kostenloses Web-Tool, Auswertung im Browser |
| Export in CycloneDX 1.7, SPDX 2.3 und CSV | Verfügbar | Kostenloser Web-Scanner |
| Firmware-SBOM-Engine (CycloneDX 1.6, SPDX 2.3, VEX) | Pilot | Validiert mit öffentlichen Firmware-Images |
| Sicherheitsereignisse von Geräten und Priorisierung mit KEV / EPSS | Pilot | Pilotprogramm für Unternehmen |
| Secure OTA (signiert, A/B-Slots, Rollback-Schutz) | Pilot | Durchgängig auf Hardware getestet |
| CRA-Meldeassistent nach Artikel 14 | Pilot | Fristüberwachung und Meldungsentwürfe; die Einreichung im ENISA-Portal übernehmen Sie |
| Gestaffelter Rollout und Delta-Updates | Roadmap | Noch nicht verfügbar |
| PUF und hardwaregestützte Identität | Roadmap | Ausgewählte Mikrocontroller |
Module
01 · Erkennung
Dynamische SBOM-Engine
Öffnet Firmware-Images (SquashFS, uImage/sysupgrade, Disk-Images, ESP32-(ESP-IDF-)Anwendungs-Images und vollständige Flash-Dumps, Archive) und identifiziert die enthaltenen Komponenten. Lässt sich eine Ebene nicht öffnen oder eine Komponente nicht identifizieren, wird die SBOM als unvollständig gekennzeichnet und der Grund angegeben.
- Analyse von Firmware-Images und Paketmanifesten
- Ausgabe in CycloneDX 1.6 und SPDX 2.3
- Abgleich mit OSV und NVD, priorisiert mit CISA KEV und EPSS
- VEX in CSAF 2.0 und OpenVEX; die endgültige Entscheidung trifft Ihr Analyst
02 · Priorisierung
Feldtelemetrie und Frühwarnung
Geräte senden signierte Telemetrie und melden ihre eigenen Sicherheitsereignisse. Schwachstellen werden danach eingestuft, ob ihre Ausnutzung bekannt ist (CISA KEV) und wie wahrscheinlich eine Ausnutzung ist (EPSS). So stehen die dringenden oben.
- Telemetrie, signiert mit dem eigenen Schlüssel jedes Geräts
- Vom Gerät gemeldete Sicherheitsereignisse: Manipulation und Speicherbeschädigung
- Kritische Geräteereignisse legen automatisch einen Bewertungsdatensatz an; ob eine Meldepflicht besteht, entscheidet Ihr Team
- Einstufung von Schwachstellen mit CISA KEV und EPSS
03 · Meldung
CRA-Meldeassistent
Die gesetzlichen Fristen beginnen, sobald der Hersteller Kenntnis von einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall erlangt. Die Plattform hält diesen Zeitpunkt fest, berechnet daraus die Fristen für 24 Stunden, 72 Stunden und den Abschlussbericht, warnt Sie vor Ablauf und erstellt den Inhalt jeder Meldung als Entwurf. Sie reichen die Meldung über die einheitliche Meldeplattform der ENISA ein, und die Einreichung wird protokolliert.
- Fristüberwachung mit Warnungen für 24 h, 72 h und den Abschlussbericht
- Entwürfe für Frühwarnung, Meldung, Abschlussbericht und Information der Nutzer (Art. 14 Abs. 8)
- Betroffene Produkte und Firmware-Versionen kommen aus den Datensätzen
- Prüfpfad, der nur ergänzt werden kann
04 · Behebung
Secure-OTA-Manager
Signiert das Update mit einem Schlüssel, der ausschließlich Ihrem Unternehmen gehört. Vor der Installation prüft das Gerät die Signatur, den Image-Hash und den Rollback-Schutz; das Update wird in den inaktiven A/B-Slot geschrieben.
- Prüfung von ECDSA-P-256-Signatur und Hash auf dem Gerät
- A/B-Slots und Rollback-Schutz
- Freigegeben werden kann nur Firmware, die die CRA-Analyse bestanden hat
- Jede Freigabe und jedes Geräteergebnis im Prüfpfad
Getestet mit echter Firmware
Wir testen die Plattform mit öffentlichen Firmware-Images und auf echter Hardware. Ergebnisse, Stand Oktober 2026:
- 6 Images · 7 Durchläufe
- Alle Analysen abgeschlossen: Embedded-Linux-Images quelloffener Router-Firmware für mehrere Prozessorarchitekturen, ein ESP32-Anwendungs-Image und ein vollständiger ESP32-Flash-Dump. Bei ESP32 wird die ESP-IDF-Version aus dem Anwendungsdeskriptor im Image gelesen; die Versionen der in ESP-IDF enthaltenen Bibliotheken (mbedTLS, lwIP, FreeRTOS) werden nicht in das Image geschrieben und deshalb mit der SBOM des Herstellers ergänzt.
- 174–220
- Identifizierte Komponenten je Embedded-Linux-Image.
- ~4.150 → 21–23
- Rohbefunde, mit CISA KEV und EPSS auf eine Prioritätenliste reduziert.
- Durchgängiges OTA
- Auf echter Hardware: Registrierung, signierte Telemetrie, CRA-Analyse des Updates, signierte Freigabe und verifizierter Download. Dieser Test lief ohne aktiviertes Secure Boot.
Aus dem Portal
Aufgenommen mit Demodaten, Oktober 2026. Echte Analyse eines öffentlich verfügbaren Firmware-Images für Open-Source-Router; Firmen- und Produktnamen sind fiktiv.

Abb. 1
Priorisierte Schwachstellen
4.135 Befunde in einer Router-Firmware. Schwachstellen aus CISA KEV und mit hohem EPSS stehen oben; jede bleibt in Prüfung, bis ein Analyst entscheidet. Export als OpenVEX und CSAF.

Abb. 2
Fristen nach Artikel 14
Eine Schwachstelle, die der Analyst als aktiv ausgenutzt bestätigt hat. Die gesetzlichen Fristen für die Frühwarnung nach 24 Stunden, die Meldung nach 72 Stunden und den Abschlussbericht, jeweils mit der verbleibenden Zeit. Die Portaloberfläche ist auf Türkisch abgebildet.
Technische Daten
- Auf dem Gerät
- C99-SDK für Mikrocontroller
- Firmware-Analyse
- Embedded-Linux-Images; ESP32-(ESP-IDF-)Anwendungs-Images (.bin) und vollständige Flash-Dumps
- Gerätekommunikation
- HTTPS mit Prüfung des Serverzertifikats; jede Anfrage mit dem ECDSA-P-256-Schlüssel des Geräts signiert
- Update-Signaturen
- ECDSA P-256 (SHA-256), ein Schlüssel pro Kunde
- Ausgabeformate
- CycloneDX 1.6 · SPDX 2.3 · CSAF 2.0 · OpenVEX
Empfohlene Hardware-Sicherheitsfunktionen
Sicherheitsfunktionen, die wir für Ihr Produkt je nach Hardwareklasse empfehlen. Es sind Empfehlungen, keine Voraussetzungen unseres SDK.
| Profil | Typischer Speicher | Empfohlene Funktionen |
|---|---|---|
| Ressourcenarmer MCU | 256 KB–1 MB Flash, 64–256 KB RAM | Hardware-Vertrauensanker, Secure Boot, A/B- oder Dual-Bank-Flash |
| Leistungsstarker MCU / MPU | 1–16 MB Flash, 512 KB+ RAM | Hardware-Kryptobeschleuniger, sichere Schlüsselspeicherung |
| Embedded Linux / Gateway | 64 MB+ RAM, eMMC / NAND | Secure Element / TPM 2.0 / Arm TrustZone |
Zuordnung zum CRA
Unser Leitfaden enthält eine Tabelle, die zeigt, welches Modul welche Pflicht aus dem CRA abdeckt. Zuordnungstabelle im CRA-Leitfaden