Grundlegende Cybersicherheitsanforderungen

Die grundlegenden Cybersicherheitsanforderungen sind der inhaltliche Kern des Cyber Resilience Acts (CRA). Sie stehen nicht im Artikeltext, sondern in Anhang I, und sie zerfallen in zwei Teile. Teil I beschreibt Eigenschaften des Produkts, Teil II die Verfahren, mit denen der Hersteller Schwachstellen behandelt.

Artikel 6 macht beide Teile zur Bedingung des Marktzugangs. Ein Produkt mit digitalen Elementen darf nur bereitgestellt werden, wenn es den Anforderungen aus Teil I genügt und die vom Hersteller festgelegten Verfahren denen aus Teil II entsprechen. Eines von beidem reicht nicht. Buchstabe a knüpft die erste Bedingung zugleich daran, dass das Produkt ordnungsgemäß installiert und gewartet, bestimmungsgemäß oder unter vernünftigerweise vorhersehbaren Umständen verwendet und gegebenenfalls mit den erforderlichen Sicherheitsaktualisierungen versehen wird.

Teil I: die Eigenschaften des Produkts

Teil I besteht aus zwei sehr ungleichen Nummern. Nummer 1 ist eine Generalklausel und gilt immer: Produkte werden so konzipiert, entwickelt und hergestellt, dass sie angesichts der Risiken ein angemessenes Cybersicherheitsniveau gewährleisten.

Nummer 2 listet dreizehn konkrete Anforderungen, Buchstaben a–m. Sie gelten auf der Grundlage der Bewertung der Cybersicherheitsrisiken nach Artikel 13 Absatz 2 und nur, soweit sie zutreffen:

• Bereitstellung ohne bekannte ausnutzbare Schwachstellen (a)
• sichere Standardkonfiguration und Rücksetzung in den Ursprungszustand (b)
• Behebbarkeit von Schwachstellen durch Sicherheitsaktualisierungen, gegebenenfalls automatisch mit Opt-out (c)
• Schutz vor unbefugtem Zugriff, zumindest durch Authentifizierung, Identitäts- oder Zugangsverwaltung, samt Meldung möglicherweise unbefugter Zugriffe (d)
• Vertraulichkeit gespeicherter, übermittelter oder anderweitig verarbeiteter Daten, etwa durch Verschlüsselung (e)
• Integrität von Daten, Befehlen, Programmen und Konfigurationen, samt Meldung von Beschädigungen (f)
• Datenminimierung im Verhältnis zur Zweckbestimmung (g)
• Verfügbarkeit wesentlicher und grundlegender Funktionen, auch nach einem Sicherheitsvorfall (h)
• möglichst geringe Beeinträchtigung fremder Dienste und Netze (i)
• möglichst kleine Angriffsflächen, auch an externen Schnittstellen (j)
• Verringerung der Auswirkungen eines Sicherheitsvorfalls durch Mechanismen und Techniken zur Minderung der Ausnutzung (k)
• Bereitstellung sicherheitsbezogener Informationen durch Aufzeichnung und/oder Überwachung einschlägiger interner Vorgänge, mit Opt-out für Nutzer (l)
• sicheres, dauerhaftes Löschen aller Daten und Einstellungen (m)

„Soweit zutreffend“ ist kein Ermessen

Der Vorbehalt in Nummer 2 wird häufig als Wahlmöglichkeit gelesen. Er ist an ein Verfahren gebunden. Artikel 13 Absatz 3 verlangt, dass die Risikobewertung angibt, ob und in welcher Weise jede Anforderung aus Teil I Nummer 2 auf das Produkt anwendbar ist und wie sie umgesetzt wird. Grundlage sind die Zweckbestimmung, die vernünftigerweise vorhersehbare Verwendung und die Bedingungen der Nutzung, etwa die Betriebsumgebung oder die zu schützenden Anlagen. Welches Cybersicherheitsrisiko von einem Produkt ausgeht, entscheidet damit über den Umfang der eigenen Pflichten.

Ist eine Anforderung nicht anwendbar, fordert Artikel 13 Absatz 4 eine klare Begründung in der technischen Dokumentation. Erwägungsgrund 55 nennt als Beispiel den Fall, dass eine Anforderung mit der Art des Produkts unvereinbar ist, etwa weil eine weithin anerkannte Interoperabilitätsnorm einzuhalten ist, deren Sicherheitsmerkmale nicht mehr dem Stand der Technik entsprechen. Bleibt dabei ein Risiko bestehen, sollte der Hersteller ihm nach demselben Erwägungsgrund mit anderen Mitteln begegnen, indem er beispielsweise die Zweckbestimmung auf vertrauenswürdige Umgebungen beschränkt oder die Nutzer über das Risiko informiert.

Teil II: die Behandlung von Schwachstellen

