Dienstag, 18. August 2026 · KW 34 DE · EN · FR · ES Dunkel
Quantencomputing

Post-Quantum-Migration in der DACH-Enterprise-IT: Welche Krypto-Bestände 2026 realistisch umgezogen werden

NIST-PQC-Standards sind seit 2024 final. Welche Krypto-Bestände DACH-Unternehmen 2026 tatsächlich migrieren - TLS, Code-Signing, Root-CAs - und welche bis 2028 liegen bleiben.

Von Alec Chizhik 14. April 2026 10 Minuten Lesezeit
Post-Quantum-Migration in der DACH-Enterprise-IT: Welche Krypto-Bestände 2026 realistisch umgezogen werden

Die NIST-Standards für Post-Quantum-Kryptografie sind seit August 2024 final – ML-KEM für Schlüsselkapselung, ML-DSA und SLH-DSA für Signaturen. Eineinhalb Jahre später beginnen in DACH-Unternehmen die ersten Migrationen produktiv zu laufen. Dieser Text räumt mit der Roadmap-Romantik auf und zeigt, welche Krypto-Bestände 2026 tatsächlich umgezogen werden – und welche bis 2028 oder länger Bestand haben.

Das Wichtigste in Kürze

  • Hybrid-Stacks sind 2026 die Realität. Kaum jemand zieht reine PQC-Krypto live – TLS-Handshakes kombinieren X25519+ML-KEM, Signaturen bleiben meist bei RSA/ECDSA plus optionaler ML-DSA-Co-Signierung. Der Umzug läuft inkrementell über Bibliotheks-Updates.
  • Code-Signing und Root-CAs sind die harten Kandidaten. Lange Gültigkeitszeiten (10-20 Jahre) machen sie für „Harvest-Now-Decrypt-Later“-Szenarien strategisch. Hier beginnt 2026 der ernsthafte Umbau – getrieben von BSI-TR-02102, nicht von Hype.
  • VPN-Gateways und IoT-Firmware bleiben liegen. Hardware-HSMs, ältere VPN-Konzentratoren und konstruktiv gebundene Embedded-Firmware schaffen die Migration frühestens 2027, oft erst im nächsten Austausch-Zyklus. Wer das heute erzwingt, bricht mehr als er sichert.

VerwandtCloud Repatriation 2026: Das TCO-Modell  /  Platform Engineering 2026: Internal Developer Platforms

Der Stand im April 2026

ML-KEM (vormals CRYSTALS-Kyber), ML-DSA (vormals CRYSTALS-Dilithium) und SLH-DSA (vormals SPHINCS+) sind als FIPS 203, 204 und 205 seit August 2024 finale US-Bundesstandards. Parallel arbeitet das BSI an Fortschreibungen der TR-02102-Reihe, die in 2026 erste verbindliche Handlungsempfehlungen für Bundesbehörden und KRITIS-Betreiber enthalten. Eine verpflichtende Migration mit hartem Stichtag gibt es in Deutschland nicht – aber Audit-Fragen werden konkret.

In Security-Audits bei Banken und Versicherern tauchen seit Q1 2026 zwei Fragen systematisch auf. Erstens: Welche eurer Systeme verwenden heute Krypto-Verfahren, die als „quantenkritisch“ gelten? Zweitens: Welche Migrations-Roadmap habt ihr bis 2028 dokumentiert? Die Antworten, die in den meisten Unternehmen zirkulieren, sind deutlich dünner als die Folien vermuten lassen.

Wer 2026 mit einer Post-Quantum-Migration beginnt, macht das selten freiwillig. Der Auslöser ist fast immer eine Compliance-Frage, ein Lieferanten-Audit oder eine C5-Testat-Runde, in der der Prüfer explizit nach PQC-Bereitschaft fragt. Die klassische „Vorsorge“ als eigenständiges Projekt ist selten budgetfähig – PQC wird als Teil größerer Krypto-Hygiene-Vorhaben mitgezogen.

Die Bankenbranche spielt in dieser Bewegung eine Sonderrolle. BaFin und EZB haben Anfang 2026 in mehreren Rundschreiben deutlich gemacht, dass Post-Quantum-Readiness in die operationellen Risiko-Assessments gehört – nicht als Pflicht mit Stichtag, aber als dokumentationspflichtige Kategorie. Das führt in Banken-IT zu einem beschleunigten Inventar-Aufbau, den andere Branchen in diesem Tempo nicht brauchen. Versicherer ziehen in Q2 2026 nach, Energieversorger und Gesundheits-KRITIS sind über das novellierte BSI-Gesetz ohnehin im Fokus.

