Post-Quantum-Kryptografie oder Quantenkryptografie: was Unternehmen wirklich brauchen

Das Wichtigste im Überblick

• Die beiden Ansätze lösen unterschiedliche Probleme. Post-Quanten-Kryptografie ersetzt oder ergänzt gefährdete Algorithmen und lässt sich grundsätzlich in bestehende IT- und Netzinfrastrukturen integrieren. QKD etabliert Schlüsselmaterial für symmetrische Kryptografie über einen Quantenkanal und benötigt dafür dedizierte Infrastruktur, dazu einen authentisierten klassischen Kanal.
• Vier europäische Behörden haben sich gemeinsam positioniert. ANSSI, BSI, die niederländische NLNCSA und die schwedischen Streitkräfte halten QKD wegen funktionaler und technologischer Einschränkungen derzeit nur in Nischenanwendungen für praktisch einsetzbar und aus Sicherheitssicht für noch nicht ausreichend ausgereift. Die Priorität für die allgemeine Migration liegt nach ihrer Einschätzung bei Post-Quanten-Kryptografie und je nach Anwendungsfall bei symmetrischen Schlüsselverfahren (Quellen: BSI, Quantenkryptografie; Positionspapier zu Quantum Key Distribution).
• Hybride Schlüsseleinigung ist in Europa die empfohlene Übergangsstrategie. Das BSI empfiehlt sie für die Übergangsphase (Quelle: BSI, TR-02102-1). Die ANSSI beschreibt einen dreistufigen Übergang und betont die Notwendigkeit der Hybridisierung kurz- und mittelfristig ausdrücklich; eine optionale Nutzung reiner Post-Quanten-Verfahren erwartet sie erst in einer späteren Phase, wahrscheinlich nach 2030 (Quellen: ANSSI, Positionspapier 2022; ANSSI, Follow-up 2023). Eine allgemeine gesetzliche Hybridpflicht für Unternehmen folgt daraus nicht.
• Für den hybriden TLS-Schlüsselaustausch liegen die Standards vor.RFC 9954 erschien im Juli 2026 als Informational RFC und beschreibt den Rahmen hybrider Schlüsselaustausche in TLS 1.3, RFC 10024 im August 2026 als Standards-Track-RFC mit den konkreten Verfahren. X25519MLKEM768 ist die einzige der drei dort standardisierten Gruppen, die im IANA-Register als „Recommended: Y“ markiert ist (Quelle: IANA, TLS Supported Groups). Zertifikate, Signaturen, PKI, SSH, IPsec und HSM-Schnittstellen deckt das nicht ab.
• QKD hat eine Nische und eigene Infrastrukturkosten. Ein Quantenkanal, spezielle Komponenten und deren Betrieb kommen zusätzlich zur klassischen Absicherung hinzu. Im Feldversuch ParisRegionQCI bezifferte ein Orange-Forscher allein die QKD-Systeme für eine dedizierte Faserstrecke unter 100 Kilometer auf etwa 180.000 bis 250.000 Euro (Quelle: Mobile Europe, 20.06.2024). Faser, Verschlüsselung, Management, Redundanz und etwaige Trusted Nodes sind darin nicht enthalten.

Was unterscheidet Post-Quantum-Kryptografie von Quantenkryptografie?

Quellen: Federal Register, FIPS 203, 204 und 205; RFC 10024; BSI, Quantenkryptografie

Der entscheidende Punkt steht in der Zeile zur Authentisierung: QKD etabliert Schlüsselmaterial und signiert nichts. Der zugehörige klassische Kanal muss authentisiert sein, damit ein Angreifer sich nicht dazwischenschalten kann, und diese Authentisierung erfolgt mit klassischen oder Post-Quanten-Verfahren. QKD ersetzt Post-Quanten-Kryptografie also nicht, auch nicht in dem Bereich, für den es gebaut ist.

Hinzu kommt der Deckungsgrad. Von den beiden gefährdeten Bereichen, Schlüsselvereinbarung und Signatur, adressiert QKD nur den ersten. Die gesamte Signaturseite, also PKI, Codesignatur, Dokumentensignatur und Authentisierung, bleibt unberührt.

Wie funktioniert Quantum Key Distribution technisch?

