Seit NIST 2024 die ersten drei Post-Quantum-Cryptography-Standards finalisiert hat, wirkt die nächste Frage einfach: Wann ersetzen Unternehmen ihre heutigen Verfahren durch ML-KEM, ML-DSA oder SLH-DSA?
In der Praxis ist diese Frage zu spät gestellt. Bevor ein Verfahren ersetzt werden kann, muss eine Organisation wissen, wo Kryptografie eingesetzt wird, welche Systeme voneinander abhängen, wie lange Daten geschützt bleiben müssen und ob sich ein Algorithmus überhaupt ändern lässt, ohne den Betrieb zu unterbrechen.
Diese Fähigkeit heißt Krypto-Agilität. Sie ist kein einzelnes Produkt und kein Schalter in einer TLS-Konfiguration. Krypto-Agilität bedeutet, kryptografische Verfahren, Schlüssel, Zertifikate und Protokolle kontrolliert finden, bewerten, austauschen und überwachen zu können.
Für die Post-Quantum-Readiness ist das der eigentliche Startpunkt.
Warum „wir nutzen TLS“ keine ausreichende Antwort ist
Viele Unternehmen dokumentieren Verschlüsselung auf einer groben Ebene: Datenbank verschlüsselt, VPN vorhanden, TLS aktiv. Das reicht für eine Migration nicht. Derselbe Geschäftsprozess kann an mehreren Stellen unterschiedliche Verfahren verwenden:
- Browser oder Client baut eine TLS-Verbindung auf.
- Ein Proxy oder Security Service inspiziert und terminiert die Verbindung.
- Die Anwendung ruft weitere interne oder externe APIs auf.
- Zertifikate werden durch unterschiedliche PKI-Prozesse ausgestellt.
- Daten werden gespeichert, archiviert, exportiert oder in Backups kopiert.
- Geräte oder Appliances besitzen eigene, nur langsam aktualisierbare Krypto-Bibliotheken.
Wenn nur eine Komponente einen neuen Algorithmus unterstützt, ist die Kette noch nicht migriert. Wenn ein Altgerät nach der Änderung nicht mehr kommuniziert, kann eine theoretisch richtige Maßnahme zum Produktionsproblem werden.
Krypto-Agilität macht diese Abhängigkeiten vor der Umstellung sichtbar.
Drei Zeitachsen, die nicht verwechselt werden dürfen
1. Lebensdauer der Daten
Manche Informationen verlieren nach Tagen ihren Wert. Andere bleiben über Jahre vertraulich: Entwicklungsdaten, Gesundheitsinformationen, personenbezogene Archive, Vertrags- oder Infrastrukturdaten. Je länger die erforderliche Vertraulichkeit, desto relevanter ist das Risiko, verschlüsselte Kommunikation heute aufzuzeichnen und später mit leistungsfähigeren Verfahren zu entschlüsseln.
2. Lebensdauer der Systeme
Ein Browser oder Cloud-Dienst kann relativ schnell aktualisiert werden. Produktionsanlagen, Netzwerkkomponenten, Embedded Devices und branchenspezifische Anwendungen bleiben oft deutlich länger im Einsatz. Die Migration muss daher nicht nur moderne Standardsoftware, sondern auch den langsamsten relevanten Bestandteil berücksichtigen.
3. Dauer der organisatorischen Umstellung
Inventar, Verantwortlichkeiten, Tests, Beschaffung, Verträge, Ausnahmen und Rollout benötigen Zeit. Selbst wenn heute kein akuter Algorithmuswechsel vorgeschrieben ist, kann die Vorbereitungszeit länger sein als das später verfügbare Migrationsfenster.
Eine belastbare Roadmap verbindet diese drei Zeitachsen. Sie priorisiert zuerst die Daten und Systeme, bei denen lange Schutzdauer, lange Lebensdauer und geringe Änderbarkeit zusammenkommen.
Was in ein Krypto-Inventar gehört
Ein Krypto-Inventar ist mehr als eine Liste von Zertifikaten. Für jede relevante Beziehung sollten mindestens folgende Informationen erfasst werden:
- Geschäftsprozess und Datenkategorie,
- Quelle, Ziel und Kommunikationsweg,
- Protokoll und eingesetzte Krypto-Bibliothek,
- Zertifikats- und Schlüsselverantwortung,
- Algorithmus und Parameter, soweit ermittelbar,
- TLS-Inspection, Proxy- oder Gateway-Beteiligung,
- Hersteller- und Produktabhängigkeit,
- Update- und Testmöglichkeit,
- erforderliche Schutzdauer,
- technischer und fachlicher Owner.
Nicht alles muss am ersten Tag vollständig sein. Wichtig ist, Unsicherheit sichtbar zu machen. Transparent markierte Prüflücken sind in diesem Stadium wertvoller als ein vermeintlich vollständiges Inventar, das nur die zentrale PKI betrachtet.
Die besondere Rolle von TLS-Inspection und Sicherheitsdiensten
In bestehenden Zscaler-Umgebungen verlaufen viele relevante Verkehrswege durch Sicherheits- und Zugriffsschichten. TLS-Inspection, Zertifikatsketten, Browser- und Applikationskompatibilität sowie Bypass-Regeln beeinflussen, welche Verfahren praktisch nutzbar sind.
Das macht eine Zscaler-Umgebung nicht automatisch „quantensicher“ oder „nicht quantensicher“. Es bedeutet, dass sie in der Migrationsanalyse als aktive Komponente der Verbindung berücksichtigt werden muss.
Ein sinnvoller Readiness-Check fragt:
- Welche Verkehrswege werden inspiziert, terminiert oder ausgenommen?
- Welche Zertifikate und Vertrauensketten sind beteiligt?
- Welche Anwendungen oder Geräte reagieren empfindlich auf Änderungen?
- Welche Richtlinien unterscheiden interne, externe und besonders schützenswerte Kommunikation?
- Wie werden Tests, Ausnahmen und Rückfalloptionen dokumentiert?
Diese Fragen verbinden PQC mit realem Netzwerk- und Security-Betrieb, statt das Thema in einer isolierten Kryptografie-Arbeitsgruppe zu belassen.
Ein pragmatischer Weg in vier Arbeitspaketen
Arbeitspaket 1: Schutzbedarf und Scope
Zuerst werden besonders langlebige oder regulatorisch sensible Datenklassen und ihre wichtigsten Geschäftsprozesse ausgewählt. Das verhindert, dass die Initiative in einem unternehmensweiten Vollinventar steckenbleibt.
Arbeitspaket 2: Verkehrs- und Krypto-Inventur
Für die ausgewählten Prozesse werden Kommunikationswege, TLS-Inspection, Zertifikate, Richtlinien, Anwendungen und technische Owner erfasst. Automatisierte Funde werden mit Architekturwissen und Interviews abgeglichen.
Arbeitspaket 3: Kompatibilitäts- und Policy-Review
Die Organisation prüft, welche Komponenten neue oder hybride Verfahren unterstützen, wo Abhängigkeiten bestehen und welche Ausnahmen heute bereits die Sichtbarkeit oder Steuerbarkeit einschränken. Kritische Pfade erhalten konkrete Testfälle.
Arbeitspaket 4: Crypto-Agility-Roadmap
Aus Risiko, Lebensdauer, Änderbarkeit und Abhängigkeiten entsteht eine priorisierte Roadmap. Sie benennt Verantwortliche, Testumgebungen, Beschaffungsanforderungen, Entscheidungszeitpunkte und Rückfallpfade.
Das Ergebnis ist keine Behauptung „PQC-ready“. Es ist eine überprüfbare Liste der nächsten Entscheidungen.
Fünf typische Fehlstarts
Nur Zertifikate zählen. Zertifikate sind wichtig, bilden aber nicht alle Protokolle, Bibliotheken und gespeicherten Daten ab.
Auf den perfekten Scanner warten. Werkzeuge helfen beim Finden. Kontext, Schutzdauer und Verantwortlichkeit bleiben organisatorische Aufgaben.
Mit dem flächendeckenden Austausch beginnen. Ohne Kompatibilitätstest erzeugt der Algorithmuswechsel neue Betriebsrisiken.
PQC als reines PKI-Projekt behandeln. Netzwerk, Security, Anwendungen, Geräte, Einkauf und Risk sind ebenfalls betroffen.
Eine Produktunterstützung mit vollständiger Readiness gleichsetzen. Eine einzelne kompatible Komponente macht die Ende-zu-Ende-Kette noch nicht migrationsfähig.
Der richtige Einstieg für bestehende Zscaler-Umgebungen
Für Unternehmen mit Zscaler ist ein fokussierter Traffic Readiness Sprint sinnvoll. Er betrachtet eine begrenzte Zahl kritischer Datenflüsse und beantwortet drei Fragen:
- Wo liegt langfristiger Schutzbedarf?
- Welche Inspection-, Zertifikats-, Policy- und Applikationsabhängigkeiten prägen den Verkehrsweg?
- Welche Tests und Entscheidungen sind vor einer späteren Migration notwendig?
Darauf können ein Policy & Compatibility Review und eine Crypto-Agility-Roadmap folgen. PKI-/HSM-Design, juristische Detailbewertung und spezialisierte Kryptografie-Implementierung werden klar abgegrenzt und bei Bedarf mit geeigneten Spezialpartnern bearbeitet.
Fazit: Migrationsfähigkeit ist heute messbar
Niemand kann den exakten Zeitpunkt einer kryptografisch relevanten Quantenbedrohung seriös garantieren. Unternehmen können aber heute feststellen, ob sie ihre Kryptografie kontrolliert verändern könnten.
Genau darin liegt der Nutzen von Krypto-Agilität: nicht in einer futuristischen Sicherheitsbehauptung, sondern in kürzeren Such-, Entscheidungs- und Testwegen. Wer Datenflüsse, Verantwortliche und Abhängigkeiten kennt, kann neue Standards geplant einführen. Wer sie nicht kennt, beginnt die spätere Migration mit einer Bestandsaufnahme unter Zeitdruck.
Der erste sinnvolle Schritt ist deshalb ein begrenzter Readiness-Scope – nicht der Einkauf eines vermeintlichen PQC-Komplettpakets.