Wie man EN 18031 Beweise nach Firmware-Updates gültig hält

Firmware Version 2.4 löscht nicht automatisch die EN 18031 Arbeit, die für Version 2.3 abgeschlossen wurde. aber es schafft eine schwierigere Frage: Welche Schlussfolgerungen beschreiben noch das Produkt, das jetzt versendet oder aktualisiert wird?

Release-Notizen können das nicht allein beantworten. Sie beschreiben Änderungen am Code. EN 18031 evidence unterstützt Schlussfolgerungen über die Vermögenswerte, Schnittstellen, Datenströme, Zugriffskontrollen, Aktualisierungsmechanismen, Abhängigkeiten und getestetes Verhalten. Ein kleiner Patch kann einen kritischen Sicherheitsanspruch beeinflussen, während ein großer interner Refaktor diesen Anspruch unangetastet lassen kann.

Die nützliche Arbeitseinheit ist daher ein Beweisdelta: ein versionierter Datensatz dessen, was sich geändert hat, die bestehenden Schlussfolgerungen auf die geänderten Fakten beruhen und welche Beweise beibehalten, ergänzen, ersetzen oder eskalieren müssen. „Beweisdelta“ ist kein Begriff, der in der Funkausrüstungsrichtlinie oder der EN 18031 verwendet wird. Es ist ein praktischer Weg, ihre Erwartungen an die Änderung der Kontrolle in eine wiederholbare Freigabeentscheidung zu verwandeln. Der Begriff bietet eine Kurzform zur Umwandlung von RED und EN 18031 in eine wiederholbare Release-Entscheidung.

Beweise erlischen, wenn sich ihre Assumptionen ändern

RED macht Produktwechselkontrolle Teil der Konformität. Artikel 21 Absatz 2 von Richtlinie 2014/53/EU fordert die Erstellung technischer Unterlagen vor dem Inverkehrbringen von Funkgeräten und die "kontinuierliche Aktualisierung". Artikel 10 Absatz 5 verpflichtet die Hersteller, Änderungen des Produktdesigns oder der Merkmale während der Produktionsserien zu berücksichtigen. Anhang V erfordert auch, dass relevante Software- oder Firmware-Versionen identifiziert werden, wenn sie Konformität beeinträchtigen.

Die gesetzliche Verpflichtung ist die Konformität mit den anwendbaren RED-wesentlichen Anforderungen. EN 18031 ist ein freiwilliger harmonisierter Standard, den Hersteller verwenden können, um eine Konformitätsvermutung zu unterstützen vorbehaltlich der Einschränkungen in seinem Amtsblatt. Diese Unterscheidung spielt eine Rolle, wenn eine Änderung die Abdeckungsstandards oder den Konformitätsbewertungsweg beeinflusst.

Die Europäische Kommission sagt dies im RED-Leitfaden ausdrücklich im Abschnitt „Serienproduktion“. Sie fordert die Hersteller auf, Hardware- und Softwareänderungen, Entwicklungen in den geltenden Normen und der Gesetzgebung sowie den Stand der Technik zu überwachen und ihre Überlegungen in der technischen Dokumentation festzuhalten. Sie bestätigt auch, dass der Hersteller weiterhin verantwortlich bleibt für die Bewertung der Funkanlagen zusammen mit der eingebetteten Software. 

Jede EN 18031 Schlussfolgerung beruht auf Produktfakten; eine Zugriffskontrolle kann davon ausgehen, dass nur lokale Verwalter eine Einstellung ändern können. Ein sicherer Kommunikationstest kann auf eine bestimmte kryptographische Bibliothek und Konfiguration zurückgreifen. Eine Prüfung des Update-Mechanismus kann auf den Bootloader, der Schlüsselbasieren Rollback steuert und Lieferpfad. Wenn sich einer dieser Fakten ändert, muss der von ihm abhängige Beweis überprüft werden.

