NIST-PQC-Standards im Unternehmensnetzwerk: Was heute umsetzbar ist

Das Wichtigste im Überblick

• Drei Standards sind final, weitere sind in Entwicklung. FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) wurden am 13. August 2024 veröffentlicht und sind seit dem 14. August 2024 in Kraft (Quelle: Federal Register, Announcing Issuance of FIPS 203, FIPS 204 and FIPS 205). Weitere PQC-Standards befinden sich in Entwicklung: NIST arbeitet an FIPS 206 für FALCON, dort FN-DSA genannt, und an einem zusätzlichen KEM-Standard auf Basis von HQC. NIST führt FALCON ausdrücklich als Algorithmus, der in FIPS 206 veröffentlicht werden soll, mit dem Status „in development“ (Quelle: NIST, PQC-Standardisierungsprozess, Stand 05.08.2026); HQC wurde mit dem Statusbericht zur vierten Runde vom 11. März 2025 als einziges weiteres Verfahren zur Schlüsseleinigung ausgewählt (Quellen: NIST IR 8545; NIST, Auswahl von HQC). Beide waren bis Oktober 2026 nicht als finale FIPS veröffentlicht.
• Der hybride TLS-1.3-Schlüsselaustausch ist standardisiert. RFC 9954 (Juli 2026, Informational) beschreibt das Konstruktionsprinzip hybrider Schlüsselaustausche in TLS 1.3 (Quelle: RFC 9954). RFC 10024 (August 2026, Standards Track) standardisiert die konkreten hybriden Gruppen X25519MLKEM768, SecP256r1MLKEM768 und SecP384r1MLKEM1024 (Quelle: RFC 10024). Von diesen führt das IANA-Register allein X25519MLKEM768 als „Recommended“ (Quelle: IANA, TLS Supported Groups).
• Für öffentlich vertrauenswürdige TLS-Serverzertifikate fehlt noch der Beschluss des CA/Browser Forums. Zum Stand September 2026 existierte kein verabschiedeter CA/Browser-Forum-Standard für ML-DSA, und bis Oktober 2026 ist keiner hinzugekommen. Laut Protokoll vom 13. August 2026 steht ein gemeinsamer Entwurf kurz vor der Fertigstellung, am 10. September 2026 wurde kein Fortschritt berichtet (Quellen: CA/Browser Forum, Protokoll vom 13.08.2026; CA/Browser Forum, Protokoll vom 10.09.2026). Für S/MIME wurden ML-DSA und ML-KEM dagegen mit Ballot SMC013 zum 22. August 2025 in die Baseline Requirements aufgenommen (Quelle: CA/Browser Forum, Ballot SMC013).
• Die Größen sind das eigentliche Problem. Für eine typische Zertifikatskette mit ML-DSA-44 und den Nachweisen der Certificate Transparency rechnet Red Sift die kryptografischen Anteile eines TLS-Handshakes, also Signaturen und öffentliche Schlüssel, auf rund 14.700 bis 18.600 Byte hoch, gegenüber etwa 586 Byte mit ECDSA (Quelle: Red Sift, Why post-quantum signatures are breaking TLS handshake limits). Die Werte hängen von Kettenlänge, Parametersatz und Kodierung ab. RFC 6928 hebt die zulässige obere Grenze des TCP Initial Window auf bis zu zehn Segmente beziehungsweise maximal 14.600 Byte an; Implementierungen können ein kleineres Fenster verwenden (Quelle: RFC 6928).
• Automatisierung ist Voraussetzung. Die maximale Laufzeit öffentlich vertrauenswürdiger TLS-Subscriber-Zertifikate sinkt stufenweise: 398 Tage bis zum 14. März 2026, seit dem 15. März 2026 200 Tage, ab dem 15. März 2027 100 Tage und ab dem 15. März 2029 47 Tage (Quelle: CA/Browser Forum, Ballot SC-081v3). Manuelle Erneuerungsprozesse werden mit den kürzer werdenden Laufzeiten zunehmend zu einem operativen Risiko, zusätzlich zur PQC-Umstellung.

Welche PQC-Parametersätze sind relevant und für welchen Einsatzkontext?

