Post‑Quanten‑Migration ohne Drama: Der 12‑Monats‑Plan für CTOs

Für die richtige Entscheidung zur Post‑Quanten‑Kryptografie (PQC) brauchen Sie kein Whiteboard voller Gittermathematik. Sie brauchen einen Plan. PQC ist aus der Forschung in Ihre Toolchain gewandert: GnuPG erhält Post‑Quanten‑Support im Mainline, OpenSSH liefert seit Jahren einen hybriden PQ‑Schlüsselaustausch, und die großen Clouds und CDNs haben hybride TLS‑Experimente in der Praxis gefahren. Angreifer sammeln schon heute verschlüsselten Traffic, um ihn später zu entschlüsseln. Wenn Ihre Daten 5–10+ Jahre vertraulich bleiben müssen, läuft die Uhr.

Das ist kein FUD. Es ist ein Sequenzierungsproblem. Wenn Sie warten, bis jedes HSM, jede Smartcard und jedes Compliance‑Framework PQC „vollständig“ unterstützt, verpassen Sie Ihr Fenster und zahlen doppelt: einmal für eine überstürzte Migration und noch einmal für die Produktionsvorfälle, die damit einhergehen. Der richtige Move ist jetzt, Ihren Stack krypto‑agil zu machen, hybriden Schlüsselaustausch und Doppelsignaturen dort einzuführen, wo sie nützen, und die Systeme nicht zu brechen, die noch in einer FIPS‑Validierungsschlange hängen.

Was sich 2026 geändert hat

• Algorithmen sind real, keine Draft‑Spielzeuge. Die NIST‑Runde endete mit Auswahlen für Key Encapsulation (ML‑KEM, abgeleitet von Kyber) und digitale Signaturen (ML‑DSA aus Dilithium; SLH‑DSA aus SPHINCS+ für Spezialfälle). FIPS‑Publikationen und Profile landen 2024–2026.
• PQC ist in Mainstream‑Tools angekommen. GnuPGs Post‑Quanten‑Landung signalisiert, dass PGP/S/MIME‑Experimente außerhalb akademischer Builds bereit sind. OpenSSH liefert einen hybriden KEX (sntrup761x25519) – im Einsatz bei großen Anbietern. Cloudflare, Google und andere haben großflächige hybride TLS‑1.3‑Trials gefahren (z. B. X25519+Kyber768).
• Harvest‑now‑decrypt‑later (HNDL) ist das eigentliche Risiko. AES‑256 übersteht Grovers quadratischen Speedup; Ihre symmetrische Kryptografie ist wahrscheinlich in Ordnung. Ihre Schlüsselvereinbarung und Signaturen sind es nicht. Wenn die Vertraulichkeit einer Sitzung ein Jahrzehnt halten muss, sollten Sie sich 2026 nicht allein auf RSA/ECDH verlassen.

Die zwei Entscheidungen, die Sie wirklich treffen müssen

1. Wo lohnt sich hybrides PQ heute trotz Betriebsaufwand? Ihre öffentlich erreichbaren TLS‑Endpoints und die administrative SSH sind Low‑Regret‑Moves. Sie liefern sofortigen HNDL‑Schutz, ohne die Identität komplett neu zu plattformen.
2. Wie gewinnen Sie überall sonst Zeit? Machen Sie Ihre Software krypto‑agil, sodass Sie Algorithmen ohne App‑Rewrites tauschen können. Führen Sie PQ dann phasenweise ein, sobald Ihre Anbieter, HSMs und Auditoren nachziehen.

Ein 12‑Monats‑Plan, den Sie umsetzen können

Phase 0 (Wochen 0–2): Spielregeln festlegen