Beginnen Sie mit einer definierten Produktbaseline. Dies sollte Produkttyp und Hardware-Revision, Firmware-Build, Bootloader, aktivierte Schnittstellen, Funkkonfiguration, begleitende Applikation und Backend-Versionen, sofern relevant, Sicherheitskomponenten von Drittanbietern, Verwendungszwecken, Benutzerrollen, Datenkategorien und Konformitätsroute. Ein Produktname allein ist keine Baseline. Zwei Varianten, die unter dem gleichen Namen verkauft werden, können unterschiedliche Schnittstellen aufdecken oder verschiedene Funktionen ermöglichen. Viele häufige EN 18031 Lücken vor dem Start beginnen damit, dass diese Grenze zu eng um das Gerät gezogen wird.

Die Grundlinie sollte auch die für die Konformität von Forderungen verwendeten genauen harmonisierten Standard- und Amtsblattbedingungen festlegen. EN 18031-1, EN 18031-2 und EN 18031-3 wurden unter RED durch Commission Implementing Decision (EU) 2025/138, zitiert mit Einschränkungen. Eine Änderung, die das Verhalten des Passworts beeinflusst, Die elterliche Zugangskontrolle oder sichere Updates in zahlungsfähigen Geräten können daher mehr als ein Testergebnis beeinflussen. Es kann sich darauf auswirken, ob der gewählte Konformitätsweg noch funktioniert. Für internetverbundene Produkte bietet QIMAs EN 18031-1 Übersicht zusätzliche Kontexte zu Produktgrenzen und technischen Dateien.

Baue ein Evidence Delta für jede Firmware-Veröffentlichung

Stellen Sie die Beweisprüfung zwischen dem Satz der technischen Veränderung und der endgültigen Freigabe der Genehmigung vor. Bis dahin weiß das Team, was sich geändert hat, aber es ist noch Zeit die Dokumentation zu aktualisieren, Führen Sie fokussierte Tests durch oder beteiligen Sie sich an einem Konformitätsspezialisten, bevor der Build Produktions- oder eingesetzte Geräte erreicht.

Die Überprüfung sollte die Änderung durch das Produkt verfolgen, anstatt die Veröffentlichung als „Minderheit“ oder „Mehr“ einzustufen. Die folgenden Beispiele zeigen, wohin diese Spur normalerweise führt.

Jeder betroffene Artikel erhält dann eine von vier Dispositionen.

Verwenden Sie ein Beweisdelta für jede veröffentlichte Konfiguration. Es sollte aufzeichnen:

1. Die Firmware Build und betroffene Produkt- oder Hardware-Varianten.

2. Die Funktionen, Komponenten, Schnittstellen und Annahmen die sich geändert haben.

3. Die Schlussfolgerungen EN 18031 und die von diesen Änderungen betroffenen technischen Dateien sind betroffen.

4. Die Disposition von jedem vorhandenen Beweisstück: beibehalten, ergänzt, ersetzt oder eskaliert.

5. Neue Tests, Verwundbarkeitsentscheidungen, Lieferanteneingaben und Beweisreferenzen.

6. Der Überprüfer, Genehmigungsdatum und endgültige Freigabeentscheidung.

Diese Felder machen aus einer Diskussion mit Wechselwirkungen einen Datensatz, den eine andere Person später rekonstruieren kann.

Eine erhaltene Entscheidung ist immer noch ein Beweis. Sie sollte mit dem früheren Artefakt verknüpft und erklären, warum seine Annahmen wahr bleiben. Ein Kontrollkästchen mit „ohne Effekt“ ohne Begründung wird schwierig sein, Monate späterzu verteidigen, vor allem nachdem die beteiligten Personen zu einem anderen Projekt gegangen sind.

Änderungsgröße ist ein schlechter Proxy für Beweisfolgen

