NIS-2 & das Quanten-Zeitalter: Warum Post-Quanten-Kryptografie (ML-KEM) nach § 30 BSIG und BSI TR-02102 jetzt zur Pflichtaufgabe wird

1. Wenn zwei Zeitalter im Serverraum aufeinandertreffen

Über Jahrzehnte hinweg besaß Kryptografie in den meisten Unternehmen den Charme einer Fußbodenheizung: Solange sie geräuschlos im Untergrund funktionierte, dachte niemand darüber nach. Im Browser leuchtete ein kleines Schlosssymbol neben der Webadresse, das Zertifikat verlängerte sich alle paar Monate von selbst, und im Jahresgespräch mit der Geschäftsleitung reichte der beruhigende Halbsatz, die Verbindung sei „natürlich SSL-verschlüsselt“. Wer genauer nachfragte, welche Schlüsselaustauschgruppen der Reverse Proxy aushandelt, ob TLS-Session-Tickets die Perfect Forward Secrecy unterlaufen oder auf welchem vergessenen Nebenport noch ein alter SSH-Daemon lauscht, galt schnell als liebenswerter Perfektionist aus dem Maschinenraum.

Diese beschauliche Ruhe endet gerade aus zwei Richtungen gleichzeitig. Auf der regulatorischen Seite hat der europäische und deutsche Gesetzgeber mit der NIS-2-Richtlinie (EU) 2022/2555 und deren nationaler Umsetzung im BSI-Gesetz (BSIG) durch das NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) die Spielregeln grundlegend verschärft. Kryptografie ist nach § 30 Abs. 2 Nr. 8 BSIG keine freiwillige Konfigurationsfeinheit der Systemadministration mehr, sondern eine explizite, bußgeldbewehrte Pflichtmaßnahme des unternehmerischen Risikomanagements – gekoppelt an die persönliche Überwachungspflicht und Haftung der Geschäftsleitung nach § 38 BSIG.

Auf der technologischen Seite vollzieht sich parallel der tiefgreifendste Umbruch der modernen Kryptografiegeschichte: der Übergang in das Quanten-Zeitalter. Mit der Verabschiedung der ersten finalen Post-Quanten-Standards durch das US-amerikanische National Institute of Standards and Technology (insbesondere NIST FIPS 203 / ML-KEM) und den aktualisierten Empfehlungen des Bundesamts für Sicherheit in der Informationstechnik in der Technischen Richtlinie BSI TR-02102 ist die Post-Quanten-Migration aus der akademischen Forschung mitten in den produktiven IT-Betrieb gerückt. Wer heute über NIS-2-Konzepte für Kryptografie und Verschlüsselung spricht, ohne das Quanten-Zeitalter mitzudenken, schreibt ein Sicherheitskonzept für die Vergangenheit.

2. „Harvest Now, Decrypt Later“ (HNDL) & die Mosca-Ungleichung: Warum das Quanten-Risiko schon heute existiert

Ein häufiger Irrtum in Vorstands- und IT-Runden lautet: „Darum kümmern wir uns, sobald der erste große Quantencomputer tatsächlich im Handel steht.“ Dieser Gedanke übersieht die Funktionsweise moderner Spionage- und Angriffsökonomien. Das reale Bedrohungsszenario trägt in Sicherheitsbehörden weltweit den Namen „Harvest Now, Decrypt Later“ (HNDL) – im deutschen Sprachraum des BSI auch als „Store Now, Decrypt Later“ (SNDL) bezeichnet.

Das Prinzip ist ebenso nüchtern wie folgenschwer: Staatliche Akteure und spezialisierte Angreifergruppen müssen heute noch keinen fehlertoleranten Quantencomputer besitzen, um heutige Kommunikation zu kompromittieren. Sie schneiden verschlüsselte Datenströme – etwa Standort-zu-Standort-VPNs, HTTPS-API-Verkehr, E-Mail-Transporte (SMTP/STARTTLS) oder administrative SSH-Sitzungen – bereits heute passiv auf Glasfaserknoten und Internet-Exchanges mit und speichern die Chiffretexte in großen Datenarchiven. Speicherplatz kostet im Jahr 2026 fast nichts mehr.

