Warum Sie diesen Brief bekommen haben: Wir schreiben Hersteller an, deren Produkte unter Anhang I des Cyber Resilience Act fallen. Dieser Brief ist einer von 39. Für diese erste Runde suchen wir eine Handvoll Hersteller, die ein Image bereitstellen und uns sagen, ob der Bericht trägt.

1
Sie stellen ein Image bereit
2
Wir analysieren es ohne Quellcodezugang
3
Sie erhalten SBOM, CVE-/KEV-Status und den technischen Befundbericht

Build-Prozess und Entwicklungsdokumentation zeigen den erwarteten Zustand. LegacyMind ergänzt diese Sicht um eine unabhängige Verifikation des final freigegebenen Images.

Der Umfang

Vier Artefakte aus einem Image

Vier Artefakte, alle aus derselben Analyse eines einzigen Images.

Software-Stückliste

CycloneDX-JSON

Name und exakte Version jeder gefundenen Komponente, aus den Paketdatenbanken des Images (dpkg, opkg, rpm, apk) und aus den Manifesten der Sprach-Ökosysteme. Die Stückliste verlässt das System als CycloneDX-JSON: ein gängiges, maschinenlesbares Format und damit die Inventar-Grundlage, auf die sich Anhang I Teil II Nr. 1 bezieht.

Schwachstellenlage

CISA KEV · EUVD

Zu jeder Komponente zeigen wir bekannte Schwachstellen sowie den verfügbaren Exploitation-Status aus CISA KEV und EUVD. Beide Kataloge werden laufend nachgezogen. Bei einer möglichen Betroffenheit schafft dieser Abgleich eine wichtige Grundlage für die weitere Bewertung.

Härtung je Binärdatei

RELRO · Stack Canary · NX/DEP · PIE

Für jede ausführbare Datei im Image: RELRO, Stack Canary, NX/DEP und PIE, Datei für Datei ausgewiesen, ohne Gesamtnote.

Zugangsdaten

/etc/shadow · /etc/passwd

Passwort-Hashes aus der Konto-Datenbank des Images, klassifiziert nach BSI TR-02102-1. Kein Suchlauf über das gesamte Dateisystem nach API-Schlüsseln: Was wir zeigen, stammt aus /etc/shadow und /etc/passwd, und ist deshalb belastbar.

Wie genau ist das Verfahren?

140von140

Gegen ein Image, für das der Hersteller seine Paketliste veröffentlicht, haben wir 140 von 140 Paketen exakt getroffen, Name und Version.

Statisch gelinkte Bibliotheken und Kernelmodule sind darin bewusst nicht bewertet, und die Zahl ist eine Untergrenze für die Trefferwahrscheinlichkeit, kein Deckungsgrad für ein beliebiges Image.

Quelle: OpenWrt-Release mit veröffentlichter Paketliste als Prüfmaßstab · anderes Image als die Analyse darunter · Abgleich 18.08.2026

Aus einem ausgelieferten ImageAus einem einzigen ausgelieferten Image

versionierte Komponenten: 550
davon mit bekannten Schwachstellen: 52
davon im KEV-Katalog der CISA, dem Verzeichnis der nachweislich ausgenutzten: 7

Quelle: Reales Industrie-Gateway · Serienprodukt · öffentlich verfügbare Firmware · Abgleich gegen CISA-KEV, Analyse 26.07.2026

Komponenten-Inventar

Software-Bestand, Bibliotheken und Versionen direkt aus dem ausgelieferten Image, auch für zugekaufte Module, deren Innenleben im Haus niemand im Detail kennt.

Auszug aus dem Komponenten-Inventar einer Firmware-Analyse: Name, Version und Funktion je Komponente.
Komponente	Version	Funktion
OpenSSL	1.1.1t	TLS-Bibliothek
BusyBox	1.34.1	Systemwerkzeuge und Shell
Linux-kernel	5.4.251	Betriebssystemkern
dnsmasq	2.85-20	DNS- und DHCP-Dienst
Dropbear	2020.81-2	SSH-Server
cURL	8.2.0	HTTP-Client
Strongswan	5.9.2	IPsec-VPN
OpenVPN	2.5.3	VPN
Libmodbus	3.1.6	Modbus-Feldbusbibliothek
Libpcap	1.9.1	Paketmitschnitt
zlib	1.2.11	Kompression
Lua	5.1.5	Skriptlaufzeit

