Bildquelle: extern
Post-Quanten-Kryptografie im Unternehmensbetrieb: Welche 5 Inventur- und Migrationsschritte IT-Teams 2026 jetzt anstoßen sollten
Post-Quanten-Kryptografie klingt für viele Unternehmen noch nach Fernziel für spätere Architekturprogramme. Genau das wird 2026 aber zum Problem. NIST hat mit FIPS 203, 204 und 205 die ersten Standards für Post-Quanten-Kryptografie verabschiedet. Das BSI betont zugleich, dass die Frage, ob oder wann Quantencomputer relevant werden, nicht mehr im Vordergrund stehen sollte, sondern die Vorbereitung der Migration. Für IT-Teams ist das eine unangenehme, aber nützliche Wahrheit: Wer erst wartet, bis ein Hersteller ein fertiges Häkchen „quantensicher“ anbietet, wird zu spät merken, wie viele Systeme, Verträge, Zertifikate und Betriebsprozesse an klassischer Public-Key-Kryptografie hängen.
Der operative Druck entsteht nicht nur durch einen künftigen technischen Bruch. Ein zentrales Risiko ist das von BSI, NIST, CISA und NSA beschriebene Szenario „store now, decrypt later“. Angreifer können verschlüsselte Daten schon heute abgreifen und später entschlüsseln, sobald leistungsfähige Quantencomputer oder neue Angriffe verfügbar sind. Für Daten mit langen Schutzfristen, etwa in Verwaltung, Forschung, Gesundheitswesen, KRITIS oder in geistigem Eigentum, ist die Frage also nicht akademisch. Wer dort Verantwortung für Infrastruktur, Workplace, Identity, Netzwerke oder Plattformen trägt, sollte die Vorbereitung jetzt in überschaubare Betriebsarbeit übersetzen.
Fünf Schritte sind dafür besonders wirksam.
1. Zuerst eine echte Kryptografie-Inventur aufbauen, nicht nur eine Produktliste
Die meisten Organisationen wissen grob, welche Firewalls, VPN-Gateways oder Zertifizierungsstellen sie betreiben. Was oft fehlt, ist eine belastbare Sicht darauf, wo genau klassische kryptografische Verfahren in der Landschaft stecken. Die gemeinsame Empfehlung von NSA, CISA und NIST fordert deshalb ausdrücklich ein Inventar der kryptografischen Systeme und Assets. Genau hier beginnt die eigentliche Arbeit.
Praktisch bedeutet das: Nicht nur Produkte erfassen, sondern die relevanten Verwendungen von Kryptografie. Dazu gehören unter anderem TLS an externen und internen Diensten, VPN-Verbindungen, PKI und Zertifikatslaufzeiten, SSH in Admin- und Automatisierungspfaden, E-Mail-Verschlüsselung, Code-Signing, Gerätezertifikate, Maschinenidentitäten, Backup-Verschlüsselung, HSM-Abhängigkeiten sowie kryptografische Bibliotheken in Eigenentwicklungen. Wer nur nach „welche Appliance kann PQC?“ fragt, übersieht oft die tiefere Abhängigkeit in Middleware, Agenten, SDKs und Partneranbindungen.
Ein brauchbarer Start ist eine einfache Matrix mit vier Spalten: System oder Dienst, eingesetzte Public-Key-Verfahren, Schutzbedarf der Daten und technischer Eigentümer. Schon diese Minimalstruktur schafft mehr Steuerbarkeit als viele strategische Folien.
2. Langzeitschutz priorisieren und das Risiko pro Datenklasse trennen
Das BSI weist darauf hin, dass vor allem Schlüsseleinigungsverfahren zuerst bedroht sind, weil dadurch die Langzeitvertraulichkeit angegriffen werden kann. Signaturen sind in vielen Fällen nur kürzer relevant, bei langen Gültigkeitszeiträumen aber ebenfalls rechtzeitig umzustellen. Genau daraus folgt eine wichtige Priorisierungsregel: Nicht jedes System muss zuerst migriert werden, aber Systeme mit langen Geheimhaltungsfristen dürfen nicht in derselben Queue landen wie Standardanwendungen mit kurzer Datenlebensdauer.
Für IT-Management und Security ist das eine Governance-Aufgabe. Sinnvoll ist eine Einstufung in drei Klassen: erstens hochsensible Daten mit langer Schutzdauer, zweitens geschäftskritische Plattformen mit vielen Abhängigkeiten, drittens Standard-Workloads mit geringerer Langzeitwirkung. In Klasse eins fallen häufig Identitätsinfrastrukturen, bestimmte Forschungsdaten, sensible Kundeninformationen oder geschützte Verwaltungsdokumente. Diese Umgebungen sollten zuerst darauf geprüft werden, wo verschlüsselte Übertragungen heute aufgezeichnet und später missbraucht werden könnten.
Die operative Folge ist klar: Das erste PQC-Programm ist kein flächiger Rollout, sondern ein priorisiertes Risikoprogramm.
3. Kryptoagilität zur harten Architekturanforderung machen
Das BSI fordert bei Neu- und Weiterentwicklungen ausdrücklich Kryptoagilität. Dahinter steckt kein Modewort, sondern eine sehr praktische Forderung: Unternehmen müssen Verfahren austauschen können, ohne den gesamten Dienst neu zu bauen. Wer heute noch Produkte beschafft oder interne Plattformen entwickelt, ohne Algorithmuswechsel, Zertifikatstausch und Protokollupdates sauber vorzusehen, produziert die nächste Migrationsfalle bereits mit.
Für Architektur- und Plattformteams heißt das konkret: Kryptografische Entscheidungen müssen an klaren Stellen konfigurierbar sein. Zertifikate und Vertrauensketten gehören nicht in schwer änderbare Images oder manuelle Sonderpfade. Protokollparameter, Bibliotheksstände und Providerabhängigkeiten sollten versionierbar und testbar sein. Ebenso wichtig ist, dass Beschaffung und Vendor-Management künftig verbindlich nach Roadmaps fragen: Unterstützt der Hersteller hybride Verfahren? Welche Protokolle und Produktlinien werden wann umgestellt? Wie sieht die Interoperabilität zu bestehenden PKI-, VPN- oder Messaging-Komponenten aus?
Viele Teams werden überrascht sein, wie schnell das Thema aus der Kryptografie in Verträge, Standardbaukästen und Architekturboards hineinwächst.
4. Hybrid- und Interoperabilitätstests früh im Labor ansetzen
Das BSI empfiehlt, Post-Quanten-Verfahren möglichst zunächst in hybriden Ansätzen mit klassischen Verfahren einzusetzen. Das ist betrieblich vernünftig, weil Unternehmen Übergangsphasen nicht vermeiden können. Niemand tauscht an einem Wochenende alle Clients, Gateways, Zertifikatsdienste und Partnerverbindungen gleichzeitig aus. Genau deshalb sollten frühe Tests nicht auf Marketing-Demos beschränkt bleiben.
Ein guter Pilot prüft mindestens vier Dinge: Erstens, welche kritischen Datenpfade bereits durch Produkte abgedeckt werden, die hybride oder PQC-nahe Optionen auf der Roadmap haben. Zweitens, wie sich Performance, Handshake-Größen und Zertifikatsketten in Testumgebungen verändern. Drittens, welche Monitoring-, Logging- und Troubleshooting-Werkzeuge mit neuen Verfahren noch sauber funktionieren. Viertens, ob externe Partner, Managed Services oder Altgeräte überhaupt interoperabel bleiben.
Gerade in Netzwerken, Remote Access, PKI und Maschinenkommunikation rächt sich ein zu später Testbeginn. Wer erst auf finalen Druck reagiert, testet unter Produktionszeitdruck und nimmt unnötige Ausnahmen in Kauf.
5. Das Thema als mehrjähriges Betriebsprogramm mit klaren Zuständigkeiten führen
PQC ist kein Nebenprojekt für einen Kryptografie-affinen Spezialisten. Die Migration betrifft Security, Infrastruktur, Netzwerk, Workplace, IAM, Entwicklung, Einkauf, Compliance und oft auch Fachbereiche mit langen Datenaufbewahrungen. NSA, CISA und NIST empfehlen deshalb einen Quantum-Readiness-Plan. In der Praxis sollte daraus ein überschaubares Programm mit klaren Eigentümern werden.
Hilfreich ist ein Arbeitsmodell in Wellen: zuerst Inventur und Priorisierung, dann Labor- und Herstellerklärung, danach Pilotdomänen, anschließend standardisierte Beschaffungs- und Architekturvorgaben. Parallel dazu sollten Risikoregister, Architekturprinzipien und Beschaffungstemplates angepasst werden. Spätestens jetzt braucht jedes Unternehmen eine Antwort auf drei Managementfragen: Welche besonders schützenswerten Daten wären durch „store now, decrypt later“ betroffen? Welche Kernsysteme hängen technisch an klassischer Public-Key-Kryptografie? Welche Hersteller liefern belastbare Roadmaps statt bloßer Absichtserklärungen?
Wenn diese Fragen niemand eindeutig beantworten kann, ist das bereits das eigentliche Risiko.
Fazit
Post-Quanten-Kryptografie ist 2026 kein Thema mehr, das man guten Gewissens auf „später“ legen kann. Die Standards sind da, die behördlichen Empfehlungen sind eindeutig, und die Migrationsdauer in gewachsenen Unternehmenslandschaften wird eher in Jahren als in Quartalen gemessen. Für IT-Teams liegt der richtige Einstieg nicht in hektischer Vollumstellung, sondern in nüchterner Betriebsarbeit: Kryptografie inventarisieren, Langzeitschutz priorisieren, Kryptoagilität erzwingen, hybride Tests früh beginnen und das Ganze als dauerhaftes Transformationsprogramm führen. Wer so startet, wird nicht morgen fertig sein, aber er verhindert, dass das Thema erst dann sichtbar wird, wenn die teuersten Abhängigkeiten schon fest eingebaut sind.
