7 Min. Lesezeit

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.

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.

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.

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.

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.

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.

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