Zwei Stationen übertragen quantenmechanische Zustände von Licht über einen Quantenkanal, im Protokoll BB84 etwa einzelne Photonen oder schwache kohärente Lichtpulse. Eine nicht passende Messung durch einen Angreifer verändert diese Zustände so, dass es sich statistisch als erhöhte Fehlerrate zeigt. Übersteigt die gemessene Fehlerrate einen Schwellwert, verwerfen beide Seiten das Material. Liegt sie darunter, folgen Fehlerkorrektur und Privacy Amplification; erst danach entsteht der gemeinsame symmetrische Schlüssel, der anschließend ein klassisches Verfahren wie AES speist.

Die Sicherheitsaussage ist stark, aber an Annahmen gebunden. Moderne Sicherheitsanalysen können bestimmte Geräteimperfektionen berücksichtigen; der Beweis gilt jedoch nur unter den zugrunde gelegten Modellannahmen und für eine korrekt implementierte Gegenmaßnahme. Damit liegt die eigentliche Frage bei der Implementierungssicherheit: Ein wesentlicher Teil der praktischen Angriffe richtet sich gegen Implementierungsdetails der QKD-Hardware, etwa Detektoren, Back-Flash-Effekte oder den lokalen Oszillator (Quelle: ETSI, White Paper zur QKD-Implementierungssicherheit). Das BSI verweist auf eine erhebliche Zahl veröffentlichter Angriffe, die Schwächen der Hardware von QKD-Systemen ausnutzen (Quelle: BSI, Quantenkryptografie).

Praktisch begrenzt die Dämpfung der Faser die Reichweite. Längere Strecken benötigen vertrauenswürdige Zwischenknoten, die Schlüsselmaterial über mehrere QKD-Abschnitte hinweg vermitteln und dabei selbst Zugriff darauf erhalten. Damit verlagert sich das Vertrauen auf diese Knoten, und die ursprüngliche Sicherheitsaussage gilt nur noch abschnittsweise.

Warum raten europäische Behörden von QKD als Allzwecklösung ab?

Ende Januar 2024 haben BSI, ANSSI, das niederländische NLNCSA und die schwedischen Streitkräfte ein gemeinsames Positionspapier zu Quantum Key Distribution veröffentlicht (Quelle: BSI, Position Paper on Quantum Key Distribution). Die Behörden raten darin nicht grundsätzlich von QKD ab, sondern von der breiten Verwendung als allgemeine Lösung für die Migration; weitere Forschung halten sie ausdrücklich für sinnvoll. Das BSI gibt die Schlussfolgerungen auf seiner Themenseite so wieder:

Die tschechische Behörde NÚKIB hat sich dem Papier im September 2024 mit einer Unterstützungserklärung angeschlossen und übernimmt dieselbe differenzierte Position (Quelle: NÚKIB, Letter of Support). Für die Beschaffung heißt das: Wer in Deutschland ein Angebot für ein QKD-System bewertet, sollte zwei Fragen stellen. Welche zusätzliche Sicherheitsgarantie liefert QKD gegenüber einer Lösung mit post-quantensicherer beziehungsweise hybrider Schlüsselvereinbarung? Und welche zusätzlichen Annahmen, Infrastrukturen und Betriebsrisiken entstehen dafür?

Was genau ist ein hybrides Verfahren?

Ein hybrides Verfahren führt zwei unabhängige Schlüsselvereinbarungen parallel durch, eine klassische und eine post-quantensichere, und leitet den Sitzungsschlüssel aus beiden Ergebnissen ab. Bei einer geeignet konstruierten Hybridisierung bleibt die Sicherheit des abgeleiteten Schlüssels erhalten, solange mindestens eines der beiden Komponentenverfahren sicher ist. Das ist eine kryptografische Konstruktion mit eigenen Annahmen und kein doppeltes Verschlüsseln.

Der Sinn liegt in der Absicherung gegen zwei entgegengesetzte Risiken. Das klassische Verfahren hat eine lange kryptanalytische Historie und ist gegenüber bekannten klassischen Angriffen gut untersucht, bleibt aber gegenüber einem hinreichend leistungsfähigen Quantencomputer verwundbar, soweit es auf Faktorisierung oder diskreten Logarithmen beruht. Das Post-Quanten-Verfahren ist gegen Quantenangriffe ausgelegt: ML-KEM beruht auf Module-LWE, einem intensiv untersuchten Gitterproblem, dessen kryptanalytische Historie aber deutlich kürzer ist als die der klassischen Annahmen hinter RSA und elliptischer Kryptografie.

