Post-Quanten-Readiness-Checkliste für Security-Teams

Eine Readiness-Checkliste für Post-Quanten-Kryptografie (PQC) hat eine einzige Aufgabe: eine mehrjährige Migration in Punkte zu zerlegen, die ein Team in diesem Quartal abschließen kann und die jeweils einen Nachweis hinterlassen, den auch andere lesen können. Die Reihenfolge ist entscheidend. Der Schlüsselaustausch kommt zuerst, weil aufgezeichneter Datenverkehr ausschließlich durch den Schlüsselaustausch geschützt ist; Inventar, Lieferanten, Signaturen und Monitoring folgen. Jeder Punkt unten benennt das zu erstellende Artefakt, nicht nur die zu bedenkende Idee.

So verwenden Sie diese Checkliste

Arbeiten Sie die Phasen der Reihe nach ab, führen Sie Discovery (Phase 2) und die Quick Wins (Phase 3) jedoch parallel durch: Wer mit der Aktivierung des hybriden Schlüsselaustauschs auf einem öffentlichen Web-Endpunkt wartet, bis das Inventar vollständig ist, verzögert die einzige Maßnahme, die das Risiko für aufgezeichneten Datenverkehr mindert. Weisen Sie jedem Punkt einen Verantwortlichen, ein Datum und ein Artefakt zu. Auf das Artefakt kommt es an: PCI DSS, DORA und NIS2 verlangen dokumentierte Richtlinien, Inventare und Überprüfungen, und eine undokumentierte Migration sieht genauso aus wie gar keine Migration. Dieser Artikel dient der Information und stellt keine Rechtsberatung dar.

Vier Begriffe werden durchgehend verwendet. ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) ist der in NIST FIPS 203 standardisierte Post-Quanten-Schlüsselaustausch, veröffentlicht als finaler Standard am 13. August 2024. Ein KEM (Key Encapsulation Mechanism) ist das Primitiv, das ein gemeinsames Geheimnis etabliert. HNDL (Harvest Now, Decrypt Later) bezeichnet die Praxis, verschlüsselten Datenverkehr heute aufzuzeichnen, um ihn zu entschlüsseln, sobald ein dazu fähiger Quantencomputer existiert. Ein CBOM (Cryptographic Bill of Materials) ist ein maschinenlesbares Inventar kryptografischer Assets.

Phase 1: Governance und Geltungsbereich

• Benennen Sie einen einzigen Verantwortlichen und eine Arbeitsgruppe aus Sicherheitsarchitektur, PKI, Netzwerk, Anwendungsverantwortlichen und Einkauf. Nachweis: ein einseitiges Mandat mit Namen, Geltungsbereich und Sitzungsrhythmus.
• Wählen Sie den Zeitplan, an dem sich Ihr Plan ausrichtet (Branchenaufsicht, nationale Leitlinien, Kundenverträge). Nachweis: eine kurze Anwendbarkeitserklärung, die die für Sie verbindlichen Rahmenwerke und die als Leitlinie behandelten benennt. Unsere Übersicht der offiziellen Fristen für die Post-Quanten-Migration führt sie mit ihren Quellen auf.
• Nehmen Sie Krypto-Agilität in die Verschlüsselungsrichtlinie auf. Die technischen Regulierungsstandards zu DORA, Commission Delegated Regulation (EU) 2024/1774, Art. 6, verlangen eine Richtlinie für Verschlüsselung und kryptografische Kontrollen, einschließlich Bestimmungen zur Aktualisierung oder Änderung der kryptografischen Technologie auf Grundlage von Entwicklungen in der Kryptoanalyse. NIS2, Directive (EU) 2022/2555, Art. 21(2)(h), verlangt Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung. Nachweis: die genehmigte, datierte Fassung der Richtlinie mit sichtbarer Klausel.
• Identifizieren Sie Daten mit langen Vertraulichkeitshorizonten: Geheimnisse, Gesundheits- und Finanzdaten, geistiges Eigentum, alles, dessen Offenlegung im Jahr 2040 noch Schaden anrichten würde. Nachweis: eine Liste der Systeme mit der erforderlichen Geheimhaltungsdauer je Datenklasse.
• Erfassen Sie HNDL namentlich im Risikoregister, mit den betroffenen Systemen. Nachweis: der Risikoeintrag mit Verantwortlichem und Überprüfungsdatum.

