Post-Quanten-Kryptografie (PQC) hat ein Kommunikationsproblem: Die einen verkaufen sie mit Weltuntergangsrhetorik („Q-Day steht bevor!"), die anderen winken ab („gibt ja noch keinen Quantencomputer"). Beides führt zu derselben falschen Entscheidung — nämlich keiner. Die realistische Position liegt dazwischen, und sie ist seit 2024/2025 erstaunlich gut dokumentiert: Die Standards sind fertig, die Behördenfahrpläne stehen, und die halbe Internet-Infrastruktur hat leise schon umgestellt. Was fehlt, ist der Mittelstand.
Warum 2026 — und nicht „irgendwann später"
Vorweg die nüchterne Bestandsaufnahme: Einen kryptografisch relevanten Quantencomputer (CRQC), der RSA-2048 oder elliptische Kurven bricht, gibt es Stand 2026 nicht. Die größten Maschinen verfügen über einige Dutzend fehlerkorrigierte logische Qubits — für einen Angriff auf RSA-2048 werden nach gängigen Schätzungen mehrere Tausend logische Qubits benötigt, hinter denen je nach Architektur Hunderttausende physische Qubits stehen. Kein seriöser Hersteller-Roadmap-Slide verspricht eine solche Maschine vor Ende der 2020er. Wer Ihnen „Q-Day 2027" verkauft, verkauft Ihnen etwas.
Aber: Die Ressourcenschätzungen fallen seit Jahren schneller als erwartet. Noch vor wenigen Jahren rechnete man mit zig Millionen physischer Qubits für einen RSA-2048-Angriff; 2025 zeigte eine vielbeachtete Google-Arbeit, dass unter eine Million reichen könnten, und 2026 kursieren Architekturvorschläge mit nochmals deutlich niedrigeren Zahlen — mit ehrlicherweise teils sehr langen Rechenzeiten und ohne Peer-Review. Die Richtung ist trotzdem eindeutig: Die Hürde sinkt auf der Algorithmen- und auf der Hardwareseite gleichzeitig. Genau deshalb arbeiten BSI, NIST und die EU-Kommission mit Planungshorizonten, nicht mit Prophezeiungen.
Und diese Planungshorizonte sind der eigentliche Grund für 2026: Die EU-Mitgliedstaaten haben sich in ihrer koordinierten PQC-Roadmap darauf verständigt, dass die Migration bis Ende 2026 beginnen soll — nicht enden. Für Hochrisiko-Systeme ist Ende 2030 als Zielmarke gesetzt, für den Rest Ende 2035. Wer die Erfahrung aus früheren Krypto-Migrationen kennt (SHA-1-Ablösung: über ein Jahrzehnt, TLS-1.0-Abschaltung: ebenfalls), weiß, dass zehn Jahre für einen kompletten Austausch der Public-Key-Kryptografie kein komfortabler Puffer sind, sondern eine sportliche Ansage.
Das eigentliche Risiko: Harvest now, decrypt later
Das Argument „es gibt ja noch keinen Quantencomputer" hat einen blinden Fleck, und der heißt „Harvest now, decrypt later" (auch: „Store now, decrypt later"): Ein Angreifer, der heute verschlüsselten Datenverkehr mitschneidet und speichert, kann ihn in dem Moment entschlüsseln, in dem ein CRQC verfügbar ist. Für die Vertraulichkeit Ihrer Daten zählt also nicht das Datum des Quantendurchbruchs, sondern die Frage: Sind die Daten dann noch schützenswert?
Für eine TLS-Session, in der ein Newsletter ausgeliefert wird, ist die Antwort offensichtlich nein. Für Konstruktionsdaten eines Zulieferers, F&E-Ergebnisse, Gesundheitsdaten, M&A-Unterlagen oder behördliche Kommunikation ist die Antwort ziemlich sicher ja — solche Daten haben Vertraulichkeitsanforderungen von 10, 20 oder 30 Jahren. Betroffen ist dabei vor allem der Schlüsseltausch: Site-to-Site-VPN-Strecken zwischen Standorten, TLS-Verbindungen zu Partnern und Clouds, verschlüsselte Backups außer Haus. Überall dort wird der Sitzungsschlüssel heute per RSA oder ECDH ausgehandelt — und genau diese Aushandlung ist es, die ein späterer Quantencomputer rückwirkend aufbrechen könnte.
In der Sicherheitsforschung fasst man das als Mosca-Ungleichung zusammen: Wenn die Zeit, die Ihre Daten vertraulich bleiben müssen (X), plus die Zeit, die Ihre Migration dauert (Y), größer ist als die Zeit bis zum ersten CRQC (Z), haben Sie ein Problem — und zwar heute, nicht erst bei Z. Bei X = 15 Jahren Datenlebensdauer und Y = 5 Jahren Migrationsdauer müsste ein CRQC mehr als 20 Jahre entfernt sein, damit Sie entspannt abwarten können. Diese Wette würde derzeit niemand Seriöses eingehen.
Das Wichtigste in einem Satz: „Harvest now, decrypt later" macht die PQC-Migration zu einem Gegenwartsproblem für alle Daten mit langer Vertraulichkeitsdauer — nicht der Quantencomputer entscheidet über Ihre Deadline, sondern die Lebensdauer Ihrer Daten plus Ihre eigene Migrationsgeschwindigkeit.
Die Standards sind fertig: ML-KEM, ML-DSA, SLH-DSA
Das häufigste Aufschub-Argument vergangener Jahre — „es gibt ja noch keine Standards" — ist seit August 2024 vom Tisch. Nach acht Jahren öffentlichem Auswahlverfahren hat das US-amerikanische NIST drei finale Standards veröffentlicht:
- FIPS 203 — ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, hervorgegangen aus CRYSTALS-Kyber): das Arbeitspferd für den Schlüsseltausch, in den Stufen 512/768/1024
- FIPS 204 — ML-DSA (hervorgegangen aus CRYSTALS-Dilithium): der primäre Standard für digitale Signaturen
- FIPS 205 — SLH-DSA (hervorgegangen aus SPHINCS+): ein hash-basiertes Signaturverfahren mit sehr konservativen Sicherheitsannahmen — langsamer, mit großen Signaturen, aber als Absicherung gegen mögliche Schwächen der Gitter-Mathematik
Dahinter wird weiter standardisiert: FN-DSA (aus Falcon, als FIPS 206 geplant) sowie HQC, das NIST im März 2025 als Backup-Verfahren zu ML-KEM ausgewählt hat — der finale Standard wird für 2027 erwartet. Für Ihre Planung heißt das: Die Verfahren, auf die Sie heute setzen sollen, stehen fest und ändern sich nicht mehr. Was sich ändert, sind Schlüssel- und Signaturgrößen im Vergleich zur gewohnten Welt:
| Verfahren | Zweck | Public Key | Signatur / Ciphertext | Quantensicher |
|---|---|---|---|---|
| RSA-3072 | Schlüsseltausch, Signatur | ca. 384 Byte | 384 Byte | Nein |
| ECDH/ECDSA (P-256) | Schlüsseltausch, Signatur | ca. 64 Byte | ca. 64 Byte | Nein |
| ML-KEM-768 (FIPS 203) | Schlüsseltausch (KEM) | 1.184 Byte | 1.088 Byte (Ciphertext) | Ja |
| ML-DSA-65 (FIPS 204) | Signatur | 1.952 Byte | 3.309 Byte | Ja |
| SLH-DSA-128s (FIPS 205) | Signatur (hash-basiert) | 32 Byte | 7.856 Byte | Ja |
Die Größenordnungen zeigen, warum die Migration mehr ist als ein Konfigurationsflag: Ein TLS-Handshake mit ML-KEM-768 transportiert gut ein Kilobyte mehr pro Richtung — im Web-Alltag unproblematisch, in Embedded-Systemen, bei zertifikatsbasierten Protokollen mit mehreren Signaturen in der Kette oder auf schmalbandigen Verbindungen aber durchaus spürbar. In der Praxis: Für 95 % der KMU-Anwendungsfälle sind die Overheads irrelevant, für Firmware, Smartcards und IoT nicht. Genau dort lohnt der frühe Blick.
BSI und EU: Der Fahrplan bis 2035
Das BSI hat seine Position in den Handlungsempfehlungen „Migration zu Post-Quanten-Kryptografie" und in der Technischen Richtlinie TR-02102-1 präzisiert — und dort steht ein Datum, das gern überlesen wird: Der alleinige Einsatz von RSA und ECC für die Schlüsseleinigung wird nur noch bis Ende 2031 empfohlen, bei sehr hohem Schutzbedarf nur bis Ende 2030. Die TR-02102 ist formal eine Empfehlung, wirkt aber mittelbar verbindlich — sie ist Referenz für Bundesbehörden, Ausschreibungen und regulierte Branchen, und sie sickert erfahrungsgemäß binnen weniger Jahre in Auditkataloge und Versicherungsfragebögen durch.
Zweite zentrale BSI-Botschaft: hybrid migrieren. PQC-Verfahren sollen vorerst nicht isoliert, sondern in Kombination mit klassischen Verfahren eingesetzt werden — etwa X25519 plus ML-KEM-768 im selben Handshake. Bricht eines der beiden Verfahren, trägt das andere weiter. Das ist keine akademische Vorsicht: Die PQC-Mathematik ist jünger und weniger kryptanalytisch abgehangen als RSA/ECC; der 2022 spektakulär gebrochene Kandidat SIKE ist die Mahnung, warum man Gürtel und Hosenträger kombiniert. Erfreulicher Nebeneffekt: Genau so, hybrid, ist PQC in TLS und SSH ohnehin implementiert.
Auf EU-Ebene hat die NIS-Kooperationsgruppe — dasselbe Gremium, das auch die NIS2-Umsetzung koordiniert — am 23. Juni 2025 die „Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography" veröffentlicht, aufbauend auf der Kommissionsempfehlung vom April 2024. Die Meilensteine:
Ehrlich: Die EU-Roadmap ist kein Gesetz, sie enthält keine unmittelbaren Bußgelder für ein KMU, das 2027 noch klassisches TLS spricht. Aber sie definiert den Stand der Technik — und über NIS2-Risikomanagement, den Cyber Resilience Act (dessen Anhang I „Stand der Technik"-Verschlüsselung für Produkte verlangt), DORA im Finanzumfeld und schlicht die Einkaufsbedingungen großer Konzerne wird daraus schneller eine faktische Pflicht, als vielen lieb ist. Wer als Zulieferer 2028 einen Fragebogen mit der Zeile „PQC-Migrationsplan vorhanden? ja/nein" bekommt, möchte nicht zum ersten Mal von dem Thema hören.
Was heute schon PQC spricht — vermutlich auch bei Ihnen
Der vielleicht wirksamste Einwand gegen das „Zukunftsthema"-Framing: Ein erheblicher Teil Ihrer IT nutzt Post-Quanten-Kryptografie bereits — ohne dass Sie etwas davon gemerkt haben.
- Browser/TLS: Chrome sendet seit Version 124 (April 2024) standardmäßig den hybriden Schlüsseltausch X25519MLKEM768, Firefox seit Version 132 (November 2024). Cloudflare maß bereits Anfang 2025 rund 38 % seines HTTPS-Verkehrs mit hybridem PQC-Handshake, Tendenz seither deutlich steigend; große CDNs haben PQC 2025/2026 zum Default gemacht. Jeder Aufruf einer entsprechend konfigurierten Website aus einem aktuellen Browser ist heute quantensicher ausgehandelt.
- SSH: OpenSSH liefert seit Version 9.0 (2022) standardmäßig den Post-Quanten-Schlüsseltausch sntrup761x25519 aus; seit OpenSSH 10.0 (April 2025) ist mlkem768x25519 der Default, und neuere Versionen warnen sogar aktiv, wenn eine Gegenstelle nur klassische Verfahren anbietet. Wer aktuelle Linux-Server administriert, nutzt PQC bei jedem SSH-Login.
- Messenger: Signal hat seinen Schlüsselaustausch bereits 2023 um das quantensichere PQXDH-Protokoll erweitert, Apple folgte 2024 mit dem PQ3-Protokoll in iMessage.
- Bibliotheken und Stacks: OpenSSL bringt ab Version 3.5 native ML-KEM/ML-DSA-Unterstützung mit, aktuelle Java-, Go- und .NET-Runtimes ziehen nach. Die Bausteine sind also da — was fehlt, ist die Konfiguration auf Serverseite und in den Appliances dazwischen.
In der Praxis heißt das: Die Frage „funktioniert PQC überhaupt schon?" ist beantwortet — milliardenfach, täglich, in Produktion. Die Migration im Web- und SSH-Umfeld ist erprobt und größtenteils ein Update- und Konfigurationsthema. Die harten Nüsse liegen woanders: ältere VPN-Gateways und Firewalls, deren Hersteller noch keine PQC-Firmware liefern, interne PKI und Zertifikatsketten, Firmware-Signaturen und Embedded-Systeme mit 15 Jahren Laufzeit.
Der praktische Einstieg: Inventar, Agilität, Priorisierung
Eine PQC-Migration für ein KMU beginnt nicht mit dem Kauf eines Produkts, sondern mit drei unspektakulären Arbeitsschritten.
1. Krypto-Inventar aufbauen
Sie können nicht migrieren, was Sie nicht kennen. Ein Krypto-Inventar beantwortet: Wo wird welche Kryptografie eingesetzt — Protokolle, Algorithmen, Schlüssellängen, Zertifikate, Bibliotheken, Hardware? Typische Fundorte: TLS-Terminierung (Webserver, Load Balancer, Reverse Proxies), VPN-Gateways (IPsec/IKEv2, WireGuard), E-Mail-Transport, interne PKI und Zertifikate, Code- und Firmware-Signaturen, Backup-Verschlüsselung, Datenbank- und Storage-Encryption, SSH-Zugänge, Legacy-Appliances. Wer ein ISO 27001-ISMS betreibt, hat mit dem Asset-Register die halbe Vorarbeit bereits geleistet und ergänzt eine Krypto-Spalte; alle anderen starten pragmatisch mit den extern erreichbaren Systemen und den Site-to-Site-Strecken.
2. Krypto-Agilität herstellen
Die wichtigste strategische Lektion aus 30 Jahren Krypto-Migrationen: Das nächste Verfahren kommt bestimmt. Krypto-Agilität bedeutet, Systeme so zu bauen und einzukaufen, dass Algorithmen austauschbar sind — Kryptografie in Konfiguration statt in Code, zentrale Zertifikats- und Schlüsselverwaltung statt händisch verteilter Schlüssel, Bibliotheken statt Eigenbau. Ein System, das heute agil auf ML-KEM umgestellt werden kann, kann morgen auch auf HQC oder einen Nachfolger umgestellt werden, falls die Kryptanalyse Überraschungen liefert. Unbequeme Wahrheit: Die meiste Arbeit der PQC-Migration ist keine Quantenarbeit, sondern das Nachholen dieser Grundhygiene.
3. Nach Datenlebensdauer priorisieren
Nicht alles muss 2026 quantensicher werden — aber die Reihenfolge muss stimmen. Der Sortierschlüssel ist die Mosca-Logik: Vertraulichkeitsdauer der Daten plus Lebensdauer des Systems.
| Kategorie | Beispiele | Vertraulichkeitsdauer | Priorität / Zeitfenster |
|---|---|---|---|
| Langzeit-Geheimnisse, extern übertragen | F&E- und Konstruktionsdaten, Gesundheitsdaten, M&A, Behördenkommunikation über VPN/TLS | 10–30 Jahre | Hoch — hybrider Schlüsseltausch 2026/2027 |
| Langlebige Signatur-Wurzeln | Interne Root-CA, Firmware-Signierung, Produkte mit 10–20 Jahren Feldlaufzeit | Systemlebensdauer | Hoch — bei nächster CA-/Produktgeneration einplanen |
| Geschäftsdaten mittlerer Lebensdauer | Verträge, Finanz- und Personaldaten, Backups außer Haus | 5–10 Jahre | Mittel — im Regelzyklus bis ca. 2030 |
| Kurzlebige Daten | Website-Traffic ohne Geheimnisse, Telemetrie, kurzlebige Sessions | < 5 Jahre | Niedrig — mit normalem Update-Lifecycle bis 2035 |
4. Lieferanten in die Pflicht nehmen
Der größte Teil Ihrer Kryptografie steckt in zugekauften Produkten — also entscheidet sich Ihre Migration bei den Herstellern. Konkrete Fragen für die nächste Vertragsverlängerung oder Ausschreibung: Unterstützt das Produkt hybride PQC-Verfahren nach FIPS 203/204 (oder liegt ein verbindlicher Zeitplan vor)? Sind Algorithmen konfigurierbar statt fest verdrahtet? Wie lange erhält die eingesetzte Gerätegeneration Firmware-Updates? Ein Hersteller, der darauf 2026 keine belastbare Antwort hat, hat ein Roadmap-Problem — und Sie damit auch. Bei Neuanschaffungen von Firewalls, VPN-Gateways und Storage mit 7–10 Jahren Nutzungsdauer gehört PQC-Fähigkeit ab sofort in die Anforderungsliste, sonst kaufen Sie sich Altlasten mit Ansage.
Ehrliche Einordnung: Was NICHT dringend ist
Zur Nüchternheit gehört auch die Gegenliste. Folgende Punkte dürfen Sie 2026 mit gutem Gewissen niedrig priorisieren:
- Symmetrische Verschlüsselung und Hashes: AES-256 und SHA-2/SHA-3 gelten auch gegen Quantenangriffe als ausreichend — der Grover-Algorithmus halbiert effektiv die Schlüssellänge, und 128 Bit Restsicherheit reichen. Ihre Datenträger- und Backup-Verschlüsselung mit AES-256 ist kein PQC-Notfall; kritisch ist nur der Weg, auf dem die Schlüssel ausgetauscht werden.
- Signaturen kurzlebiger Natur: Für TLS-Server-Zertifikate mit 90 Tagen Laufzeit gilt „Harvest now, decrypt later" nicht — eine Signatur zu fälschen nützt dem Angreifer erst, wenn der CRQC tatsächlich existiert. Der Schlüsseltausch ist dringlich, die breite Signatur-Migration folgt mit dem Ökosystem (CA/Browser-Forum, Zertifikatsketten) in der zweiten Welle.
- Quantum Key Distribution (QKD): Hardware-basierte Quanten-Schlüsselverteilung ist für KMU keine Alternative — das BSI und seine europäischen Partnerbehörden stufen die Technologie in einem gemeinsamen Positionspapier als nicht ausgereift für den breiten Einsatz ein. PQC ist Software, QKD ist teure Spezialhardware für Nischenszenarien.
- Panik-Einkäufe: „Quantum-safe"-Produktversprechen ohne Bezug auf FIPS 203/204/205 oder BSI-TR-02102 sind ein Warnsignal, kein Kaufargument. Es gibt keinen Grund, funktionierende Infrastruktur vorzeitig herauszureißen — es gibt Gründe, jede Neuanschaffung an PQC-Fähigkeit zu messen.
- Und ganz grundsätzlich: Die akute Bedrohung für den Mittelstand bleibt 2026 Ransomware, nicht Shor's Algorithmus. Wer kein getestetes Backup, keine MFA und kein Monitoring hat, sollte dort zuerst investieren. PQC ist die strategische Baustelle neben der operativen — kein Ersatz dafür.
Fazit: Kein Sprint, aber ein Startschuss
Die Post-Quanten-Migration ist die seltene Sicherheitsaufgabe mit langem Vorlauf und klarem Fahrplan: Standards final seit August 2024, EU-Migrationsstart bis Ende 2026, BSI-Ablaufdatum für rein klassisches RSA/ECC 2030/31, EU-Zielmarken 2030 und 2035. Niemand muss 2026 fertig sein — aber wer 2026 nicht einmal weiß, wo im eigenen Haus welche Kryptografie läuft und welche Daten 2035 noch vertraulich sein müssen, verspielt genau den Vorlauf, der diese Migration entspannt machen könnte.
Das realistische Pensum für ein KMU bis Ende 2027: Krypto-Inventar der extern erreichbaren Systeme und VPN-Strecken, hybrides PQC auf den eigenen TLS-Endpunkten und SSH-Zugängen aktivieren (vielfach nur ein Update plus Konfiguration), Datenklassifizierung nach Vertraulichkeitsdauer und PQC-Fähigkeit als Kriterium in jede Neuanschaffung. Das sind wenige Wochen Aufwand, verteilt über Monate — und deutlich billiger als eine Hauruck-Migration 2030 unter Audit-Druck. Wir unterstützen dabei mit Bestandsaufnahme, Priorisierung und der Umsetzung auf Firewall-, VPN- und Server-Ebene — nüchtern, ohne Quanten-Marketing.