Betrachten Sie einen verbundenen Build-Controller. Firmware 2.3.1 aktualisiert seine TLS-Bibliothek, um die Verwundbarkeit zu korrigieren. Die unterstützten Protokolle, Schlüsselverwaltung, Datenfluss, externe Schnittstellen und Updatepfade bleiben unverändert. Das Team muss möglicherweise nur die Komponenten- und Verwundbarkeitsdatensätze aktualisieren, die neue Build-Identifikation bewahren, die konfigurierte Kryptographie überprüfen und fokussierte Regressionstests durchführen. Die Architektur und die Zugriffskontrolle können auch weiterhin anwendbar sein, wenn der Abschluss dokumentiert ist und die eigentliche Integration dies unterstützt.

Firmware 3.0 fügt dann Remote-Administration durch eine neue Cloud-API hinzu. Diese Änderung öffnet die Produktgrenze, das Datenflussdiagramm, das Inventar externer Schnittstellen, Bedrohungsszenarien, Administratorrollen, Authentifizierung, Protokollierung, Backend-Abhängigkeit und möglicherweise die Beurteilung persönlicher Daten. Die Notwendigkeit neuer Beweise ergibt sich aus der veränderten Exposition, nicht aus der großen Versionsnummer.

Die Anleitung der Europäischen Kommission vom Juli 2026 zum Cyber-Widerstandsgesetz folgt der gleichen risikobasierten Logik für substanzielle Änderungen. Sie lenkt die Hersteller zu prüfen, ob ein Software-Update neue Bedrohungsvektoren oder Angriffssszenarien einführt oder die Wahrscheinlichkeit oder Wirkung bestehender verändert. Es erklärt auch, dass eine Sicherheitsaktualisierung im Allgemeinen nicht wesentlich ist, wenn sie den beabsichtigten Zweck unverändert lässt und kein neues Cybersicherheitsrisiko einführt, auch wenn die technische Änderung signifikant ist.

Das sind CRA-Überlegungen, kein Ersatz für eine EN 18031-Prüfung im Rahmen des RED. Sie sind jetzt nützlich, weil sie zeigen, warum Labels wie „Sicherheitspatch“, „Feature-Release“ oder „Minor Update“ nicht ausreichen. Der Produkteffekt muss geprüft werden.

Behalte die alten Beweise anstatt sie zu überschreiben

Technische Dokumentation sollte aktuell bleiben, aber „aktuell“ bedeutet nicht, dass der vorherige Datensatz verschwinden sollte. RED verpflichtet die Hersteller, die technische Dokumentation und die EU-Konformitätserklärung zehn Jahre nach dem Inverkehrbringen der Funkgeräte beizubehalten. Verbleibt ein Produkt in Serie über mehrere Firmware-Releases, der Hersteller eventuell neu konstruieren muss, welche Konfiguration eine bestimmte Produktionsmenge oder eine bestimmte Einheit unterstützte.

Verwalten Sie einen Versionsverwalter, der jede Firmware-Version mit den anwendbaren Modellen und Hardware-Revisionen, Produktions- oder Serienbereichen verbindet, Feld-Rollout-Bevölkerung, Beweisdelta, Dokumentenversionen und Testergebnisse, Genehmigungen und jegliche Mitteilungsmitteilung. Die Rollout- und Rollback-Rekorde sollten bei einem Over-the-Air-Update ebenfalls beibehalten werden. Dies schafft eine Zeitachse dessen, was beurteilt wurde, was sich geändert hat und welche Beweise jede Entscheidung unterstützten.

Keine einzelne Datei mit dem Namen EN18031_Assessment_Final bearbeiten. Werden alte Annahmen stillschweigend ersetzt, kann die Datei das neueste Build beschreiben, ohne einen zuverlässigen Datensatz für frühere Einheiten zu hinterlassen. Die Release-Notizen sind kein Ersatz dafür, sondern zeigen auf, was die Technik verändert hat, aber nicht, warum eine frühere Konformitätsentscheidung noch immer besteht.