• „Vertraulichkeitsdauer“ nach Datenklassen definieren. Beispiel‑Buckets: 0–2 Jahre (flüchtige Logs), 3–7 Jahre (User‑PII/PHI), 8–20 Jahre (Finanzen, Regierungsverträge, Genomik). Alles ≥7 Jahre kommt auf die PQ‑Prioritätsspur.
• Ein DRI‑Team benennen: 1 Security Engineer, 1 SRE, 1 Platform Engineer. Ergänzen Sie einen TPM, wenn Sie viel Vendor‑Surface haben. Geben Sie dem Team ein wöchentliches Executive‑Checkpoint und ein 12‑Monats‑OKR.

Phase 1 (Wochen 2–8): Erstellen Sie Ihre Crypto Bill of Materials (CBOM)

• Inventarisieren Sie anhand von Belegen, nicht nach Gefühl. Nutzen Sie testssl.sh oder ztls, um externe TLS‑Endpoints zu scannen, und protokollieren Sie unterstützte KEX/Signatur‑Suiten. Für internes mTLS Telemetrie aus Envoy/HAProxy zu verhandelten Ciphern ergänzen. Für SSH fleetweit sshd_config parsen und Server‑KEX‑Listen erfassen.
• Code‑Suche in Ihren Repos nach Kryptobibliotheken (OpenSSL, BoringSSL, BouncyCastle, libsodium, JCE‑Provider). Versionen notieren. Fragile Hand‑rolled‑Krypto und gepinnte Cipher‑Strings markieren.
• Keys und Zertifikate katalogisieren: CA‑Chains, Leaf‑Certs, JWT‑Signierschlüssel, Code‑Signing‑Zertifikate, KMS‑Keys zum Wrappen von DEKs/KEKs, PGP‑Keys. Kurven, RSA‑Längen und Rotationskadenz erfassen.
• HSM/KMS‑Fähigkeiten und Vendor‑Roadmaps abbilden. Gezielt nachfragen: Zeitpläne für ML‑KEM/ML‑DSA‑Support, Hybrid‑TLS‑Support, FIPS‑Status, Firmware‑Upgrade‑Pfade, Durchsatz‑Auswirkungen und Kosten.

Phase 2 (Wochen 8–16): Die Plattform krypto‑agil machen

• Krypto zentral abstrahieren. Wenn Ihre Services direkt OpenSSL aufrufen, führen Sie eine dünne Provider‑Schicht mit Algorithmus‑Aushandlung ein. In der JVM über JCE‑Provider und Property‑Flags konfigurieren statt Suiten hart zu kodieren. In Go tls.Config mit dynamischen CurvePreferences und Cipher‑Suiten aus der Config bevorzugen.
• Fragile Pins entfernen. Explizite Pins à la „TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256“ durch Policy‑Namen ersetzen (z. B. „prod‑tls‑policy‑2026“), die beim Start aus der Config aufgelöst werden. Diese eine Indirektion macht den Unterschied zwischen Config‑Flip und Redeploy.
• Dual‑Sign‑Support in Pipelines aktivieren. Stellen Sie für Artefakte sicher, dass Ihr Signing‑Workflow sowohl eine klassische als auch eine PQ‑Signatur anfügen kann (z. B. cosign Multi‑Signature, JOSE/COSE‑Strukturen oder detached Metadata). Vielleicht schalten Sie PQ heute noch nicht an, aber Sie können es tun, sobald Ihre Truststores es erlauben.

Phase 3 (Monate 4–6): Hybrides dort shippen, wo es sich jetzt lohnt

• TLS für öffentliche Endpunkte: Stellen Sie eine Canary‑Domain mit X25519+Kyber768 Hybrid‑KEX über ein CDN oder einen Edge‑Proxy bereit, der es unterstützt. Rechnen Sie mit ~1–2 KB mehr Handshake‑Bytes und einem vernachlässigbaren CPU‑Anstieg auf modernen CPUs. Peilen Sie 10–20% des externen Traffics für 2–4 Wochen an, tracken Sie Handshake‑Fehlerraten und Client‑Mix. Wenn Middleboxes zicken, rollen Sie pro SNI zurück, während Sie Hybrid für moderne Clients beibehalten.
• SSH für Admin‑Pfade: Aktivieren Sie sntrup761x25519-sha512@openssh.com in OpenSSH für Mitarbeiterzugriff. Es ist Drop‑in, getestet und schützt genau die Credentials post‑quanten, die am meisten zählen: jene mit Shell auf Prod.
• Data at Rest: Überall AES‑256‑GCM sicherstellen. Falls noch ein Service AES‑128 oder 3DES nutzt, jetzt beheben. Für Key‑Wrapping (KEKs, die DEKs schützen) symmetrisches lokales Wrapping oder KMS mit öffentlichem Commitment zu PQ‑KEM‑Support bevorzugen; vermeiden Sie langlebige RSA‑verpackte Secrets für Daten mit hoher Lebensdauer.

