PQC StatusNIS2 Artikel 21(2)(h) verpflichtet wesentliche und wichtige Einrichtungen, über Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung zu verfügen. Die Richtlinie schreibt weder eine Vorlage noch eine Algorithmenliste oder eine Frist vor, die Qualität des Dokuments liegt also in Ihrer Verantwortung. Dieser Artikel liefert eine kopierbare Gliederung Abschnitt für Abschnitt, ordnet jedem Abschnitt die Nachweise zu, die ein Prüfer verlangen wird, und zeigt genau, wohin die Regelungen zum Post-Quanten-Übergang gehören.
Was Artikel 21(2)(h) verlangt und was nicht
Die Richtlinie (EU) 2022/2555 listet in Artikel 21(2) die Mindestmaßnahmen des Cybersicherheits-Risikomanagements auf, die Einrichtungen im Anwendungsbereich ergreifen müssen. Buchstabe (h) besteht aus einer einzigen Zeile: Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung. Der Text ist auf EUR-Lex abrufbar (data.europa.eu/eli/dir/2022/2555/oj). Artikel 21(1) stellt all diese Maßnahmen unter den Grundsatz der Verhältnismäßigkeit gegenüber dem bestehenden Risiko und verlangt, dass sie den Stand der Technik berücksichtigen.
Daraus ergeben sich drei Folgen. Erstens ist die Pflicht dokumentarischer und prozeduraler Natur: Sie benötigen eine schriftliche Policy samt den Verfahren, die sie umsetzen, nicht eine bestimmte Cipher Suite. Zweitens muss die Policy selbst diese Liste enthalten und festlegen, wie sich die Liste im Laufe der Zeit ändert, da die Richtlinie weder Algorithmus noch Schlüssellänge nennt. Drittens bedeutet die Formulierung „gegebenenfalls“, dass die Entscheidung, etwas nicht zu verschlüsseln, eine dokumentierte, risikobasierte Entscheidung sein muss und keine Auslassung. Unsere Referenzseite zu NIS2 Artikel 21(2)(h) bündelt den Text und die zugehörigen Meilensteine.
Dieser Artikel dient der Information und stellt keine Rechtsberatung dar. Was in der Praxis ausreicht, bestimmen Ihr nationales Umsetzungsgesetz, Ihr Sektor und Ihre zuständige Behörde.
Die Gliederung zum Kopieren
Die folgende Struktur ist eine Arbeitsgliederung, keine rechtliche Vorgabe. Sie ist so angeordnet, dass ein Leser, der bei Abschnitt 1 beginnt, bis Abschnitt 5 zu einer freigegebenen Algorithmenentscheidung gelangt, und dass jeder spätere Abschnitt ein Artefakt erzeugt, das ein Prüfer einsehen kann. Eine Policy von acht bis fünfzehn Seiten, mit den technischen Parametern in einem Anhang, den Sie überarbeiten können, ohne das gesamte Dokument erneut freigeben zu müssen, reicht in der Regel aus.
| # | Abschnitt | Inhalt |
|---|---|---|
| 1 | Zweck und Rechtsgrundlage | Dass das Dokument NIS2 Artikel 21(2)(h) in der nationalen Umsetzung umsetzt, sowie alle weiteren relevanten Regelwerke (DORA, PCI DSS, Cyber Resilience Act, sektorspezifische Vorschriften). |
| 2 | Geltungsbereich | Erfasste Einrichtungen, Tochtergesellschaften, Umgebungen (Produktion, Test, Cloud, OT), Datenklassen und Drittanbieterdienste. Benannte Ausnahmen mit Begründung. |
| 3 | Rollen und Verantwortlichkeiten | Wer die Policy verantwortet, wer Algorithmenänderungen freigibt, wer Ausnahmen genehmigt, wer Rollen als Schlüsselverwalter innehat, und die Einbindung des Leitungsorgans, die NIS2 erwartet. |
| 4 | Risiko- und Datenklassifizierung | Wie die Vertraulichkeitsdauer je Datenklasse festgelegt wird. Diese Angabe entscheidet, welche Systeme zuerst migriert werden. |
| 5 | Zugelassene Algorithmen und Parameter | Die Positivliste mit Mindestparametern je Anwendungsfall: Daten bei der Übertragung, ruhende Daten, Signaturen, Hashing, Schlüsselableitung, Zufallszahlenerzeugung. |
| 6 | Veraltete und verbotene Algorithmen | Was nicht mehr eingesetzt werden darf, was nur noch zur Verifikation von Altbeständen geduldet wird, und das jeweilige Entfernungsdatum. |
| 7 | Protokoll- und Konfigurations-Baselines | Mindestversion von TLS, Reihenfolge der Gruppen und Cipher Suites, SSH-Schlüsselvereinbarung, VPN- und Datenbankeinstellungen. Eine Baseline je Plattformfamilie. |
| 8 | Schlüsselmanagement | Erzeugung, Verteilung, Speicherung, Rotation, Hinterlegung, Archivierung und Vernichtung, mit den Hardwareanforderungen für jede Schlüsselklasse. |
| 9 | Zertifikatsmanagement | Ausstellende Stelle, maximale Gültigkeitsdauer, automatisierte Erneuerung, Widerruf und ein Zertifikatsregister mit Verantwortlichen. |
| 10 | Kryptografisches Inventar | Was inventarisiert wird (Algorithmus, Parameter, Bibliothek und Version, System, Verantwortlicher, Datenklasse), wie es erhoben und wie oft es aktualisiert wird. |
| 11 | Krypto-Agilität und Post-Quanten-Übergang | Die auslösenden Bedingungen, die Migrationsreihenfolge und die Zieltermine. Siehe nächster Abschnitt. |
| 12 | Anforderungen an Lieferanten und Beschaffung | Von Anbietern und Cloud-Providern geforderte Klauseln: Offenlegung der eingesetzten Algorithmen, Unterstützung für hybriden Schlüsselaustausch, Ankündigung kryptografischer Änderungen. |
| 13 | Ausnahmen | Antragsformat, erforderliche Ebene der Risikoakzeptanz, kompensierende Maßnahmen, verbindliches Ablaufdatum, zentrales Register. |
| 14 | Überwachung, Tests und Überprüfung | Rhythmus externer und interner Scans, Erkennung von Konfigurationsabweichungen und der Überprüfungszyklus der Policy selbst. |
| 15 | Behandlung kryptografischer Vorfälle | Vorgehen bei Schlüsselkompromittierung, fehlerhafter Zertifikatsausstellung oder Veröffentlichung eines praktikablen Angriffs auf einen zugelassenen Algorithmus, einschließlich der Verknüpfung mit dem NIS2-Meldeprozess für Vorfälle. |
Abschnitt 5: Was die Positivliste enthalten sollte
Nennen Sie finale Standards und geben Sie Parameter an. Für die Schlüsselkapselung ist ML-KEM in NIST FIPS 203 standardisiert, veröffentlicht als finaler Standard am 13. August 2024, zusammen mit ML-DSA in FIPS 204 und SLH-DSA in FIPS 205 (csrc.nist.gov/pubs/fips/203/final). Für symmetrischen Schutz wird bei langlebigen Daten AES-256 bevorzugt: Symmetrische Algorithmen und Hashfunktionen werden durch Shors Algorithmus nicht gebrochen, und Grovers Algorithmus ist der Grund für die Wahl der größeren Schlüssellänge. Wenn Sie in Deutschland tätig sind: Die BSI TR-02102-1 (Version 2026-01, veröffentlicht am 23. Januar 2026) ist eine Technische Richtlinie, die hybride Post-Quanten-Schlüsselvereinbarung und RSA mit mindestens 3000 Bit empfiehlt und rein klassische Schlüsselvereinbarung nur noch bis Ende 2031 empfiehlt, bei sehr hohem Schutzbedarf bis Ende 2030. Richtlinien dieser Art sind Empfehlungen, keine Pflichten, sofern nicht Ihr nationales Recht oder ein Vertrag sie verbindlich macht.
Abschnitt 6: Was ausdrücklich verboten werden sollte
RC4 ist in TLS durch RFC 7465 verboten. MD5 und SHA-1 sind für Signaturen obsolet. DSA ist nach FIPS 186-5 für die Signaturerzeugung nicht mehr zugelassen und darf nur noch zur Verifikation alter Signaturen verwendet werden. Die vorstandardisierten Kyber-TLS-Gruppen, etwa X25519Kyber768Draft00 mit Codepoint 0x6399, sind obsolet und sollten zugunsten der registrierten ML-KEM-Gruppen entfernt werden. Versehen Sie jede Zeile mit einem Entfernungsdatum, sonst wird der Abschnitt zur Wunschliste.
Abschnitt 11: Die Regelungen zum Post-Quanten-Übergang
NIS2 erwähnt Post-Quanten-Kryptografie nicht. Der Grund, sie dennoch aufzunehmen, ist „Harvest now, decrypt later“: Heute aufgezeichneter Datenverkehr ist nur durch den Schlüsselaustausch geschützt, mit dem er ausgehandelt wurde, sodass eine jetzt mitgeschnittene Sitzung später entschlüsselt werden könnte, wenn der Schlüsselaustausch quantenverwundbar ist. Deshalb kommt der hybride Schlüsselaustausch zuerst, und Signaturen und Zertifikate können danach migriert werden. Beachten Sie, dass COM(2026) 13, veröffentlicht am 20. Januar 2026, ein Vorschlag der Europäischen Kommission zur Änderung von NIS2 ist, damit nationale Strategien eine Policy für den Post-Quanten-Übergang enthalten. Es handelt sich um einen Vorschlag, er wurde nicht angenommen, und er richtet sich an die Strategien der Mitgliedstaaten, statt den Einrichtungen eine unmittelbare Pflicht aufzuerlegen (EUR-Lex CELEX 52026PC0013).
Halten Sie in diesem Abschnitt vier Dinge fest. Erstens: die Inventarpflicht, aktualisiert in einem festgelegten Rhythmus, denn was Sie nicht erfassen können, können Sie nicht migrieren. Zweitens: die Reihenfolge, Schlüsselaustausch vor Signaturen, extern erreichbare Dienste vor internen, Daten mit langer Vertraulichkeitsdauer zuerst. Drittens: die Referenztermine, an denen Sie sich ausrichten, jeweils gekennzeichnet als das, was sie sind. Die EU Coordinated Implementation Roadmap v1.1 (veröffentlicht am 23. Juni 2025) ist eine koordinierte Leitlinie für die Mitgliedstaaten, keine für Unternehmen verbindliche Verordnung: Sie sieht als erste Schritte ein kryptografisches Inventar und nationale Roadmaps bis Ende 2026 vor, die Migration von Anwendungsfällen mit hohem Risiko bis Ende 2030 und mit mittlerem Risiko bis Ende 2035, bei niedrigem Risiko so weit wie möglich (unsere Zusammenfassung und der Eintrag in der Bibliothek der Kommission). NIST IR 8547 ist weiterhin ein Initial Public Draft, veröffentlicht am 12. November 2024: Er schlägt vor, quantenverwundbare Algorithmen mit 112-Bit-Sicherheit nach 2030 als veraltet einzustufen und alle quantenverwundbaren Public-Key-Algorithmen nach 2035 nicht mehr zuzulassen. Zitieren Sie ihn als Entwurf. Viertens: die Agilitätsklausel, also die technischen und vertraglichen Voraussetzungen, unter denen Sie einen Algorithmus wechseln können, ohne das System neu zu entwerfen.
Die Baseline für den Anhang ist kurz. Hybride Gruppe zuerst, klassischer Fallback bleibt erhalten, vor der Produktion in Staging getestet:
# OpenSSL 3.5 or later is required for the ML-KEM TLS groups
# openssl.cnf, ssl_conf section: hybrid first, classical fallback retained
Groups = X25519MLKEM768:SecP256r1MLKEM768:X25519:P-256X25519MLKEM768 ist bei der IANA unter 0x11EC (4588) registriert, SecP256r1MLKEM768 unter 0x11EB (4587) und SecP384r1MLKEM1024 unter 0x11ED (4589); maßgeblich ist das IANA-Register der TLS-Parameter (iana.org). RFC 10024 (August 2026) spezifiziert die hybride Post-Quanten-/klassische Schlüsselvereinbarung für TLS 1.3. Aktuelle Versionen von Chrome, Edge und Firefox bieten X25519MLKEM768 bereits standardmäßig an, die Aktivierung ist für Nutzer daher normalerweise unsichtbar. Auf SSH-Seite hat OpenSSH 10.0 (9. April 2025) mlkem768x25519-sha256 zur Standard-Schlüsselvereinbarung gemacht, und OpenSSH 10.1 (6. Oktober 2025) warnt, wenn eine Verbindung eine nicht postquantensichere Schlüsselvereinbarung aushandelt.
Von der Policy-Klausel zum Nachweis
Ein Prüfer liest die Policy und verlangt anschließend den Nachweis, dass sie angewendet wird. Das Artefakt bereits beim Schreiben festzulegen ist günstiger, als es später zu rekonstruieren. Die rechte Spalte unten gibt unsere Auslegung guter Praxis wieder, keine wörtliche Anforderung von Artikel 21(2)(h).
| Policy-Klausel | Aufzubewahrender Nachweis |
|---|---|
| Zugelassene Algorithmen und Parameter | Unterzeichnete Policy mit Versionshistorie und dem Freigabeprotokoll der letzten Änderung. |
| Kryptografisches Inventar | Datierter Inventarexport mit Systemverantwortlichem je Eintrag. Eine CBOM (Cryptographic Bill of Materials) ist ein praktikabler Weg, ihn zu erstellen, wie in unserer Notiz was eine CBOM ist beschrieben. |
| Protokoll-Baselines | Aufzeichnungen des Konfigurationsmanagements sowie externe Scanergebnisse je öffentlichem Endpunkt. |
| Schlüssel- und Zertifikatsmanagement | Schlüsselregister, Rotationsprotokolle und ein Zertifikatsregister mit Ablaufdaten und Verantwortlichen. |
| Ausnahmen | Ausnahmeregister mit Risikoakzeptanz, kompensierender Maßnahme und Ablaufdatum. |
| Überprüfungsrhythmus | Protokoll der letzten Überprüfung und die daraus resultierende Änderungsliste. |
| Post-Quanten-Übergang | Migrationsplan mit Verantwortlichen und Zielterminen sowie ein Fortschrittsbericht dazu. |
NIS2 legt keine Überprüfungsfrequenz fest. Wenn Sie auch in den Anwendungsbereich von PCI DSS v4.0.1 fallen, verlangt Anforderung 12.3.3, dass die eingesetzten Cipher Suites und Protokolle dokumentiert und mindestens alle 12 Monate überprüft werden, einschließlich einer dokumentierten Strategie für erwartete Änderungen bei kryptografischen Schwachstellen, verpflichtend seit dem 31. März 2025. Ein Zwölfmonatsrhythmus für die gesamte Policy ist eine vertretbare einheitliche Baseline. Finanzunternehmen sollten dasselbe Dokument mit DORA abstimmen: Artikel 6 der Delegierten Verordnung (EU) 2024/1774 der Kommission verlangt eine Policy für Verschlüsselung und kryptografische Kontrollen, die Regelungen zur Aktualisierung oder Änderung der kryptografischen Technologie auf Grundlage von Entwicklungen in der Kryptoanalyse enthält, und Artikel 7 verlangt ein Schlüsselmanagement über den gesamten Lebenszyklus sowie ein Zertifikatsregister für IKT-Assets, die kritische oder wichtige Funktionen unterstützen. Unser Leitfaden zur DORA-Verschlüsselungs-Policy nach Artikel 6 behandelt den präskriptiveren Wortlaut, und ein einziges Dokument kann beide Regelwerke abdecken, wenn der Abschnitt zum Geltungsbereich eindeutig ist.
Nationale Umsetzungen und was zu vermeiden ist
NIS2 ist eine Richtlinie und entfaltet ihre Wirkung daher über nationales Recht. Umsetzungsgesetze, Leitlinien nationaler Behörden und Durchführungsrechtsakte können Details ergänzen: eine vorgeschriebene Policy-Struktur, benannte nationale Referenzrichtlinien, bestimmte Überprüfungsfrequenzen oder Meldeformate. Diese Details unterscheiden sich je nach Mitgliedstaat und Sektor. Prüfen Sie daher die veröffentlichten Leitlinien Ihrer nationalen Behörde, bevor Sie das Dokument finalisieren. Gehen Sie nicht davon aus, dass das Minimum der Richtlinie Ihre Obergrenze ist.
Vier häufige Schwächen verdienen es, benannt zu werden. Eine Policy, die Algorithmen auflistet, aber keine Entfernungsdaten, ist nicht prüfbar. Eine Policy ohne Ausnahmeprozess drängt Teams in stille Nichtkonformität. Eine Policy, die ein Herstellerprodukt statt einer Algorithmenfamilie nennt, scheitert bei der nächsten Migration. Und eine Policy, die Post-Quanten-Bereitschaft behauptet, ohne ein Inventar zu haben, kann nicht zeigen, welche Systeme betroffen sind. Halten Sie auch im Dokument die Abstufungen präzise: Ein Standardentwurf ist ein Entwurf, und eine Empfehlung einer nationalen Behörde ist keine Pflicht, sofern Ihr Geltungsbereich sie nicht dazu macht. Die ANSSI etwa erklärt die Hybridisierung innerhalb ihres regulierten Bereichs (Produktqualifizierung, verteidigungsbezogene Bereiche, SAIV und SIIV) für verpflichtend, während ihre weitergehenden Post-Quanten-Empfehlungen anderswo noch keine regulatorischen Pflichten sind.
Nächster Schritt: Messen Sie, was Ihre Policy behauptet
Abschnitt 7 der Gliederung ist der einzige Teil der Policy, den ein Dritter von außen überprüfen kann, also überprüfen Sie ihn zuerst selbst. Scannen Sie Ihre Domain mit PQC Status, um zu sehen, welche TLS-Versionen, Cipher Suites, Unterstützung hybrider ML-KEM-Gruppen und Zertifikatskette Ihre öffentlichen Endpunkte tatsächlich aushandeln, und fügen Sie das Ergebnis dem Baseline-Anhang als datierten Nachweis für diese Klausel bei. Ein Scan beschreibt ausschließlich die von außen sichtbare TLS-Konfiguration: Er ist weder eine Zertifizierung noch eine Konformitätsbestätigung. Führen Sie ihn für jeden öffentlichen Hostnamen aus, tragen Sie die Lücken mit Ablaufdatum in das Ausnahmeregister ein, und der Post-Quanten-Abschnitt Ihrer Policy ist keine bloße Absichtserklärung mehr.