Die Industrie hingegen arbeitet mit einer längeren Zeitachse. Hier verhandeln IT-Abteilungen mit OT-Teams, Maschinenherstellern und Steuerungs-Lieferanten – eine Kette, die sich nur im Rahmen von Investitionszyklen verschiebt. Ein Automobilzulieferer, der neue Produktionslinien plant, nimmt PQC-fähige Hardware heute in die Lastenheft-Gespräche auf, aber die existierende Fertigungsumgebung bleibt bis 2028 oder länger im Bestand.

Welche Bestände 2026 realistisch umgezogen werden

Die Migrationsrealität folgt drei Clustern: was heute schon produktiv läuft, was in Migration ist und was stabil liegen bleibt. Die Einordnung basiert auf Projektbeobachtungen aus Enterprise-Umgebungen zwischen Q4 2025 und Q1 2026 – Bankenkonzerne, zwei DAX-Industrieunternehmen und drei größere Mittelständler.

Krypto-Bestand Heute typisch PQC-Ziel 2026-2028 Migrations-Realität
TLS-Terminierung (Public) ECDHE + ECDSA/RSA Hybrid X25519+ML-KEM (TLS 1.3) 2026 breit im Rollout bei Chrome/Edge/Firefox, Server-Side über OpenSSL 3.5+ und BoringSSL
Code-Signing (Software) RSA-3072 / ECDSA-P-256 ML-DSA oder SLH-DSA Erste produktive Deployments bei Sigstore, Microsoft-Signierung testet – breite Adoption 2027
Root-CAs / Intermediates RSA-4096 / ECDSA-P-384, 10-20 Jahre Laufzeit Parallel-CA-Hierarchie mit ML-DSA Kaum produktiv – Planungsphase, erste Bund-CAs und große Enterprise-PKIs bauen Parallel-Trust-Stores
VPN-Gateways (Site-to-Site) IKEv2 mit ECP256/ECP384 Hybrid IKEv2 + ML-KEM Hardware-abhängig. Firewall-Hersteller liefern erste Firmware-Updates, Rollout realistisch 2027
IoT / Embedded-Firmware ECDSA, teilweise RSA-2048 ML-DSA oder Hybrid Konstruktiv gebunden – Migration meist erst im nächsten Hardware-Austausch-Zyklus (2028+)
HSM-gebundene Schlüssel RSA / ECC nach FIPS 140-2/3 PQC-Firmware der HSM-Hersteller Abhängig von Thales, Utimaco, Entrust. Firmware-Cycles sind lang, Zertifizierung läuft

Quelle: NIST FIPS 203/204/205 (August 2024), BSI TR-02102-1 (Fortschreibung 2026), Projektbeobachtungen aus Bankenkonzernen und DAX-Industrieunternehmen Q4/2025-Q1/2026.

Der klarste Fortschritt läuft in der TLS-Terminierung für öffentliche Endpoints. Google hat im Chrome-Browser bereits 2024 die Hybrid-Gruppe X25519+Kyber768 aktiviert, Firefox zog 2025 nach. Serverseitig übernehmen Cloudflare, Akamai und die großen Load-Balancer den Handshake transparent – wer heute einen modernen Reverse-Proxy betreibt, macht PQC-TLS ohne aktives Zutun. Der spannende Teil ist nicht der Handshake selbst, sondern die Frage, welche inneren Services hinter dem Proxy diesen Umbau bisher überhaupt bemerkt haben.

Code-Signing ist das zweite Feld, auf dem sich 2026 etwas bewegt. Microsoft testet ML-DSA-Signaturen für Windows-Driver-Kataloge, Sigstore experimentiert mit Hybrid-Signaturketten. Für Enterprise-Software gilt: wer eigene Produkt-Signaturen ausrollt (etwa bei App-Store-Publikationen oder internen Deployment-Pipelines), hat 2026 einen sinnvollen Umstiegszeitpunkt, weil die Verifikationsbibliotheken auf der Konsumentenseite breit verfügbar sind. Bei Firmware-Signaturen mit Hardware-Root-of-Trust bleibt das Thema bis mindestens 2027 im Wartezimmer.