Referenzdaten für die Planung

Phase 2: Discovery und Inventarisierung

• Erfassen Sie zuerst die externe Angriffsfläche: jeden öffentlichen Hostnamen, seine TLS-Versionen, angebotenen Schlüsselaustauschgruppen, Cipher Suites und die Zertifikatskette. Nachweis: ein datierter Scan-Export je Hostname, aufbewahrt als Ausgangszustand.
• Erweitern Sie nach innen: TLS-Terminatoren und Load Balancer, VPN-Konzentratoren, SSH-Flotten, Mutual TLS zwischen Diensten, Datenbank- und Message-Queue-Verbindungen, HSMs, Backup-Verschlüsselung, Signatur-Pipelines für Firmware und Software. Nachweis: ein Inventar mit Zweck, Standort und Verantwortlichem je Eintrag; genau das erwartet auch PCI DSS v4.0.1 Anforderung 12.3.3 für die eingesetzten Cipher Suites und Protokolle.
• Machen Sie Discovery wiederholbar, statt eine einmalige Tabelle anzulegen. OMB M-26-15 verlangt von US-Behörden ein automatisiertes, kontinuierlich aktualisiertes kryptografisches Inventar; diese Messlatte ist auch anderswo ein sinnvolles Ziel, selbst wenn sie dort nicht gilt.
• Erstellen Sie ein CBOM. Dies ist unsere Auslegung, keine wörtliche Anforderung der oben genannten Texte: Ein CBOM ist ein praktikabler Weg, ein Inventar nachzuweisen und es zwischen Releases zu vergleichen. Zur Struktur siehe was ein CBOM enthält.
• Markieren Sie Veraltetes und Quantenanfälliges: RSA, ECDSA, EdDSA, ECDH, DH über endlichen Körpern und DSA werden durch den Shor-Algorithmus auf einem ausreichend großen Quantencomputer gebrochen, unabhängig von der Schlüssellänge. RC4 ist in TLS verboten (RFC 7465), MD5 und SHA-1 sind für Signaturen veraltet, und die vorstandardisierte Kyber-TLS-Gruppe X25519Kyber768Draft00 (Codepoint 0x6399) sollte entfernt werden.

openssl version
openssl s_client -connect example.com:443 -tls1_3 -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i "Negotiated TLS1.3 group"
ssh -Q kex | grep mlkem
ssh -v user@example.com 2>&1 | grep "kex: algorithm"

Für die ML-KEM-Gruppen ist OpenSSL 3.5 oder neuer erforderlich. Lehnt openssl s_client den Gruppennamen ab, ist der Client zu alt, und das Ergebnis sagt nichts über den Server aus.

Phase 3: Quick Wins beim Schlüsselaustausch

