Was heißt sicher laut CRA? Fünf Fragen an Ihr Produkt ab Werk

CRA-Journey, Teil 2 von 4 · Lesezeit ca. 8 Minuten

Stellen Sie sich vor, Ihr Produkt kommt beim Kunden an. Jemand installiert es, startet es zum ersten Mal und meldet sich an. Mit welchem Konto? Mit welchem Passwort? Und welche Schnittstellen sind in diesem Moment schon offen?

Genau diesen Moment trifft Anhang I des Cyber Resilience Act (CRA). Er beschreibt unter anderem, wie ein Produkt beschaffen sein muss, bevor der Kunde irgendetwas eingestellt hat.

In Teil 1 ging es um die Frage, ob der CRA Sie überhaupt betrifft. Wer dort bei „betroffen“ gelandet ist, fragt jetzt: Was heißt „sicher“ laut Gesetz eigentlich konkret? Anhang I ist überraschend handfest. Und ein Punkt darin nennt Identitäts- oder Zugangsverwaltungssysteme ausdrücklich beim Namen.

Mit den fünf Fragen in diesem Beitrag prüfen Sie, wo Ihr Produkt im Auslieferungszustand steht, und finden die Stellen, die in Ihrer Risikobewertung noch fehlen.

Die fünf Fragen auf einen Blick

Hier sind die Fragen vorab. Die Abschnitte darunter erklären jede einzeln, am Ende steht, wie Sie Ihre Antworten auswerten. Die Fragen ersetzen keine Rechtsberatung, zeigen aber schnell, wo Sie stehen.

Erstanmeldung: Mit welchem Konto und welchem Passwort startet Ihr Produkt beim Kunden?
Voreinstellungen: Ist jede Einstellung ab Werk die sichere Variante, und kann der Kunde auf diesen Zustand zurücksetzen?
Zugang: Womit schützt Ihr Produkt den Zugang, und wer erfährt von verdächtigen Zugriffsversuchen?
Offene Türen: Welche Schnittstellen und Dienste sind ab Werk aktiv, und braucht der Kunde jede davon?
Spur: Zeichnet Ihr Produkt auf, wer auf Daten, Dienste und Funktionen zugreift oder sie ändert?

Skizze: fünf Fragen ab Werk mit den Buchstaben aus Anhang I

Wie Anhang I gebaut ist

Anhang I hat zwei Teile. Teil I beschreibt Eigenschaften des Produkts: wie es ausgeliefert wird und was es können muss. Teil II beschreibt, wie der Hersteller danach mit Schwachstellen umgeht.

Teil I beginnt mit einem Grundsatz. Produkte sollen ein Cybersicherheitsniveau bieten, das ihren Risiken angemessen ist. Danach folgen unter Nummer 2 dreizehn Anforderungen, die Buchstaben a bis m.

Wichtig ist, wie die Buchstaben gelten. Nicht jeder greift für jedes Produkt in gleicher Weise. Der Hersteller hält in seiner Risikobewertung fest, ob und wie die Anforderungen aus Teil I Nummer 2 anwendbar sind (Art. 13 Abs. 3). Greift eine nicht, begründet er das in der technischen Dokumentation (Art. 13 Abs. 4).

Anhang I gilt mit der Verordnung insgesamt ab dem 11. Dezember 2027 (Art. 71 Abs. 2). Das klingt weit weg. Ein Produkt, das ab dann in Verkehr gebracht wird, entsteht aber heute.

Ich greife fünf Buchstaben heraus, die den Auslieferungszustand und den Zugang betreffen. Die Zitate aus der Verordnung stammen aus der amtlichen deutschen Fassung. Die Leitlinien zitiere ich auf Englisch.

Frage 1, Erstanmeldung: das erste Konto

Das Wort Standardpasswort kommt in Anhang I nicht vor. Zwei Buchstaben treffen den Moment der ersten Anmeldung trotzdem direkt.

