Das EU-Gesetz zur Cyberresilienz (CRA) verändert alles – und Ihr derzeitiger Ansatz wird wahrscheinlich nicht ausreichen.
Erinnern Sie sich noch daran, als „admin/admin” ein akzeptables Standardpasswort war?
Diese Zeiten sind nun offiziell vorbei.
Das EU-Gesetz zur Cyberresilienz (Cyber Resilience Act, CRA) trat im Dezember 2024 in Kraft. Wenn Sie IoT nach Europa versenden, ist dies keine Option, sondern gesetzlich vorgeschrieben.
Und hier ist, was die meisten Teams übersehen: Ihre OAuth2-Token, JWTs und API-Schlüssel werden wahrscheinlich nicht die Compliance-Anforderungen erfüllen.
Das Problem, über das niemand spricht
Die CRA verbietet nicht nur schwache Passwörter. Sie untersagt auch alle gemeinsam genutzten oder fest programmierten Anmeldedaten auf Ihren Geräten.
Das in Ihrer Firmware eingebettete Client-Geheimnis? Nicht konform.
Der API-Schlüssel, der jedem Gerät zugewiesen wird? Nicht konform.
Dieser JWT-Signaturschlüssel, der für Ihre gesamte Produktlinie verwendet wird? Nicht konform.
Die Verordnung schreibt vor, dass jedes Gerät über eine eigene, kryptografisch gesicherte Identität verfügen muss. Außerdem müssen Besitzer in der Lage sein, Zugangsdaten zu widerrufen, wenn ein Gerät kompromittiert wurde.
Verstöße werden mit Strafen von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Umsatzes geahndet.
Das Bootstrap-Authentifizierungsproblem
Was Befürworter von OAuth2 und JWT oft übersehen: Man benötigt zunächst einmal eine fest codierte Anmeldeinformation, um das Token zu erhalten.
Denken Sie darüber nach:
OAuth2-Client-Anmeldeinformationen-Ablauf erfordert, dass Ihr Gerät eine client_id und client_secret um einen Zugriffstoken anzufordern. Dabei handelt es sich um statische Werte, die in die Firmware eingebrannt sind – genau das, was die CRA verbietet.
Für die JWT-Authentifizierung muss das Gerät über einen privaten Signaturschlüssel verfügen, um Token zu generieren. Dieser Schlüssel muss auf irgendeine Weise bereitgestellt werden. Wenn es sich um denselben Schlüssel für Ihre gesamte Flotte handelt, haben Sie gegen die Anforderungen für eindeutige Geräte verstoßen. Wenn Sie eindeutige Schlüssel pro Gerät bereitstellen, herzlichen Glückwunsch – Sie bauen ohnehin eine PKI-Infrastruktur auf.
API-Schlüssel und PATs sind per Definition statische Zeichenfolgen, die in das Gerät eingebettet sind.
Die unangenehme Wahrheit? Diese Methoden ersetzen lediglich ein fest codiertes Geheimnis (ein Passwort) durch ein anderes fest codiertes Geheimnis (ein Client-Geheimnis, einen Signaturschlüssel oder ein Token). Sie haben das CRA-Compliance-Problem nicht gelöst, sondern lediglich umverpackt.
Warum mTLS grundlegend anders ist
Gegenseitiges TLS X.509-Zertifikaten löst das Bootstrap-Problem vollständig.
Hier ist der entscheidende Punkt: Der private Schlüssel kann auf dem Gerät selbst generiert werden und muss nirgendwo anders gespeichert werden.
Während der Herstellung generiert das Gerät intern sein eigenes Schlüsselpaar – idealerweise in einem hardware , aus dem der private Schlüssel buchstäblich nicht extrahiert werden kann. Das Gerät sendet nur eine Zertifikatssignierungsanforderung (mit dem öffentlichen Schlüssel) an Ihre Zertifizierungsstelle. Das signierte Zertifikat wird zurückgesendet. Fertig.
Keine gemeinsamen Geheimnisse. Keine fest programmierten Anmeldedaten. Keine Übertragung sensibler Daten während der Bereitstellung.
Vergleichen Sie das mit OAuth2, wo Ihr Client-Geheimnis serverseitig erstellt und dann irgendwie sicher auf jedes Gerät in Ihrer Flotte übertragen werden muss.
Was mTLS bietet:
✅ Jedes Gerät erhält ein einzigartiges Zertifikat mit einem eigenen Schlüsselpaar.
✅ Private Schlüssel verlassen niemals das Gerät – niemals.
✅ Keine fest programmierten Geheimnisse in der Firmware
✅ Individuelle Geräte-Sperrung über Zertifikatssperrlisten
✅ Gegenseitige Authentifizierung – Gerät überprüft Server, Server überprüft Gerät
AWS IoT , Azure IoT und Google Cloud IoT empfehlen aus genau diesen Gründen die X.509-Zertifikatsauthentifizierung.
Was dies für Ihre Roadmap bedeutet
Bis Dezember 2027 müssen Ihre Geräte konform sein. Das klingt noch weit entfernt, aber bedenken Sie Folgendes:
-
Hardware Entwicklungszyklen dauern 18 bis 24 Monate.
-
Der Aufbau einer PKI-Infrastruktur erfordert Zeit.
-
Die Fertigung benötigt die Integration der Zertifikatsbereitstellung.
-
Ihr Backend benötigt mTLS-Unterstützung.
Die Teams, die jetzt beginnen, werden einen Wettbewerbsvorteil haben. Die Teams, die warten, werden sich beeilen müssen, um Produkte, die nie dafür konzipiert wurden, nachträglich mit Sicherheitsfunktionen auszustatten.
Die Quintessenz
Die CRA fordert Sie nicht dazu auf, eine bessere fest codierte Anmeldeinformation zu wählen. Sie fordert Sie dazu auf, fest codierte Anmeldeinformationen vollständig zu entfernen.
OAuth2 und JWT wurden nicht für diese Welt entwickelt. Sie lösen Probleme der Benutzerauthentifizierung auf brillante Weise. Aber für die Geräteidentität gemäß den CRA-Anforderungen verlagern sie lediglich die Compliance-Verletzung von einem Ort zum anderen.
mTLS mit X.509-Zertifikaten unterscheidet sich in seiner Architektur. Es ist der einzige Ansatz, bei dem sensible Anmeldedaten niemals weitergegeben, übertragen oder fest codiert werden müssen.
Die Unternehmen, die diesen Unterschied jetzt verstehen, werden konforme Produkte entwickeln. Diejenigen, die dies nicht tun, werden nachrüsten müssen – oder aus dem EU-Markt ausscheiden.
Unabhängig davon, wo Sie sich auf Ihrem Weg zu mehr Sicherheit befinden, stehen Ihnen unsere Experten stehen Ihnen gerne zur Seite. Buchen Sieeine Demo und erzählen Sie uns mehr über Ihr Organisation und Ihre Ziele.