Die Parametersätze sind in der Praxis wichtiger als die Standardnummern, weil sie den Einsatzkontext bestimmen. ML-KEM-768 ist der NIST-Sicherheitskategorie 3 zugeordnet und der naheliegende Ausgangspunkt für den allgemeinen Unternehmenseinsatz (Quelle: NIST, FIPS 203). RFC 10024 standardisiert X25519MLKEM768 als hybride TLS-1.3-Gruppe; sie kombiniert das weit verbreitete X25519 mit ML-KEM-768 (Quelle: RFC 10024), und nur diese Post-Quantum-Gruppe führt das IANA-Register als empfohlen (Quelle: IANA, TLS Supported Groups). Dass die Gruppe im Web auch tatsächlich zum Einsatz kommt, zeigen die Standardeinstellungen aktueller Browser (Quellen: Google Security Blog; Firefox 132; Apple Support). ML-KEM-1024 und ML-DSA-87 gehören in Umgebungen mit höherem Schutzbedarf und sind verbindlich, wo CNSA 2.0 gilt, also im Umfeld US-amerikanischer National Security Systems (Quelle: NSA, CNSA 2.0 FAQ). Das BSI empfiehlt ML-KEM-768 und ML-KEM-1024, bei Signaturen ML-DSA-65 und ML-DSA-87, jeweils in der „hedged“-Variante (Quelle: BSI, TR-02102-1, Version 2026-01, Tabellen 2.7 und 5.7). SLH-DSA ist die konservative Rückfalloption mit großen Signaturen, gedacht für Fälle, in denen die Gitterannahme vermieden werden soll (Quelle: NIST, FIPS 205). Für Firmware- und Softwaresignaturen kommen LMS und XMSS nach SP 800-208 infrage, zustandsbehaftete hashbasierte Signaturen, die ein sorgfältiges State Management verlangen und deshalb nicht für den allgemeinen Einsatz gedacht sind (Quelle: NIST, SP 800-208).

Wo im Unternehmensnetz greifen die Standards zuerst?

Aus der Tabelle lässt sich eine praktische Regel ableiten: Der von außen sichtbare Teil ist überwiegend durch Aktualisierungen von Browsern und Bibliotheken abgedeckt. Der interne Teil ändert sich erst, wenn er im eigenen Haus geplant wird.

Die Warnung erscheint im ssh-Client, nicht im Serverprotokoll (Quelle: OpenSSH 10.1 Release Notes). Als Hinweisgeber taugt sie trotzdem: Wer die Meldungen im Administrationsteam sammelt, erkennt Gegenstellen, die noch klassisch verhandeln. Ein vollständiges Inventar ersetzt das nicht. Wie schnell ein Unternehmen tatsächlich ein repräsentatives Bild erhält, hängt von der Verbindungsfrequenz, dem überwachten Netzwerksegment und der Logging-Abdeckung ab. Als Diagnose für einzelne Verbindungen ist eine erhöhte Protokollierung möglich, als dauerhafte Inventarisierung ist sie nicht geeignet: Die OpenBSD-Dokumentation zu sshd_config hält zum LogLevel ausdrücklich fest, „Logging with a DEBUG level violates the privacy of users and is not recommended“ (Quelle: OpenBSD, sshd_config(5)).

Wie stark wachsen Schlüssel, Signaturen und Handshakes?

Die folgenden Werte beschreiben die algorithmischen Größen der öffentlichen Schlüssel, Signaturen beziehungsweise KEM-Ciphertexte; sie entsprechen nicht automatisch der Größe der jeweiligen X.509-, TLS- oder SSH-Strukturen (Quellen: NIST, FIPS 203, Tabelle 3; NIST, FIPS 204, Tabelle 2; NIST, FIPS 205, Tabelle 2; RFC 7748; RFC 8032; SEC 1; RFC 3279).

* Der Wert von 65 Byte bezieht sich auf den unkomprimierten P-256-Public-Key als elliptischen Kurvenpunkt; eine vollständige SubjectPublicKeyInfo- beziehungsweise X.509-Kodierung ist größer.
** Bei ECDSA ist die DER-kodierte Signatur nicht immer exakt 72 Byte groß; die konkrete Länge hängt von den kodierten r- und s-Werten ab.

Für den hybriden Schlüsselaustausch bedeutet das konkret: Der KeyShare für X25519MLKEM768 umfasst 1.216 Byte beim Client und 1.120 Byte beim Server. Gegenüber einem reinen X25519-KeyShare von 32 Byte kommen damit rund 1.184 beziehungsweise 1.088 Byte hinzu (Quelle: RFC 10024). Das ist verkraftbar und seit 2024 breit erprobt und eingesetzt: Chrome hatte den hybriden Schlüsselaustausch zunächst mit der damaligen Kyber-Entwurfsfassung für sämtliche Desktop-Clients aktiviert und mit Version 131 auf ML-KEM umgestellt, womit die Kyber-Variante entfiel (Quellen: Chromium Blog, Protecting Chrome Traffic with Hybrid Kyber KEM; Google Security Blog, A new path for Kyber on the web). Breit erprobt und eingesetzt heißt aber nicht final standardisiert: Die ML-KEM-basierte TLS-Hybridisierung wurde erst im August 2026 mit RFC 10024 standardisiert (Quelle: RFC 10024).