Das Muster ist konsistent. Wo Krypto softwareseitig austauschbar ist und im Update-Zyklus mitgezogen wird, läuft die Migration 2026. Wo Hardware, Firmware oder lange Gültigkeit im Spiel sind, passiert bis 2028 wenig – oder die Migration findet beim nächsten Gerätewechsel statt, nicht als eigenes Projekt.

Was an den Roadmaps wackelt

Fast jede Post-Quantum-Roadmap, die 2025 geschrieben wurde, hat eine oder mehrere der folgenden drei Schwächen. Erstens überschätzen sie die Geschwindigkeit, mit der Bibliotheken und Zertifizierungen nachziehen. OpenSSL 3.5 mit nativem ML-KEM ist seit Q1 2026 verfügbar – aber Enterprise-Middleware, Datenbanken und ältere TLS-Terminierungen nutzen oft deutlich ältere OpenSSL-Versionen. Bis die PQC-Unterstützung durch den gesamten Dependency-Graph einer Produktionsumgebung gewandert ist, dauert es 12 bis 24 Monate.

Zweitens unterschätzen die Roadmaps die Zertifikatsverwaltung bei Parallel-Trust-Strukturen. Wer zusätzlich zur bestehenden Root-CA eine PQC-Root-CA plant, muss die Ausrollmechanik für Browser-Trust-Stores, interne Systeme und Partner-PKIs durchdenken. Das ist keine Krypto-Frage, das ist Identity- und Zertifikats-Lifecycle-Management – ein Bereich, den die meisten Unternehmen heute schon mit großer Mühe betreiben.

// Kernsatz

Die eigentliche Quantum-Bedrohung für ein typisches DACH-Unternehmen liegt nicht in einem Crypto-relevanten Quantenrechner im Jahr 2030 – sondern in der operativen Frage, wer in den nächsten 36 Monaten die PKI-Hygiene so weit aufräumt, dass überhaupt eine Migration möglich wäre.

Drittens ignorieren viele Roadmaps die Supply-Chain-Dimension. Software von Drittanbietern, insbesondere Enterprise-SaaS mit TLS-Handshake in fremder Regie, entzieht sich der direkten Kontrolle. Wer heute bei Salesforce, Microsoft 365 oder HubSpot fragt, wann deren TLS-Terminierung auf Hybrid-PQC umstellt, bekommt typischerweise eine Roadmap-Aussage ohne Datum. Das ist keine Nachlässigkeit der Anbieter, sondern eine realistische Einschätzung ihrer eigenen Abhängigkeiten.

Ein Detail, das in Projekten oft spät auffällt: die Performance-Kosten hybrider TLS-Handshakes sind real, aber in den meisten Szenarien vernachlässigbar. ML-KEM-768 im Hybrid-Verfahren fügt rund ein bis zwei Kilobyte zum Client-Hello hinzu und verlängert den Handshake um wenige Millisekunden. Für User-facing HTTPS ist das nicht spürbar. Ernst wird es bei hochfrequenten mTLS-Pipelines, bei denen jede Connection neu aufgebaut wird – dort können die paar Millisekunden zum Stolperstein werden, insbesondere in Service-Meshes mit kurzen Session-Timeouts. Entsprechend lohnt sich vor dem Rollout ein Benchmark auf der eigenen mTLS-Spur, bevor Produktions-Latenzen zur Überraschung werden.

Ein zweiter Punkt, den Roadmap-Papers selten erwähnen: KMIP-Integrationen und Zertifikats-Templates in bestehender PKI-Software sind meist nicht PQC-ready. Wer Microsoft Certificate Services, Dogtag, EJBCA oder kommerzielle Enterprise-CA-Produkte betreibt, muss die Version prüfen – PQC-Signaturen erscheinen erst in aktuellen Produktzyklen. Die Migration des PKI-Stacks ist ein eigenes mittelgroßes Projekt neben der reinen Algorithmen-Umstellung.

Was 2026 praktisch zu tun ist

Die Unternehmen, die ihre PQC-Hausaufgaben in diesem Jahr ernsthaft angehen, folgen einem unspektakulären Muster. Sie beginnen mit einem Krypto-Inventar – nicht als theoretisches Dokument, sondern als ausführbarer Scan durch CycloneDX-SBOMs, TLS-Inventory-Tools und manuelle Prüfung aller Signaturverfahren in der eigenen CI/CD-Pipeline. Das Inventar ist die Grundlage für alles weitere und braucht allein drei bis vier Monate.