Sobald ein kryptografisch relevanter Quantencomputer (Cryptographically Relevant Quantum Computer, CRQC) verfügbar ist, löst der bereits 1994 von Peter Shor formulierte Shor-Algorithmus das Faktorisierungsproblem großer ganzer Zahlen sowie das diskrete Logarithmusproblem (auch über elliptischen Kurven) in polynomieller Zeit. Damit brechen sämtliche klassischen asymmetrischen Schlüsselaustausch- und Signaturverfahren, auf denen das heutige Internet ruht:

• RSA (unabhängig davon, ob 2048, 3072 oder 4096 Bit verwendet werden),
• Klassisches Diffie-Hellman (DH / FFDHE),
• Elliptic Curve Diffie-Hellman (ECDH / ECDHE) wie X25519, secp256r1 (P-256) und secp384r1 (P-384),
• ECDSA und EdDSA (Ed25519) bei digitalen Signaturen.

Zwar schützt klassisches Perfect Forward Secrecy (PFS) mittels ephemerem Diffie-Hellman (ECDHE) heute davor, dass der spätere Diebstahl eines privaten Serverzertifikats vergangene Sitzungen kompromittiert. Gegen einen Quantencomputer hilft klassisches ECDHE jedoch nicht: Denn der Quantencomputer berechnet den privaten Sitzungsschlüssel direkt aus dem im aufgezeichneten TLS-Handshake öffentlich übertragenen ephemeren ECDHE-Public-Key zurück und entschlüsselt anschließend den gesamten symmetrischen Datenstrom (z. B. AES-GCM).

Die Mosca-Ungleichung (X + Y > Z): Der Kryptologe Prof. Michele Mosca hat dieses Zeitproblem in eine prägnante Formel gefasst:

X (Jahre, die Ihre übertragenen Daten vertraulich bleiben müssen) + Y (Jahre, die Ihr Unternehmen für die vollständige Krypto-Migration aller Systeme benötigt) > Z (Jahre bis zur Verfügbarkeit eines kryptografisch relevanten Quantencomputers).

Müssen Ihre Geschäftsgeheimnisse, Konstruktionspläne, Patientendaten oder Finanztransaktionen beispielsweise X = 10 Jahre vertraulich bleiben und dauert die Umstellung Ihrer IT-Landschaft Y = 3 Jahre, dann ist Ihre Organisation bereits heute im Verzug, sobald Z ≤ 13 Jahre beträgt.

Symmetrische Algorithmen wie AES und Hashfunktionen wie SHA-2 / SHA-3 sind vom Shor-Algorithmus hingegen nicht betroffen. Hier bewirkt der Grover-Algorithmus lediglich eine quadratische Beschleunigung der Suche, was einer Halbierung des effektiven Sicherheitsniveaus entspricht: Aus AES-256 bleiben unter Quantenbedingungen weiterhin hochsichere 128 Bit effektive Sicherheit übrig. Die Achillesferse der heutigen Transportverschlüsselung liegt also exakt im asymmetrischen Schlüsselaustausch während des Verbindungsaufbaus.

3. Alle gesetzlichen Grundlagen im Überblick: NIS-2, § 30 & § 38 BSIG, DORA, DSGVO und CRA

Warum ist dieses physikalisch-mathematische Thema gleichzeitig eine unmittelbare Rechtsfrage? Weil das europäische und deutsche Sicherheitsrecht keine starren Algorithmen im Gesetzestext festschreibt, sondern über dynamische Verweisungsklauseln den „Stand der Technik“ (und die einschlägigen europäischen und internationalen Normen sowie Technischen Richtlinien des BSI) zum verbindlichen Rechtsmaßstab erhebt.