Teil II richtet sich an den Hersteller, nicht an das Produkt, und er kennt keinen Anwendbarkeitsvorbehalt. Die acht Nummern gelten vollständig, und nach Artikel 13 Absatz 8 während der erwarteten Produktlebensdauer und des gesamten Unterstützungszeitraums:

• Schwachstellen und Komponenten ermitteln und dokumentieren, unter anderem durch eine Software-Stückliste (SBOM) in einem gängigen maschinenlesbaren Format, die zumindest die obersten Abhängigkeiten abdeckt (1)
• Schwachstellen unverzüglich behandeln und beheben; soweit technisch machbar, werden Sicherheitsaktualisierungen getrennt von Funktionsaktualisierungen bereitgestellt (2)
• die Sicherheit regelmäßig und wirksam testen und überprüfen (3)
• nach Bereitstellung einer Aktualisierung über behobene Schwachstellen informieren, mit Beschreibung, betroffenem Produkt, Auswirkungen und Schwere (4)
• eine Strategie für die koordinierte Offenlegung von Schwachstellen aufstellen und umsetzen (5)
• den Informationsaustausch über mögliche Schwachstellen erleichtern und eine Kontaktadresse für Meldungen angeben (6)
• Mechanismen für die sichere Verbreitung von Aktualisierungen bereitstellen (7)
• verfügbare Sicherheitsaktualisierungen unverzüglich und kostenlos verbreiten, zusammen mit Hinweisen zu möglichen Maßnahmen (8)

Zwei Nummern enthalten eine ausdrückliche Öffnung. Nummer 4 erlaubt, die Veröffentlichung einer behobenen Schwachstelle aufzuschieben, bis Nutzer den Patch anwenden konnten, sofern die Risiken der Veröffentlichung die Sicherheitsvorteile überwiegen und der Fall hinreichend begründet ist. Nummer 8 lässt bei maßgeschneiderten Produkten eine abweichende Vereinbarung mit dem gewerblichen Nutzer zu, allerdings nur zur Kostenfreiheit, nicht zur Frist.

Wie die Erfüllung nachgewiesen wird

Artikel 27 kennt drei Wege zu einer Konformitätsvermutung: eine Harmonisierte Norm, deren Fundstelle im Amtsblatt veröffentlicht ist, eine gemeinsame Spezifikation der Kommission und ein europäisches Schema für die Cybersicherheitszertifizierung nach der Verordnung (EU) 2019/881. Die Vermutung reicht in allen drei Fällen nur so weit, wie die betreffende Norm, Spezifikation oder Zertifizierung die einzelne Anforderung tatsächlich abdeckt.

Wo keine Fundstelle veröffentlicht ist, entfällt die Vermutung, nicht die Anforderung. Der Hersteller muss die Erfüllung dann aus eigener Kraft darlegen: über die Konformitätsbewertung nach Artikel 32, die genau gegen Anhang I prüft, über die technische Dokumentation nach Artikel 31 und Anhang VII und über die Informationen für Nutzer nach Anhang II. Anhang II Nummer 8 Buchstabe e verlangt unter anderem eine Anleitung dazu, wie sich die Standardeinstellung deaktivieren lässt, die die automatische Installation von Sicherheitsaktualisierungen nach Anhang I Teil I Nummer 2 Buchstabe c ermöglicht.

Was an Anhang I sonst noch hängt

Der Anhang ist Bezugspunkt für zahlreiche weitere Vorschriften. Die CE-Kennzeichnung ist nach Artikel 3 Nummer 31 die Erklärung des Herstellers, dass Produkt und Verfahren Anhang I genügen. Eine wesentliche Änderung ist nach Artikel 3 Nummer 30 eine Änderung nach dem Inverkehrbringen, die sich auf die Konformität mit Anhang I Teil I auswirkt oder zu einer Änderung des bestimmungsgemäßen Zwecks führt, für den das Produkt geprüft wurde. Einführer dürfen nach Artikel 19 Absatz 1 nur Produkte in den Verkehr bringen, die Anhang I Teil I genügen und bei denen die Herstellerverfahren Anhang I Teil II entsprechen.

Auch bei den Sanktionen steht Anhang I an erster Stelle. Artikel 64 Absatz 2 sieht für die Nichteinhaltung der grundlegenden Cybersicherheitsanforderungen sowie für Verstöße gegen die Artikel 13 und 14 Geldbußen von bis zu 15 000 000 EUR oder, im Falle von Unternehmen, von bis zu 2,5 % des gesamten weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres vor, je nachdem, welcher Betrag höher ist. Das ist der höchste Bußgeldrahmen der Verordnung.

Für die Planung zählt ein Datum: Die Anforderungen aus Anhang I gelten ab dem 11. Dezember 2027. Früher greifen nur die Meldepflichten des Artikels 14 ab dem 11. September 2026 und Kapitel IV über die Notifizierung von Konformitätsbewertungsstellen, also die Artikel 35 bis 51, ab dem 11. Juni 2026.