Buchstabe b verlangt eine sichere Standardkonfiguration. Buchstabe d verlangt Schutz vor unbefugtem Zugriff durch geeignete Kontrollmechanismen. Beides erkläre ich in den Fragen 2 und 3 genauer.

Nach meiner Auslegung ist ein Konto, dessen Zugangsdaten für alle Exemplare gleich und bekannt sind und das beim ersten Start nicht geändert werden muss, mit beiden Anforderungen schwer vereinbar. Es ist ab Werk nicht sicher konfiguriert, und ein Schutz, den jeder kennt, ist in meinen Augen keiner.

Was die Kommission vom nachträglichen Härten hält, zeigen ihre Leitlinien zum CRA (C(2026) 5252, Juli 2026, nicht bindend).

Ein Sicherheitsupdate, das bestehende Einstellungen verschärft, etwa die Regeln für das Standard-Administratorpasswort ändert oder eine schon angelegte Mehrfaktor-Authentifizierung (MFA) verpflichtend macht, gilt dort nicht als wesentliche Änderung des Produkts (Beispiel 47).

Nachträgliches Härten löst also nicht automatisch eine neue Konformitätsbewertung aus. Besser ist, es gar nicht erst nachholen zu müssen.

Frage 2, Voreinstellungen: sicher ab Werk, mit Weg zurück

Buchstabe b im Wortlaut:

„mit einer sicheren Standardkonfiguration auf dem Markt bereitgestellt werden, sofern zwischen dem Hersteller und dem gewerblichen Nutzer in Bezug auf ein maßgeschneidertes Produkt mit digitalen Elementen nichts anderes vereinbart wurde, und die Möglichkeit bieten, das Produkt in seinen ursprünglichen Zustand zurückzusetzen“

Darin stecken zwei Pflichten. Die erste betrifft den Zustand bei Auslieferung. Die zweite betrifft den Weg zurück dorthin.

Die Leitlinien nennen Buchstabe b nicht ausdrücklich. In einem Beispiel zu Produkten, die mit älteren Systemen zusammenarbeiten müssen (Beispiel 10), erwarten sie aber: Kann ein Produkt ein sicheres und ein weniger sicheres Protokoll, baut der Hersteller das sichere ein und aktiviert es „by default“. Das weniger sichere bleibt nur erlaubt, wo die Zusammenarbeit es verlangt.

Nach meiner Lesart ist das genau der Gedanke von Buchstabe b.

Die Ausnahme für Maßanfertigungen ist eng. Sie gilt nach dem Wortlaut nur für ein maßgeschneidertes Produkt und nur mit einem gewerblichen Kunden, und sie muss vereinbart sein. Ein Standardprodukt mit offener Grundeinstellung fällt nicht darunter.

Der Weg zurück wird leicht übersehen. Kann der Kunde sein Produkt auf den Auslieferungszustand zurücksetzen, muss dieser Zustand nach meiner Lesart selbst sicher sein. Sonst würde Buchstabe b sich selbst aufheben, und das Zurücksetzen setzte die Lücke wieder ein.

Frage 3, Zugang: verhindern und melden

Buchstabe d im Wortlaut:

„durch geeignete Kontrollmechanismen Schutz vor unbefugtem Zugriff bieten, darunter u. a. zumindest Authentifizierungs-, Identitäts- oder Zugangsverwaltungssysteme, und einen möglicherweise unbefugten Zugriff melden“

Auch hier stecken zwei Pflichten in einem Satz: verhindern und melden. Den ersten Teil kennen die meisten Produkte: Anmeldung, Rollen, vielleicht eine Sperre nach Fehlversuchen. Ob ein abgewehrter Versuch irgendwo sichtbar wird, ist eine andere Frage.

