Post-Quantum-Kryptografie: der Fahrplan zur Quantum Readiness

Planungsmaßstab ist der kryptografisch relevante Quantencomputer (CRQC): genügend fehlerkorrigierte Qubits und Laufzeitstabilität, um Shor gegen reale Schlüssellängen auszuführen. Heutige Systeme sind davon Größenordnungen entfernt. Die Nachricht des Jahres 2024 war deshalb keine Rekordzahl, sondern ein Kurvenknick: Googles Willow-Chip zeigte erstmals unter realen Bedingungen, dass die Fehlerrate sinkt, wenn der Fehlerkorrektur-Code wächst — die zentrale Skalierungshürde ist nachweislich überwindbar.

Entscheidend ist deshalb nicht das Datum des Q-Day, sondern die Vertraulichkeitsdauer je Datenklasse: Wie lange wäre eine Offenlegung schädlich? Alles, dessen Schutzdauer über den — unbekannten — Q-Day hinausreicht, ist bereits heute exponiert, sobald es klassisch verschlüsselt eine Leitung passiert.

Der Wert des Tests liegt in seiner Disziplin: x zwingt zur Datenklassifizierung mit Schutzdauern, y zur ehrlichen Schätzung der eigenen Veränderungsgeschwindigkeit — Erfahrungswert gewachsener Landschaften: drei bis sieben Jahre, in Konzernen länger —, und z macht die Q-Day-Annahme explizit, statt sie implizit auf „irgendwann" zu setzen. Führen Sie den Test je Datenklasse durch, nicht einmal fürs Unternehmen: Die Streuung zwischen den Klassen ist genau die Priorisierung, die Kapitel 11 formalisiert.

Interaktiv durchrechnen können Sie den Test mit dem Mosca-Rechner auf unserer PQC-Leistungsseite.

Die Verfahren sind schnell, aber größer: Schlüssel und Signaturen wachsen vom zweistelligen Byte- in den Kilobyte-Bereich. ML-KEM-768 arbeitet mit 1.184 Byte öffentlichem Schlüssel und 1.088 Byte Ciphertext; ML-DSA-65 signiert mit 3.309 Bytes, wo ECDSA P-256 rund 64 braucht; SLH-DSA-128s liegt bei 7.856 Bytes je Signatur. Daraus entstehen die praktischen Migrationsthemen: Handshake-Pakete, Zertifikatsketten, HSM-Speicher, MTU-Grenzen und Protokollfelder mit fixen Längen.

In TLS 1.3 heißt der De-facto-Standard X25519MLKEM768: Client und Server führen X25519 und ML-KEM-768 parallel aus und verschmelzen beide Geheimnisse im Schlüsselplan. Für den generischen Fall standardisiert NIST die Kombination in SP 800-227; das BSI benennt in der TR-02102-1 (2026-01) CatKDF und KeyCombine als empfohlene Verfahren. Wichtig für Auditoren: Hybrid ist keine Abschwächung, sondern die vom BSI ausdrücklich empfohlene Betriebsform der Übergangsjahre — ab 2032 sollen klassische Schlüsseleinigungen ohnehin nur noch hybrid laufen.

• Browser: Chrome, Edge und Firefox handeln X25519MLKEM768 standardmäßig aus.
• Netz: Über 50 % des menschlichen Web-Traffics bei Cloudflare sind quantensicher geschlüsselt (10/2025); seit 09/2026 hebt „Automatic Key Exchange" auch die Origin-Strecken an.
• Messenger: Signal (PQXDH, 2023) und Apple iMessage (PQ3, 2024) schützen den Sitzungsaufbau bzw. laufende Kommunikation hybrid.
• Bibliotheken: OpenSSL 3.5 LTS (04/2025) bringt ML-KEM, ML-DSA und SLH-DSA nativ; BouncyCastle und liboqs decken Java- und Forschungs-Stacks ab.

Die Roadmap ist rechtlich eine Empfehlung — ihre Wirkung entfaltet sie über die Bande: Sie definiert, was Aufsichtsbehörden künftig unter „Stand der Technik" verstehen. Genau dieser Begriff ist in NIS2 und DORA die Messlatte für Kryptografie. Wer 2028 in einer Prüfung erklären muss, warum Hochrisiko-Systeme noch klassisch verschlüsseln, argumentiert gegen einen dokumentierten europäischen Konsens.

Der NIST-Transitionsplan IR 8547 (Entwurf seit November 2024) stuft Verfahren mit 112-Bit-Sicherheitsniveau — darunter RSA-2048 und ECDSA P-256 — ab 2030 als „deprecated" ein und sieht ab 2035 „disallowed" für RSA und ECC insgesamt vor. Noch Entwurf, aber bereits Referenz der US-Behördenplanung: FIPS-validierte Produkte und US-Clouddienste werden ihre klassischen Modi entlang dieser Daten abbauen — auch für europäische Kunden.