Gesetz / Rechtsnorm	Regelungsgehalt für Kryptografie & Quanten-Sicherheit	Adressaten & Sanktionsrahmen	Offizielle Quelle
Art. 21 Abs. 2 lit. h NIS-2-Richtlinie (RL (EU) 2022/2555)	Verpflichtet wesentliche und wichtige Einrichtungen zu technischen und organisatorischen Risikomanagementmaßnahmen unter Berücksichtigung des Stands der Technik, ausdrücklich inklusive „Konzepten und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung“ sowie Lieferkettensicherheit (Art. 21 Abs. 2 lit. d).	Wesentliche & wichtige Einrichtungen in 18 Sektoren (Anhang I & II NIS-2); Art. 34 sieht bis zu 10 Mio. € bzw. 2 % Jahresumsatz vor.	EUR-Lex: RL (EU) 2022/2555
§ 30 Abs. 1 & Abs. 2 Nr. 8 BSIG (i. d. F. des NIS2UmsuCG)	Nationale Umsetzung im BSI-Gesetz: Einrichtungen müssen geeignete, verhältnismäßige und wirksame Maßnahmen ergreifen, wobei die Einhaltung des Stands der Technik sicherzustellen ist (§ 30 Abs. 1 S. 2 BSIG). § 30 Abs. 2 Nr. 8 BSIG nennt explizit Konzepte und Verfahren für Kryptografie und Verschlüsselung; Nr. 4 regelt die Sicherheit der Lieferkette.	Besonders wichtige und wichtige Einrichtungen gem. § 28 BSIG (i. d. R. ab 50 Mitarbeitenden oder > 10 Mio. € Umsatz & Bilanzsumme in den Sektoren der Anlagen 1 und 2 BSIG).	Gesetze im Internet: BSIG
§ 38 BSIG & § 65 BSIG (Geschäftsleiterhaftung & Bußgelder)	§ 38 Abs. 1 BSIG: Geschäftsleiter sind verpflichtet, die Risikomanagementmaßnahmen nach § 30 BSIG umzusetzen, deren Umsetzung zu überwachen und regelmäßig an Schulungen teilzunehmen. § 38 Abs. 2 BSIG: Persönliche Schadensersatzhaftung der Geschäftsleiter gegenüber der Einrichtung bei schuldhafter Pflichtverletzung.	Geschäftsführer, Vorstände und Leitungsorgane persönlich (§ 38 BSIG); Bußgelder nach § 65 BSIG bis 10 Mio. € / 2 % Umsatz (besonders wichtige) bzw. 7 Mio. € / 1,4 % (wichtige Einrichtungen).	§§ 38, 65 BSIG
Art. 9 & Art. 28 DORA (VO (EU) 2022/2554) i. V. m. Art. 6–7 DelVO (EU) 2024/1774	Finanzunternehmen müssen eine dokumentierte Kryptografie-Richtlinie sowie ein vollständiges Schlüsselmanagement implementieren. Nach Art. 6 Abs. 3 der RTS (DelVO 2024/1774) müssen kryptografische Verfahren dem Stand der Technik entsprechen und bei Schwächung unverzüglich ersetzt werden (Krypto-Agilität & Bestandsregister).	Banken, Versicherungen, Wertpapierfirmen, Zahlungsdienstleister, Krypto-Dienstleister sowie kritische IKT-Drittdienstleister (Art. 28 ff. DORA).	EUR-Lex: DORA & DelVO 2024/1774
Art. 32 Abs. 1 lit. a DSGVO (VO (EU) 2016/679)	Verpflichtet Verantwortliche und Auftragsverarbeiter unter Berücksichtigung des Stands der Technik zur Verschlüsselung personenbezogener Daten. Bei sensiblen Daten mit langer Schutzbedürftigkeit (z. B. Gesundheits-, Steuer-, Personal- oder Mandantendaten) begründet HNDL ein relevantes Ausfallrisiko klassischer Transportverschlüsselung.	Alle Unternehmen und Behörden, die personenbezogene Daten verarbeiten (Art. 83 Abs. 4 DSGVO: bis zu 10 Mio. € oder 2 % Jahresumsatz).	EUR-Lex: DSGVO Art. 32
Cyber Resilience Act (CRA) (VO (EU) 2024/2847)	Hersteller von Produkten mit digitalen Elementen (Hardware & Software) müssen nach Anhang I Teil I Nr. 2 lit. f die Vertraulichkeit und Integrität von Daten durch modernste kryptografische Mechanismen schützen und Schwachstellen über den gesamten Lebenszyklus beheben.	Hersteller, Importeure und Händler vernetzter Software- und Hardwareprodukte im EU-Binnenmarkt (bis zu 15 Mio. € oder 2,5 % Umsatz).	EUR-Lex: CRA 2024/2847
EU-PQC-Empfehlung (Empfehlung (EU) 2024/1101)	Koordinierter Umsetzungsfahrplan der EU-Kommission für den Übergang zur Post-Quanten-Kryptografie: Bestandsaufnahme (Krypto-Inventar / CBOM), Einsatz hybrider Verfahren und synchronisierte Migration der digitalen Infrastrukturen in Europa.	Mitgliedstaaten, Betreiber kritischer und wichtiger Infrastrukturen, öffentliche Verwaltung und Lieferketten.	EUR-Lex: Empf. 2024/1101