Dasselbe gilt für Lieferantenbeweise: Ein neuer Bibliotheksbericht, Moduldeklaration oder Sicherheitsdatenblatt belegt nicht automatisch, dass das Endprodukt abgedeckt bleibt. Der Hersteller muss noch die genaue Version und die verwendete Konfiguration identifizieren Prüfen Sie die Annahmen, die für das Produkt wichtig sind, und verbinden Sie das Lieferantenmaterial mit den Nachweisen auf der Produktebene.

Benutzen Sie den RED Record, um sich auf das CRA Sicherheitsmanagement vorzubereiten

Diese Release-Historie hat einen unmittelbaren Wert über die nächste RED-Rezension hinaus: Die delegierte Verordnung RED Cybersecurity bleibt bis zum 10. Dezember 2027 anwendbar. delegierte Verordnung (EU) 2026/339 hebt sie ab dem 11. Dezember 2027 auf, wenn die wichtigsten CRA-Verpflichtungen gelten. QIMAs breitere CRA Übersicht erklärt seine Beziehung zu RED und anderen EU-Regeln.

CRA-Meldepflichten sind bereits in Kraft. Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle melden, die In-scope Produktebetreffen. Die Kommission offizielle Berichterstattung legt eine 24-Stunden Frühwarnfrist und eine 72-Stunden-Frist für die vollständige Benachrichtigung fest. In der Anwendungshinweise vom Juli 2026 heißt es außerdem, dass die Meldepflicht inscope Produkte abdeckt, die vor dem Hauptanwendungsdatum der CRA in Verkehr gebracht werden.

Ein versionsspezifischer Beweisspur gibt dem Verwundbarkeitsteam einen Kopf-Start. Es zeigt an, welche veröffentlichten Builds eine betroffene Komponente enthalten, wie diese Komponente konfiguriert ist, welche Schnittstellen sie exponieren und welche Geräte die entsprechende Firmware erhalten haben. Es entscheidet sich nicht, ob ein Ereignis gemeldet werden kann, aber es verkürzt die Zeit, das Produkt zu rekonstruieren, während die Reportinguhr läuft.

Der CRA-Leitfaden vom Juli 2026 weist auch auf ereignisorientierte Tests hin. Hersteller sollten prüfen, ob neue Bedrohungen, Verwundbarkeiten oder Produktänderungen den Test erfordern, um sich zu ändern, und dann die entsprechenden Tests durchführen. Es verlangt nicht die mechanische Wiederholung einer unveränderten Testkampagne in festen Zeitabständen. Die gleiche Anleitung erlaubt die Wiederverwendung bestehender Dokumentations- und Testergebnisse für nicht betroffene Teile eines wesentlich modifizierten Produkts. Das ist der längerfristige Wert eines Beweisdeltas: Es bewahrt die Wiederverwendung, ohne dass alte Beweise vom Produkt abweichen dürfen.

Für einen strukturierten Startpunkt verwenden Sie QIMAs RED und CRA Readiness Workbook für angeschlossene Produkte um den Produktbereich abzugrenzen, EN 18031 Beweise, Lieferantenlücken, Verwundbarkeitsberichte und ein 30-tägiger Aktionsplan.

Bei Veröffentlichungsüberprüfung ersetzen Sie die Frage „Ist das Dokument EN 18031 aktualisiert worden? mit „Welche Schlussfolgerungen zur Einhaltung der Vorschriften haben sich geändert, und wo ist der Beweis für diese Entscheidung?“

Cyberexperts produktspezifische Anforderungskarte, Beweis-Checkliste und Schwachstellen-Management-Workspace geben Produkt, B. Firmware, QA und Compliance-Teams einen gemeinsamen Ort, um Anforderungen, Risiken, Beweisinhaber zu verbinden und Änderungen freizugeben. Cyberexpert unterstützt die Bereitschafts- und Beweisvorbereitung. Es zertifiziert das Produkt nicht, und die Verantwortung für die Konformität bleibt beim Hersteller. Scope your connected product for free to identify which EN 18031 evidence your next firmware release should reopenen.