Für hashbasierte Signaturen ist eine Hybridisierung nach der ANSSI-Empfehlung optional. SLH-DSA, LMS und XMSS beruhen auf Hashfunktionen, deren Sicherheitsannahmen gut verstanden sind (Quelle: ANSSI, Follow-up 2023).

Welche hybriden Standards sind heute einsetzbar?

RFC 10024 definiert drei Codepoints: X25519MLKEM768 mit 4588 (0x11EC), im IANA-Register als „Recommended: Y“ markiert, sowie SecP256r1MLKEM768 mit 4587 und SecP384r1MLKEM1024 mit 4589, beide dort nicht als empfohlen markiert (Quelle: IANA, TLS Supported Groups). Für allgemeine TLS-1.3-Einsätze ist X25519MLKEM768 derzeit die naheliegende Standardwahl. Konkrete Vorgaben können je nach Sicherheitsprofil, FIPS- oder CNSA-2.0-Anforderungen und regulatorischem Umfeld abweichen; für CNSA-2.0-regulierte Umgebungen ist insbesondere ML-KEM-1024 relevant.

Bemerkenswert an dieser Tabelle ist der Abstand zwischen Einsatz und Standardisierung. Was seit 2024 in Browsern läuft, war zunächst ein Einsatz vor der Standardisierung: Google verwendete eine Entwurfsfassung mit Kyber, Chrome wechselte mit Version 131 auf die finale ML-KEM-Variante, und beide Fassungen sind nicht miteinander kompatibel (Quelle: Google Security Blog). Zum Standard wurde das Verfahren erst im Sommer 2026. Wer eine Beschaffungsunterlage oder eine Architekturrichtlinie aus 2025 verwendet, findet dort noch Entwurfsbezeichnungen.

Verfügbar ist das Verfahren an folgenden Stellen: in Chrome seit Version 131 vom 12. November 2024 (Quelle: Google Security Blog), in Firefox auf dem Desktop seit Version 132 vom 29. Oktober 2024 und für HTTP/3 seit Version 135 (Quellen: Firefox 132; Firefox 135), auf Apple-Plattformen seit iOS, iPadOS und macOS 26 (Quelle: Apple Support), in OpenSSL seit Version 3.5.0 vom 8. April 2025 (Quelle: OpenSSL 3.5), in Go ab 1.24 (Quelle: Go 1.24), in Java ab JDK 27 vom September 2026 (Quellen: JEP 527; inside.java) und in Node.js ab v24.5.0 über das mitgelieferte OpenSSL 3.5 (Quelle: Node.js v24.5.0). OpenSSH nutzt das entsprechende SSH-Verfahren mlkem768x25519-sha256 seit Version 9.9 und als Standard seit Version 10.0 vom 9. April 2025 (Quellen: OpenSSH 9.9; OpenSSH 10.0). Verfügbar bedeutet dabei nicht, dass das Verfahren in einer konkreten Verbindung auch ausgehandelt wird: Konfiguration, Gegenstelle, FIPS-Modus, Sicherheitsrichtlinien und Zwischensysteme beeinflussen das Ergebnis.

Der Effekt ist messbar, allerdings an zwei verschiedenen Messgrößen. Der Anteil des post-quanten-verschlüsselten, menschlich erzeugten Datenverkehrs bei Cloudflare stieg von 29 Prozent Anfang 2025 auf 52 Prozent Anfang Dezember 2025 (Quelle: Cloudflare, Radar 2025 Year in Review) und lag im April 2026 bei über 65 Prozent (Quelle: Cloudflare, Post-Quantum Roadmap). Davon getrennt zu lesen ist die Serverseite: Im Februar 2026 unterstützten rund 10 Prozent der Origin-Server einen Post-Quanten-Schlüsselaustausch (Quelle: Cloudflare Blog, 27.02.2026), im September 2026 waren es über 12 Prozent (Quelle: Cloudflare, Automatic key exchange for origins, 08.09.2026). Clientverkehr und Serverunterstützung messen Verschiedenes und lassen sich nicht gegeneinander verrechnen.

Wann ist Hybrid vorgegeben und wann eine Architekturentscheidung?

Drei Kategorien sind zu unterscheiden: eine verbindliche Vorgabe aus einer Regulierung, einem Vertrag oder einem Sicherheitsprofil, eine technische Empfehlung einer Behörde und eine freiwillige Architekturentscheidung. Die folgende Übersicht ordnet die wichtigsten Quellen diesen Kategorien zu.