Bei Zertifikaten sieht die Rechnung anders aus. Nach Überschlagsrechnungen von Red Sift umfassen die kryptografischen Anteile einer typischen Kette, also Signaturen und öffentliche Schlüssel einschließlich der Nachweise der Certificate Transparency, mit ECDSA rund 586 Byte, mit RSA rund 1.712 Byte, mit ML-DSA-44 durchgängig rund 14.724 Byte und mit stärkeren Verfahren für Zwischen- und Wurzelzertifikat rund 18.640 Byte (Quelle: Red Sift, Why post-quantum signatures are breaking TLS handshake limits). Cloudflare kommt für ML-DSA auf einen vergleichbaren Zuwachs von rund 14,7 Kilobyte, gerechnet mit zwei öffentlichen Schlüsseln und fünf Signaturen (Quelle: Cloudflare, Another look at PQ signatures). Die Vergleichsgröße dazu: RFC 6928 hebt die zulässige obere Grenze des TCP Initial Window auf bis zu zehn Segmente beziehungsweise maximal 14.600 Byte an; Implementierungen können ein kleineres Fenster verwenden. Die Formel dort lautet min(10 × MSS, max(2 × MSS, 14.600 Byte)), und die Erhöhung ist ausdrücklich optional: „a TCP MAY start with an initial window that is smaller than 10 segments“ (Quelle: RFC 6928, Experimental, April 2013). Samt übrigem Handshake bedeutet das bei verbreiteten Einstellungen in der Regel einen zusätzlichen Roundtrip. Bei QUIC ist die relevante Grenze zunächst nicht ein TCP-Congestion-Window, sondern das Anti-Amplification-Limit: Vor erfolgreicher Adressvalidierung darf ein Server höchstens das Dreifache der von einem Client empfangenen Daten senden. Beim minimalen Client-Initial von 1.200 Byte sind das 3.600 Byte (Quelle: RFC 9000).

Cloudflare hat den Effekt in einem Experiment mit künstlich vergrößerten Handshakes gemessen, in dem zusätzliche Zertifikate eingefügt wurden: Weniger als neun Kilobyte Zusatzdaten verlängerten den Verbindungsaufbau um rund 15 Prozent (Quelle: Cloudflare, Another look at PQ signatures). In einem Cloudflare-Experiment wurde unter den dort verwendeten Testbedingungen für größere Zertifikatsketten und ein Initial Window von zehn Paketen eine Größenordnung von 60 bis 80 Prozent zusätzlicher Verbindungsaufbauzeit beobachtet beziehungsweise erwartet (Quelle: Cloudflare, Sizing Up Post-Quantum Signatures). Cloudflare weist selbst darauf hin, dass reale TLS-Handshakes hinsichtlich Zertifikaten und Erweiterungen erheblich variieren; es handelt sich also um experimentelle Ergebnisse unter bestimmten Bedingungen, nicht um allgemeingültige Werte. Je höher die Latenz, etwa im Mobilfunk, desto stärker fällt jeder zusätzliche Roundtrip ins Gewicht.

Für eingebettete Systeme ist der Speicherbedarf das härtere Kriterium. Eine frühere Fassung des IETF-Entwurfs zu PQC auf beschränkten Geräten nannte für das Signieren mit ML-DSA-65 auf Hardware der Cortex-M4-Klasse über 68 Kilobyte Arbeitsspeicher; speicheroptimierte Varianten kamen mit acht Kilobyte aus, waren dann aber deutlich langsamer, die Verifikation war mit drei bis zehn Kilobyte machbar. Eine spätere Fassung beziffert das Signieren mit ML-DSA-87 auf rund 79 Kilobyte, mit Lazy Expansion auf rund 12 Kilobyte; der Entwurf liegt inzwischen in der Fassung 07 vom 8. Oktober 2026 vor (Quelle: IETF, draft-ietf-pquip-pqc-hsm-constrained). Geräte mit acht bis sechzehn Kilobyte verfügbarem RAM stehen damit vor einer echten Abwägung.

Was bricht in bestehender Infrastruktur?

Drei Fehlerbilder treten wiederholt auf:

