CRA und Schnittstellen: USB, Ethernet, RJ45 absichern

Machen Schnittstellen ein Produkt CRA-pflichtig?

Die Frage taucht in der Praxis ständig auf: Fällt mein Gerät unter den Cyber Resilience Act, nur weil es eine USB-, Ethernet- oder RJ45-Schnittstelle hat? Die kurze Antwort: nicht die Buchse allein entscheidet — aber sie ist oft genau das Merkmal, das ein Produkt in den Anwendungsbereich zieht.

Den Anwendungsbereich definiert Artikel 2 Absatz 1 der EU-Verordnung 2024/2847: erfasst sind Produkte mit digitalen Elementen, die eine direkte oder indirekte, logische oder physische Datenverbindung zu einem Gerät oder Netz einschließen.¹ Eine Schnittstelle, über die Software, Firmware, Konfigurationen oder Nutzdaten fließen, ist genau eine solche Datenverbindung. Ein Gerät mit Ethernet-Port, das mit einem Netzwerk spricht, erfüllt dieses Kriterium. Ein Sensor mit serieller Schnittstelle, der Messwerte an eine Steuerung überträgt, ebenfalls.

Entscheidend ist also nicht das Vorhandensein der Buchse, sondern die Kombination aus digitalen Elementen und Datenverbindung. Sobald beides gegeben ist, greift der CRA — und dann werden die Schnittstellen selbst zum Prüfgegenstand.

Anhang I Teil I Nr. 6: Jede Schnittstelle ist Angriffsfläche

Der zentrale Hebel für Schnittstellen steht in Anhang I Teil I Nr. 6 CRA: Produkte müssen so gestaltet sein, dass die Angriffsfläche — einschließlich externer Schnittstellen — auf das für den Zweck notwendige Minimum reduziert wird.¹

Praktisch heißt das: Jede aktivierte Schnittstelle braucht einen dokumentierten Zweck. Was nicht gebraucht wird, muss deaktiviert oder entfernt werden. Ein Debug-USB-Port, der im Serienprodukt noch aktiv ist, ein ungenutzter Ethernet-Dienst, ein offener Telnet-Zugang auf einer RJ45-Buchse — das sind die typischen Befunde, die eine Marktaufsichtsbehörde bei einem Port-Scan sofort findet.

Vier Anforderungen aus Anhang I Teil I greifen bei jeder externen Schnittstelle zusammen:

• Nr. 2 — Sichere Standardkonfiguration: Beim Auslieferungszustand dürfen keine unnötigen Dienste und Schnittstellen aktiv sein.¹
• Nr. 3 — Zugriffskontrolle: Der Zugriff über die Schnittstelle muss durch Authentifizierung und Rechtemanagement gegen unbefugte Nutzung geschützt sein.¹
• Nr. 4 — Vertraulichkeit: Über die Schnittstelle übertragene Daten müssen bei der Übertragung geschützt werden — in der Regel durch Verschlüsselung.¹
• Nr. 6 — Angriffsfläche minimieren: Ungenutzte Ports und Schnittstellen sind zu schließen.¹

Diese vier Punkte sind kein Wunschkatalog, sondern grundlegende Cybersicherheitsanforderungen nach Anhang I. Wer sie nicht erfüllt, bringt kein konformes Produkt in Verkehr.

USB-Schnittstelle

USB ist der unterschätzte Angriffsvektor. Anders als Netzwerkschnittstellen wird USB oft als „nur lokal” abgetan — dabei ist ein USB-Port ein vollwertiger Datenkanal, über den Firmware eingespielt, Konfigurationen geändert und Daten ausgelesen werden können.

Für CRA-pflichtige Produkte mit USB-Schnittstelle sind drei Punkte relevant:

• Debug- und Service-Ports abschalten: JTAG, serielle Debug-Konsolen über USB und Bootloader-Zugänge dürfen im Serienzustand nicht offen zugänglich sein. Sie gehören zur Angriffsfläche nach Nr. 6.
• USB-Firmware-Update signieren: Wird Firmware über USB eingespielt, muss ihre Integrität geschützt sein (Anhang I Teil I Nr. 5). Unsignierte USB-Updates erfüllen diese Anforderung nicht.¹
• Datenzugriff kontrollieren: Ein USB-Massenspeicher-Modus, der ohne Authentifizierung Zugriff auf interne Daten gibt, verstößt gegen Nr. 3.

Bei industriellen Steuerungen und Messgeräten ist der USB-Serviceport der klassische Schwachpunkt — praktisch zum Warten, riskant im Feld.

Ethernet und RJ45