4. § 38 BSIG und Lieferkettensicherheit (§ 30 Abs. 2 Nr. 4 BSIG): Warum auch der Mittelstand betroffen ist

Viele kleinere und mittlere Unternehmen wiegen sich in falscher Sicherheit, wenn sie die Schwellenwerte des § 28 BSIG (in der Regel mindestens 50 Beschäftigte oder mehr als 10 Millionen Euro Jahresumsatz und Jahresbilanzsumme in einem der 18 NIS-2-Sektoren der Anlagen 1 und 2 BSIG) betrachten und feststellen, dass sie selbst formal nicht als „besonders wichtige“ oder „wichtige Einrichtung“ registrierungspflichtig sind. Doch NIS-2 entfaltet in der Praxis eine enorme Sogwirkung weit über den Kreis der unmittelbar regulierten Unternehmen hinaus – und zwar über zwei gesetzliche Hebel:

Hebel 1: Die gesetzliche Lieferkettenpflicht (§ 30 Abs. 2 Nr. 4 BSIG / Art. 21 Abs. 2 lit. d NIS-2)

Jede unter NIS-2 fallende Einrichtung – vom Stadtwerk über das Krankenhaus, den Maschinenbauer, das Logistikunternehmen und den Cloud-Anbieter bis zur Lebensmittelkette – ist gesetzlich verpflichtet, die Sicherheit der Lieferkette einschließlich der sicherheitsbezogenen Aspekte der Beziehungen zu ihren unmittelbaren Anbietern und Diensteanbietern zu gewährleisten. Bei der Auswahl und Überwachung von IT-Dienstleistern, Softwarehäusern, Managed-Service-Providern (MSPs), Web-Agenturen, SaaS-Plattformen und Zulieferern müssen diese Einrichtungen nach § 30 Abs. 2 Nr. 4 BSIG die Gesamtqualität und Cybersicherheitspraxis der Lieferanten prüfen.

In der Praxis bedeutet das: Selbst ein IT-Dienstleister mit zwölf Mitarbeitenden erhält von seinen Unternehmenskunden heute verbindliche Sicherheitsfragebögen, in denen er darlegen muss, ob seine Web-, API-, Mail- und Administrationsschnittstellen nach den Empfehlungen der BSI TR-02102-2 konfiguriert sind, ob TLS 1.0/1.1 abgeschaltet ist, ob ein dokumentiertes Kryptokonzept vorliegt und wie die Roadmap für Post-Quanten-Kryptografie (ML-KEM) aussieht. Wer hier keine belastbare technische Dokumentation und kein maschinenlesbares Krypto-Inventar (CBOM) vorlegen kann, riskiert bei Ausschreibungen und Vertragsverlängerungen den Verlust wichtiger B2B-Auftraggeber.

Hebel 2: Die persönliche Geschäftsleiterhaftung (§ 38 BSIG)

Mit § 38 BSIG (in Umsetzung von Art. 20 NIS-2) hat der Gesetzgeber eine bemerkenswerte Durchbrechung der klassischen Delegation eingeführt. Geschäftsleiter können IT-Sicherheit nicht mehr mit dem Hinweis „Dafür haben wir doch einen IT-Leiter oder externen Systemadministrator“ von sich weisen. Sie müssen:

1. die von der Einrichtung ergriffenen Risikomanagementmaßnahmen nach § 30 BSIG (einschließlich des Kryptokonzepts nach § 30 Abs. 2 Nr. 8 BSIG) billigen und deren Umsetzung überwachen (§ 38 Abs. 1 BSIG),
2. regelmäßig an Schulungen teilnehmen, um ausreichende Kenntnisse und Fähigkeiten zur Erkennung und Bewertung von Risiken der Informationstechnik zu erwerben (§ 38 Abs. 3 BSIG).

Verletzen Geschäftsleiter diese Pflichten schuldhaft, haften sie ihrer Einrichtung nach § 38 Abs. 2 BSIG für den entstandenen Schaden nach den auf die Rechtsform der Einrichtung anwendbaren gesellschaftsrechtlichen Vorschriften (etwa § 43 Abs. 2 GmbHG oder § 93 Abs. 2 AktG). Ein Verzicht oder Vergleich der Gesellschaft über diese Ersatzansprüche ist grundsätzlich unwirksam. Eine regelmäßige, objektiv messbare Stichtagsprüfung der eigenen Domains samt dokumentierter Management-Zusammenfassung und Kenntnisnahme ist daher eines der wirksamsten Instrumente, um dieser Überwachungspflicht nachweisbar nachzukommen.