12 von 550 Komponenten · Auswahl nach öffentlicher Nachprüfbarkeit

Der Herstellername steht nirgends. Wir zeigen keine fremde Firmware mit Namen. Ihre auch nicht.

Der Ausschnitt stammt aus der Analyse eines Serienprodukts mit öffentlich verfügbarer Firmware.

Quelle: Auszug aus dem Analyseergebnis · 12 von 550 Komponenten, ausgewählt nach öffentlicher Nachprüfbarkeit · Versionsangaben unverändert so, wie sie im Image stehen · anonymisiertes Herstellerimage · Analyse 26.07.2026

25 bis 30 Minutenan einem realen Firmware-Image

Zum Termin

Prüfumfang

Was die Analyse abdeckt, und was nicht

Wir stellen keine Konformität fest. Wir liefern die Evidenz, mit der Ihr Prüfer sie feststellt.

Erklärung zum Prüfumfang

So druckt der Befundbericht seine Grenzen: als Gegenstand mit Stückzahlen. Was innerhalb der gezogenen Linie liegt, wurde geprüft. Was außerhalb liegt, nicht.

Zeichnung: Erklärung zum Prüfumfang
Blatt: § 12 des Befundberichts
Analyse: 01.09.2026
Maß: Stückzahlen, kein Prozentwert
Vollständigkeit: complete: false
Grund: distro_unmapped

Vollständigkeit und Grund: Feldnamen und Feldwerte aus dem Bericht (Feld coverage_contract), unverändert übernommen.

Stückliste

Stückliste 8Anzeigen

Position 1: Wurzeldateisystem1 geprüft
Alle folgenden Stückzahlen beziehen sich auf dieses eine Dateisystem.
Position 2: Binärdateien894
Jede auf RELRO, Stack Canary, NX/DEP und PIE geprüft, dazu auf Aufrufe unsicherer Funktionen.
Position 3: Übersprungen2
Gestrippt oder statisch gelinkt. Ein Canary ist dort nicht bestimmbar und wird konservativ als fehlend gezählt.
Position 4: Komponenten467 mit Version
Aus den Paketdatenbanken des Images, Name und exakte Version.
Position 5: Ohne Distributions-Zuordnung326
Für diese läuft der CVE-Abgleich nur über Name und Version. Rückportierte Korrekturen sind nicht erkennbar, die Befunde können zu hoch liegen.
Position 6: Prüfschritte9 von 9 ausgeführt
Paketdatenbanken · Komponenten-CVE-Abgleich · Anmeldedaten · Schlüssel · Zertifikate · Binär-Härtung je ausführbarer Datei · unsichere Funktionsaufrufe
Position 7: Außerhalb der Linienicht Bestandteil
Laufzeit- und Dynamikanalyse, Penetrationstest, CWE-Mustersuche in Binärdateien. Diese drei sind kein Schritt des Verfahrens, ihr Fehlen ist keine Lücke. Der Bericht führt sie trotzdem auf, damit ein Prüfer die Grenze kennt, bevor er den ersten Befund liest.
Position 8: Vollständigkeitcomplete: false
Feldwert aus dem Bericht. Grund, ebenfalls als Feldwert: distro_unmapped, also 326 Komponenten ohne Distributions-Zuordnung. Die Erklärung sagt es so, statt die Abdeckung als vollständig auszugeben.

Position 1: Wurzeldateisystem1 geprüft
Alle folgenden Stückzahlen beziehen sich auf dieses eine Dateisystem.
Position 2: Binärdateien894
Jede auf RELRO, Stack Canary, NX/DEP und PIE geprüft, dazu auf Aufrufe unsicherer Funktionen.
Position 3: Übersprungen2
Gestrippt oder statisch gelinkt. Ein Canary ist dort nicht bestimmbar und wird konservativ als fehlend gezählt.
Position 4: Komponenten467 mit Version
Aus den Paketdatenbanken des Images, Name und exakte Version.
Position 5: Ohne Distributions-Zuordnung326
Für diese läuft der CVE-Abgleich nur über Name und Version. Rückportierte Korrekturen sind nicht erkennbar, die Befunde können zu hoch liegen.
Position 6: Prüfschritte9 von 9 ausgeführt
Paketdatenbanken · Komponenten-CVE-Abgleich · Anmeldedaten · Schlüssel · Zertifikate · Binär-Härtung je ausführbarer Datei · unsichere Funktionsaufrufe
Position 7: Außerhalb der Linienicht Bestandteil
Laufzeit- und Dynamikanalyse, Penetrationstest, CWE-Mustersuche in Binärdateien. Diese drei sind kein Schritt des Verfahrens, ihr Fehlen ist keine Lücke. Der Bericht führt sie trotzdem auf, damit ein Prüfer die Grenze kennt, bevor er den ersten Befund liest.
Position 8: Vollständigkeitcomplete: false
Feldwert aus dem Bericht. Grund, ebenfalls als Feldwert: distro_unmapped, also 326 Komponenten ohne Distributions-Zuordnung. Die Erklärung sagt es so, statt die Abdeckung als vollständig auszugeben.