Wem gemeldet wird und in welcher Form, lässt der Wortlaut offen. Ob ein Protokolleintrag reicht oder eine aktive Meldung nötig ist, sagt der Text nicht. Ich lese es so: Ein Produkt, das einen Angriff still abwehrt und nirgends festhält, erfüllt den zweiten Teil von Buchstabe d nicht.

Beim IDM-Portal aus Teil 1 lief es so: Das Dienstkonto, mit dem das Portal im Active Directory arbeitete, war vorher festgelegt. Seine Berechtigungen bekam es nach und nach, jeweils für die Organisationseinheiten (OUs), die es verwalten sollte. Festgehalten wurde, was das Portal tat, über seine Reports.

Für mich zeigt das: Zugangskontrolle betrifft nicht nur die Menschen, die sich an einem Produkt anmelden. Sie betrifft auch das Konto, mit dem das Produkt selbst arbeitet.

Frage 4, offene Türen: Angriffsfläche begrenzen

Buchstabe j verlangt, dass ein Produkt so konzipiert, entwickelt und hergestellt wird, dass es „möglichst geringe Angriffsflächen“ bietet, und zwar „auch bei externen Schnittstellen“.

Nach meiner Auslegung gehört dazu alles, was ab Werk von außen erreichbar ist: Dienste, Ports, Programmierschnittstellen, Wartungszugänge. Jede davon ist eine Tür. Die Frage ist nicht, ob es Türen gibt, sondern ob der Kunde jede davon braucht.

Eine Tür, die erst geöffnet wird, wenn der Kunde sie braucht, ist kleiner als eine, die ab Werk offen steht und später geschlossen werden soll.

Frage 5, Spur: aufzeichnen, wer zugreift

Buchstabe l im Wortlaut:

„sicherheitsbezogene Informationen durch Aufzeichnung und/oder Überwachung einschlägiger interner Vorgänge wie Zugang zu Daten, Diensten oder Funktionen und Änderungen daran bereitstellen und den Nutzern einen Opt-out-Mechanismus zur Verfügung stellen“

Hier trifft der CRA auf eine Frage, die aus Prüfungen nach der NIS2-Richtlinie (Richtlinie (EU) 2022/2555) bekannt ist: Wer hat wann was geändert? Der Unterschied ist die Blickrichtung. Der CRA verlangt die Spur vom Produkt, nicht vom Betreiber.

Die Möglichkeit, das abzuwählen (Opt-out), gehört zum Wortlaut. Die Spur ist also die Grundeinstellung, das Abwählen die bewusste Entscheidung des Nutzers.

Wo der CRA Identitäts- und Zugriffsmanagement beim Namen nennt

Für mich als jemand, der aus dem Identitäts- und Zugriffsmanagement (IAM) kommt, ist Buchstabe d der Kern dieses Teils. Der Gesetzestext nennt „Identitäts- oder Zugangsverwaltungssysteme“ ausdrücklich als Mittel gegen unbefugten Zugriff.

In Teil 1 stand IAM schon einmal ganz oben: Identitätsmanagementsysteme sind die erste Kategorie der wichtigen Produkte in Anhang III. Hersteller, deren Produkt Identitätsmanagement als Kernfunktion hat, sind damit doppelt betroffen. Ihr Produkt ist ein wichtiges Produkt, und es ist zugleich das Werkzeug, mit dem andere Hersteller Buchstabe d erfüllen.

Die Leitlinien ziehen den Bogen in die Cloud. Unter den Funktionen, deren Verarbeitung aus der Ferne zum Produkt gehören kann, nennen sie ausdrücklich „identity and access management“ (Rn. 190).

Und weiter: Ein Authentifizierungsportal, das Zugangsdaten oder Tokens ausgibt, die das Produkt zum Funktionieren braucht, kann als Teil dieser Datenfernverarbeitung gelten, sofern auch die übrigen Merkmale der Definition erfüllt sind, vor allem: Der Hersteller hat es entwickelt oder verantwortet es (Rn. 194).