5. Der Stand der Technik im Detail: BSI TR-02102, BSI TR-03108 (DANE) und NIST FIPS 203 (ML-KEM)

Was bedeutet „Stand der Technik“ bei der Transportverschlüsselung heute konkret? Im deutschen Rechtsraum geben die Technischen Richtlinien des BSI der Reihe TR-02102 (ergänzt durch die BSI TR-03108 für E-Mail-Sicherheit) die maßgeblichen fachlichen Empfehlungen vor. Obwohl Technische Richtlinien des BSI formal keine Gesetze sind, werden sie von Aufsichtsbehörden, Gerichten, Wirtschaftsprüfern und Cyberversicherern regelmäßig herangezogen, um den unbestimmten Rechtsbegriff des „Stands der Technik“ in § 30 Abs. 1 Satz 2 BSIG und Art. 32 Abs. 1 DSGVO fachlich auszufüllen.

Warum das „Hybride Prinzip“ der Goldstandard der Post-Quanten-Migration ist

Weder das BSI noch die europäische Agentur ENISA empfehlen einen abrupten Austausch bewährter klassischer Algorithmen gegen reine Post-Quanten-Verfahren im Alleingang. Stattdessen gilt in der BSI TR-02102-1 und TR-02102-2 das Prinzip der kryptografischen Hybridisierung:

Bei einem hybriden Schlüsselaustausch – wie der von der IETF für TLS 1.3 spezifizierten Gruppe X25519MLKEM768 oder SecP256r1MLKEM768 – werden zwei unabhängige Schlüsselaustauschverfahren parallel durchgeführt und ihre Geheimnisse über eine Key Derivation Function (HKDF) im TLS-1.3-Key-Schedule miteinander verknüpft:

• Komponente 1 (Klassisch): Elliptische-Kurven-Diffie-Hellman (X25519 oder secp256r1 / P-256) – seit Jahrzehnten intensiv kryptoanalysiert und gegen alle bekannten klassischen Computerangriffe sicher.
• Komponente 2 (Post-Quanten): Der im August 2024 vom NIST als FIPS 203 finalisierte Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM-768 bzw. ML-KEM-1024, hervorgegangen aus CRYSTALS-Kyber). Seine Sicherheit beruht auf der mathematischen Schwierigkeit des Module Learning With Errors (M-LWE)-Problems in hochdimensionalen Gittern, gegen das weder klassische Supercomputer noch Quantencomputer mit Shor-Algorithmus einen effizienten Angriff kennen.

Der entscheidende Vorteil dieser Kombination: Die Verbindung bleibt selbst dann vollständig geschützt, wenn eines der beiden Verfahren versagen sollte. Sollte in Zukunft ein Quantencomputer X25519 brechen, schützt ML-KEM-768 das Geheimnis. Sollte umgekehrt jemals eine unerwartete mathematische Schwäche in einem neuen Gitterverfahren entdeckt werden, garantiert X25519 weiterhin mindestens das volle klassische Sicherheitsniveau. Gleichzeitig bleiben Server durch eine geordnete Kurvenliste (Fallback auf X25519:secp384r1:secp256r1) zu 100 % abwärtskompatibel mit älteren Browsern und Clients.