Quelle: Feld coverage_contract und Prüfschritt-Protokoll einer Analyse vom 01.09.2026 · ausgeliefertes Release einer Industrie-Steuerung · Zahlen unverändert aus der Analyse · anderes Image als das Komponenten-Inventar oben

Außerhalb der Linie

Außerhalb der Linie 6Anzeigen

Kein Quellcode, keine Laufzeit

Keine dynamische Analyse, kein Penetrationstest, keine Hardware- oder Seitenkanalanalyse, keine Prüfung Ihrer Prozesse.

Vorhandensein ist nicht Erreichbarkeit

Wir weisen nach, dass eine netzfähige Komponente im Image liegt; nicht, dass sie im Feld erreichbar ist.

Verschlüsselte oder gepackte Images

Lässt sich ein Image nicht auspacken, sagen wir das und liefern keine erfundene Stückliste. Genau deshalb wählen wir das Image gemeinsam mit Ihnen aus.

Herstellerspezifische Container

Reine Konfigurations-, Ressourcen- oder Delta-Update-Container enthalten keinen ausführbaren Code. Daraus entsteht keine Stückliste, und wir sagen es Ihnen, statt eine zu erzeugen. Genau deshalb wählen wir das Image gemeinsam mit Ihnen aus.

Rückportierte Korrekturen

Distributionen pflegen Sicherheitskorrekturen in alte Versionen zurück, ohne die Versionsnummer zu ändern. Von außen ist das nicht prüfbar; Befunde können dadurch zu hoch liegen.

Gestrippte Binärdateien

Ein Stack Canary lässt sich dort nicht bestimmen und wird konservativ als fehlend gezählt.

Kein Quellcode, keine Laufzeit

Keine dynamische Analyse, kein Penetrationstest, keine Hardware- oder Seitenkanalanalyse, keine Prüfung Ihrer Prozesse.

Vorhandensein ist nicht Erreichbarkeit

Wir weisen nach, dass eine netzfähige Komponente im Image liegt; nicht, dass sie im Feld erreichbar ist.

Verschlüsselte oder gepackte Images

Lässt sich ein Image nicht auspacken, sagen wir das und liefern keine erfundene Stückliste. Genau deshalb wählen wir das Image gemeinsam mit Ihnen aus.

Herstellerspezifische Container

Rückportierte Korrekturen

Distributionen pflegen Sicherheitskorrekturen in alte Versionen zurück, ohne die Versionsnummer zu ändern. Von außen ist das nicht prüfbar; Befunde können dadurch zu hoch liegen.

Gestrippte Binärdateien

Ein Stack Canary lässt sich dort nicht bestimmen und wird konservativ als fehlend gezählt.

Wir zeigen die Analyse an einem realen Image.

Zum Termin

Der Befundbericht

Was Ihr Prüfer darin findet, Abschnitt für Abschnitt

Die Gliederung des technischen Befundberichts im Hersteller-Schnitt. Die meisten Abschnitte stehen in jedem Bericht. Angriffsfläche, Kernel-Härtung und Normbezug werden nur gedruckt, wenn das Image die Eingabe dafür hergibt. Was ein Abschnitt enthält, hängt am Image.

21 AbschnitteAnzeigen

