Art. 21(2)(h) NIS 2 + CIR §9

Kryptografiekonzept nach Artikel 21(2)(h)

Verkehr zu verschlüsseln ist nicht dasselbe wie ein Kryptografiekonzept zu haben. Artikel 21(2)(h) NIS 2 verlangt das Konzept. CIR §9 sagt, was drinstehen muss: Algorithmen, Schlüsselstärken, Kryptoagilität und ein zwölfteiliger Schlüsselmanagementzyklus.

Simon OrzelSimon Orzel·

Die Kurzfassung

Kryptografie in NIS 2 ist nicht die technische Maßnahme. Es ist das schriftliche Konzept, das festlegt, welche Kryptografie wo eingesetzt wird und wie die Schlüssel verwaltet werden. Artikel 21(2)(h) ist ein Satz. CIR §9 macht daraus ein konkretes Dokument mit drei festen Abschnitten.

Das Konzept muss drei Dinge leisten. Die Kryptostärke an die Anlagen- und Werteklassifizierung knüpfen. Genehmigte Algorithmen, Schlüsselgrößen und Protokolle benennen, und zwar nach einem Krypto-Agilitätsansatz, damit sie ausgetauscht werden können, wenn sich der Stand der Technik weiterentwickelt. Und den gesamten Lebenszyklus des Schlüsselmanagements abdecken (CIR nennt zwölf Schritte von der Erzeugung bis zur Vernichtung).

Deutschland überträgt die Pflicht in §30 Absatz 2 Nummer 8 BSIG. Der technische Anker beim BSI ist die TR-02102-Reihe (TR-02102-1 für Algorithmen und Schlüssellängen, TR-02102-2/-3/-4 für TLS, IPsec, SSH). Diese Seite geht Richtlinie, CIR-Detailregelung und deutsche Umsetzung in dieser Reihenfolge durch.

Die Rechtsgrundlage
Drei Ebenen übereinander. Die Richtlinie (für jeden EU-Staat verbindlich). Die Durchführungsverordnung (unmittelbar geltendes EU-Recht für die im Anhang genannten Sektoren). Die nationale Umsetzung (in Deutschland: BSIG).

Artikel 21(2)(h) NIS-2-Richtlinie (2022/2555)

Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung;

Buchstabe (h) auf der Liste der zehn Cybersicherheitsmaßnahmen, die jede wesentliche und wichtige Einrichtung umsetzen muss. 'Gegebenenfalls' bezieht sich auf die Verschlüsselung (die Anwendung), nicht auf das Konzept selbst (das ist Pflicht).

CIR (EU) 2024/2690, Anhang §9

Für die Zwecke von Artikel 21 Absatz 2 Buchstabe h der Richtlinie (EU) 2022/2555 legen die betreffenden Einrichtungen ein Konzept und Verfahren in Bezug auf Kryptografie fest, setzen sie um und wenden sie an, um eine angemessene und wirksame Nutzung von Kryptografie sicherzustellen, damit die Vertraulichkeit, Authentizität und Integrität der Daten im Einklang mit der Anlagen- und Werteklassifizierung der betreffenden Einrichtungen und den Ergebnissen der gemäß Nummer 2.1 durchgeführten Risikobewertung geschützt sind.

Als Verordnung (nicht Richtlinie) ist die CIR unmittelbar geltendes EU-Recht für die im Anhang genannten Sektoren (DNS, TLDs, Cloud, Rechenzentren, MSPs, Vertrauensdienste und weitere). §9.2 schreibt die drei Abschnitte des Konzepts vor, §9.3 verpflichtet zur regelmäßigen Überprüfung mit Blick auf den Stand der Technik.

§30 Absatz 2 Nummer 8 BSIG (Deutschland)

Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung.

Deutschland übernimmt den EU-Text fast wörtlich. Technische Referenz ist die TR-02102-Reihe des BSI (Kryptographische Verfahren: Empfehlungen und Schlüssellängen). Der IT-Grundschutz-Baustein CON.1 (Krypto-Konzept) liefert das Umsetzungsmuster.

Die drei Bestandteile, die CIR §9.2 verlangt
CIR 2024/2690 §9.2 teilt das Kryptografiekonzept in drei Teile. Jeder Teil ist ein eigener Unterpunkt. Alle drei müssen schriftlich vorliegen.
§9.2(a)

Kryptostärke an Anlagenklassifizierung binden

Für jede Daten- oder Anlagenklasse (Vertraulichkeit, Authentizität, Integrität, nach Schutzstufen) benennt das Konzept Art, Stärke und Qualität der eingesetzten kryptografischen Maßnahmen. Der Bezug zur Anlageninventur und zur Risikobewertung aus §2.1 ist ausdrücklich. Höherwertige Daten bekommen stärkere Kryptografie. Die Regel steht im Konzept, nicht im Bauch der Administratorin.

§9.2(b)

Zugelassene Algorithmen, Schlüsselstärken, Kryptoagilität

