CNSA 2.0 Zeitplan: Algorithmen und Fristen erklärt

CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) ist die Gruppe von Post-Quanten-Algorithmen, die die NSA für die National Security Systems (NSS) der USA und für die darin eingesetzten kommerziellen Produkte vorschreibt. Die Suite umfasst ML-KEM-1024 für die Schlüsseletablierung, ML-DSA-87 für allgemeine Signaturen, LMS und XMSS für die Signatur von Software und Firmware, AES-256 für die symmetrische Verschlüsselung sowie SHA-384 oder SHA-512 für das Hashing. Die ausschließliche Nutzung ist bis Ende 2030 für die Signatur von Software und Firmware sowie für klassische Netzwerkausrüstung vorgeschrieben, und bis Ende 2033 für Webbrowser und Webserver, Cloud-Dienste, Betriebssysteme und Nischengeräte.

Für wen CNSA 2.0 gilt

CNSA 2.0 ist weder eine allgemeine Kryptografievorschrift der Vereinigten Staaten noch ein internationaler Standard. Sie regelt National Security Systems: Systeme, die Verschlusssachen verarbeiten oder für militärische und nachrichtendienstliche Funktionen kritisch sind. Sie betrifft drei Gruppen. Erstens die Organisationen, die diese Systeme besitzen und betreiben. Zweitens die Integratoren, die sie aufbauen. Drittens, und diese Gruppe ist am häufigsten überrascht, die kommerziellen Anbieter, deren Produkte für diese Systeme beschafft werden.

Zivile Bundesbehörden folgen einem anderen Pfad. Ihre Pflichten ergeben sich aus der Executive Order 14412 (22. Juni 2026) und dem OMB-Memorandum M-26-15 (24. Juni 2026), zusammengefasst auf unserer Seite zu den Post-Quanten-Vorgaben der US-Bundesbehörden: automatisiertes Kryptografie-Inventar, Migrationspläne der Behörden bis 22. Oktober 2026, TLS 1.3 verpflichtend bis 2. Januar 2030, hochwertige Systeme mit Post-Quanten-Schlüsseletablierung bis Ende 2030 und mit Post-Quanten-Signaturen bis Ende 2031, vollständige Migration bis 2035 gemäß NSM-10. Beide Pfade weisen in dieselbe Richtung, doch Fristen und Geltungsbereich unterscheiden sich. Maßgeblich ist der Pfad, der für den jeweils vorliegenden Vertrag gilt. Die datierten Meilensteine von CNSA 2.0 selbst finden Sie auf unserer Referenzseite zu CNSA 2.0.

Dieser Artikel dient der Information und stellt keine Rechtsberatung dar. Die Beschaffungsklauseln eines konkreten Vertrags haben stets Vorrang vor einer allgemeinen Zusammenfassung.

Die Algorithmen-Suite

CNSA 2.0 sagt nicht bloß „post-quantum“. Sie benennt Parametersätze, und zwar die höchsten.

Drei Punkte verdienen Aufmerksamkeit. ML-KEM ist die standardisierte Form von CRYSTALS-Kyber, von NIST am 13. August 2024 als FIPS 203 veröffentlicht, zusammen mit FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA). Vorstandardisierte Kyber-Gruppen wie X25519Kyber768Draft00 sind veraltet und erfüllen keine Anforderung. Zweitens verlangt CNSA 2.0 die höchsten Parametersätze, ML-KEM-1024 und ML-DSA-87, nicht das ML-KEM-768, das Browser heute standardmäßig aushandeln. Ein Produkt, das nur X25519MLKEM768 unterstützt, ist post-quantum, aber nicht CNSA 2.0. Schließlich verweist die Suite für die Signatur von Software und Firmware auf LMS und XMSS, definiert in SP 800-208. Diese Verfahren sind zustandsbehaftet: Der Signaturschlüssel darf einen Einmalschlüssel-Index niemals wiederverwenden, daher muss die Signaturinfrastruktur die Persistenz des Zustands garantieren. SLH-DSA (FIPS 205) ist zustandslos und gehört nicht zu der oben beschriebenen Suite.