• Größenlimits und fehlerhafte Implementierungen. Als Cloudflare Origin-Servern von Kunden einen Post-Quantum-Schlüsselanteil anbot, kam bei weniger als 0,34 Prozent der Server keine Verbindung zustande. Die beobachteten Ausfälle wurden auf eine Reihe von Implementierungs- und Interoperabilitätsproblemen zurückgeführt; die bloße Größe des KeyShares war dabei nicht die einzige Fehlerursache (Quelle: Cloudflare, Post-quantum to origins). In einem separaten Experiment mit künstlich vergrößerten Handshakes, in die Dummy-Zertifikate eingefügt wurden, zeigten sich bei ungefähr 10 und 30 Kilobyte Zusatzdaten auffällige Einbrüche bei den erfolgreichen Verbindungen (Quelle: Cloudflare, Sizing Up Post-Quantum Signatures). Ein direkter Test mit realen ML-DSA-Zertifikatsketten war das nicht.
• Fragmentierung im ClientHello. Mit X25519MLKEM768 wächst der ClientHello um über ein Kilobyte. Das kann dazu führen, dass das ClientHello auf mehrere TCP-Segmente verteilt werden muss (Quelle: Cloudflare, Post-quantum to origins). Ein mehrteiliges ClientHello ist dabei nicht unzulässig: tldr.fail beschreibt ausdrücklich, dass TLS-Implementierungen das vollständige TLS-Record anhand seiner Längenangabe lesen müssen. Fehlerhafte Implementierungen in Proxys, Firewalls, Load Balancern und TLS-Terminierungen können jedoch nur einen Teil der Daten lesen und die Verbindung dadurch abbrechen (Quelle: tldr.fail). Chrome führte dafür ab Version 116 die Unternehmensrichtlinie PostQuantumKeyAgreementEnabled ein, mit der Administratoren den hybriden Schlüsselaustausch bei Kompatibilitätsproblemen abschalten konnten. Google bezeichnete sie ausdrücklich als Übergangsmaßnahme, „This policy will only be offered as a temporary measure“, und forderte Administratoren auf, mit den Herstellern der betroffenen Produkte an einer schnellen Fehlerbehebung zu arbeiten (Quelle: Chromium Blog, Protecting Chrome Traffic with Hybrid Kyber KEM); seit dem Wechsel auf ML-KEM gilt die Richtlinie für beide Verfahren (Quelle: Google Security Blog, A new path for Kyber on the web). Die Lösung liegt also beim Aktualisieren der betroffenen Netzwerkprodukte, nicht beim dauerhaften Abschalten über diese Richtlinie.
• Fest verdrahtete Algorithmenlisten. Anwendungen, die ihre unterstützten Gruppen und Algorithmen im Quellcode führen, verhandeln keine neue Gruppe, auch wenn die darunterliegende Bibliothek sie kennt. Bei TLS 1.3 sind Schlüsselaustauschgruppen wie X25519 oder X25519MLKEM768 nicht dasselbe wie Cipher Suites, weshalb eine moderne Bibliothek allein nicht genügt. Das fällt erst auf, wenn die klassische Option abgeschaltet wird.

Ein vierter Punkt betrifft nicht die Kryptografie, sondern die Toolkette: OpenSSL 4.0.0 hat am 14. April 2026 die ENGINE-Schnittstelle entfernt (Quelle: OpenSSL 4.0 Final Release). Wer HSM-Anbindungen über ENGINE betreibt, hat damit eine Migrationsaufgabe, die mit PQC nichts zu tun hat, aber im selben Zeitfenster anfällt.

Warum sind PQC-Zertifikate in der öffentlich vertrauenswürdigen Web-PKI noch nicht breit verfügbar?

Die Größe der Signaturen ist dafür ein wesentlicher technischer Grund, aber nicht der alleinige. Daneben müssen die Anforderungen des CA/Browser Forums, die Zertifikats- und Sperrinfrastruktur samt Certificate Transparency und die Root-Programme der Browser angepasst werden, und die hybriden Zertifikatsmodelle sind noch in Arbeit: Für zusammengesetzte Signaturen in X.509 liegt bislang nur ein IETF-Entwurf vor (Quelle: IETF, draft-ietf-lamps-pq-composite-sigs). Die Branche prüft deshalb zwei Wege gleichzeitig.

