Das Wichtigste in Kürze
- Der Zeitdruck kommt nicht vom Quantenrechner, sondern vom Mitschnitt: Was heute abfließt, kann später entschlüsselt werden. Für lange schutzbedürftige Daten läuft die Frist bereits.
- Die Algorithmen sind standardisiert — ML-KEM als FIPS 203, ML-DSA als FIPS 204, SLH-DSA als FIPS 205 —, und IKEv2 kann über RFC 9242 und RFC 9370 mehrere Schlüsselaustausche kombinieren.
- Hybrid ist der empfohlene Übergang: klassisches und post-quantenfestes Verfahren gleichzeitig. Diese Linie tragen NIST, NSA, das BSI und die französische ANSSI gemeinsam.
- Bei Cisco Secure Firewall sind RFC 8784 ab ASA 9.18 und die hybriden Austausche nach RFC 9242/9370 ab ASA 9.19 verfügbar; ML-KEM ist für FTD 10.5 und ASA 9.25 für Ende 2026 angekündigt.
Post-Quantum-Kryptografie leidet unter einem Kommunikationsproblem: Sie wird als Zukunftsthema verhandelt, obwohl der Teil mit der Frist längst begonnen hat. Der Grund ist unspektakulär und liegt nicht in der Rechenleistung, sondern im Speicher.
Warum die Uhr bereits läuft
Das Angriffsmodell heißt „harvest now, decrypt later“: Verschlüsselter Verkehr wird heute mitgeschnitten und gespeichert, um ihn zu entschlüsseln, sobald ein hinreichend leistungsfähiger Quantenrechner existiert. Für den Angreifer ist das billig — Speicher kostet fast nichts, und er muss nicht wissen, was er hat.
Daraus folgt die einzige Rechnung, die für die Planung zählt: Wie lange müssen die Daten geschützt bleiben, die heute über diese Strecke laufen? Bei Konstruktionsdaten, Patentvorbereitungen, Personal- oder Gesundheitsdaten sind zehn Jahre eine konservative Annahme. Wer solche Daten über eine Verbindung schickt, die nur klassisch geschützt ist, hat die Frist bereits überschritten — unabhängig davon, wann der erste kryptografisch relevante Quantenrechner tatsächlich läuft.
Was inzwischen standardisiert ist
Die Unsicherheit der letzten Jahre ist an dieser Stelle vorbei. Es gibt benannte Standards, und die Protokollarbeit für IKEv2 ist abgeschlossen.
| Standard | Was er regelt | Rolle im Netz |
|---|---|---|
| FIPS 203 — ML-KEM | Schlüsselkapselung, Parameter 512/768/1024 | Schlüsselaustausch für VPN und TLS |
| FIPS 204 — ML-DSA | Digitale Signaturen | Geräte- und Softwareauthentisierung |
| FIPS 205 — SLH-DSA | Hashbasierte Signaturen | Alternative mit anderer mathematischer Grundlage |
| RFC 9242 | Intermediate Exchange in IKEv2 | Trägt die großen Schlüssel, ohne IP-Fragmentierung zu erzwingen |
| RFC 9370 | Mehrere Schlüsselaustausche in IKEv2 | Ermöglicht den hybriden Austausch |
| RFC 8784 | Post-Quantum-Preshared-Keys für IKEv2 | Übergangsschutz ohne neue Algorithmen |
Der Zusammenhang zwischen den beiden RFCs ist der praktische Kern: RFC 9370 erlaubt, während eines IKEv2-Aufbaus mehrere Schlüsselaustausche zu kombinieren und daraus einen gemeinsamen Schlüssel abzuleiten. Weil post-quantenfeste Schlüssel deutlich größer sind als klassische, braucht es dafür RFC 9242 — den Intermediate Exchange —, damit die Nachrichten nicht auf IP-Ebene fragmentiert werden müssen. Beides zusammen ergibt einen hybriden Austausch, der abwärtskompatibel bleibt.
Hybrid ist die Empfehlung, nicht der faule Kompromiss
Bei einem hybriden Verfahren laufen ein klassisches und ein post-quantenfestes Verfahren gleichzeitig; der Sitzungsschlüssel entsteht aus beiden. Der Verkehr ist damit genau so lange sicher, wie mindestens eines der beiden Verfahren hält.
Das ist kein Zögern, sondern die begründete Übergangsstrategie: Die post-quantenfesten Verfahren sind jung, und ihre Implementierungen sind es erst recht. Die Kombination schützt gegen den Quantenrechner, ohne im Gegenzug ein Risiko aus einem Implementierungsfehler in einem neuen Verfahren einzukaufen. NIST, die NSA, das BSI und die französische ANSSI empfehlen diesen Weg übereinstimmend für die Migrationsphase.
Was auf Cisco-Plattformen verfügbar ist — und was angekündigt
Für Cisco Secure Firewall ist der Fahrplan öffentlich und ungewöhnlich konkret. Zwei Dinge sind heute nutzbar, der Rest ist datierte Roadmap:
| Fähigkeit | Release | Zeitpunkt |
|---|---|---|
| RFC 8784 (Post-Quantum-Preshared-Keys) | ASA ab 9.18 | verfügbar |
| RFC 9242 / RFC 9370 (hybrider Austausch) | ASA ab 9.19 | verfügbar |
| ML-KEM für VPN-Handshakes | FTD 10.5 / ASA 9.25 | angekündigt für Ende 2026 |
| TLS-Entschlüsselung mit PQC | FTD 10.5 | angekündigt |
| ML-DSA und SLH-DSA (Signaturen) | FTD/ASA 11.0 | angekündigt für H2 2027 |
| Remote-Access-VPN mit PQC | ASA/FTD 11.0 | geplant |
Die wichtigste Lesart dieser Tabelle: Der Übergangsschutz ist keine Zukunftsfrage. Wer ASA in einer Version ab 9.19 betreibt, kann hybride Austausche heute aktivieren — für die Strecken, auf denen langlebig schutzbedürftige Daten laufen. Das ist eine Konfigurationsentscheidung, kein Beschaffungsprojekt.
Bei MACsec liegen die Dinge anders. Die Integration post-quantenfester Verfahren in den dynamischen Schlüsselaustausch ist in Arbeit, aber Terminaussagen sind hier mit Vorsicht zu behandeln, solange die Funktionen nicht in einem freigegebenen Konfigurationsleitfaden stehen. Für Strecken zwischen Rechenzentren, die heute mit MACsec geschützt sind, heißt das: Das Thema gehört auf die Risikoliste, nicht auf den Projektplan.
Der Schritt, der immer zuerst kommt: das Krypto-Inventar
Jede Migrationsplanung scheitert an derselben Frage: Wo genau wird was verschlüsselt? Nicht auf Produktebene, sondern auf Strecken- und Algorithmusebene. Diese Erhebung ist unspektakulär, dauert Wochen und ist der einzige Teil, der sich nicht durch ein Upgrade ersetzen lässt.
Strecken erfassen
Jeder Tunnel, jede TLS-terminierende Stelle, jede MACsec-Verbindung, jeder Management-Zugang. Auch die, die seit Jahren niemand angefasst hat — besonders die.
Verfahren je Strecke bestimmen
Welcher Schlüsselaustausch, welche Signatur, welche Schlüssellängen? Das steht in der Konfiguration, nicht im Datenblatt.
Schutzdauer der Daten zuordnen
Fachlich, nicht technisch: Wie lange muss vertraulich bleiben, was hier fließt? Diese Zahl bestimmt die Priorität, nicht die Bandbreite der Strecke.
Gegenstellen und Abhängigkeiten prüfen
Ein hybrider Austausch braucht beide Seiten. Fremdgegenstellen, Cloud-Endpunkte und ältere Appliances entscheiden über die tatsächliche Reihenfolge.
Reihenfolge festlegen und umsetzen
Zuerst die Strecken mit langer Schutzdauer und beidseitig fähigen Endpunkten. Umstellung als regulärer Change mit Rückfallplan, nicht als Sonderaktion.
Dieses Inventar hat einen Nebennutzen, der die Arbeit oft allein rechtfertigt: Es findet zuverlässig die Strecken, die noch mit veralteten Verfahren oder abgelaufenen Zertifikaten arbeiten. Die Post-Quantum-Frage ist dann der Anlass, nicht der einzige Ertrag. Wie wir solche Erhebungen führen und in belastbare Changes überführen, beschreibt unsere Arbeitsweise unter Unternehmensnetze und Netzwerk-Security.
Was in zwölf Monaten realistisch ist
- Krypto-Inventar für die Kernstrecken. Vollständig für Site-to-Site-VPN, Management-Zugänge und Rechenzentrumsverbindungen.
- Hybride Austausche dort aktivieren, wo beide Seiten es können. Auf ASA ab 9.19 ist das eine Konfiguration, kein Projekt.
- Beschaffung anpassen. Neue Firewalls, Router und Terminierungspunkte werden gegen die Fähigkeit geprüft, ML-KEM per Software nachzurüsten — nicht gegen die heutige Funktionsliste.
- Zertifikatslaufzeiten und -prozesse aufräumen. Die Signaturumstellung kommt 2027; sie trifft nur die vorbereitet, die wissen, welche Zertifikate wo hängen — und die 47-Tage-Staffel zwingt ohnehin zur Automatisierung.
- Die MACsec-Strecken als offenen Punkt führen. Mit Datum der nächsten Prüfung, nicht als erledigt.
Was in zwölf Monaten nicht realistisch ist: eine vollständig post-quantenfeste Infrastruktur. Das ist keine Schwäche der Planung, sondern der Stand der Implementierungen. Reine PQC-Betriebsmodi bleiben vorerst die Ausnahme; der hybride Übergang ist für diese Phase der Zielzustand.
Quellen
Jede belegte Aussage dieses Beitrags ist hier nachvollziehbar. Das Abrufdatum sagt, wie frisch die Prüfung ist.
- Preparing for Post-Quantum Cryptography: The Secure Firewall Roadmapöffnet in neuem Tab
Cisco Blogs · abgerufen am 2. August 2026
- RFC 9370 — Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)öffnet in neuem Tab
IETF / RFC Editor · abgerufen am 2. August 2026
- RFC 9242 — Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)öffnet in neuem Tab
IETF / RFC Editor · abgerufen am 2. August 2026
- FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standardöffnet in neuem Tab
NIST · abgerufen am 2. August 2026
- Post-Quantum Security: Why Cisco Is Preparing Networks for Threats That Don't Exist Yetöffnet in neuem Tab
Networkers Home · abgerufen am 2. August 2026