Das Konzept benennt die zugelassenen Protokolle, Algorithmen, Schlüsselstärken und Schlüsselmanagementverfahren und schließt die nicht zugelassenen aus. CIR fordert ausdrücklich 'soweit angemessen einen Krypto-Agilitätsansatz': Algorithmen müssen austauschbar sein, wenn sich der Stand der Technik weiterentwickelt. Neuer Algorithmus, neue Schlüsselgröße, neue Protokollversion: das Konzept trägt den Austausch, nicht einen Neuaufbau.

§9.2(c)

Zwölfteiliger Schlüsselmanagementzyklus

CIR §9.2(c) nennt zwölf konkrete Schritte: (i) Erzeugung, (ii) Ausstellung von Zertifikaten für öffentliche Schlüssel, (iii) Verteilung und Aktivierung, (iv) Speicherung und autorisierter Zugriff, (v) Änderung oder Aktualisierung, (vi) Umgang mit kompromittierten Schlüsseln, (vii) Widerruf, (viii) Wiederherstellung verlorener oder beschädigter Schlüssel, (ix) Sicherung und Archivierung, (x) Vernichtung, (xi) Protokollierung und Prüfung, (xii) Aktivierungs- und Deaktivierungsdaten. Alle zwölf gehören ins Konzept.

Zwei Regeln, die alles Übrige formen
Artikel 21 und CIR §9.3 setzen zwei Auslegungsregeln. Die erste entscheidet, wie tief die Kryptografie gehen muss. Die zweite entscheidet, dass das Konzept nie fertig ist.

Die Anlagenklassifizierung bestimmt die Kryptotiefe (Art. 21(1) Verhältnismäßigkeit)

Niemand fährt AES-256 mit HSM-gestützten Schlüsseln für alles. Die Kryptografie passt zur Bedeutung und Exposition der Anlage. Kundendatenbank mit personenbezogenen Daten, Finanzunterlagen, Quellcode: hohe Stufe. Interne Vorlagen und Sitzungsnotizen: niedrige Stufe. Artikel 21(1) verlangt 'angemessene und verhältnismäßige' Maßnahmen. CIR §9.2(a) baut diese Verbindung ins Konzept ein.

Kryptoagilität: prüfen und ersetzen (CIR §9.3)

CIR §9.3 verlangt, dass die Einrichtungen ihr Konzept 'in geplanten Zeitabständen' überprüfen und 'soweit angemessen' aktualisieren, 'wobei sie dem Stand der Technik im Bereich der Kryptografie Rechnung tragen'. Das ist Kryptoagilität in zwei Sätzen. SHA-1 war einmal in Ordnung, dann nicht mehr. RSA-1024 war einmal in Ordnung, dann nicht mehr. Postquantum kommt für RSA und ECC im nächsten Jahrzehnt. Das Konzept trägt den Austausch, nicht nur die Beschreibung des heutigen Stands.

Wie nationale Aufsichten das praktisch handhaben
Die EU setzt die Regel. Jedes Land setzt sie um. Die Substanz ist gleich. Der technische Anker ist national.
Deutschland

BSI / §30(2)(8) BSIG / TR-02102

Deutschland überträgt Artikel 21(2)(h) durch §30(2)(8) BSIG. Technische Referenz ist die TR-02102-Reihe des BSI: TR-02102-1 für kryptographische Algorithmen und Schlüssellängen, TR-02102-2 für TLS, -3 für IPsec, -4 für SSH. Der IT-Grundschutz-Baustein CON.1 (Krypto-Konzept) liefert das Umsetzungsmuster. Prüferinnen erwarten, dass die Einrichtung entweder TR-02102 referenziert oder begründet, warum ihre Auswahl mindestens gleichwertig ist.

EU-weit

ENISA Technical Implementation Guidance

Die ENISA-Umsetzungsleitlinie für die CIR deckt §9 ab und bildet ihn auf ISO/IEC 27001:2022 (A.8.24 Verwendung von Kryptografie), NIST CSF 2.0, ETSI EN 319 401 und CEN/TS 18026 ab. Wer ISO 27001 bereits betreibt, hat die meisten Controls. NIS 2 möchte das Konzept trotzdem entlang der §9.2-Struktur sehen.

Andere Mitgliedstaaten

Nationale Umsetzungsgesetze

Jeder Mitgliedstaat hat ein eigenes Umsetzungsgesetz (Niederlande: Cyberbeveiligingswet, Österreich: NISG, Belgien: NIS2-Wet). Die Pflicht ist gleich, weil die Richtlinie einen EU-weiten Standard setzt. Was sich unterscheidet: die nationale technische Referenz. Frankreich verweist über ANSSI auf RGS, die Niederlande nutzen ENISA-Abgleiche. Die Konzeptstruktur ändert sich nicht.

