IoT - CRA-Compliance
Cyber Resilience Act und IoT-Sicherheit: Was Hersteller jetzt wissen müssen
CRA-Compliance für IoT-Geräte: Warum Abwarten keine Option ist
Von Jiannis Papadakis, Director of Solutions Engineering bei Keyfactor
Vor gut einem Jahr hat die EU mit dem Cyber Resilience Act (CRA) neue Maßstäbe für die Sicherheit vernetzter Produkte gesetzt.
Spätestens Ende 2027 müssen Hersteller ihre IoT-Geräte CRA-konform auf den Markt bringen – sonst dürfen sie in der EU nicht mehr verkauft werden. Was auf den ersten Blick nach einem großzügigen Übergangszeitraum klingt, ist in Wahrheit ein sehr enges Zeitfenster. Denn es geht nicht um kleine Anpassungen, sondern um einen grundlegenden Wandel in der Geräte-Authentifizierung.
Der neue CRA, er verbietet nicht nur schwache Passwörter. Er verbietet gemeinsam genutzte und fest codierte Anmeldedaten in der IoT-Geräteflotte. Das in der Firmware eingebettete Client-Geheimnis? Es ist nicht mehr Compliance-konform. Der API-Schlüssel, der jedem Gerät zugewiesen wird? Nicht mehr konform. Der JWT-Signaturschlüssel, der in der gesamten Produktlinie verwendet wird? Auch nicht mehr konform. Die neue Verordnung verlangt, dass jedes Gerät über eine eigene, kryptografisch sichere Identität verfügt; und dass die Eigentümer vom Hersteller in die Lage versetzt werden, ihre Anmeldedaten zu widerrufen, wenn ein Gerät kompromittiert worden ist.
Was sich mit dem CRA grundlegend ändert
Der Cyber Resilience Act verbietet nicht nur schwache Passwörter. Er geht deutlich weiter:
- Keine gemeinsam genutzten Zugangsdaten mehr
- Keine fest codierten Geheimnisse in der Firmware
- Keine statischen Schlüssel, die für eine gesamte Geräteflotte gelten
Das betrifft viele heute etablierte Verfahren. Was jahrelang als pragmatische Lösung galt, wird künftig zum Compliance-Risiko. Und die Konsequenzen sind ernst: Bei Verstößen drohen Strafen von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.
Viele IoT-Hersteller setzen heute auf bewährte Standards wie OAuth2, JWT oder API-Schlüssel. Doch genau hier liegt das Problem.
OAuth2 Client Credentials Flow
Das Gerät speichert eine client_id und ein client_secret, um ein Zugriffstoken zu erhalten. Diese Werte sind statisch – meist in die Firmware eingebrannt. Genau solche fest codierten Anmeldedaten untersagt der CRA.
JWT-Authentifizierung
Hier besitzt das Gerät einen privaten Signaturschlüssel, um Tokens zu erzeugen. Wird derselbe Schlüssel in einer gesamten Produktlinie verwendet, fehlt die eindeutige Identität pro Gerät – ebenfalls nicht CRA-konform.
API-Schlüssel und Personal Access Tokens
Per Definition statische Zeichenfolgen. In der Firmware hinterlegt. Nicht individuell. Nicht widerrufbar pro Gerät. Das Grundproblem bleibt immer gleich: Ein hart codiertes Geheimnis wird lediglich durch ein anderes hart codiertes Geheimnis ersetzt. Das ist keine Lösung – nur eine neue Verpackung desselben Risikos.
Der CRA fordert, dass:
- Jedes Gerät eine eigene, kryptografisch sichere Identität besitzt
- Eigentümer kompromittierte Anmeldedaten widerrufen können
- Keine geteilten Geheimnisse mehr existieren Damit rückt ein Verfahren in den Mittelpunkt, das in klassischen IT-Umgebungen längst etabliert ist: Mutual TLS mit X.509-Zertifikaten.
Warum mTLS mit X.509 der saubere Weg ist
Beim Mutual TLS (mTLS) erzeugt das Gerät sein eigenes Schlüsselpaar selbst – idealerweise innerhalb eines Hardware-Sicherheitsmoduls (HSM). Der private Schlüssel:
- verlässt das Gerät nie
- wird nicht übertragen
- ist nicht extrahierbar
Das Gerät sendet lediglich eine Zertifikatsanforderung mit dem öffentlichen Schlüssel an eine Zertifizierungsstelle. Nach der Signatur erhält es sein individuelles Zertifikat zurück.
Keine gemeinsamen Geheimnisse. Keine fest codierten Credentials. Keine sensiblen Daten im Provisioning-Prozess. Damit wird das sogenannte Bootstrap-Problem sauber gelöst – und gleichzeitig die Grundlage für echte Geräteidentität geschaffen.
Warum „bis 2027“ trügerisch klingt
Viele Verantwortliche denken: Wir haben noch Zeit. Doch ein Blick auf die Realität zeigt etwas anderes:
- Hardware-Designzyklen dauern 18–24 Monate
- Der Aufbau einer skalierbaren PKI-Infrastruktur braucht Planung
- Produktionsprozesse müssen Zertifikatsbereitstellung integrieren
- Backend-Systeme benötigen mTLS-Unterstützung
- Prozesse für Zertifikatsmanagement und Widerruf müssen etabliert werden
Wer 2027 compliant sein will, muss 2026 produktionsbereit sein. Wer 2026 produktionsbereit sein will, muss 2025 entwickelt haben. Und wer 2025 entwickeln will, muss jetzt beginnen.
Die Umstellung auf eine zertifikatsbasierte Identitätsarchitektur betrifft:
- Hardware-Engineering
- Firmware-Entwicklung
- Backend-Architektur
- Fertigungsprozesse
- Lifecycle-Management
Es geht nicht nur um Compliance. Es geht um Vertrauen, Produktsicherheit und Wettbewerbsfähigkeit auf dem europäischen Markt.
Fazit: Wer wartet, verliert
Der Cyber Resilience Act ist keine abstrakte Regulierung für die Zukunft – er ist eine konkrete Marktbarriere ab Ende 2027. IoT-Hersteller, die auch künftig in der EU verkaufen wollen, sollten noch in diesem Jahr mit der Umstellung auf mTLS/X.509 beginnen. Nicht, weil die Deadline naht. Sondern weil Architekturentscheidungen Zeit brauchen. Und weil Sicherheit heute kein Feature mehr ist – sondern eine Voraussetzung für Marktzugang.