• Aktivieren Sie hybriden Schlüsselaustausch auf öffentlichen TLS-Endpunkten. Bieten Sie X25519MLKEM768 (IANA-Codepoint 0x11EC) an erster Stelle an und behalten Sie klassisches X25519 dahinter als Fallback. SecP256r1MLKEM768 (0x11EB) und SecP384r1MLKEM1024 (0x11ED) sind die registrierten Alternativen. Aktuelle Versionen von Chrome, Edge und Firefox bieten X25519MLKEM768 bereits standardmäßig an, sodass die Umstellung für Browser-Datenverkehr unmittelbar greift. Nachweis: der Konfigurations-Diff sowie ein Scan vorher und nachher.
• Testen Sie zuerst in Staging und achten Sie auf Middleboxes, die größere ClientHello-Nachrichten nicht vertragen. Nachweis: das Staging-Testprotokoll und etwaige Befunde zu MTU oder Fragmentierung.
• Aktualisieren Sie SSH. OpenSSH 9.9 (19. September 2024) hat mlkem768x25519-sha256 eingeführt, OpenSSH 10.0 (9. April 2025) hat es zur Standard-Schlüsselvereinbarung gemacht, und OpenSSH 10.1 (6. Oktober 2025) warnt, wenn eine Verbindung eine nicht post-quantensichere Schlüsselvereinbarung aushandelt. Nachweis: Versionsbericht der Flotte und ausgehandelter Schlüsselaustausch je Jump Host.
• Bevorzugen Sie AES-256 für langlebige ruhende Daten. Symmetrische Algorithmen und Hashfunktionen werden durch Shor nicht gebrochen; der Grover-Algorithmus ist der Grund, warum AES-256 für langfristigen Schutz bevorzugt wird.

# nginx built against OpenSSL 3.5 or later: hybrid first, classical kept as fallback
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

Syntax und erforderlicher Build unterscheiden sich je nach Server und Distribution; unser Leitfaden zum Aktivieren von ML-KEM in nginx, Apache, HAProxy und Caddy nennt die Direktiven je Server. RFC 10024 (August 2026) spezifiziert die hybride Schlüsselvereinbarung aus Post-Quanten- und traditionellen Verfahren für TLS 1.3.

Phase 4: Lieferanten und Beschaffung

Der größte Teil der IT-Landschaft gehört jemand anderem. Senden Sie jedem kritischen Lieferanten dieselben fünf Fragen und legen Sie die Antworten beim Vertrag ab.

1. Welche TLS-Schlüsselaustauschgruppen bietet Ihr Dienst heute an, und können wir das von außen überprüfen?
2. Wie sieht Ihre datierte Roadmap für die ML-KEM-Unterstützung aus, und in welchen Release Notes wird sie angekündigt?
3. Welche Implementierungen von FIPS 203, 204 oder 205 nutzen Sie, und in welchen Komponenten?
4. Können Sie für das gelieferte Produkt ein CBOM oder ein gleichwertiges kryptografisches Inventar bereitstellen?
5. Wie regelt der Vertrag einen erzwungenen Algorithmuswechsel, falls sich die Kryptoanalyse weiterentwickelt?

Nachweis: datierte schriftliche Antworten je Lieferant sowie eine Krypto-Agilitäts-Klausel bei Vertragsverlängerungen. Für in der EU verkaufte Produkte verlangt der Cyber Resilience Act, Regulation (EU) 2024/2847, Annex I, Part I (2)(e), den Schutz der Vertraulichkeit, zum Beispiel durch Verschlüsselung relevanter gespeicherter oder übertragener Daten mit Mechanismen nach dem Stand der Technik; Post-Quanten-Algorithmen werden darin nicht genannt. Seine Meldepflichten gelten ab dem 11. September 2026, vollständig anwendbar ist er ab dem 11. Dezember 2027.

Phase 5: Signaturen, Zertifikate und PKI