Drei Irrtümer, die wir ständig sehen
Drei Annahmen, die in fast jedem Audit-Vorbereitungsgespräch auftauchen. Alle drei reißen eine Lücke, die ein Prüfer findet.
  • Wir haben überall TLS, damit sind wir durch.

    Transportverschlüsselung ist ein Teil des Konzepts. CIR §9.2(c) verlangt den vollen Schlüssellebenszyklus schriftlich: wie Schlüssel erzeugt werden, wo sie liegen, wie sie rotiert werden, was passiert, wenn einer kompromittiert ist, wer ihn wiederherstellen kann, wann er vernichtet wird. Wenn diese zwölf Punkte nicht auf Papier stehen, ist das Konzept nicht fertig, egal wie viel TLS im Einsatz ist.

  • Wir nutzen, was der Anbieter liefert.

    Die Einrichtung bleibt verantwortlich. §30 BSIG und Artikel 21 übertragen die Pflicht nicht auf den Anbieter. Wenn der SaaS-Anbieter AES-128 nutzt und die Einrichtung diese Daten als hoch eingestuft hat, ist das ein Problem, das ins Konzept oder in den Vertrag gehört. Das Konzept benennt, was die Einrichtung akzeptiert, nicht das, was zufällig in der Standardkonfiguration steht.

  • Schlüsselverwaltung ist Sache der IT.

    Schlüsselverwaltung ist Governance. Das Konzept wird von der Geschäftsleitung unterschrieben (Art. 20 plus das Freigabemuster, das sich durch Artikel 21 zieht). Wenn ein Schlüssel kompromittiert wird, läuft die Reaktion durch den Vorfallsprozess nach Artikel 23. Wenn Zugriff auf einen hochwertigen Schlüssel erteilt wird, wird protokolliert. Die IT betreibt die Controls; die Leitung verantwortet das Konzept.

Wie der Mittelstand das tatsächlich umsetzt

Was wir im deutschen Mittelstand sehen: Transportverschlüsselung sitzt meist (TLS, VPN, S/MIME oder SMTP-TLS für Mail). Verschlüsselung im Ruhezustand ist lückig, aber reparierbar. Die echte Lücke ist die Dokumentation der Schlüsselverwaltung. Wer hat die Hauptschlüssel für das VPN? Wo werden die Cloud-KMS-Schlüssel gesichert? Was passiert mit dem Verschlüsselungszertifikat einer ausscheidenden Mitarbeiterin? Die meisten Teams kennen die Antworten. Aufgeschrieben sind sie nicht.

Zwei Schritte, die im Audit halten. Erst das Konzept schreiben: Anlagenstufen, zugelassene Algorithmen (mit Verweis auf TR-02102 oder ENISA TIG), Schlüssellebenszyklus mit allen zwölf §9.2(c)-Punkten, Freigabe durch die Geschäftsleitung. Dann das Konzept auf die bestehenden Systeme abbilden (Cloud-KMS, Zertifizierungsstelle, VPN, Mail, Dateiverschlüsselung). Die meisten Controls existieren. Die §9.2(c)-Liste ist das Artefakt, nach dem Prüferinnen fragen.

Wie wir das auf der Plattform umsetzen

Wir liefern eine Kryptografiekonzept-Vorlage, die entlang CIR §9.2(a), (b) und (c) strukturiert ist. Die Einrichtung startet mit der Vorlage, benennt ihre Anlagenstufen, wählt Algorithmen aus einer TR-02102-konformen Liste und arbeitet den zwölfteiligen Schlüssellebenszyklus durch. Das Ergebnis ist ein unterschriebenes Dokument, das jedem CIR-Unterpunkt direkt zugeordnet ist.

Die Schlüsselinventur im CRY-Modul listet Schlüssel nach Zweck (TLS, Signatur, Verschlüsselung, Code), System, Eigentümerin, Aktivierungs- und Deaktivierungsdatum. CIR §9.2(c)(xi) (Protokollierung) und §9.2(c)(xii) (Aktivierungs- und Deaktivierungsdaten) werden zu einer Tabelle, nicht zu einer Gedächtnisübung. Das Konzept wird jährlich überprüft; die Plattform plant die §9.3-Prüfung und führt die Freigabe nach.

Quellen
  • Richtlinie (EU) 2022/2555 (NIS 2), Artikel 21 Absatz 2 Buchstabe h — eur-lex.europa.eu/eli/dir/2022/2555/oj
  • Durchführungsverordnung (EU) 2024/2690 (CIR), Anhang §9 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
  • BSI-Gesetz (BSIG), §30 Absatz 2 Nummer 8 in der Fassung des NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetzes
  • BSI TR-02102 (Kryptographische Verfahren: Empfehlungen und Schlüssellängen) — bsi.bund.de/dok/tr-02102
  • IT-Grundschutz-Kompendium, Baustein CON.1 (Krypto-Konzept) — bsi.bund.de/grundschutz
  • ENISA Technical Implementation Guidance zur CIR (EU) 2024/2690, Mapping zu ISO/IEC 27001:2022 A.8.24
Das Kryptokonzept einmal schreiben, jährlich prüfen
CIR §9-Vorlage, anlagengetreue Algorithmenauswahl, zwölfteiliger Schlüssellebenszyklus, Freigabe auf einer Plattform. Kostenlos, Open Source, kein Lock-in.