Geltungsbereich und Prüfgegenstand
Welches Image, welche Version, welche Architektur; woran die Aussagen hängen.
Management-Kurzfassung
Risikoscore, aktiv ausgenutzte CVEs und die Maßnahmen, die zuerst dran sind, auf einer Seite.
Technische Einordnung
Gerät, Architektur und die Schweregrad-Verteilung der CVEs je Stufe.
Methodik und Prüfgrundlage
Statische Analyse des Images, binär-intern. Keine Laufzeit- oder Penetrationsprüfung am Gerät.
Priorisierung, vom Rohbefund zur Handlung
Wie aus der Rohliste die Reihenfolge entsteht: aktive Ausnutzung und öffentlicher Exploit vor Schweregrad allein.
Angriffsfläche und Exposition
Netzfähige Komponenten im Image. Nachgewiesen wird ihre Präsenz, nicht ihre Erreichbarkeit im Feld.
Steht im Bericht, wenn netzfähige Komponenten im Image erkannt wurden.
Vorrangig zu behandelnde Befunde
Die Befunde, die zuerst dran sind, gereiht nach Priorität, jeder mit Komponente, Kennung und Fundstelle.
Komponenten-Schwachstellenkatalog
Je Komponente die zugeordneten CVEs, mit Schweregrad, KEV-Kennzeichnung und Versionsbezug.
Anmeldedaten und Geheimnisse
Konten und Passwort-Hashes aus /etc/shadow und /etc/passwd, nach BSI TR-02102-1 klassifiziert; private Schlüssel und Zertifikate.
Speicherschutz und Exploit-Schutzmaßnahmen
RELRO, Stack Canary, NX/DEP und PIE, Datei für Datei, mit der Grundgesamtheit der geprüften Binärdateien.
Kernel-Härtung und Kernel-Exposition
Kernel-Version und, wenn eine kconfig im Image liegt, die Prüfung gegen die KSPP-Härtungsoptionen. Fehlt sie, sagt der Abschnitt das.
Steht im Bericht, wenn ein Kernel im Image liegt.
Weitere statische Prüfungen
Aufrufe unsicherer Funktionen in den Binärdateien.
Software-Stückliste (SBOM), angelehnt an BSI TR-03183-2
Angelehnt an BSI TR-03183-2, mit Schwachstellenbezug; als CycloneDX-JSON exportierbar.
Anhang: Komponenteninventar (Auszug)
Die Komponenten ohne zugeordnete Schwachstelle, als Auszug. Vollständig steht das Inventar in der CycloneDX-SBOM.
Abdeckung, Grenzen und Erklärung zum Prüfumfang
Die Zeichnung oben, als Text: geprüft, mit Einschränkung, nicht bewertet, Datenstand der Kataloge.
Befundliste zur Nachverfolgung
Jeder Befund als Zeile mit Kennung, damit er im nächsten Release wiedergefunden wird.
Maßnahmenplan je Befund (Release-Planung)
Welche Korrektur welchen Befund schließt. Keine Aufwände, die nicht aus der Analyse hervorgehen.
Normbezug: CRA Anhang I und unterstützende Normen
Die Punkte des Anhangs I, zu denen die Analyse eine Feststellung treffen kann, mit Verweis auf den Abschnitt, der sie trägt.
Steht im Bericht, immer, je Punkt mit der Form der Feststellung.
Glossar und Abkürzungsverzeichnis
Abkürzungen und die Begriffe, die der Bericht benutzt.
Referenzen und Normenverzeichnis
Normenverzeichnis und die zitierten Quellen.
Berichtsnachweis und Dokumentenlenkung
Analyse-Kennung, Datum, Freigabe.