Die Signale sind unmissverständlich: Das Quantum Safe Financial Forum bei Europol rief im Februar 2025 Institute, Anbieter und Politik auf, die PQC-Migration zum strategischen Ziel zu erheben — bemerkenswert: nicht per neuer Regulierung, sondern koordiniert im bestehenden Rahmen. Im Januar 2026 folgte mit FS-ISAC eine gemeinsame Priorisierungsmethodik, die Quantum-Risiko gegen Migrationsaufwand abwägt. Bereits im September 2024 hatte die G7 Cyber Expert Group die Finanzaufseher aufgefordert, Quantum-Risiken in die Planung aufzunehmen.

Das Ergebnis konsolidiert eine Cryptography Bill of Materials (CBOM) — ein maschinenlesbares Inventar der kryptografischen Bestandteile, analog zur SBOM für Softwarekomponenten und mit CycloneDX standardisiert abbildbar. Der Unterschied zur Excel-Liste: Eine CBOM ist versionierbar, diffbar, in CI/CD prüfbar — und beantwortet Prüferfragen (PCI 12.3.3, DORA-Zertifikatsregister) als Nebenprodukt. Die typischen Funde sind überall dieselben: SHA-1 und 3DES in Legacy-Schnittstellen, hartkodierte Kryptografie im Quellcode, Zertifikats-Wildwuchs außerhalb jeder CA-Governance, Schatten-Schlüsselstores in Deployments — und eine Lieferkette, die auf Anhieb nicht sagen kann, welche Kryptografie in ihren Produkten steckt.

Die Zielarchitektur baut nicht „PQC ein", sondern Austauschbarkeit: Algorithmen und Schlüssellängen in zentralen Policies statt im Anwendungscode, eine Krypto-Abstraktionsschicht, Protokolle mit Spielraum für größere Schlüssel und neue Identifier, bewegliche Vertrauensanker — und ein zentrales Key Management mit HSM-Verankerung als Rückgrat, das nebenbei DORA-RTS Art. 7 erfüllt. Der Praxistest der Agilität ist eine einzige Frage: „Wie lange bräuchten wir, um in allen extern erreichbaren Diensten die Schlüsseleinigung zu wechseln?" Antworten in Tagen zeugen von Agilität, Antworten in Jahren von Handlungsbedarf.

Der Pilot (Phase 4) beweist dabei nicht, dass PQC funktioniert — das haben Milliarden Browser-Verbindungen erledigt —, sondern dass Ihr Betrieb es kann: Verträgt die Infrastruktur die größeren Handshakes? Erkennen Monitoring, IDS-Regeln und SIEM-Parser die neuen Algorithmus-Identifier, statt ML-KEM-Handshakes als Anomalie zu melden? Und funktioniert der dokumentierte Rückweg? Der Pilot endet mit einem Zahlenblatt (Latenz-Deltas, Fehlerraten je Client-Klasse, Middlebox-Befunde, SOC-Erkennungsquote) — damit wird die Rollout-Entscheidung zur Rechenaufgabe.

• Woche 1–2: Mandat holen — einseitige Vorstandsvorlage mit Fristen, HNDL und Kosten der Verzögerung; Steering benennen.
• Woche 2–4: Außenhaut scannen — TLS-/Zertifikats-Scan aller extern erreichbaren Dienste als schnellster Realitätscheck.
• Sofort: Altverfahren abstellen — SHA-1, 3DES, RSA-1024 abschalten oder mit Termin ins Ausnahmen-Register.
• Woche 3–6: Schutzdauern je Datenklasse festlegen und den Mosca-Test je Klasse rechnen — die stärkste Folie für den Vorstand.
• Woche 4–10: Krypto-Inventur als Discovery-Projekt beauftragen, Ergebnis als CBOM v1 konsolidieren.
• Parallel: Kritische Lieferanten strukturiert nach PQC-Roadmaps fragen und die Musterklausel in laufende Vergaben aufnehmen.
• Woche 8–13: Hybrid-Pilot auf einem realen Dienst (X25519MLKEM768) mit Messwerten starten.
• Woche 12–13: Roadmap-Entwurf mit Wellenplan, Budgetpfad, KPI-Set und Berichtsrhythmus vorlegen.

Alle Vorlagen — Vorstandsfolie, Einkaufs-Musterklausel, Einwände-Guide — enthält das Whitepaper „Quantum Readiness für CISOs" (Download oben auf dieser Seite).