Parallel werden Bibliotheks-Upgrades als Teil der regulären Plattform-Releases durchgezogen. OpenSSL 3.5+, aktuelle LibreSSL- oder BoringSSL-Versionen, Java-TLS-Stacks mit PQC-Support, Go-Crypto-Packages. Wer den Upgrade als eigenes Projekt plant, verfehlt ihn – wer ihn an den regulären Patch-Zyklus koppelt, zieht ihn in sechs bis neun Monaten durch.

Was 2026 operativ trägt

  • Hybrid-TLS über OpenSSL 3.5 oder BoringSSL im Reverse-Proxy-Layer
  • Krypto-Inventar über SBOM und TLS-Scanning, min. quartalsweise aktualisiert
  • Plattform-Upgrades im regulären Patch-Zyklus, nicht als Sonderprojekt
  • BSI-TR-02102-Abgleich für KRITIS- und Behörden-Systeme

Was den Rollout kippt

  • Forcierter Austausch von VPN-Hardware außerhalb des Refresh-Zyklus
  • Parallel-Root-CA-Rollout ohne durchdachten Trust-Store-Prozess
  • Migration firmware-gebundener IoT-Flotten ohne Hersteller-Roadmap
  • SaaS-Drittanbieter als Migrationsblocker statt als dokumentiertes Rest-Risiko

Das Krypto-Inventar ist in der Praxis der anstrengendste Teil. TLS-Inventory-Tools wie testssl.sh, sslyze oder kommerzielle Scanner wie Venafi liefern eine erste Karte der öffentlich sichtbaren Endpoints. Aber Inventar-Fragen tauchen an Stellen auf, die kein Scanner automatisch findet: Welche Messaging-Schicht signiert mit welchem Key? Welche ERP-Modul-Schnittstellen nutzen welche Cipher-Suites? Welche JWT-Signing-Keys rotieren in welchem Rhythmus und werden von welchen Bibliotheken verifiziert? Diese Fragen bearbeitet man in mehreren Iterationen über mehrere Teams – sie lassen sich nicht in einem Sprint erledigen.

Die dritte Säule ist die Lieferanten-Konversation. Wer Software in der Cloud betreibt, sollte 2026 bei seinen drei wichtigsten SaaS-Anbietern explizit nachfragen, wann deren TLS-Terminierung auf Hybrid-PQC umstellt und wann interne Signatur-Infrastrukturen PQC-Verfahren unterstützen. Die Antworten sind selten präzise, aber sie markieren die Abhängigkeiten, die man in eigenen Roadmaps als Rest-Risiko dokumentieren sollte. Ein gutes Muster: jährlicher PQC-Stand in den Supplier-Review-Meetings, dokumentiert im Vendor-Risk-Register neben DSGVO- und NIS2-Themen.

Nicht zuletzt gehört die Kommunikationsseite dazu. Geschäftsleitungen, die 2027 von einem Prüfer oder einer Aufsichtsbehörde nach PQC-Stand gefragt werden, brauchen einen nüchternen Status-Report – nicht ein Hochglanz-Dokument. Ein einseitiger Überblick mit drei Zahlen (Anteil migrierter TLS-Endpoints, Status Code-Signing, dokumentierte Supply-Chain-Abhängigkeiten) schlägt jedes 40-Seiten-Konzept, das niemand liest.

Der Fahrplan bis 2028

Realistische Zeitachse aus Projektsicht – nicht als Vorschrift, sondern als Orientierung für CIOs, die gegenüber Geschäftsleitung und Prüfer plausibel machen müssen, warum welcher Schritt wann kommt.

Realistischer PQC-Fahrplan 2026-2028
Q2 2026
Krypto-Inventar aufsetzen, SBOM-Scan produktiv, TLS-Inventarisierung über alle öffentlich erreichbaren Endpunkte
H2 2026
Hybrid-TLS im Reverse-Proxy-Layer für Public-Facing-Services, OpenSSL 3.5-Upgrade in Plattform-Patch-Zyklus integriert
2027
Code-Signing auf ML-DSA umstellen, erste Parallel-CA-Hierarchien in Pilot, VPN-Gateway-Firmware bei großen Herstellern produktiv
ab 2028
IoT- und Embedded-Flotten im regulären Austauschzyklus auf PQC-fähige Firmware, HSM-PQC-Firmware breit zertifiziert

Orientierungswerte. Konkrete Schritte hängen an Branche, Regulatorik-Exposure, Hardware-Bestand und Liefergeschwindigkeit der verwendeten Anbieter.