Einsatzbereich / Protokoll	Richtlinie / Standard	Klassische Mindestanforderung	Empfohlener Post-Quanten-Hybrid-Standard (2026)
HTTPS / Web / REST-APIs (Port 443, 8443)	BSI TR-02102-2 & NIST FIPS 203	TLS 1.3 (bevorzugt) oder TLS 1.2 ausschließlich mit PFS (ECDHE) & AEAD (AES-GCM, ChaCha20-Poly1305); TLS 1.0/1.1 & Session-Tickets aus; RSA-Zertifikate ≥ 3000 Bit (3072/4096 Bit) oder ECDSA (P-256/P-384).	TLS 1.3 mit hybriden Key-Shares: X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024 (OpenSSL ≥ 3.5 / Caddy 2.8+ / HAProxy / Nginx).
Secure Shell (SSH) (Port 22 & Sonderports wie 2222)	BSI TR-02102-4 & NIST FIPS 203	SSH-2.0 mit curve25519-sha256 oder diffie-hellman-group16/18-sha512; AEAD-Ciphers (chacha20-poly1305, aes256-gcm); EtM-MACs (hmac-sha2-*-etm); kein SHA-1 / ssh-rsa.	Hybride SSH-KEX-Algorithmen: mlkem768x25519-sha256 (ab OpenSSH 9.9), sntrup761x25519-sha512@openssh.com (Standard ab OpenSSH 9.0).
E-Mail-Transport (SMTP) (Port 25, 465, 587)	BSI TR-03108 & BSI TR-02102-2	STARTTLS mit TLS 1.2/1.3, DNSSEC-Signierung der Zone, DANE / TLSA Resource Records (RFC 6698/7672), ergänzend MTA-STS, SPF, DKIM und DMARC (p=quarantine / p=reject).	STARTTLS über TLS 1.3 mit hybriden Schlüsselaustauschgruppen (z. B. Postfix mit OpenSSL ≥ 3.5) + DANE/TLSA.
Digitale Signaturen & PKI (X.509 / Code-Signing)	BSI TR-02102-1, FIPS 204 / FIPS 205	ECDSA (P-256 / P-384), Ed25519 oder RSA mit SHA-256/384/512 und Schlüssellänge ≥ 3000 Bit.	Schrittweise Vorbereitung auf gitterbasierte Signaturen (ML-DSA / FIPS 204, ehemals Dilithium) und hashbasierte Signaturen (SLH-DSA / FIPS 205, SPHINCS+) sowie zusammengesetzte Hybrid-Zertifikate.

Typische Schwachstellen, die bei externen Prüfungen immer wieder auffallen

Wenn wir auf sichergenug.de reale Unternehmens-Domains prüfen, zeigt sich selten ein einzelner Totalausfall auf der Hauptdomain www.unternehmen.de. Das Hauptportal ist meist ordentlich gepflegt. Die kritischen Abweichungen verbergen sich fast immer in der zweiten Reihe:

1. Vergessene Subdomains in Certificate-Transparency-Logs (crt.sh): Alte Testsysteme (staging., dev.), Kundenportale, Webmail-Instanzen, VPN-Gateways oder Fernwartungszugänge, die noch TLS 1.0/1.1 sprechen oder abgelaufene bzw. 2048-Bit-RSA-Zertifikate ohne Perfect Forward Secrecy ausliefern.
2. Verschobene Administrations- und SSH-Ports: Viele Administratoren verlegen SSH von Port 22 auf Port 2222 oder 22222 oder betreiben Virtualisierungs- und Management-Oberflächen auf Ports wie 8006 (Proxmox), 8443 oder 9443 – in der Hoffnung, durch „Security by Obscurity“ unsichtbar zu sein. Automatisierte Scanner finden diese Ports binnen Sekunden; häufig laufen dort veraltete SSH-Schlüsselaustauschgruppen (diffie-hellman-group14-sha1) ohne Post-Quanten-Schutz.
3. Fehlende DANE/TLSA-Absicherung beim E-Mail-Verkehr: Obwohl ein Mailserver STARTTLS anbietet, fehlt häufig die DNSSEC-gesicherte Hinterlegung eines _25._tcp.mail... TLSA-Eintrags nach BSI TR-03108. Ohne DANE oder zumindest striktes MTA-STS kann ein aktiver Man-in-the-Middle-Angreifer den Verbindungsaufbau per Strip-TLS auf unverschlüsselten Klartext herabstufen.

6. Krypto-Agilität und Nachweisführung: Warum ein CycloneDX v1.6 CBOM unverzichtbar wird

Wer weder weiß, welche Subdomains, Ports, Zertifikate und kryptografischen Primitiven in seiner Infrastruktur aktiv sind, kann weder ein belastbares Kryptokonzept nach § 30 Abs. 2 Nr. 8 BSIG noch ein IKT-Kryptoregister nach Art. 9 DORA / DelVO (EU) 2024/1774 führen. Genau deshalb fordern sowohl der BSI-Leitfaden zur Migration auf Post-Quanten-Kryptografie als auch die EU-Empfehlung (EU) 2024/1101 als allerersten Schritt den Aufbau eines strukturierten Krypto-Inventars und die Herstellung von Krypto-Agilität.