Phase 4 (Monate 6–9): Auf Identität und Messaging ausweiten

• JWT und Service‑Identität: RS256/ES256 für Interoperabilität beibehalten, aber PQ‑fähige Plumbing ergänzen. Wenn Sie eine eigene CA betreiben, pilotieren Sie eine interne CA, die doppelt signierte Zertifikate (klassisch + PQ‑Signatur) für Nicht‑Browser‑Clients ausstellt, die Sie kontrollieren. Für SPIFFE/SPIRE oder mTLS‑Service‑Mesh PQ‑KEM in Staging‑Kanälen testen, wo unterstützt.
• E‑Mail‑ und Datei‑Verschlüsselung: Mit GnuPGs anstehendem PQ‑Support richten Sie einen parallelen Keyring für sensible Rollen (Legal, Finance, Healthcare Ops) mit hybriden oder reinen PQ‑Zertifikaten ein. Fahren Sie einen Closed‑Group‑Pilot: 20–50 Mitarbeitende, Opt‑in, mit Fallbacks. Rechnen Sie mit größeren Nachrichten (Dilithium‑Signaturen ~2–3 KB; SPHINCS+ noch größer). Kompatibilität der Clients dokumentieren.
• Code‑Signing und Supply Chain: Die meisten OS‑Truststores akzeptieren PQ‑Signaturen noch nicht. Der heutige Schritt ist Dual Signing: Behalten Sie die klassische Signatur für Truststores und fügen Sie eine PQ‑Signatur als zusätzliche Attestation in der Provenance (SLSA, GUAC) hinzu. So können Sie intern PQ verifizieren und extern umschalten, sobald Truststores nachziehen.

Phase 5 (Monate 9–12): In Betrieb und Beschaffung verankern

• Observability: Fügen Sie Metriken zu TLS‑Handshake‑Größe und Failures nach Gruppen zu Ihren Dashboards hinzu. Tracken Sie „hybrid negotiated“ als Verhältnis. Setzen Sie ein SLO: weniger als 0,1% Handshake‑Fehlschläge, die während Rollouts der KEX‑Aushandlung zuzuschreiben sind.
• Rotationsrichtlinie: Zertifikats‑ und Key‑Lebensdauern verkürzen (z. B. 30–90 Tage), um Krypto‑Wechsel risikoarm zu machen. Praktisch rotieren Sie öfter, aber mit Automation ist das günstige Versicherung für schnelle Algorithmuswechsel.
• Vendor‑Gating: Aktualisieren Sie Ihren Security‑Fragebogen: „Listen Sie unterstützte KEMs und Signaturschemata auf; bestätigen Sie die Fähigkeit, ML‑KEM/ML‑DSA zu verhandeln; nennen Sie FIPS‑Status und Roadmap.“ Lehnen Sie Blackboxes ab, die Cipher hartkodieren.
• Incident‑Runbooks: Dokumentieren Sie Downgrade/Fallback‑Verhalten, damit ein Ops‑Engineer unter Druck nicht site‑weit Hybrid deaktiviert. Die richtige Reaktion auf einen Middlebox‑Fehler ist eine gezielte SNI‑ oder IP‑Range‑Policy, kein globaler Rollback.

Was es kostet (und was es spart)