Was bleibt – und was nicht

Die Erwartung, dass Post-Quantum-Kryptografie bis 2027 flächendeckend produktiv läuft, ist unrealistisch. Die Erwartung, dass gar nichts passiert, ist ebenso falsch. 2026 ist das Jahr, in dem Hybrid-TLS im Public-Web breit wird, Code-Signing-Projekte ernsthaft beginnen und Krypto-Inventare aufgebaut werden. Die echte Migration der harten Fälle – Root-CAs, HSM-gebundene Schlüssel, Embedded-Firmware – zieht sich bis Ende des Jahrzehnts.

Für CIOs und Security-Leads ist die operativ relevante Frage nicht, wie weit Quantencomputer sind. Sie ist, welche Krypto-Hygiene das eigene Haus im nächsten Audit überlebt und welche Hausaufgaben jetzt angefasst werden müssen, damit die Migration in drei Jahren überhaupt machbar ist. Wer heute ein sauberes Krypto-Inventar hat und Bibliotheken aktuell hält, hat 70 Prozent der Post-Quantum-Vorbereitung erledigt – ohne ein einziges PQC-Verfahren produktiv zu fahren.

Häufige Fragen

Muss ich 2026 schon produktiv PQC einsetzen?

Nein, außer in spezifischen Kontexten mit langer Schlüssel-Gültigkeit oder klarer Compliance-Auflage. Für die meisten DACH-Unternehmen ist 2026 das Jahr, in dem Hybrid-TLS breit verfügbar wird und Krypto-Inventare aufgebaut werden. Pure PQC-Migration ist die Ausnahme, nicht die Regel.

Welche Bibliotheken unterstützen PQC heute produktionsreif?

OpenSSL 3.5 (März 2025) mit nativem ML-KEM in TLS 1.3, BoringSSL (Chrome, Edge), Mozilla NSS (Firefox) seit 2025 mit X25519+ML-KEM Hybrid. Sigstore testet ML-DSA für Code-Signing. Java unterstützt PQC ab OpenJDK 24 experimentell. Für Embedded sind wolfSSL und mbedTLS mit PQC-Branches verfügbar.

Was kostet eine Post-Quantum-Migration für einen mittelgroßen Enterprise?

Seriöse Zahlen existieren kaum, weil die Migration in den Plattform-Patch-Zyklus integriert ist und selten als eigenes Projekt abgerechnet wird. Der separate Aufwand für Krypto-Inventar, PKI-Refactoring und Trust-Store-Management liegt für einen 1000-Mitarbeiter-Enterprise erfahrungsgemäß im mittleren sechsstelligen Bereich über drei Jahre verteilt – weniger als die meisten NIS2-Umsetzungen.

Ist „Harvest-Now-Decrypt-Later“ ein realistisches Bedrohungsmodell?

Für staatliche Geheimnisse, lange gültige Verträge und Identitätsdaten mit zehnjähriger Verwertung: ja. Für typische Geschäftsdaten mit kurzer operativer Halbwertszeit: eher nein. Die BSI-TR-02102 differenziert entsprechend. Wer heute TLS-Traffic verschlüsselt, der in fünf Jahren keinen Wert mehr hat, muss Post-Quantum nicht als Zukunftsvorsorge einsetzen.

Welche Rolle spielt BSI-TR-02102 für nicht-KRITIS-Unternehmen?

Formal keine verpflichtende. In der Praxis ist die TR-02102 der Referenzrahmen, an dem sich Auditoren, Versicherer und Rahmenvertragspartner orientieren. Wer in Ausschreibungen oder bei Cyber-Versicherungen antritt, wird zunehmend nach TR-02102-Konformität gefragt – auch jenseits der formalen Pflicht.

Lesetipps der Redaktion

Quelle Titelbild: Pexels / Markus Spiske (px:1089438)

Auch verfügbar in

FrançaisEspañolEnglish
MBF Media Newsletter

Das monatliche Briefing für Entscheider

Einmal im Monat bündelt der MBF Media Newsletter das Wichtigste aus cloudmagazin, MyBusinessFuture, Digital Chiefs und SecurityToday, kuratiert von der Redaktion.

25.000 IT- und Business‑Entscheider lesen diesen Newsletter. Lesen Sie mit.

Kostenfrei abonnieren
MBF Media Newsletter, aktuelle Ausgabe auf dem iPhone
Ein Magazin der Evernine Media GmbH