Die Ethernet- beziehungsweise RJ45-Schnittstelle ist ein Netzzugang und damit die am stärksten regulierte Schnittstellenklasse. Hier greifen alle vier genannten Anforderungen unmittelbar.

Was in der Praxis geprüft wird:

• Offene Ports: Ein Netzwerk-Port-Scan zeigt sofort, welche Dienste über die RJ45-Buchse erreichbar sind. Jeder offene Port ohne dokumentierten Zweck ist ein Befund gegen Nr. 6.
• Klartext-Protokolle: Telnet, HTTP ohne TLS, unverschlüsseltes Modbus/TCP oder FTP verletzen die Vertraulichkeitsanforderung aus Nr. 4. Für die Konfigurationsoberfläche eines vernetzten Geräts ist HTTPS heute Mindeststandard.
• Standardpasswörter: Ein über Ethernet erreichbares Web-Interface mit einheitlichem Werkspasswort für alle Geräte verstößt gegen Nr. 2 und Nr. 3. Der CRA verbietet identische Default-Zugangsdaten faktisch.
• Netzwerk-Stack-Härtung: Auch der IP-Stack selbst gehört zur Angriffsfläche. Nicht benötigte Protokolle (etwa UPnP, mDNS) sollten abschaltbar oder standardmäßig aus sein.

Eine physisch vorhandene, aber ungenutzte RJ45-Buchse ist übrigens nicht automatisch unkritisch: Solange dahinter ein aktiver Netzwerk-Stack läuft, zählt sie zur Angriffsfläche.

Serielle Schnittstellen (RS-232/RS-485)

Serielle Schnittstellen wirken harmlos, weil sie kein IP sprechen — sie sind es aber nicht. Über RS-232 oder RS-485 laufen in der Industrie Feldbus-Protokolle wie Modbus RTU, die häufig ohne jede Authentifizierung arbeiten.

Für den CRA gilt auch hier: Ist die serielle Schnittstelle ein Datenkanal des Produkts, gehört sie zur Angriffsfläche und muss auf ihren dokumentierten Zweck begrenzt sein (Nr. 6). Wo ein serieller Wartungszugang unauthentifizierten Vollzugriff auf die Gerätekonfiguration erlaubt, ist das ein Verstoß gegen die Zugriffskontrolle nach Nr. 3 — unabhängig davon, dass die Schnittstelle physischen Zugang voraussetzt.

Funkschnittstellen

WLAN, Bluetooth, Zigbee, Mobilfunk und andere Funkschnittstellen sind ebenfalls externe Schnittstellen im Sinne von Anhang I — mit der Besonderheit, dass hier zusätzlich die Funkanlagenrichtlinie (RED) und ihre delegierte Verordnung 2022/30 greifen. Für Produkte mit Funkschnittstellen ist die Abgrenzung zwischen RED und CRA eigenständig zu klären.

Details dazu im Artikel CRA und RED: Funkanlagen und der Übergang.

Checkliste: Schnittstellen CRA-konform gestalten

1. Inventar: Alle physischen und logischen Schnittstellen des Produkts auflisten — USB, Ethernet/RJ45, seriell, Funk, Debug-Ports.
2. Zweck dokumentieren: Für jede aktivierte Schnittstelle den Nutzungszweck festhalten. Ohne Zweck: deaktivieren oder entfernen.
3. Port-Scan: Auslieferungszustand scannen. Jeder offene Port muss erklärbar sein.
4. Verschlüsselung: Klartext-Protokolle durch TLS-gesicherte Varianten ersetzen.
5. Authentifizierung: Keine einheitlichen Werkspasswörter, erzwungene Änderung bei Erstinbetriebnahme.
6. Debug abschalten: JTAG, serielle Konsolen und Bootloader-Zugänge im Serienprodukt sperren.
7. Firmware signieren: Updates über jede Schnittstelle kryptographisch absichern.

Welche dieser Punkte für Ihr Produkt Pflicht sind, hängt von seiner Risikoklasse ab. Der kostenlose CRA-Check ermittelt Ihre Klasse und das anwendbare Konformitätsbewertungsverfahren. Die vollständige Liste der Sicherheitsanforderungen finden Sie im Artikel Anhang I: die 13 Sicherheitsanforderungen.

Quellen

1. EU-Verordnung 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 (Cyber Resilience Act), Artikel 2, Artikel 13, Anhang I Teil I: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
2. BSI — Cyber Resilience Act, technische Anforderungen: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/
3. Delegierte Verordnung (EU) 2022/30 zur Funkanlagenrichtlinie 2014/53/EU: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022R0030