Während in der Softwareentwicklung die Software Bill of Materials (SBOM) längst etabliert ist, hat sich für die Kryptografie der offene Standard OWASP CycloneDX v1.6 CBOM (Cryptographic Bill of Materials) durchgesetzt. Eine cbom.json-Datei dokumentiert maschinenlesbar und revisionssicher für jeden gemessenen Netzwerk-Endpunkt:

• das eingesetzte Transportprotokoll (z. B. TLSv1.3, SSH-2.0) und die aktiven Cipher-Suites,
• das ausgehandelte Schlüsselaustauschverfahren (z. B. X25519MLKEM768 vs. klassisches X25519) einschließlich des NIST-Quanten-Sicherheitslevels (nistQuantumSecurityLevel),
• die Parameter der X.509-Zertifikatskette (Algorithmus, Schlüssellänge in Bit, Signatur-Hash, Gültigkeitsdauer, Aussteller),
• die kryptografischen Eigenschaften von E-Mail- und DNS-Sicherheitsmechanismen (DANE/TLSA, DNSSEC, MTA-STS, SPF, DMARC).

Ein solches CycloneDX-CBOM lässt sich direkt in GRC-, SIEM- und Vulnerability-Management-Plattformen (wie Dependency-Track) importieren oder als technischer Nachweis an Kunden in der Lieferkette (§ 30 Abs. 2 Nr. 4 BSIG) und Prüfer übergeben.

7. Praxis-Fahrplan: In 5 Schritten zur NIS-2- und Post-Quanten-Bereitschaft

Die gute Nachricht lautet: Die Umstellung der externen Transportverschlüsselung auf die Empfehlungen der BSI TR-02102 und auf hybride Post-Quanten-Kryptografie erfordert in aller Regel keine teure Spezialhardware. Sie ist mit moderner Open-Source-Standardsoftware im laufenden Betrieb (Zero-Downtime) umsetzbar, wenn man strukturiert vorgeht:

1. Schritt 1 – Externe Bestandsaufnahme & Schatten-IT aufdecken: Ermitteln Sie über Certificate-Transparency-Register (crt.sh) und DNS-Analysen sämtliche öffentlich sichtbaren Subdomains Ihrer Organisation – einschließlich vergessener Projekt-, VPN-, Mail- und Administrations-Hosts sowie verschobener Nebenports. Einen sofortigen Überblick liefert unser kostenfreier Live-Krypto-Check auf sichergenug.de.
2. Schritt 2 – Krypto-Inventar (CycloneDX v1.6 CBOM) & Stichtagsbericht erstellen: Überführen Sie die Messergebnisse in ein strukturiertes Krypto-Inventar (cbom.json & CSV) sowie einen dokumentierten Prüfbericht, der Abweichungen von den Empfehlungen der BSI TR-02102-2/-4 und TR-03108 nach Kritikalität priorisiert.
3. Schritt 3 – Server-Konfigurationen auf Hybrid-PQC (ML-KEM) härten:
   • Aktualisieren Sie Ihre Webserver und Reverse Proxies (Nginx, Apache httpd, Caddy, HAProxy) auf einen TLS-Stack mit OpenSSL ≥ 3.5 (bzw. Go/BoringSSL in Caddy) und stellen Sie die hybriden Schlüsselaustauschgruppen an die erste Stelle, mit klassischen Gruppen als Rückfallebene für ältere Clients.
   • Deaktivieren Sie TLS 1.0, TLS 1.1, schwache CBC-Chiffren und statische TLS-Session-Tickets.
   • Härten Sie OpenSSH-Server (ab OpenSSH 9.9 mit mlkem768x25519-sha256 bzw. ab OpenSSH 9.0 mit sntrup761x25519-sha512@openssh.com) gemäß BSI TR-02102-4.
   • Sichern Sie Ihre Mail-Gateways (Postfix/Exim) mittels DNSSEC und DANE/TLSA nach BSI TR-03108 ab.