Der erste Weg ist ML-DSA im heutigen Zertifikatsformat. Die Grundlage dafür ist mit RFC 9881 seit Oktober 2025 gelegt, der die Verwendung von ML-DSA in X.509-Zertifikaten und Sperrlisten standardisiert (Quelle: RFC 9881). Im CA/Browser Forum liegt der Entwurf als Ballot SC-106 vor: Im Protokoll der Server Certificate Working Group vom 30. Juli 2026 heißt es, man arbeite weiterhin an der Zusammenführung zweier ML-DSA-Entwürfe (Quelle: CA/Browser Forum, Protokoll vom 30.07.2026); laut Protokoll vom 13. August 2026 steht ein gemeinsamer Entwurf kurz vor der Fertigstellung (Quelle: CA/Browser Forum, Protokoll vom 13.08.2026), am 10. September 2026 wurde kein Fortschritt berichtet (Quelle: CA/Browser Forum, Protokoll vom 10.09.2026). Verabschiedet ist der Ballot bis Oktober 2026 nicht. Cloudflare ordnet ML-DSA in einem Beitrag vom 9. Juli 2026, aktualisiert am 6. August 2026, als Verfahren für die erste Migrationsphase ein: „ML-DSA is available today, and it will have to do for the first migration.“ Die dort veröffentlichte Zeitleiste erwartet die Verfügbarkeit erster ML-DSA-Zertifikate im Web-PKI für das Frühjahr 2027. Das ist eine Prognose des Anbieters (Quelle: Cloudflare, Why we cannot wait for better post-quantum signature algorithms).

Der zweite Weg sind Merkle Tree Certificates. Let’s Encrypt hat am 3. Juni 2026 angekündigt, diesen Weg zu gehen, mit einer Staging-Umgebung Ende 2026 und Produktivbetrieb 2027. Die Begründung: Ein TLS-Handshake mit reinen ML-DSA-Signaturen würde deutlich über zehn Kilobyte groß; Merkle Tree Certificates (MTC) sollen die Größe des im TLS-Handshake übertragenen Authentisierungspfads deutlich reduzieren (Quelle: Let’s Encrypt, A Post-Quantum Future for Let’s Encrypt). Google Chrome hat am 27. Februar 2026 einen dreistufigen Plan veröffentlicht und nimmt traditionelle X.509-Zertifikate mit PQC nicht unmittelbar in den bestehenden Chrome Root Store auf. Stattdessen wurde der separate Chrome Quantum-resistant Root Store (CQRS) eingeführt, der ausschließlich Merkle Tree Certificates unterstützt: ab dem ersten Quartal 2027 soll das Bootstrapping öffentlicher Merkle Tree Certificates beginnen, ab dem dritten Quartal 2027 sollen weitere Zertifizierungsstellen hinzukommen (Quelle: Google, Cultivating a robust and efficient quantum-safe HTTPS). Der Entwurf der zugehörigen Programmrichtlinie vom August 2026 ist kein bloßer Zukunftsplan mehr: Er enthält konkrete Anforderungen an MTC-Zertifizierungsstellen und an Mirroring Operators (Quelle: Chrome Quantum-resistant Root Program Policy, Entwurf). Dazu liegen Testanweisungen vor, laut Fachprüfung veröffentlicht am 24. September 2026, Stand der Seite 16. Oktober 2026: Chrome stellt einen eigenen Test-Root-Store für Merkle Tree Certificates bereit, beschreibt die nötigen Flags ab Chrome 152 und ein Verfahren für Test-Cosigner (Quelle: Chrome Quantum-resistant Root Program, Testanweisungen).

Für die Unternehmensplanung folgen daraus zwei Konsequenzen. Zum einen können Unternehmen heute mit einer PQC-fähigen internen PKI beginnen, ohne auf die Aufnahme entsprechender Zertifikate in die Root-Programme der Browser zu warten; Trust Stores, Anwendungen, Hardware-Sicherheitsmodule und Zertifikatsprofile müssen dabei kompatibel sein. Zum anderen wird die externe Umstellung nicht durch eine Konfigurationsänderung erledigt, sondern durch die Fähigkeit, Zertifikate schnell und automatisiert zu wechseln.

Diese Fähigkeit wird ohnehin verlangt. Das CA/Browser Forum hat mit Ballot SC-081v3 (Abstimmung bis 11. April 2025) beschlossen, die maximale Laufzeit öffentlicher TLS-Zertifikate von 398 Tagen schrittweise auf 200 Tage (seit 15. März 2026), 100 Tage (ab 15. März 2027) und 47 Tage (ab 15. März 2029) zu senken. Die Wiederverwendungsdauer der Domainvalidierung sinkt bis 2029 auf zehn Tage (Quelle: CA/Browser Forum, Ballot SC-081v3). Automatisierte Zertifikatsausstellung und Rotation schaffen die operative Voraussetzung dafür, kryptografische Verfahren später ohne manuelle Einzelmigration austauschen zu können.

Was gilt für HSM, FIPS 140-3 und CNSA 2.0?

