Harvest now, decrypt later: die Frage, die Unternehmenskunden seit 2026 stellen

Eine Frage, die vor zwei Jahren in Sicherheitsfragebögen nicht vorkam, taucht inzwischen regelmäßig auf, meist in einer dieser Formen:

• “Beschreiben Sie Ihren Migrationsplan zur Post-Quantum-Kryptografie.”
• “Unterstützen Ihre öffentlichen Endpunkte hybride Schlüsselvereinbarung?”
• “Wie ist Ihre Krypto-Agilität aufgestellt?”

Die meisten Anbieter antworten schlecht, auf zwei Arten. Entweder heißt es “wir nutzen TLS 1.3 und AES-256”, was die Frage nicht berührt. Oder es folgt eine mehrjährige Roadmap ohne eine einzige ausgerollte Komponente, was wie ein Ausweichen wirkt.

Worum es dem Kunden tatsächlich geht

Die Sorge ist konkret und keine Science-Fiction. Ein Angreifer zeichnet heute verschlüsselten Verkehr auf und speichert ihn. Die Sitzungsschlüssel wurden per Diffie-Hellman auf elliptischen Kurven vereinbart. Sobald ein hinreichend leistungsfähiger Quantencomputer existiert, werden diese Aufzeichnungen rückwirkend entschlüsselt.

Damit hängt das Risiko an einer einzigen Größe, die der Kunde bereits kennt: wie lange seine Daten sensibel bleiben.

Die Sitzungstoken eines Händlers sind nach einer Woche wertlos. Die Kundenakten einer Bank, die Daten eines Krankenhauses, die Handakten einer Kanzlei und die Zeichnungspositionen eines Versicherers bleiben es über Jahrzehnte. Deshalb kommt die Frage überproportional von regulierten Kunden und erreicht Sie angehängt an DORA- und NIS2-Bewertungen statt an den allgemeinen Einkauf.

Der Kunde fragt nicht, ob Sie die Post-Quantum-Kryptografie gelöst haben. Er fragt, ob die Daten, die er Ihnen gleich schickt, heute in einer Form aufgezeichnet werden, die später lesbar ist.

Die Antwort, die trägt

Es gibt eine ausrollbare Komponente, und sie kostet eine Konfigurationszeile.

Aktivieren Sie die hybride Gruppe X25519MLKEM768 auf Ihrer TLS-Terminierung. Browser verhandeln sie seit Chrome, Firefox und Edge 131 standardmäßig. Clients ohne Unterstützung fallen ohne Kompatibilitätsbruch auf klassischen Schlüsselaustausch zurück.

ssl_conf_command Groups X25519MLKEM768:X25519:prime256v1;

Sobald das aktiv ist, hört Ihre Antwort auf, eine Roadmap zu sein, und wird zu einer Beobachtung, die der Kunde selbst nachvollziehen kann:

openssl s_client -connect ihredomain.de:443 -groups X25519MLKEM768

Dieser Wechsel wiegt schwerer, als er aussieht. Ein Sicherheitsteam, das fünfzig Lieferantenantworten liest, prüft diese in zehn Sekunden, ohne Ihnen glauben zu müssen. Extern überprüfbare Aussagen haben ein anderes Gewicht als nicht überprüfbare, aus demselben Grund, aus dem ein externer Bericht mehr zählt als eine Selbstauskunft.

Aufbau der vollständigen Antwort

Eine vollständige Antwort hat vier Teile, und nur der erste muss heute fertig sein.

1. Was ausgerollt ist. Hybride Schlüsselvereinbarung auf allen öffentlichen Endpunkten, mit Nennung der Gruppe und des Aktivierungsdatums.

2. Was nicht, und warum. Die Authentifizierung bleibt klassisch: Ihr Zertifikat ist mit RSA oder ECDSA signiert. Sagen Sie das. Die ehrliche Begründung lautet, dass eine Signaturfälschung während einer laufenden Verbindung erfolgen muss, es also kein Harvest-now-Äquivalent für Authentifizierung gibt, und dass öffentliche Zertifizierungsstellen noch keine Post-Quantum-Ketten ausstellen. Eine Kryptografin auf Kundenseite akzeptiert das. Die Behauptung, Sie seien “vollständig post-quantum”, akzeptiert sie nicht.

3. Krypto-Agilität. Wie lange bräuchten Sie für einen Algorithmenwechsel? Der konkrete Beleg ist hier die Zertifikatsautomatisierung: Teams mit ACME und kurzen Laufzeiten tauschen ihren gesamten Zertifikatsbestand in Wochen. Teams, die von Hand erneuern, können das nicht, und genau das ist das eigentliche Maß für Agilität.

4. Inventar. Welche Endpunkte terminieren TLS, und wer betreibt sie. Ein CDN vor Ihrem Origin bedeutet, dass die hybride Gruppe an zwei Stellen aktiviert werden muss, und Anbieter aktivieren sie regelmäßig am Edge, während die Verbindung zum Origin klassisch bleibt.

Die regionale Nuance

ETSI und das EUCC-Rahmenwerk empfehlen den hybriden Einsatz mindestens bis 2028 und halten rein post-quantenbasierte Deployments für verfrüht. Fragt ein Kunde, warum Sie nicht ML-KEM allein nutzen, ist das die Antwort, und sie beschreibt die empfohlene Haltung, keinen Kompromiss.

Unterliegt der Kunde FIPS-Auflagen, ist anzumerken, dass ML-KEM FIPS-zugelassen ist, X25519 aber nicht, der streng konforme Hybrid also SecP256r1MLKEM768 lautet, den Browser nicht standardmäßig anbieten. Das ist ein echter Zielkonflikt, den Sie nicht verursacht haben, und ihn zu benennen zeigt Sachkenntnis.

Was man nicht sagen sollte

Vermeiden Sie “quantensicher” und “quantenfest”. Beides sind Marketingbegriffe, keiner trifft auf ein hybrides Deployment zu, und eine technische Prüferin zieht dafür Punkte ab.

Vermeiden Sie ein Zusagedatum für die Signaturmigration. Es hängt an der Ausstellung durch die Zertifizierungsstellen und liegt außerhalb Ihrer Kontrolle.

Zuordnung

• NIS2 Artikel 21(2)(h), Kryptografie und Verschlüsselung.
• ISO/IEC 27001:2022 A.8.24, Einsatz von Kryptografie.
• DORA Artikel 9, Schutz, für Finanzunternehmen und ihre IKT-Dienstleister.

Kurzfassung

Die Frage betrifft die Lebensdauer der Daten, nicht Quantencomputer.

Eine Konfigurationszeile liefert Ihnen heute eine ausgerollte, extern überprüfbare Antwort. Kombiniert mit einer ehrlichen Aussage darüber, was noch nicht abgedeckt ist, trägt sie weiter als eine doppelt so lange Roadmap.