Geltungsbereich und Prüfgegenstand
Welches Image, welche Version, welche Architektur; woran die Aussagen hängen.
Management-Kurzfassung
Risikoscore, aktiv ausgenutzte CVEs und die Maßnahmen, die zuerst dran sind, auf einer Seite.
Technische Einordnung
Gerät, Architektur und die Schweregrad-Verteilung der CVEs je Stufe.
Methodik und Prüfgrundlage
Statische Analyse des Images, binär-intern. Keine Laufzeit- oder Penetrationsprüfung am Gerät.
Priorisierung, vom Rohbefund zur Handlung
Wie aus der Rohliste die Reihenfolge entsteht: aktive Ausnutzung und öffentlicher Exploit vor Schweregrad allein.
Angriffsfläche und Exposition
Netzfähige Komponenten im Image. Nachgewiesen wird ihre Präsenz, nicht ihre Erreichbarkeit im Feld.
Steht im Bericht, wenn netzfähige Komponenten im Image erkannt wurden.
Vorrangig zu behandelnde Befunde
Die Befunde, die zuerst dran sind, gereiht nach Priorität, jeder mit Komponente, Kennung und Fundstelle.
Komponenten-Schwachstellenkatalog
Je Komponente die zugeordneten CVEs, mit Schweregrad, KEV-Kennzeichnung und Versionsbezug.
Anmeldedaten und Geheimnisse
Konten und Passwort-Hashes aus /etc/shadow und /etc/passwd, nach BSI TR-02102-1 klassifiziert; private Schlüssel und Zertifikate.
Speicherschutz und Exploit-Schutzmaßnahmen
RELRO, Stack Canary, NX/DEP und PIE, Datei für Datei, mit der Grundgesamtheit der geprüften Binärdateien.
Kernel-Härtung und Kernel-Exposition
Kernel-Version und, wenn eine kconfig im Image liegt, die Prüfung gegen die KSPP-Härtungsoptionen. Fehlt sie, sagt der Abschnitt das.
Steht im Bericht, wenn ein Kernel im Image liegt.
Weitere statische Prüfungen
Aufrufe unsicherer Funktionen in den Binärdateien.
Software-Stückliste (SBOM), angelehnt an BSI TR-03183-2
Angelehnt an BSI TR-03183-2, mit Schwachstellenbezug; als CycloneDX-JSON exportierbar.
Anhang: Komponenteninventar (Auszug)
Die Komponenten ohne zugeordnete Schwachstelle, als Auszug. Vollständig steht das Inventar in der CycloneDX-SBOM.
Abdeckung, Grenzen und Erklärung zum Prüfumfang
Die Zeichnung oben, als Text: geprüft, mit Einschränkung, nicht bewertet, Datenstand der Kataloge.
Befundliste zur Nachverfolgung
Jeder Befund als Zeile mit Kennung, damit er im nächsten Release wiedergefunden wird.
Maßnahmenplan je Befund (Release-Planung)
Welche Korrektur welchen Befund schließt. Keine Aufwände, die nicht aus der Analyse hervorgehen.
Normbezug: CRA Anhang I und unterstützende Normen
Die Punkte des Anhangs I, zu denen die Analyse eine Feststellung treffen kann, mit Verweis auf den Abschnitt, der sie trägt.
Steht im Bericht, immer, je Punkt mit der Form der Feststellung.
Glossar und Abkürzungsverzeichnis
Abkürzungen und die Begriffe, die der Bericht benutzt.
Referenzen und Normenverzeichnis
Normenverzeichnis und die zitierten Quellen.
Berichtsnachweis und Dokumentenlenkung
Analyse-Kennung, Datum, Freigabe.

Quelle: Gliederung des technischen Befundberichts, Hersteller-Schnitt · Abschnittstitel wörtlich aus dem Berichtsgenerator · Stand 09.09.2026

Den Bericht behalten Sie, unabhängig davon, ob wir danach zusammenarbeiten.

Zum Termin

Datensouveränität

Was mit Ihrem Image passiert

Unter NDA. Ein Image, gemeinsam ausgewählt. Die Analyse läuft auf unseren Servern in Deutschland.

Analyse auf dedizierten Servern in Deutschland
EU-basierte Schwachstellenquellen inklusive EUVD
Ohne Quellcodezugang, ohne Agent, ohne Eingriff in den laufenden Betrieb
Regelbasierte Analyse, jeder Befund bis zur Quelle nachrechenbar
Mandanten-Isolation, Verschlüsselung, Löschung der Firmware nach Abschluss der Analyse
On-Premise-Deployment für kritische Umgebungengeplant

Cyber Resilience Act

Worauf sich das bezieht

11. September 2026: Meldepflichten.

Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle sind zu melden: Frühwarnung binnen 24 Stunden, Schwachstellenmeldung binnen 72 Stunden. Diese Pflicht gilt auch für Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, also für das, was heute bereits beim Kunden steht.

11. Dezember 2027: CE-Kennzeichnung.

Ab dann dürfen Produkte mit digitalen Elementen in der EU nur in Verkehr gebracht werden, wenn die Anforderungen aus Anhang I erfüllt und die Konformität erklärt ist.

Schwachstellen und Komponenten der Produkte mit digitalen Elementen ermitteln und dokumentieren, u. a. durch Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen.
Verordnung (EU) 2024/2847, Anhang I Teil II Nr. 1