• Inventarisieren Sie Signaturalgorithmen und Gültigkeitszeiträume. Listen Sie jedes Zertifikat und jeden Signaturschlüssel auf, deren Gültigkeit über Ihre Referenzdaten hinausreicht. Nachweis: ein Zertifikatsregister, das DORA RTS Art. 7 für IKT-Assets zur Unterstützung kritischer oder wichtiger Funktionen verlangt, zusammen mit einem Schlüsselmanagement über den gesamten Lebenszyklus.
• Verkürzen Sie Laufzeiten und automatisieren Sie die Erneuerung, damit ein Algorithmuswechsel eine Konfigurationsänderung ist und kein Projekt. Nachweis: Abdeckung der automatisierten Ausstellung, als Prozentsatz der automatisiert verwalteten Zertifikate.
• Planen Sie Code- und Firmware-Signierung separat. ML-DSA (FIPS 204) und SLH-DSA (FIPS 205) sind die finalen Standards; LMS und XMSS sind in NIST SP 800-208 spezifiziert und zustandsbehaftet, sodass die Zustandsverwaltung das eigentliche technische Problem ist. Für US National Security Systems verlangt CNSA 2.0 die ausschließliche Nutzung seiner Algorithmen bis Ende 2030 für Software- und Firmware-Signierung sowie traditionelle Netzwerkausrüstung und bis Ende 2033 für Webbrowser und Webserver, Cloud-Dienste, Betriebssysteme und Nischenausrüstung.
• Erzwingen Sie im öffentlichen Web noch keine Post-Quanten-Zertifikate. Behalten Sie den hybriden Schlüsselaustausch als Priorität bei: Aufgezeichneter Datenverkehr wird durch den Schlüsselaustausch geschützt, daher können Signaturen und Zertifikate später nach einem geplanten Zeitplan migriert werden.
• Testen Sie jetzt die Größentoleranz: Größere öffentliche Schlüssel und Signaturen belasten Zertifikatsspeicher, Embedded-Geräte und Handshake-Puffer. Nachweis: ein Laborbericht je Gerätefamilie.

openssl x509 -in cert.pem -noout -subject -issuer -enddate
openssl x509 -in cert.pem -noout -text | grep -i -E "Signature Algorithm|Public-Key"

Phase 6: Monitoring und Überprüfung

• Scannen Sie die externe Angriffsfläche regelmäßig erneut und lösen Sie bei Rückschritten Alarme aus. Ein Austausch des Load Balancers oder eine Konfigurationsänderung am CDN kann die hybride Gruppe unbemerkt entfernen. Nachweis: eine monatliche Scan-Historie je Hostname.
• Überprüfen Sie Cipher Suites und Protokolle mindestens alle 12 Monate. Dieser Rhythmus ist der Wortlaut von PCI DSS v4.0.1 Anforderung 12.3.3, verpflichtend seit dem 31. März 2025, zusammen mit der Überwachung der fortbestehenden Eignung und einer dokumentierten Strategie für erwartete Änderungen bei kryptografischen Schwachstellen. Nachweis: das unterzeichnete Protokoll der jährlichen Überprüfung.
• Verfolgen Sie die Standardisierungspipeline. NIST hat am 11. März 2025 HQC als fünften Algorithmus und Backup-KEM ausgewählt, geplant als FIPS 207; Stand September 2026 ist noch kein Entwurf veröffentlicht. NIST IR 8547 und SP 800-131A Rev. 3 sind weiterhin erste öffentliche Entwürfe.
• Berichten Sie eine Kennzahl an die Leitungsebene: den Anteil kritischer Endpunkte, die einen hybriden Schlüsselaustausch aushandeln. Nachweis: ein quartalsweiser Trend, keine einmalige Momentaufnahme.

Machen Sie aus der Checkliste eine erste Messung

Phase 2 und Phase 6 benötigen denselben Input: eine Außensicht darauf, was Ihre Server tatsächlich aushandeln. Sie können kostenlos Ihre Domain mit PQC Status scannen, um die TLS-Versionen, die angebotenen Schlüsselaustauschgruppen und die Zertifikatskette zu sehen, und den Export anschließend als datierte Baseline für den Inventarpunkt aufbewahren. Ein Scan beschreibt ausschließlich die von außen sichtbare TLS-Konfiguration: Er ist keine Zertifizierung und keine Compliance-Bestätigung. Der konkrete nächste Schritt: Führen Sie ihn für Ihre drei am stärksten exponierten Hostnamen aus, legen Sie die Ergebnisse ab und eröffnen Sie ein Ticket je Hostname, der noch keine hybride Gruppe anbietet.