Für ein Softwarehaus heißt das nach meiner Lesart: Wer die Anmeldung seines Produkts über einen eigenen Clouddienst abwickelt, ohne den das Produkt nicht nutzbar ist, hat diesen Dienst mit in der Risikobewertung.

Ein weiteres Beispiel der Leitlinien zeigt, wie empfindlich der Zugang ist. Ein Update ergänzt eine Funktion „Angemeldet bleiben“ und speichert dafür Tokens lokal.

Die Leitlinien nennen die neuen Risiken „token theft, unauthorised access, and session hijacking“ und stufen das Update als wesentliche Änderung ein (Beispiel 44). Eine kleine Komfortfunktion am Zugang kann also dazu führen, dass das Produkt als wesentlich verändert gilt und die Konformitätsbewertung neu ansteht.

So werten Sie Ihre Antworten aus

Jede Frage, die Sie mit Nein oder „weiß nicht“ beantworten, ist kein Verstoß. Sie ist eine Zeile, die in Ihrer Risikobewertung nach Art. 13 Abs. 3 noch fehlt.

Erstanmeldung: Gibt es ein gemeinsames, bekanntes Standardkonto ohne Änderungszwang, prüfen Sie es zuerst gegen die Buchstaben b und d.
Voreinstellungen: Jede Einstellung ab Werk, die nicht die sichere Variante ist, braucht eine Begründung. Prüfen Sie den Zustand nach dem Zurücksetzen gleich mit.
Zugang: Wird ein Zugriffsversuch abgewehrt, aber nirgends festgehalten oder gemeldet, fehlt nach meiner Lesart der zweite Teil von Buchstabe d.
Offene Türen: Jede Schnittstelle, die ab Werk aktiv ist, ohne dass jeder Kunde sie braucht, vergrößert die Angriffsfläche nach Buchstabe j.
Spur: Zeichnet das Produkt Zugriffe und Änderungen nicht auf, fehlt Buchstabe l.

Wer die Lücken jetzt findet, hat bis Dezember 2027 Zeit, sie im Produkt zu schließen. Wer sie erst bei der Konformitätsbewertung findet, hat diese Zeit nicht mehr.

Fazit

Anhang I klingt nach Technik. Ein guter Teil davon ist eine Frage an den Auslieferungszustand: Was gilt, bevor der Kunde irgendetwas einstellt? Und beim Zugang verlangt er zwei Dinge, nicht eines: verhindern und melden.

Frage	Worauf es ankommt	Grundlage
1 Erstanmeldung	kein unsicherer Zugang ab Werk	Anh. I Teil I Nr. 2 Buchst. b, d (Auslegung)
2 Voreinstellungen	sichere Standardkonfiguration, sicherer Zustand nach dem Zurücksetzen	Buchst. b
3 Zugang	Schutz durch Authentifizierungs-, Identitäts- oder Zugangsverwaltungssysteme, plus Meldung eines möglicherweise unbefugten Zugriffs	Buchst. d
4 Offene Türen	Angriffsfläche begrenzen, auch an Schnittstellen	Buchst. j
5 Spur	Zugang und Änderungen aufzeichnen und/oder überwachen, Opt-out für den Nutzer	Buchst. l

Ein Prüfschritt für diese Woche: Fragen Sie Ihre Produktverantwortlichen, mit welchem Konto und welchem Passwort Ihr Produkt beim Kunden startet, und wo das in Ihrer Risikobewertung steht.

Im nächsten Teil

Ein sicherer Auslieferungszustand ist der Anfang. Aber was passiert, wenn trotzdem eine Lücke auftaucht? Dafür hat Anhang I einen zweiten Teil, und für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gilt seit dem 11. September 2026 schon eine Meldepflicht (Art. 14). Darum geht es in Teil 3.

Wenn Sie die Serie nicht verpassen wollen: Folgen Sie mir auf LinkedIn.