Der Check liefert hierfür eine technische Inventar-Grundlage direkt aus dem analysierten Firmware-Image. Die Konformitätsaussage treffen Sie.

Der Check ist eine technische Bestandsaufnahme aus dem Image heraus, kein Zertifikat und keine Konformitätsaussage.

Der Check nennt jeden der 32 Punkte aus CRA Anhang I und § 30 BSIG mit seiner Nummer. Zu welchen davon Ihr Image eine Feststellung trägt, entscheidet, was in ihm liegt: ein Linux-Image mit Paketdatenbank beantwortet bis zu sieben aus dem Image, ein Roh-Image ohne extrahierbares Dateisystem trägt an diesen Punkten den Grund statt eines Ergebnisses.

Ablauf

Wie es abläuft

1
Termin
25 bis 30 Minuten, zu einem Zeitpunkt, den Sie vorschlagen. Wir zeigen die Analyse an einem realen Image.
2
NDA
Vor jeder Übergabe.
3
Image
Eines, gemeinsam ausgewählt. Ihr Aufwand: ein Image bereitstellen.
4
Report
SBOM (CycloneDX) und technischer Befundbericht. Den Bericht behalten Sie, unabhängig davon, ob wir danach zusammenarbeiten. Für diese erste Runde kostenfrei.

Wer das macht

Zwei Personen, ein Werkzeug

LegacyMind ist aus Gesprächen mit Sicherheitsverantwortlichen entstanden. Als zum fünften Mal die Frage kam, wer eigentlich in die ausgelieferte Firmware schaut, haben wir angefangen, das Werkzeug dafür zu bauen. Heute analysiert es Firmware auf Binärebene, regelbasiert, ohne Cloud-Dienst Dritter, aus Ingolstadt.

Marco Plannet
Geschäftsführer
Ihr Ansprechpartner für Termin und NDA.
Ben Plannet
Technik
Führt die Analyse durch und zeigt sie Ihnen.

Terminbuchung

Zeigen Sie es mir.

Wenn das Thema für Sie relevant ist, zeigen wir Ihnen den Ansatz live. Sie entscheiden danach, ob ein kostenfreier CRA-Readiness-Check für eines Ihrer Images sinnvoll ist.

25 bis 30 Minutenan einem realen Firmware-Image

Der Kalender wird von cal.meetergo.com geladen. Dabei wird eine Verbindung zu diesem Dienst aufgebaut und Ihre IP-Adresse übertragen. Vorher verlässt nichts Ihr Gerät.

Was Sie live sehen

die Komponenten, die tatsächlich im Image stecken
CVEs je Komponente, mit KEV-Kennzeichnung
Zugangsdaten und private Schlüssel, sofern das Image welche enthält

Es zeigt Ihnen: Ben PlannetTechnik
Termin und NDA: Marco PlannetGeschäftsführer

Lieber direkt: marco.plannet@legacymind.de +49 151 7000 9497

Woher wir Ihre Adresse haben: Wir haben Sie aus öffentlich zugänglichen Quellen angeschrieben: Branchen- und Mitgliederverzeichnissen sowie Unternehmenswebsites. Zweck ist die Ansprache zum Cyber Resilience Act. Sie können der Verarbeitung Ihrer Daten jederzeit widersprechen (Art. 21 Abs. 2 DSGVO). Eine Nachricht an info@legacymind.de genügt. Einzelheiten in unserer Datenschutzerklärung.

Ein Firmware-Image rein.Ein prüffähiger Befundbericht raus.

Software-Stückliste

Schwachstellenlage

Härtung je Binärdatei

Zugangsdaten

Kein Quellcode, keine Laufzeit

Vorhandensein ist nicht Erreichbarkeit

Verschlüsselte oder gepackte Images

Herstellerspezifische Container

Rückportierte Korrekturen

Gestrippte Binärdateien

Kein Quellcode, keine Laufzeit

Vorhandensein ist nicht Erreichbarkeit

Verschlüsselte oder gepackte Images

Herstellerspezifische Container

Rückportierte Korrekturen

Gestrippte Binärdateien

11. September 2026: Meldepflichten.

11. Dezember 2027: CE-Kennzeichnung.

Termin

NDA

Image

Report

Zwei Personen, ein Werkzeug

Zeigen Sie es mir.

Ein Firmware-Image rein.
Ein prüffähiger Befundbericht raus.