• People/Time: Ein 3–4‑köpfiges Team kann in 6–8 Wochen eine belastbare CBOM erstellen, in weiteren 4–6 Wochen für die Top‑10‑Services eine Krypto‑Agilitäts‑Abstraktion ergänzen und in weiteren 4–6 Wochen hybrides TLS/SSH pilotieren. Das sind ~3–4 Kalendermonate bis zu spürbarem Schutz dort, wo es zählt.
• Infra‑Overhead: Hybride TLS‑Handshakes fügen grob 1–2 KB hinzu und nur geringe CPU‑Last (ML‑KEM‑Decapsulation ist auf modernen CPUs schnell). Rechnen Sie mit einem niedrigen einstelligen Prozentanstieg bei der Handshake‑CPU am Edge. Für die meisten SaaS‑Traffic‑Formen liegt das im Rauschen.
• Vendor‑Spend: Teuer werden HSM‑ und KMS‑Upgrades, wenn Sie PQ in Hardware verlangen. Wenn Sie hybrides TLS am Edge für die nächsten 12–24 Monate in Software terminieren können, verschieben Sie größere CapEx, bis der HSM‑Markt reift.

Kompatibilität und Performance: vertretbare Trade‑offs

• Größere Signaturen und Schlüssel. Ungefähre Größen sind für die Planung relevant: ML‑KEM‑768 Public Keys ~1,1 KB; Ciphertexts ~1,1 KB. ML‑DSA‑Signaturen ~2–3 KB. SPHINCS+‑Signaturen können 8–30 KB sein. Das betrifft E‑Mail, Logging und Bandbreiten‑Accounting.
• Middleboxes werden Sie überraschen. Manche Unternehmens‑Proxys und IDS droppen unbekannte TLS‑Gruppen. Deshalb starten Sie mit einer Canary‑Domain und SNI‑basierten Policies. Schalten Sie Hybrid nicht am ersten Tag auf Ihrem primären Login‑Hostname frei.
• FIPS und Audits hängen hinterher. Regulierte Umgebungen brauchen FIPS‑validierte Module. In Ordnung – fahren Sie jetzt PQ in kontrollierten Piloten und krypto‑agilen Codepfaden und hängen Sie später ein validiertes Modul an. Auf den Stempel zu warten, bevor Sie eine Zeile Code schreiben, endet in Q4‑Heroics.

Brazil und LatAm Realitäten, die Sie berücksichtigen sollten

• Trust Anchors: Wenn Sie Kunden in Brazil bedienen, beobachten Sie ICP‑Brasil‑Guidance für digitale Signaturen in E‑Invoicing und öffentlichen Ausschreibungen. Greifen Sie dem Root‑Programm nicht vor; statt dessen Doppelsignaturen für Artefakte und interne Attestierungen, damit Sie bereit sind, sobald PQ‑Profile erscheinen.
• Payments und Fintech: PIX/Open Finance‑Provider achten auf Latenzbudgets. Ein Handshake‑Zuwachs von 1–2 KB ist typischerweise tolerierbar, wenn Sie an Edge‑PoPs in São Paulo und Rio terminieren. Messen Sie p95‑Handshake‑Zeit vorher/nachher; budgetieren Sie 5–10 ms extra auf ausgelasteten Strecken.
• Nearshore‑Umsetzung: Ein Squad mit Sitz in Brazil und 6–8 Stunden US‑Overlap kann Ihre CBOM, Krypto‑Agilitäts‑Abstraktion und Traffic‑Canaries ohne Zeitzonenstress fahren. Das ist keine exotische F&E; es ist starke Platform‑Engineering‑Arbeit mit diszipliniertem Change‑Management.

Was Sie nicht tun sollten

