September 2025

EU RED DA:
Vorbereitung auf den Cyber Resilience Act

Seit dem 01.08.25 ist der EU Radio Equipment Directive Delegated Act, kurz RED DA, in Kraft. Was unterscheidet RED DA vom CRA, schließlich haben beide Regelungen die Cybersecurity im Blick?

Dazu SSV CEO Klaus-Dieter Walter:

In meinen letzten drei Posts (siehe 👉 RED DA Teil 1, 👉 RED DA Teil 2, 👉 RED DA Teil 3 und 👉 RED DA Teil 4) habe ich u. a. versucht zu klären, wer von der RED DA überhaupt betroffen ist.

Ab dem 11. Dezember 2027 dürfen in der EU nur noch Produkte mit digitalen Elementen ein CE-Kennzeichen erhalten, wenn sie auch die Anforderungen des CRA erfüllen.

Anders als bei RED DA (hier kann man die Cybersecurity ja noch nachträglich an das Produkt „dranschrauben“) erfordert der CRA ein „Security by Design“.

Mit anderen Worten: Die Cybersicherheit eines Produkts muss bereits von Beginn an in den Entwicklungsprozess integriert werden. Des Weiteren muss diese Sicherheit über den gesamten Lebenszyklus sichergestellt werden, um die CRA-Compliance zu gewährleisten.

Wenn man sich bei der Umsetzung der EN 18031-1-Compliance für eine Funkanlage mit dem GEC-1-Mechanismus (GEC = General Equipment Capabilities) auseinandersetzt und die Anforderung „Die Anlage darf keine öffentlichen bekannten ausnutzbaren Schwachstellen aufweisen!“ umsetzt, wird man i. d. R. einen CVE-Management-Prozess realisieren. CVE steht für Common Vulnerabilities and Exposures.

Solche CVEs sind in praktisch jedem Softwarestack vorhanden. Um sie zu finden, wird zunächst eine SBOM (Software Bill of Materials, automatisch erzeugte Beschreibung zum Softwarestack in einem maschinenlesbaren Format, z. B. CycloneDX oder SPDX) erstellt und dann mit Hilfe eines Security Scanners gegen eine CVE-Datenbank geprüft.

Der erste Scanner-Output ist oft sehr frustrierend: Je nach Softwarestack, Security Scanner und der möglichen Parameter bei der Nutzung können da schon mal Listen mit tausenden CVEs entstehen (z. B. für Embedded-Linux-Systeme). Nach effektivem Feintuning und einigen Iterationen wird das Ergebnis meist übersichtlicher.

Die verbleibenden CVEs werden dann manuell bewertet. Dabei ist zu klären, ob sie evtl. unter die Ausnahmen der GEC-1 fallen und bzgl. der jeweiligen Funkanlage zum Betrachtungszeitpunkt eigentlich kein ausnutzbares Risiko darstellen.

Eventuell sind aber auch einige Software-Patches und weitere erneute Durchläufe der vollständigen Prozessschleife „SBOM erstellen > scannen > individuelle Schwachstellenbehandlung“ nötig.

Abschließend wird alles dokumentiert. Dabei ist zu berücksichtigen, dass eine CVE-Datenbank im Internet „lebt“, da laufend neue CVEs hinzukommen. So können auch für eine bereits gescannte SBOM immer wieder neue Risiken auftauchen.

Wenn Sie ein CVE-Management erfolgreich in Ihren Entwicklungsprozess integrieren und die Schwachstellen während des gesamten Produktlebenszyklus permanent identifizieren, bewerten und beheben, haben Sie einen ersten großen Schritt in Richtung CRA vollzogen!

 

 

Zurück zur Übersicht