Hardware-Sicherheitsmodule (HSM) verwahren die Schlüssel, auf denen interne PKI, Codesignatur und viele Anwendungen beruhen. Für die Post-Quantum-Migration reicht es deshalb nicht, dass ein HSM die neuen Verfahren beherrscht. In regulierten Umgebungen muss es sie auch in zertifizierter Form anbieten. Dabei lohnt eine Unterscheidung, die in Herstellerunterlagen oft verwischt wird.

Eine CAVP-Validierung bestätigt die korrekte Implementierung einzelner kryptografischer Algorithmen und ist Voraussetzung für die Modulvalidierung (Quelle: NIST, CAVP). Eine CMVP-Validierung bestätigt dagegen das kryptografische Modul nach FIPS 140-3 (Quelle: NIST, CMVP). Wenn eine Beschaffung eine FIPS-140-3-validierte kryptographische Modulimplementierung verlangt, ist die CMVP-Zertifizierung des konkreten Moduls maßgeblich. Eine CAVP-Listung sagt nicht, dass der Algorithmus innerhalb der validierten Modulgrenze liegt. Nicht jede regulierte Umgebung verlangt dabei automatisch FIPS 140-3 Level 3.

Entrust meldete am 10. September 2025 CAVP-Validierungen für ML-DSA, ML-KEM und SLH-DSA in der nShield-Firmware 13.8.0 (Quelle: Entrust, Pressemitteilung vom 10.09.2025). Thales integrierte ML-KEM und ML-DSA mit der Luna-Firmware 7.9, angekündigt am 27. Juni 2025 (Quelle: Thales, Luna HSM Firmware v7.9). Im Sommer 2026 folgten frühe FIPS-140-3-Level-3-Hardwarevalidierungen mit explizit ausgewiesenen PQC-Algorithmen: Thales Trusted Cyber Technologies erhielt am 29. Juli 2026 das Zertifikat 5450 für das Modul Luna T7 mit ML-DSA, ML-KEM und LMS (Quelle: NIST CMVP, Zertifikat 5450), Crypto4A am 19. August 2026 das Zertifikat 5497 für das QASM (Quelle: NIST CMVP, Zertifikat 5497). Viele verbreitete Plattformen hatten PQC im Oktober 2026 dagegen nur CAVP-validiert. Das Beratungsunternehmen Encryption Consulting nennt für den Abstand zwischen Verfügbarkeit eines Algorithmus und zertifiziertem Modul zwölf bis achtzehn Monate und bezieht sich dabei auf eine Fachpublikation (Quelle: Encryption Consulting, Are Your HSMs PQC-Ready?).

Für Organisationen, die an US-Behörden liefern oder in deren Beschaffungskontext arbeiten, gilt CNSA 2.0. Die Suite ist für U.S. National Security Systems (NSS) und entsprechende Beschaffungs- und Interoperabilitätskontexte bestimmt, nicht als allgemein strengere Vorgabe: Die NSA hält fest, dass sie mit diesen Anforderungen keiner Stelle außerhalb der NSS vorschreibt, welche Algorithmen sie verwendet, „NSA is not using these requirements to dictate to any other entity outside of NSS what algorithms they should use“, und dass CNSA 2.0 außerhalb der NSS keine Pflicht ist, „it is not a requirement beyond NSS“; nützlich sein kann die Vorgabe für alle, die mit NSS interoperieren wollen (Quelle: NSA, CNSA 2.0 FAQ). Für Public-Key-Verfahren sieht sie ML-KEM-1024 und ML-DSA-87 vor, dazu AES-256 und SHA-384 oder SHA-512; für Software- und Firmware-Signaturen kommen LMS und XMSS hinzu. SLH-DSA gehört nicht zur Suite und ist in National Security Systems nicht zugelassen. Innerhalb der NSS gilt dagegen: Neubeschaffungen müssen ab dem 1. Januar 2027 CNSA-2.0-konform sein, Geräte ohne CNSA-2.0-Unterstützung sollen bis zum 31. Dezember 2030 außer Betrieb sein, und bis zum 31. Dezember 2031 ist die Nutzung der CNSA-2.0-Algorithmen vorgeschrieben; bei der Firmware- und Softwaresignierung soll der Übergang mit LMS und XMSS sofort beginnen (Quelle: NSA, CNSA 2.0 FAQ). Nach Produktkategorien unterscheidet die Zeitachse zwischen „support and prefer“, also Unterstützung und Bevorzugung, und „exclusively use“, der ausschließlichen Nutzung: Für traditionelle Netzwerkausrüstung nennt die NSA 2026 für Unterstützung und Bevorzugung und 2030 für die ausschließliche Nutzung, für Betriebssysteme 2027 und 2033, bei Software- und Firmware-Signaturen den unmittelbaren Beginn mit ausschließlicher Nutzung bis 2030 (Quelle: NSA, Announcing the Commercial National Security Algorithm Suite 2.0).

