RSA-2048 nach 2030: was der Entwurf NIST IR 8547 vorschlägt

NIST IR 8547 ist ein erster öffentlicher Entwurf (Initial Public Draft), veröffentlicht am 12.11.2024 und im September 2026 weiterhin ein Entwurf. Er schlägt vor, quantenverwundbare Public-Key-Algorithmen mit einer Sicherheitsstärke von 112 Bit, für die RSA-2048 das Standardbeispiel ist, nach 2030 abzukündigen (deprecated) und alle quantenverwundbaren Public-Key-Algorithmen nach 2035 nicht mehr zuzulassen (disallowed). Diese beiden Daten sind Vorschläge in einem Entwurf, keine finalisierten Anforderungen des NIST, auch wenn sie häufig so zitiert werden, als wären sie bereits in Kraft.

Was NIST IR 8547 ist

NIST IR 8547 wurde am 12.11.2024 als erster öffentlicher Entwurf herausgegeben (csrc.nist.gov/pubs/ir/8547/ipd). Ein Initial Public Draft ist die erste Fassung, die zur öffentlichen Kommentierung freigegeben wird. Er kann überarbeitet, neu gegliedert oder in seinen Daten angepasst werden, bevor eine endgültige Fassung erscheint. Stand September 2026 ist keine endgültige Fassung veröffentlicht.

Er sollte zusammen mit NIST SP 800-131A Rev. 3 gelesen werden, ebenfalls ein erster öffentlicher Entwurf (21.10.2024, csrc.nist.gov/pubs/sp/800/131/a/r3/ipd). SP 800-131A ist die Publikation, die die Übergangsregeln für Algorithmen im US-Bundesbereich enthält. Diese Regeln wirken sich darauf aus, was validierte kryptografische Module tun dürfen, weshalb Hersteller und Auditoren beide Dokumente genau verfolgen. Beide sind Entwürfe. Keines ist ein Gesetz, und keines ist für sich genommen für ein privates Unternehmen verbindlich.

Deprecated und disallowed sind Fachbegriffe

Im Übergangsvokabular des NIST sind die beiden Begriffe keine Synonyme. Deprecated (abgekündigt) bedeutet, dass ein Algorithmus weiterhin zugelassen ist, seine Verwendung aber nicht empfohlen wird und mit anerkanntem Risiko verbunden ist. Disallowed (nicht mehr zugelassen) bedeutet, dass er für die beschriebene Verwendung nicht mehr zugelassen ist. Der Entwurf schlägt den ersten Status nach 2030 und den zweiten nach 2035 vor und definiert die von ihm verwendeten Begriffe: Lesen Sie den Entwurf selbst, bevor Sie eine Definition in einer internen Richtlinie zitieren.

Warum die 112-Bit-Grenze RSA-2048 trifft

Der Entwurf argumentiert mit Sicherheitsstärken statt mit Schlüssellängen, und RSA-2048 ist das Beispiel, das er für das 112-Bit-Niveau anführt. Die praktische Folge: Ein so formulierter Übergang reicht weit über RSA hinaus. ECDSA, EdDSA, ECDH, Finite-Field-Diffie-Hellman und DSA werden auf einem ausreichend großen Quantencomputer durch den Shor-Algorithmus gebrochen, unabhängig von der Schlüssellänge. DSA ist nach FIPS 186-5 bereits nicht mehr für die Signaturerzeugung zugelassen; erlaubt ist nur noch die Verifikation bestehender Signaturen.

Ein größerer RSA-Schlüssel ist keine Migration

Der Wechsel von RSA-2048 zu einem größeren Modulus erhöht die klassische Sicherheitsstärke, und genau deshalb verlangt BSI TR-02102-1 RSA mit mindestens 3000 Bit. Gegen den Shor-Algorithmus hilft das nicht. Die quantensichere Antwort ist eine andere Algorithmenfamilie: ML-KEM (Key Encapsulation Mechanism, standardisiert in FIPS 203 am 13.08.2024) für den Schlüsselaustausch sowie ML-DSA oder SLH-DSA für Signaturen. Die standardisierten Parametersätze und die TLS-Gruppen, die sie transportieren, finden Sie auf der ML-KEM-Seite.

Die Reihenfolge der Arbeiten ist hier entscheidend. Harvest now, decrypt later (HNDL) bedeutet, dass ein Angreifer verschlüsselten Datenverkehr heute aufzeichnet und später entschlüsselt: Aufgezeichnete Sitzungen sind nur durch den Schlüsselaustausch geschützt. Deshalb kommt der hybride Schlüsselaustausch zuerst, und Zertifikate und Signaturen können danach migriert werden. Eine Infrastruktur, die noch mit RSA-2048-Zertifikaten signiert, aber eine hybride ML-KEM-Gruppe aushandelt, steht besser da als im umgekehrten Fall.

Der Entwurf im Vergleich mit BSI, EU und anderen

Das Zeitfenster 2030 bis 2035 ist keine Besonderheit des NIST, aber das rechtliche Gewicht der einzelnen Dokumente unterscheidet sich deutlich. Die folgende Tabelle ordnet jede Quelle ihrer eigenen Kategorie zu. Die vollständige, datierte Liste mit Primärquellen für jeden Meilenstein finden Sie in unserem Referenzartikel zu den Fristen der Post-Quanten-Migration.