• Versuchen Sie nicht, „den Ozean zum Kochen zu bringen“. Sie brauchen nicht bis Dezember PQ in jedem Microservice. Schützen Sie zuerst Public Ingress und Root‑of‑Trust‑Pfade.
• Sperren Sie sich nicht in eine Sackgassen‑Appliance ein. Wenn ein Anbieter seine unterstützten KEM/Signatur‑Schemata nicht benennen und kein funktionierendes Hybrid‑Demo zeigen kann, ist er nicht bereit – egal wie glänzend das Datasheet ist.
• Verwechseln Sie Krypto‑Agilität nicht mit Chaos. Zentralisieren Sie Cipher‑Policy an einer Stelle, rollen Sie mit Canaries aus und beobachten Sie. Sie wollen reversible Schritte mit engem Blast‑Radius.

Ein einfaches Entscheidungsframework

Nutzen Sie dies, um zu priorisieren, wo PQ zuerst hin gehört:

• Müssen die Daten ≥7 Jahre vertraulich bleiben? Ja → PQ‑Hybrid bei Transport und Key‑Wrapping priorisieren. Nein → vorerst klassisch lassen; krypto‑agile Codepfade sicherstellen.
• Kontrollieren Sie beide Enden der Verbindung vollständig? Ja → schneller vorgehen (mTLS, Service‑Mesh, SSH). Nein → Canaries auf öffentlichem TLS einsetzen und Client‑Breakage messen.
• Ist der Pfad ein Root of Trust? Code‑Signing, CI/CD‑Provenance, Admin‑Zugänge → Doppelsignaturen oder hybriden KEX früh implementieren – unabhängig vom Client‑Mix.

Antworten auf die Executive‑Fragen, die kommen werden

• „Sind wir heute exponiert?“ Wenn Sie reines RSA/ECDHE‑TLS für Traffic einsetzen, dessen Vertraulichkeit ein Jahrzehnt halten muss, ja – HNDL ist ein reales Risiko. Sie können es innerhalb eines Quartals materiell reduzieren, indem Sie hybriden KEX am Edge ergänzen.
• „Werden Kunden es bemerken?“ Sehr wahrscheinlich nicht. Handshake‑Bytes und CPU steigen etwas; Tail‑Latenz bewegt sich im schlimmsten Fall um wenige Millisekunden. Das liegt weit unter Ihrer üblichen Varianz durch Network Weather.
• „Was, wenn sich die Algorithmen ändern?“ Genau deshalb implementieren Sie Krypto‑Agilität. Sie tätowieren sich Kyber nicht auf die Stirn; Sie machen es zu einem Config‑Knopf.

Warum jetzt, nicht später

Warten bringt Ihnen keine Sicherheit, sondern Schulden. Die Standards sind hinreichend ausgereift, Mainstream‑Tools shippen, und die Kosten für Piloten sind niedrig. Der Preis des Nichtstuns ist, weiterhin langlebige Secrets unter klassischer Krypto zu shippen, während Gegner Ihren Traffic aufzeichnen. Sie erreichen 80% des Nutzens mit 20% des Aufwands, wenn Sie sich auf TLS‑Ingress, Admin‑SSH und krypto‑agile Software konzentrieren. Alles andere kann hinter diesem Beachhead reifen.

Wichtigste Erkenntnisse

• Starten Sie mit einer CBOM in 6–8 Wochen und machen Sie Ihren Code krypto‑agil; das ist der Enabler für alles Weitere.
• Shippen Sie hybrides TLS (X25519+Kyber768) auf Public Ingress und hybrides SSH für Admin; messen, mit Canaries ausrollen und Fallbacks pro SNI bereithalten.
• Nutzen Sie AES‑256‑GCM für Data at Rest und vermeiden Sie langlebige RSA‑verpackte KEKs für Daten mit hoher Lebensdauer.
• Signieren Sie Artefakte und Provenance doppelt, damit Sie extern umschalten können, sobald Truststores PQ annehmen.
• Erwarten Sie kleine Performance‑Kosten (KB und Millisekunden), größere Signaturen und gelegentliche Middlebox‑Probleme – planen Sie Rollouts entsprechend.
• Behandeln Sie PQ als Produktfähigkeit: Observability, Rotation, Beschaffungssprache und Runbooks – nicht als einmaliges Krypto‑Upgrade.