Daraus ergibt sich der häufigste Konflikt in internationalen Konzernen: Die europäischen Behörden empfehlen die Hybridisierung nachdrücklich, CNSA 2.0 definiert dagegen ein eigenes Profil für National Security Systems und setzt auf festgelegte Parameterstufen ohne zusätzliche klassische Komponente (Quelle: NSA, CNSA 2.0 FAQ). Eine gemeinsame Konfiguration für beide Räume gibt es deshalb nicht: X25519MLKEM768 erfüllt CNSA 2.0 nicht, weil dort ML-KEM-1024 verlangt wird. Für Systeme, die unter CNSA 2.0 beziehungsweise entsprechende Anforderungen an National Security Systems fallen, ist ein separates konformes Profil erforderlich; allein US-Kunden zu haben, begründet das nicht. Für viele europäische Enterprise-Szenarien ist die hybride Schlüsselvereinbarung derzeit die naheliegende Übergangsstrategie.

Der zusätzliche Rechenaufwand für ML-KEM-768 neben X25519 ist bei modernen TLS-Implementierungen häufig überschaubar. Die wesentlichen Betriebsrisiken liegen woanders: Der zusätzliche Schlüsselanteil von rund 1,2 Kilobyte vergrößert den ClientHello so weit, dass er bei typischen Konfigurationen mehrere TCP-Segmente benötigen kann (Quelle: Cloudflare, Post-quantum to origins). Aufwand entsteht deshalb bei der Bestandsaufnahme und bei Zwischensystemen, die aufgeteilte ClientHellos nicht verarbeiten (Quelle: tldr.fail), dazu bei Tests, Interoperabilität und veralteten Netzwerkkomponenten.

Wo hat Quantenkryptografie trotzdem einen Platz?

In klar abgegrenzten Fällen. Dafür sprechen eine begrenzte Distanz, kontrollierbare Endpunkte und Übertragungswege, sehr hohe Schutzanforderungen über lange Zeiträume und die Bereitschaft, dedizierte Infrastruktur zu betreiben. Als mögliche Einsatzfelder gelten Verbindungen zwischen Rechenzentren eines Finanzinstituts innerhalb einer Metropolregion und staatliche Kommunikationsstrecken, wie sie auch EuroQCI und FranceQCI adressieren. In größeren Netzen ist QKD ebenfalls einsetzbar, dann aber mit zusätzlichen Komponenten wie vertrauenswürdigen Zwischenknoten. Die Praxis zeigt, dass sich der Aufwand rechnen muss. Ein Orange-Forscher hat ihn in einem Feldversuch beziffert.

Orange hat den Ansatz in kombinierter Form weiterverfolgt. Im Juni 2024 wurde im Projekt ParisRegionQCI eine rund 80 Kilometer lange Strecke über bereits verlegte Glasfasern von Orange France betrieben, teils in Betrieb, teils unbeschaltet, mit QKD-Systemen und Relais, die mit Post-Quanten-Kryptografie gesichert waren (Quellen: Mobile Europe, 20.06.2024; ID Quantique). Orange koordiniert außerdem als einziger Telekommunikationsbetreiber im Konsortium das Projekt FranceQCI, den französischen Beitrag zur europäischen EuroQCI-Initiative (Quelle: Orange Newsroom, FranceQCI).

Aus dieser Arbeit ist ein kommerzielles Angebot entstanden. Orange Business hat am 11. Juni 2025 zusammen mit Toshiba Europe den Dienst Orange Quantum Defender gestartet, der QKD und PQC in einer hybriden Architektur kombiniert und über bestehende Glasfaser gelegt wird (Quelle: Orange Business, Pressemitteilung vom 11.06.2025). Am 10. Februar 2026 kündigte Orange Business PQC-gesicherte WAN-Dienste auf Basis der Cisco 8000 Series Secure Router an (Quelle: Orange Business, Pressemitteilung vom 10.02.2026).

Auch ein QKD-Einsatz sollte in eine übergeordnete Strategie für quantensichere Kommunikation eingebettet sein. Krypto-Agilität und eine Bestandsaufnahme der vorhandenen Kryptoinfrastruktur sind dabei die breiter nutzbaren ersten Schritte; Orange führt beides als Bestandteile des Ansatzes hinter Quantum Defender auf (Quelle: Orange Business, Orange Quantum Defender).

Fazit: Erst PQC, dann die Frage nach QKD