Zwei Punkte sollten klar benannt werden. Erstens gelten die einzigen fest datierten Verpflichtungen in dieser Tabelle für US-Bundesbehörden; BSI TR-02102-1 ist eine Technische Richtlinie (das Dokument selbst), und die EU-Roadmap sind koordinierte Leitlinien, die sich an die Mitgliedstaaten richten. Die ANSSI erklärt, dass ihre PQC-Empfehlungen außerhalb ihres regulierten Bereichs (Produktqualifizierung und bestimmte regulierte Betreiber), in dem Hybridisierung verpflichtend ist, noch keine regulatorischen Pflichten sind; sie strebt an, PQC für Produkte zu verlangen, die ab 2027 in die Qualifizierung gehen, und ist der Auffassung, dass der Kauf von Produkten ohne PQC nach 2030 nicht mehr vernünftig sein wird, was eine Empfehlung ist. Zweitens laufen alle diese Texte auf dieselben zwei ersten Schritte hinaus, Inventarisierung und hybriden Schlüsselaustausch, weshalb das weitere Schicksal des Entwurfs nichts daran ändert, was jetzt zu tun ist.

Was zu tun ist, solange der Entwurf ein Entwurf ist

Dieser Artikel dient der Information und ist keine Rechtsberatung. Die folgende Abfolge ist gewöhnliche Engineering-Arbeit, und sie bleibt dieselbe, ob die endgültige Fassung von NIST IR 8547 ihre vorgeschlagenen Daten beibehält, verschiebt oder abschwächt.

1. Wissen, wo RSA-2048 im Einsatz ist. Inventarisieren Sie Schlüssel, Zertifikate und TLS-Konfigurationen mit Schlüssellänge, Signaturalgorithmus, verantwortlicher Stelle und Ablaufdatum. PCI DSS v4.0.1 Anforderung 12.3.3 verlangt, dass die verwendeten Cipher Suites und Protokolle dokumentiert und mindestens alle 12 Monate überprüft werden, einschließlich einer dokumentierten Strategie für absehbare Änderungen bei kryptografischen Schwachstellen; sie ist seit dem 31.03.2025 verpflichtend.
2. Die Agilitätsklausel festschreiben, nicht den Algorithmus. Die DORA-RTS, Delegierte Verordnung (EU) 2024/1774 der Kommission, Art. 6, verlangt wörtlich eine Richtlinie zu Verschlüsselung und kryptografischen Kontrollen, die Bestimmungen zur Aktualisierung oder Änderung der kryptografischen Technologie auf Grundlage von Entwicklungen in der Kryptoanalyse enthält, und Art. 7 verlangt ein Schlüsselmanagement über den gesamten Lebenszyklus sowie ein Zertifikatsregister für IKT-Assets, die kritische oder wichtige Funktionen unterstützen. Den genauen Anwendungsbereich finden Sie auf der DORA-Seite. Unsere Auslegung, keine wörtliche Anforderung: Eine Richtlinie, die einen Überprüfungsauslöser benennt (zum Beispiel die Veröffentlichung eines finalen NIST-Übergangsdokuments), erfüllt Art. 6 leichter als eine Richtlinie, die RSA-2048 und ein Datum nennt.
3. Hybriden Schlüsselaustausch dort aktivieren, wo Sitzungen aufgezeichnet werden. Zuerst öffentlich erreichbare TLS- und VPN-Endpunkte, denn genau darauf zielt HNDL.
4. Zertifikatslaufzeiten bewusst begrenzen. Ein heute ausgestelltes RSA-2048-Zertifikat sollte nicht dafür vorgesehen sein, über das für Ihre Branche relevante Zeitfenster hinaus gültig zu bleiben.

Zuerst rein lesende Prüfungen. Diese Befehle zeigen, was tatsächlich im Einsatz ist, und nicht, was die Dokumentation behauptet:

openssl x509 -in server.crt -noout -subject -enddate
openssl x509 -in server.crt -noout -text | grep -E "Public-Key|Signature Algorithm"
openssl s_client -connect example.com:443 -tls1_3 -groups X25519MLKEM768 </dev/null

Die ML-KEM-TLS-Gruppen erfordern OpenSSL 3.5 oder neuer; ein älterer Client lehnt daher den Gruppennamen ab, nicht der Server. Wenn Sie zu Konfigurationsänderungen übergehen, behalten Sie einen klassischen Fallback bei (X25519 nach X25519MLKEM768 aufführen) und testen Sie in einer Staging-Umgebung, bevor Sie in Produktion gehen.

Nächster Schritt: messen, dann planen

Bevor Sie ein Datum aus einem Entwurf in einer Vorlage für die Geschäftsleitung zitieren, prüfen Sie die Fakten in Ihrem eigenen Perimeter: ob Ihre Server bereits eine hybride ML-KEM-Gruppe aushandeln, welche TLS-Versionen sie akzeptieren und welche Schlüssellängen und Signaturalgorithmen in der Zertifikatskette stecken. Sie können Ihre Domain kostenlos mit PQC Status scannen und das Ergebnis als erste Zeile des oben beschriebenen Inventars verwenden. Ein Scan beschreibt ausschließlich die von außen sichtbare TLS-Konfiguration: Er ist weder eine Zertifizierung noch ein Konformitätsnachweis.