Wie sieht ein Rollout in Wellen aus?

Welle 0, Vorbereitung und Discovery. Krypto-Inventarisierung, Kritikalitätsbewertung und Interoperabilitätstests, bevor Konfigurationen geändert werden. NIST beschreibt Cryptographic Discovery und Testing ausdrücklich als zentrale Bestandteile der PQC-Migration (Quelle: NCCoE, NIST SP 1800-38). Parallel dazu gehört in diese Phase die Vorbereitung der Austauschbarkeit kryptografischer Verfahren auf Protokoll-, Anwendungs-, Hardware- und Infrastrukturebene, wie sie NIST in seinen Arbeiten zur Krypto-Agilität beschreibt (Quelle: NIST, CSWP 39upd1). Eine vierte große Rollout-Welle muss daraus nicht werden; methodisch gehört die Phase aber vor die Wellen eins bis drei.

Welle 1, ohne Zertifikatsänderung. Hybriden Schlüsselaustausch unterstützen, bevorzugen und anhand der tatsächlich ausgehandelten Gruppe verifizieren, und zwar dort, wo beide Seiten kontrolliert werden: interne TLS-Strecken, SSH, Site-to-Site-VPN. Bibliotheken auf eine unterstützte und aktuelle OpenSSL-3.5.x-Version oder eine dafür freigegebene neuere Version und auf OpenSSH 10.x heben (Quelle: OpenSSL 3.5). Diese Welle ändert keine Zertifikate und keine Vertrauensketten. RFC 10024 standardisiert dafür X25519MLKEM768, SecP256r1MLKEM768 und SecP384r1MLKEM1024; die Sicherheitsidee der Hybridisierung ist, dass der kombinierte Schlüssel geschützt bleibt, solange mindestens eine der beiden Komponenten sicher ist (Quelle: RFC 10024). Erst wenn eine dieser Gruppen tatsächlich ausgehandelt und das überprüft wurde, ist der künftige Verkehr auf diesen Strecken gegen nachträgliche Entschlüsselung geschützt.

Welle 2, Betriebsfähigkeit herstellen. Zertifikatsautomatisierung über ACME oder gleichwertige Verfahren flächendeckend einführen und auf die geltenden Laufzeiten auslegen: Seit dem 15. März 2026 beträgt die maximale Laufzeit öffentlicher TLS-Zertifikate 200 Tage, ab dem 15. März 2027 werden 100 Tage verbindlich, ab dem 15. März 2029 sind es 47 Tage (Quelle: CA/Browser Forum, Ballot SC-081v3). Krypto-Bibliotheken zentralisieren, fest verdrahtete Gruppen- und Algorithmenlisten aus eigenen Anwendungen entfernen. Parallel eine interne PQC-Testhierarchie aufbauen und Anwendungen gegen ML-DSA-Zertifikate testen, um Größenprobleme früh zu finden.

Welle 3, Signaturen und Hardware. Interne PKI auf ML-DSA umstellen, zweiten Signaturpfad in Codesignatur und Firmware einziehen, HSM-Bestand nach CMVP-Status prüfen und Ersatzbeschaffung planen, öffentliche Web-PKI entsprechend den jeweils unterstützten CA-/Browser-/Trust-Store-Mechanismen migrieren.

Ein Testkriterium sollte jede Welle begleiten: Wird die klassische Option probeweise abgeschaltet, muss die Verbindung weiterhin zustande kommen. Ein hybrider Handshake, der im Zweifel auf X25519 zurückfällt, ist konfiguriert, aber betrieblich noch nicht abgesichert.

Fazit: Anfangen, wo Standards und Implementierungen tragfähig sind

Die Algorithmen sind standardisiert; die vollständige Integration in alle Protokoll-, PKI-, Trust-Store- und Hardware-Ökosysteme ist noch nicht abgeschlossen. Am weitesten fortgeschritten ist derzeit der Pfad des Key Establishment: RFC 10024 wurde im August 2026 als Standards Track RFC veröffentlicht und definiert X25519MLKEM768, SecP256r1MLKEM768 und SecP384r1MLKEM1024 (Quelle: RFC 10024). X25519MLKEM768 ist dabei als Recommended TLS Supported Group registriert (Quelle: IANA, TLS Supported Groups). Für Signaturen liegen die Standards ebenfalls vor: NIST hat FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) am 13. August 2024 veröffentlicht (Quellen: NIST, PQC-Standardisierungsprozess; NIST, FIPS 204; NIST, FIPS 205), und RFC 9881 regelt seit Oktober 2025 die Verwendung von ML-DSA in X.509-Zertifikaten und Sperrlisten (Quelle: RFC 9881). Was tatsächlich noch fehlt beziehungsweise sich entwickelt, ist die breite interoperable Nutzung dieser Signaturen in der öffentlichen Web-PKI, einschließlich CA-Regeln, Browser-Root-Programme, Certificate Transparency und Trust Stores. Welcher der parallelen Entwicklungswege der Web-PKI sich durchsetzt, ist offen; eine Jahresprognose gibt dieser Beitrag deshalb nicht ab.