AES-256 und die SHA-2-Familie gehören zur Suite, weil sie durch den Shor-Algorithmus nicht gebrochen werden. Der Grover-Algorithmus ist der Grund, warum AES-256 für langfristigen Schutz gegenüber AES-128 bevorzugt wird, und warum die Hashlängen 384 Bit und mehr betragen.

Die Fristen, Kategorie für Kategorie

CNSA 2.0 legt Fristen für die ausschließliche Nutzung fest, was strenger ist als bloße Unterstützung. Ausschließliche Nutzung bedeutet, dass für die betreffende Funktion nur noch die CNSA-2.0-Algorithmen zum Einsatz kommen: RSA, ECDSA und ECDH sind dann entfernt, nicht nur nachrangig. Die Unterstützung muss daher deutlich vor der Frist vorhanden sein, denn bis dahin muss der gesamte Bestand vollständig umgestellt sein.

Diese Fristen stammen aus der CNSA 2.0 FAQ in Version 2.1 (Dezember 2024) und dem Hinweis „CNSA 2.0 Algorithms“ vom 30. Mai 2025. Die Reihenfolge ist bewusst gewählt. Die Signatur kommt zuerst, weil eine Signaturwurzel eine lange Lebensdauer hat: Firmware, die heute mit einem ECDSA-Schlüssel signiert wird, kann noch in zehn Jahren von Geräten im Feld verifiziert werden, und das Neuausstellen eines Vertrauensankers in einem ausgerollten Gerätebestand ist langwierig. Netzwerkausrüstung kommt zuerst, weil sie die langlebigen verschlüsselten Tunnel terminiert, die das attraktivste Ziel für Harvest now, decrypt later sind: Aufgezeichneter Datenverkehr ist nur durch den Schlüsselaustausch geschützt, aus dem seine Sitzungsschlüssel hervorgegangen sind, sodass heute mitgeschnittene Daten später zu Klartext werden können. Browser, Server, Cloud-Plattformen und Betriebssysteme haben bis 2033 Zeit, weil die Abhängigkeitskette darunter (Bibliotheken, Hardware-Sicherheitsmodule, Zertifizierungsstellen, Protokollstacks) tiefer ist.

Warum Lieferanten außerhalb der Vereinigten Staaten betroffen sind

Drei Gründe, keiner davon theoretisch.

• Beschaffungsklauseln wandern weiter. Anforderungen aus CNSA 2.0 werden in Verträge und Ausschreibungen aufgenommen. Ein Komponentenlieferant zwei oder drei Stufen tiefer in einer Verteidigungslieferkette übernimmt sie über seinen Kunden, nicht über seine eigene Aufsichtsbehörde.
• Die hohen Parametersätze sind eine Produktentscheidung, kein Konfigurationsschalter. ML-KEM-1024 und ML-DSA-87 verändern Schlüssel- und Signaturgrößen, Handshake-Größen, Firmware-Image-Größen und die Anforderungen an Hardware-Sicherheitsmodule. Eine Roadmap, die bei ML-KEM-768 endet, wird einen zweiten Durchgang benötigen.
• Europäische Anforderungen sind nicht identisch. Die ANSSI schreibt die Hybridisierung innerhalb ihres regulierten Geltungsbereichs verbindlich vor (Produktqualifizierung, verteidigungsbezogene Verfahren, Betreiber von lebenswichtiger Bedeutung) und stellt klar, dass ihre übrigen Post-Quanten-Empfehlungen noch keine regulatorischen Pflichten sind. BSI TR-02102-1 (Version 2026-01) ist eine Technische Richtlinie, die eine hybride Post-Quanten-Schlüsselvereinbarung empfiehlt und eine allein eingesetzte klassische Schlüsselvereinbarung nur bis Ende 2031 als akzeptabel betrachtet, bei sehr hohem Schutzbedarf nur bis Ende 2030. Ein Produkt, das in beiden Märkten verkauft wird, muss sowohl eine hybride Gruppe als auch einen CNSA-2.0-Parametersatz aushandeln können. Das spricht für Krypto-Agilität im Code statt für eine einzige fest kodierte Wahl.