Für praktisch jede Organisation ist Post-Quanten-Kryptografie die Antwort und QKD eine Zusatzfrage für einzelne Strecken. Der Grund ist die Abdeckung: PQC umfasst Verfahren für die Schlüsselvereinbarung und für Signaturen und ist damit überall einsetzbar, wo Kryptografie heute verwendet wird. QKD erzeugt Schlüsselmaterial für symmetrische Kryptografie auf einer Strecke und ersetzt weder digitale Signaturen noch die Authentisierung von Kommunikationspartnern.

Eine wichtige europäische Besonderheit ist die nachdrückliche Empfehlung zur Hybridisierung. Sie adressiert ein reales Restrisiko: Die Erfahrung mit der langfristigen kryptanalytischen und Implementierungssicherheit der Gitterverfahren ist deutlich kürzer als bei den etablierten klassischen Verfahren, und die klassische Komponente erhält die bisherige Sicherheitsbasis. Der Rechenaufwand ist dabei meist überschaubar, die Gesamtaufwände können durch größere Nachrichten, Zwischensysteme, Altsysteme, Tests und Überwachung aber erheblich sein. Für Systeme im Anwendungsbereich von CNSA 2.0 gilt ein eigenes Profil mit ML-KEM-1024; das ist eine separate Architektur- und Nachweisvorgabe, kein zweiter europäischer Weg.

Wie können die nächsten Schritte aussehen?

1. Hybride Schlüsselvereinbarung als Standard festlegen. Verankern Sie in der Krypto-Richtlinie, dass die Post-Quanten-Schlüsselvereinbarung hybrid erfolgt, mit begründeten Ausnahmen. Damit folgen Sie der BSI-Empfehlung (Quelle: BSI, TR-02102-1). Für Systeme im Anwendungsbereich von CNSA 2.0 braucht es ein eigenes Profil mit ML-KEM-1024 (Quelle: NSA, CNSA 2.0 FAQ). Bei Signaturen ist Hybridisierung kein universelles Muster: Die Empfehlung betrifft vor allem die Schlüsselvereinbarung.
2. X25519MLKEM768 konfigurieren. Von den drei in RFC 10024 standardisierten Gruppen ist sie die einzige, die im IANA-Register als empfohlen markiert ist, und in den gängigen aktuellen Bibliotheken verfügbar (Quellen: IANA, TLS Supported Groups; OpenSSL 3.5). Eine universelle Konfigurationspflicht folgt daraus nicht; prüfen Sie Ihr Sicherheitsprofil.
3. QKD-Angebote am Anwendungsfall messen. Verlangen Sie eine Begründung, welche Sicherheitsanforderung QKD erfüllt, die sich mit Post-Quanten-Kryptografie allein oder in Kombination mit geeigneten symmetrischen Verfahren nicht wirtschaftlicher erfüllen lässt. Lassen Sie Gesamtbetriebskosten, Reichweite, Redundanz, vertrauenswürdige Zwischenknoten, Hardwareabhängigkeiten und Verfügbarkeit ausweisen.
4. Die Authentisierung mitdenken. Eine QKD-Architektur benötigt einen authentisierten klassischen Kanal. Für langfristige Quantensicherheit muss dessen Authentisierung ebenfalls gegen Quantenangriffe ausgelegt sein, etwa über Post-Quanten-Signaturen oder geeignete symmetrische Mechanismen. In der Praxis führt ein QKD-Projekt deshalb meist auch zu Post-Quanten-Kryptografie.
5. Serverseite prüfen. Im Browserverkehr wird der hybride Schlüsselaustausch überwiegend ausgehandelt, auf der Serverseite unterstützt ihn erst eine Minderheit der Origin-Server: über 65 Prozent des menschlich erzeugten Datenverkehrs im April 2026 gegenüber über 12 Prozent der Origin-Server im September 2026 (Quellen: Cloudflare, Post-Quantum Roadmap; Cloudflare Blog, 27.02.2026; Cloudflare, Automatic key exchange for origins, 08.09.2026). Der Nachholbedarf liegt damit in Ihrem Rechenzentrum, nicht bei Ihren Nutzerinnen und Nutzern.

Weitere Informationen dazu finden Sie in den Artikeln Umsetzung der NIST-PQC-Standards in Unternehmensnetzwerken, Risikobewertung des Quantencomputer-Risikos und Migrationsplanung und Quantum Computing und Post-Quantum Security im Überblick.