Bildquelle: Pexels / Brett Sayles / https://www.pexels.com/photo/close-up-photo-of-ethernet-port-2881228/
Post-Quanten-Kryptografie beginnt im Zertifikatsinventar, nicht im Labor
Post-Quanten-Kryptografie wirkt auf viele IT-Organisationen noch wie ein Thema für Forschungsabteilungen, Hardwarehersteller oder ferne Roadmaps. Genau diese Einordnung wird zunehmend riskant. NIST hat mit FIPS 203, 204 und 205 bereits die ersten zentralen Standards für quantenresistente Verfahren verabschiedet und fordert Organisationen auf, mit der Migration zu beginnen. Das BSI betont zugleich, dass nicht mehr die Frage im Vordergrund steht, ob Quantencomputer irgendwann kommen, sondern wie sich Unternehmen rechtzeitig auf den Übergang vorbereiten. Für den IT-Betrieb ist das keine akademische Debatte mehr. Es ist eine praktische Steuerungsaufgabe.
Der häufigste Denkfehler liegt dabei im Fokus auf den Algorithmen. Natürlich muss ein Unternehmen irgendwann entscheiden, welche Verfahren, Bibliotheken und Produkte unterstützt werden. Operativ scheitert der Einstieg aber fast nie an der Auswahl von ML-KEM oder einer Signaturalternative. Er scheitert daran, dass niemand sauber sagen kann, wo heute überhaupt kryptografische Abhängigkeiten stecken: in TLS-Zertifikaten, VPN-Gateways, Load Balancern, API-Gateways, HSMs, Service-Meshes, E-Mail-Signaturen, Code-Signing-Pfaden, Maschinenidentitäten, PKI-Laufzeiten oder Lieferantenprodukten. Genau deshalb beginnt Post-Quanten-Kryptografie nicht im Labor, sondern im Zertifikatsinventar.
Die eigentliche Betriebsfrage heißt: Wo steckt verwundbare Public-Key-Kryptografie?
CISA, NSA und NIST empfehlen in ihrer gemeinsamen Quantum-Readiness-Factsheet ausdrücklich, zuerst eine belastbare kryptografische Bestandsaufnahme aufzubauen. Das klingt trocken, ist aber der operative Hebel. Viele Organisationen kennen ihre zentralen Zertifizierungsstellen, aber nicht die lange Kette abhängiger Komponenten dahinter. Dann existieren irgendwo Webserver-Zertifikate, Client-Zertifikate, MDM-Profile, SAML-Integrationen, Maschinenkonten, Firmware-Signaturen oder proprietäre Provider-Anbindungen, ohne dass sie in einem gemeinsamen Bild sichtbar werden.
Für den Alltag ist deshalb eine einfache Leitfrage nützlicher als jede Frühdiskussion über Mathematik: Wo verwenden wir heute Public-Key-Kryptografie für Schlüsselaustausch, Signaturen oder Vertrauensanker, und welche geschäftskritischen Dienste hängen daran? Diese Sicht trennt relevante Arbeit von Zukunftsfolklore. Denn ein Team muss nicht sofort alles migrieren. Es muss zuerst erkennen, welche Pfade langlaufende Vertraulichkeit betreffen, wo Zertifikate mit langen Laufzeiten aktiv sind und welche Infrastrukturen später besonders schwer umzustellen sein werden.
Gerade der Hinweis des BSI auf store now, decrypt later macht diesen Punkt wichtig. Wenn Daten heute abgegriffen und später entschlüsselt werden könnten, betrifft das vor allem Schlüsselvereinbarungs- und Verschlüsselungspfade mit langer Schutzdauer. Wer vertrauliche Kunden-, Gesundheits-, Forschungs- oder Verwaltungsdaten über Jahre schützen muss, hat einen anderen Zeitdruck als bei Signaturen mit kurzer Relevanz. Ohne Inventar bleibt dieser Unterschied unsichtbar.
PKI, Laufzeiten und HSMs entscheiden über die echte Migrationsdauer
In der Praxis verlängern nicht die Algorithmen, sondern die Betriebsabhängigkeiten jede Umstellung. Zertifikate laufen nicht isoliert, sondern in ganzen Ketten aus internen CAs, öffentlichen Trust Stores, Reverse Proxies, Appliances, Hardware-Sicherheitsmodulen und automatisierten Erneuerungsprozessen. Sobald eine Organisation hier nur auf einzelne Endpunkte schaut, unterschätzt sie die Migrationsdauer fast zwangsläufig.
Besonders heikel sind HSMs, Smartcards, VPN-Konzentratoren, Netzwerksicherheitsgeräte und spezialisierte SaaS- oder OT-Komponenten. Selbst wenn ein Kryptostandard verfügbar ist, heißt das noch lange nicht, dass jedes eingesetzte Produkt denselben Übergang schon unterstützt. Genau deshalb empfehlen CISA, NSA und NIST ausdrücklich, früh mit Technologieanbietern über PQC-Roadmaps, Supportzeiträume und Abhängigkeiten zu sprechen. Für IT-Leitungen ist das kein Nice-to-have, sondern klassisches Lieferantenmanagement.
Praktisch bewährt sich hier eine Staffelung in drei Gruppen. Erstens Komponenten, die das Unternehmen selbst konfigurieren und vergleichsweise schnell pilotieren kann, etwa interne TLS-Endpunkte oder nicht kundensichtbare Dienste. Zweitens Kernsysteme mit hoher Zertifikats- oder HSM-Abhängigkeit, die ein eigenes Migrationsprogramm brauchen. Drittens Fremdprodukte, bei denen zunächst die Roadmap des Herstellers über das reale Tempo entscheidet. Wer diese Gruppen vermischt, baut unnötige Erwartungslücken zwischen Security, Infrastruktur und Management auf.
Hybrid statt Big Bang ist der vernünftige Einstieg
Das BSI empfiehlt klar, Post-Quanten-Verfahren möglichst in hybriden Ansätzen zusammen mit klassischen Verfahren einzusetzen. Diese Position ist für den Betrieb sehr hilfreich, weil sie den üblichen Big-Bang-Reflex entschärft. Niemand muss von heute auf morgen jede klassische Kryptografie abschalten. Sinnvoller ist ein Migrationspfad, in dem Teams erst kryptoagile Übergänge schaffen und dann schrittweise Verfahren ergänzen, testen und absichern.
Für Architektur und Operations bedeutet Kryptoagilität vor allem, dass Zertifikats- und Schlüsselpfade austauschbar werden müssen. Wo Algorithmen hart in Altsoftware, Geräte-Firmware oder Sonderintegrationen eingebrannt sind, wird jede spätere Umstellung teuer. Wo dagegen PKI-, TLS- und Signaturpfade sauber versioniert, automatisiert und dokumentiert sind, entsteht Spielraum für kontrollierte Piloten. Genau deshalb ist PQC im Kern auch ein Reifegradtest für bestehende Kryptobetriebsmodelle.
Ein vernünftiger Einstieg kann deshalb so aussehen: zuerst kryptografische Abhängigkeiten erfassen, dann kritische Schutzbedarfe priorisieren, danach Hersteller- und Plattformfähigkeit prüfen und schließlich hybride Piloten in begrenzten internen Szenarien aufsetzen. Das ist unspektakulärer als große Quantum-Claims, aber betrieblich belastbar.
Ohne Zuständigkeiten bleibt die Migration eine lose Fachdebatte
Viele Häuser haben heute mehrere Teams mit Teilverantwortung: PKI oder IAM für Zertifikate, Netzwerk für VPN und Perimeter, Workplace für Endgeräte, DevOps für Service-Zertifikate und Code Signing, Security Governance für Richtlinien, Einkauf für Herstellerkontakte. Wenn diese Sicht nicht gebündelt wird, bleibt Post-Quanten-Kryptografie eine lose Reihe richtiger Einzelgespräche ohne operative Führung.
NIST verweist mit dem Migrationsprojekt und dem Übergangspfad in IR 8547 ausdrücklich darauf, dass Organisationen ihre verwundbaren Verfahren identifizieren und planvoll ablösen müssen. Im Alltag heißt das: ein klarer Owner, ein inventarbasierter Arbeitsvorrat und feste Entscheidungen über Prioritäten. Hilfreich ist ein kleines Steuerungsmodell mit vier Fragen: Welche kryptografischen Bestände kennen wir schon? Welche Schutzbedarfe verlangen frühe Aufmerksamkeit? Welche Herstellerpfade sind belastbar dokumentiert? Und wo fehlen uns noch kryptoagile Betriebsmechanismen wie automatisierte Zertifikatserneuerung, zentrale Sichtbarkeit oder standardisierte Ausnahmeprozesse?
Diese Fragen klingen banal, verhindern aber den typischen Leerlauf. Ohne sie diskutiert ein Unternehmen monatelang über Quantenrisiken und bewegt keinen einzigen produktiven Vertrauenspfad. Mit ihnen wird aus einem abstrakten Thema ein normales Portfolio aus Inventararbeit, Lieferantensteuerung, Pilotierung und Risikopriorisierung.
Fazit
Post-Quanten-Kryptografie wird im Unternehmen nicht zuerst an den Algorithmen entschieden, sondern an Transparenz, Zuständigkeiten und Kryptoagilität. Wer seine Zertifikate, Vertrauensanker, HSM-Abhängigkeiten und Lieferantenpfade nicht sauber kennt, kann keine realistische Migrationsreihenfolge bauen. Genau deshalb beginnt die Arbeit jetzt nicht im Labor und auch nicht bei Marketingversprechen über Quantum Readiness, sondern im Zertifikatsinventar, in der Lieferantenabfrage und in kleinen hybriden Piloten. Das ist der Punkt, an dem aus einem Zukunftsthema eine belastbare Betriebsaufgabe wird.