Wenn Sie alle offiziellen Fristen nebeneinander sehen möchten, stellt unsere Übersicht der Fristen für die Post-Quanten-Migration CNSA 2.0 der EU-Roadmap, den Fristen des britischen NCSC und dem Pfad der US-Bundesbehörden gegenüber.

Was Sie in diesem Quartal prüfen sollten

Beginnen Sie rein lesend, in einer Staging-Umgebung, und behalten Sie einen klassischen Fallback bei, bis die für Sie geltende Frist näher rückt.

Prüfen Sie, welche Gruppen Ihr TLS-Stack tatsächlich anbieten kann. ML-KEM-Gruppen erfordern OpenSSL 3.5 oder neuer:

openssl version
openssl list -tls-groups

Achten Sie auf MLKEM1024 und SecP384r1MLKEM1024 sowie auf das weit verbreitete X25519MLKEM768. Die IANA-Codepoints sind in der TLS-Parameter-Registry veröffentlicht, und der hybride Mechanismus selbst ist in RFC 10024 (August 2026) spezifiziert.

Testen Sie anschließend gegen einen Staging-Host, was ein Server aushandelt, jeweils eine Gruppe nach der anderen:

openssl s_client -connect staging.example.com:443 -groups MLKEM1024 </dev/null 2>&1 | grep -i -E "negotiated|group"
openssl s_client -connect staging.example.com:443 -groups X25519MLKEM768 </dev/null 2>&1 | grep -i -E "negotiated|group"

Erzeugen Sie für die Signaturseite ein Test-Schlüsselpaar ML-DSA-87 und messen Sie, wie sich die größeren Signaturen auf Ihre Artefaktgrößen, Ihren Update-Kanal und Ihre Verifikationspfade im Code auswirken:

openssl genpkey -algorithm ML-DSA-87 -out mldsa87-test.key

Halten Sie den Testschlüssel aus jedem produktiven Trust Store heraus. Die schwierigere Arbeit ist organisatorisch: Inventarisieren Sie jede Signaturwurzel und ihr Ablaufdatum, identifizieren Sie die Hardware-Sicherheitsmodule, die ML-DSA-87 oder zustandsbehaftete hashbasierte Signaturen unterstützen müssen, und planen Sie die Zustandsverwaltung, die LMS und XMSS erfordern. Unsere Anleitung zur Migration der Codesignatur auf ML-DSA behandelt die Reihenfolge, einschließlich doppelter Signatur während der Übergangsphase.

Nächster Schritt: Messen Sie, was Sie heute anbieten

Bei den Fristen von CNSA 2.0 geht es darum, was Ihre Produkte und Dienste tatsächlich aushandeln, nicht darum, was Ihre Roadmap verspricht. Beginnen Sie mit der von außen sichtbaren Ebene: Scannen Sie Ihre Domain mit PQC Status, um zu sehen, welche Schlüsselaustauschgruppen, TLS-Versionen und Zertifikatsalgorithmen Ihre Endpunkte derzeit anbieten. Nutzen Sie das Ergebnis als erste Zeile einer Lückenliste: Endpunkte ganz ohne ML-KEM-Gruppe, Endpunkte, die nur ML-KEM-768 anbieten, wo ein CNSA-2.0-Vertrag ML-KEM-1024 verlangen wird, und Zertifikatsketten, die noch mit RSA oder ECDSA signiert sind. Ein Scan beschreibt eine von außen sichtbare TLS-Konfiguration. Er ist weder eine Zertifizierung noch eine Konformitätsbestätigung, ergänzen Sie ihn daher um Ihr internes Inventar von Signaturschlüsseln, Firmware-Images und eingebetteten Bibliotheken.