4. Schritt 4 – Interne Kryptografie-Richtlinie & Lieferanten-Abfrage verankern: Verabschieden Sie eine schriftliche, auf Ihre Organisation angepasste Kryptografie-Richtlinie (Kryptokonzept zu § 30 Abs. 2 Nr. 8 BSIG), in der Mindestschlüssellängen, erlaubte Protokolle, Zykluszeiten für den Zertifikatswechsel (Krypto-Agilität) und Ausnahmeregelungen festgehalten sind. Ergänzen Sie Ihr Lieferantenmanagement (§ 30 Abs. 2 Nr. 4 BSIG) um einen standardisierten Krypto-Fragebogen und Multi-Faktor-Authentifizierung (MFA nach § 30 Abs. 2 Nr. 10 BSIG).
5. Schritt 5 – Management-Kenntnisnahme (§ 38 BSIG) & regelmäßige Wiederholungsprüfung: Legen Sie die Management-Zusammenfassung und den Krypto-Prüfbericht der Geschäftsleitung zur dokumentierten Kenntnisnahme und Maßnahmenfreigabe vor und wiederholen Sie die Prüfung regelmäßig sowie nach größeren Infrastrukturänderungen.

8. Häufig gestellte Fragen (FAQ) zu NIS-2, BSIG & Post-Quanten-Kryptografie

9. Offizielle Gesetzesquellen, Technische Richtlinien & weiterführende Verlinkungen

A) Europäische & deutsche Rechtsgrundlagen

• Richtlinie (EU) 2022/2555 (NIS-2-Richtlinie) im Amtsblatt der Europäischen Union (EUR-Lex) – insbesondere Art. 20 (Governance), Art. 21 Abs. 2 lit. d (Lieferkette) und lit. h (Kryptografie und Verschlüsselung).
• Gesetz über das Bundesamt für Sicherheit in der Informationstechnik (BSIG) auf gesetze-im-internet.de – insbesondere § 28 (Anwendungsbereich), § 30 Abs. 1 & Abs. 2 Nr. 4 und Nr. 8 (Risikomanagement & Kryptokonzepte), § 32 (Meldepflichten), § 38 (Billigungs-, Überwachungs- und Schulungspflicht der Geschäftsleitung) sowie § 65 (Bußgeldvorschriften).
• Verordnung (EU) 2022/2554 – Digital Operational Resilience Act (DORA) sowie Delegierte Verordnung (EU) 2024/1774 (RTS zum IKT-Risikomanagement, Art. 6 & 7 zur Kryptografie).
• Verordnung (EU) 2016/679 – Datenschutz-Grundverordnung (DSGVO), Art. 32 (Sicherheit der Verarbeitung).
• Verordnung (EU) 2024/2847 – Cyber Resilience Act (CRA).
• Empfehlung (EU) 2024/1101 der Kommission über einen koordinierten Umsetzungsfahrplan für den Übergang zur Post-Quanten-Kryptografie.

B) Technische Richtlinien & internationale Standards (BSI, NIST, ENISA, OWASP)

• BSI TR-02102: Kryptographische Verfahren – Empfehlungen und Schlüssellängen (Teil 1, Teil 2: TLS, Teil 4: SSH).
• BSI TR-03108: Sicherer E-Mail-Transport (STARTTLS, DNSSEC & DANE/TLSA).
• BSI: Quantentechnologien und Post-Quanten-Kryptografie – Leitfäden zur Migration.
• BSI: Informationen für NIS-2-regulierte Unternehmen.
• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM) sowie NIST FIPS 204 (ML-DSA) und NIST FIPS 205 (SLH-DSA).
• ENISA: Post-Quantum Cryptography – Current State and Quantum Mitigation.
• OWASP CycloneDX v1.6: Cryptographic Bill of Materials (CBOM) Specification.

C) Weiterführende Beiträge & Werkzeuge auf sichergenug.de

• Live-Krypto-Check orientiert an BSI TR-02102: Kostenfreie Direkt-Auswertung Ihrer Domain inkl. Prüfbericht (mind. 15 Seiten) & CycloneDX v1.6 CBOM
• Was ist MFA? Eine einfache Erklärung der Multi-Faktor-Authentifizierung (§ 30 Abs. 2 Nr. 10 BSIG)
• Wenn die Server frieren lernen – Physische und technische Resilienz von Rechenzentren
• Urlaubsvertretung Sicherheitsrisiko: Die unterschätzte Gefahr im leeren Büro
• Unverzichtbare Awareness Days: Warum IT-Sicherheit jetzt zur Kulturfrage wird
• Wichtige Anlaufstellen bei Cybervorfällen (BSI & ZAC)