Bildquelle: Bildquelle: Pexels / https://www.pexels.com/photo/silver-and-black-usb-in-close-up-shot-13061158/
Post-Quantum-Kryptografie verlangt zuerst Transparenz über Zertifikate, Protokolle und Abhängigkeiten
Post-Quantum-Kryptografie, kurz PQC, bezeichnet neue Verfahren für Schlüsselaustausch und digitale Signaturen, die auch dann sicher bleiben sollen, wenn eines Tages kryptografisch relevante Quantencomputer verfügbar sind. Relevant ist das Thema, weil heute weit verbreitete Public-Key-Verfahren wie RSA und elliptische Kurven den Vertrauensanker für TLS, VPNs, Zertifikate, Signaturen und viele Identitätsdienste bilden. NIST hat im August 2024 mit FIPS 203, 204 und 205 die ersten zentralen PQC-Standards finalisiert. Für Unternehmen bedeutet das nicht, dass morgen überall neue Algorithmen eingeschaltet werden müssen, wohl aber, dass die Migrationsarbeit jetzt mit belastbarer Bestandsaufnahme beginnen sollte.
Genau deshalb ist PQC im Betrieb zuerst keine Algorithmusdebatte, sondern eine Transparenzaufgabe. Die meisten Organisationen wissen ziemlich gut, wo ihre Server stehen, welche SaaS-Verträge laufen oder welche Endgeräte gemanagt werden. Sie wissen aber oft nicht sauber genug, an welchen Stellen in ihrer Landschaft heute noch RSA, ECDSA oder ECDH stecken, welche Zertifikatslaufzeiten kritisch lang sind, welche Appliances bestimmte Bibliotheken hart verdrahten und welche Drittanbieter ein Upgrade überhaupt schon einplanen.
Wer diese Fragen nicht beantworten kann, hat zwar ein Zukunftsthema erkannt, aber noch keine steuerbare Migrationsbasis. Genau dort entscheidet sich, ob Post-Quantum-Kryptografie später geordnet in Roadmaps und Wartungsfenster passt oder als hektische Sondermigration in PKI, Netzwerk, IAM und Anwendungsbetrieb einschlägt.
Warum das Thema schon vor der eigentlichen Umstellung relevant ist
Ein häufiger Denkfehler lautet: Solange es noch keinen praxistauglichen Quantencomputer gibt, kann man das Thema vertagen. Für kurzfristige Massenumstellungen stimmt das teilweise, für die Priorisierung aber nicht. NCSC und ENISA nennen zwei Gründe, warum Vorarbeit schon jetzt sinnvoll ist.
Erstens gibt es das sogenannte „harvest now, decrypt later“-Risiko. Wer heute verschlüsselte Daten abgreift, kann darauf spekulieren, sie später mit leistungsfähigeren Verfahren zu entschlüsseln. Das betrifft nicht jede Information im gleichen Maß, aber sehr wohl Daten mit langer Vertraulichkeitsdauer, etwa Gesundheitsdaten, sensible Entwicklungsunterlagen, staatlich regulierte Informationen oder langlebige Vertrags- und Identitätsnachweise.
Zweitens dauert die Umstellung in großen Organisationen erfahrungsgemäß Jahre. NIST schreibt in seiner Mitteilung zu den finalen Standards ausdrücklich, dass Administratoren mit der Integration beginnen sollten, weil die vollständige Einbettung Zeit braucht. Genau diese Zeit geht verloren, wenn Unternehmen den ersten Schritt – das Sichtbarmachen der kryptografischen Abhängigkeiten – immer weiter aufschieben.
Der eigentliche Startpunkt ist ein Krypto-Inventar
Bevor über konkrete Algorithmen oder Produktkäufe gesprochen wird, braucht es ein Inventar darüber, wo Public-Key-Kryptografie heute betriebsrelevant ist. Dazu zählen typischerweise externe und interne TLS-Verbindungen, VPN-Gateways, Load Balancer, Web Application Firewalls, E-Mail-Signaturen und -Verschlüsselung, SSH, S/MIME, Code-Signing, PKI-Komponenten, Hardware-Sicherheitsmodule, Identitätsprovider, MDM- und Gerätezugänge sowie eingebettete kryptografische Funktionen in Appliances und SaaS-Diensten.
Wichtig ist dabei, nicht nur Systeme, sondern auch Vertrauenspfade zu erfassen. Ein Webservice kann technisch schnell aktualisiert sein und trotzdem an einer zwischengeschalteten Komponente scheitern, etwa an einem alten ADC, einer TLS-Inspection-Lösung, einer VPN-Appliance, einer Java-Laufzeit oder einem HSM-Firmwarestand. Der operative Engpass liegt selten nur in der Anwendung selbst.
Sinnvoll ist ein Inventar in drei Ebenen. Erstens: Wo werden heute welche Public-Key-Verfahren genutzt? Zweitens: Welche Produkte, Bibliotheken, Dienstleister und Zertifizierungsstellen hängen daran? Drittens: Welche Laufzeiten, Schutzbedarfe und Änderungsfenster gelten dafür? Erst mit dieser Dreiteilung wird aus einem Technologiethema ein umsetzbarer Migrationsplan.
Zertifikate und langlebige Vertrauenselemente gehören nach vorn
Besondere Aufmerksamkeit verdienen Bereiche, in denen Vertrauenselemente lange im Feld bleiben. Das NCSC nennt ausdrücklich Komponenten mit weit in die Zukunft reichenden Zertifikatslaufzeiten oder solche Teile der Public-Key-Infrastruktur, die besonders schwer zu ersetzen sind. Dazu zählen Root- und Intermediate-CAs, Geräteidentitäten in Industrie- und IoT-Umgebungen, signierte Firmware, Smartcards, Maschinenzertifikate in Produktionsnetzen oder langfristig genutzte Dokumentensignaturen.
Diese Objekte sind nicht automatisch zuerst zu migrieren, aber sie gehören zuerst in die Priorisierung. Wenn ihre Austauschzyklen lang sind, reicht es eben nicht, irgendwann eine neue Cipher Suite freizuschalten. Dann müssen Beschaffung, Lebenszyklusmanagement, Gerätemanagement und teilweise auch regulatorische Nachweise mitgedacht werden.
Für IT-Management ist das eine wichtige Verschiebung: Die PQC-Frage beginnt nicht im Kryptolabor, sondern im Asset- und Lifecycle-Management. Wer schon heute keine saubere Sicht auf Zertifikate, Schlüsselhalter, Gültigkeiten und technische Eigentümer hat, wird später auch keine belastbare Migrationssteuerung haben.
Protokolle, Produkte und Lieferanten machen die Roadmap kompliziert
Die Migration wird nicht in einem großen Schalter erfolgen, sondern protokoll- und produktweise. TLS, IPsec, SSH, PKI-Workflows, Code-Signing-Pipelines und Identitätsprotokolle entwickeln sich unterschiedlich schnell. Hinzu kommt, dass viele Unternehmen zentrale Sicherheits- und Netzkomponenten nicht selbst bauen, sondern als Produkt oder Managed Service einkaufen. Damit wird Lieferantenreife zu einem operativen Faktor.
Genau hier hilft die Forderung nach Transparenz über Abhängigkeiten. Unternehmen sollten früh klären, welche Hersteller bereits standardkonforme Roadmaps für ML-KEM, ML-DSA oder alternative Übergangsverfahren kommunizieren, welche Protokollversionen überhaupt betroffen sind und wo proprietäre Sonderwege drohen. Das NCSC warnt ausdrücklich vor verfrühter Einführung nicht standardisierter Verfahren, weil sonst Interoperabilität und Sicherheit leiden können.
Für Einkauf und Architektur bedeutet das: PQC gehört in Vertrags- und Plattformgespräche, bevor ein Migrationsprojekt startet. Wer Appliances, PKI-Bausteine oder Identitätsdienste heute verlängert, ohne die Krypto-Roadmap des Anbieters abzufragen, verschiebt das Problem nur in die nächste Vertragsperiode.
Es wird eine Phase mit klassischen und neuen Verfahren parallel geben
Ein weiterer operativer Punkt wird oft unterschätzt: Die Zielarchitektur ist über längere Zeit hybrid. Das NCSC erwartet ausdrücklich eine Phase, in der konventionelle und quantum-safe Kryptografie parallel betrieben werden müssen, um die Umstellung praktikabel zu machen. ENISA hat schon früh hybride Implementierungen und das Einmischen vorab geteilter Schlüssel als sinnvolle Übergangsmaßnahmen beschrieben, solange Standards, Protokolle und Produkte noch nicht vollständig umgestellt sind.
Das hat Folgen für Betrieb und Governance. Monitoring, Zertifikatsmanagement, Kompatibilitätstests, Performancebewertung und Incident Response müssen damit umgehen können, dass nicht überall sofort dieselben Verfahren aktiv sind. Auch Change-Fenster werden komplexer, weil Sicherheits-, Netzwerk-, Workplace- und Anwendungsteams stärker koordiniert werden müssen.
Praktisch heißt das: PQC ist nicht nur ein Upgrade der Kryptobibliothek, sondern ein mehrjähriges Betriebsprogramm. Ohne saubere Ownership über PKI, Netzwerkpfade, Identitätssysteme und Lieferantensteuerung entsteht schnell eine Gemengelage, in der einzelne Teams modernisieren wollen, aber gemeinsame Freigaben, Testpfade oder Rückfalloptionen fehlen.
Worauf Unternehmen jetzt konkret achten sollten
- Krypto-Inventar aufbauen: Nicht nur Zertifikate listen, sondern Nutzung, Protokolle, Bibliotheken, Produkte und technische Eigentümer verbinden.
- Schutzdauer priorisieren: Daten und Vertrauenselemente mit langer Lebensdauer zuerst markieren.
- Lieferantenreife prüfen: Roadmaps von PKI-, HSM-, Netzwerk-, IAM- und SaaS-Anbietern aktiv abfragen.
- Krypto-Agilität bewerten: Wo lassen sich Algorithmen, Zertifikatsprofile oder Protokollparameter überhaupt austauschen, ohne Systeme neu zu bauen?
- Hybridbetrieb vorbereiten: Test, Monitoring, Kompatibilität und Rückfallpfade für eine längere Übergangsphase einplanen.
- Governance festziehen: PQC darf nicht zwischen Security, Infrastruktur und Architektur hängenbleiben; Ownership und Entscheidungswege müssen klar sein.
Fazit
Post-Quantum-Kryptografie ist für Unternehmen noch kein Sofort-Schalter, aber auch kein Thema mehr für einen fernen Forschungskalender. Seit NIST die ersten Standards finalisiert hat, verschiebt sich die Managementfrage von „ob“ zu „wo zuerst“. Die sinnvollste Antwort beginnt mit Transparenz: über Zertifikate, Protokolle, Produkte, Lieferanten und Schutzdauern.
Wer diese Sicht jetzt aufbaut, kann spätere Migrationen priorisiert, standardnah und mit realistischen Wartungsfenstern steuern. Wer sie nicht aufbaut, riskiert, dass PQC irgendwann nicht als geordnete Modernisierung kommt, sondern als teure Notfallserie über PKI, Netzwerk, Identität und Lieferketten hinweg.