Daraus folgt eine einfache Reihenfolge. Dort, wo PQ/T-Hybrid-Key-Establishment interoperabel verfügbar und getestet ist, sollte die produktive Aktivierung priorisiert werden. Parallel sollten PKI, Zertifikatsautomatisierung, HSMs und Anwendungen auf die später erforderliche PQC-Authentisierung vorbereitet werden. Diese Reihenfolge adressiert die drängendere Bedrohung, und zwar ohne zunächst die bestehende Zertifikats- und Vertrauensinfrastruktur austauschen zu müssen. Das bedeutet nicht, dass jede Organisation sofort alle PQC-Funktionen produktiv erzwingen muss; die Vorbereitung zahlt sich unabhängig davon aus, welcher der beiden Zertifikatswege sich durchsetzt.

Wie können die nächsten Schritte aussehen?

1. Bibliotheksstand erheben. OpenSSL 3.5, veröffentlicht am 8. April 2025, hat native Unterstützung für ML-KEM, ML-DSA und SLH-DSA eingeführt und ist eine LTS-Version, unterstützt bis zum 8. April 2030 (Quelle: OpenSSL, 3.5 Final Release). Der 3.5-Zweig stand am 29. September 2026 bei 3.5.9 (Quelle: OpenSSL 3.5). Für eine aktuelle Bestandsaufnahme sollte daher nicht nur „3.5 oder höher“, sondern konkrete Version plus Konfiguration erfasst werden. OpenSSH nutzt einen hybriden Post-Quantum-Schlüsselaustausch seit Version 9.0 standardmäßig, ML-KEM seit 9.9 und als Standard seit 10.0 (Quellen: OpenSSH 9.9; OpenSSH 10.0).
2. Die OpenSSH-Warnung auswerten. Ab Version 10.1 warnt der ssh-Client bei jeder Verbindung ohne Post-Quantum-Schlüsselaustausch (Quelle: OpenSSH, Post-Quantum Cryptography). Gesammelt ergeben diese Meldungen eine Liste offener Punkte, kein vollständiges Inventar.
3. Einen Größentest fahren. Bauen Sie eine Teststrecke mit ML-DSA-Zertifikatskette und prüfen Sie, welche Zwischensysteme Probleme machen. Die Größenbereiche um zehn und dreißig Kilobyte sollten dabei als historische Interoperabilitätswarnsignale getestet werden, weil sich dort in Cloudflare-Experimenten mit künstlich vergrößerten Handshakes Einbrüche zeigten (Quelle: Cloudflare, Sizing Up Post-Quantum Signatures). Für einen schnellen Einzelcheck bietet Cloudflare Radar einen Post-Quantum-TLS-Checker, der seit dem 29. Mai 2026 auch die typischen Fehlerbilder meldet: Split ClientHello, HelloRetryRequest-Fehler und Unknown Keyshare (Quelle: Cloudflare, Radar PQ TLS Bug Detection).
4. Zertifikatsautomatisierung priorisieren. Manuelle Erneuerungsprozesse werden mit den kürzer werdenden Laufzeiten zunehmend zu einem operativen Risiko: ab dem 15. März 2027 höchstens 100 Tage, ab dem 15. März 2029 höchstens 47 Tage (Quelle: CA/Browser Forum, Ballot SC-081v3).
5. HSM- und Herstellerstatus abfragen. Für PQC sollte die Abfrage mindestens enthalten: CMVP-Zertifikat und Status, Security Policy, Modul- und Firmwareversion, konkret validierte PQC-Algorithmen, deren Parametersätze und die tatsächliche Betriebsart. Eine CAVP-Listung oder die Zertifikatsnummer allein genügt nicht.

Weiterführend: Risikobewertung des Quantencomputer-Risikos und Migrationsplanung, Post-Quantum- und Quantum-Cryptography im Vergleich und Quantum Computing und Post-Quantum Security im Überblick.