Neue Verschlüsselung wird zum Risiko, wenn niemand die Zertifikate im Blick hat

Post-Quantum-Kryptografie klingt nach einem Spezialthema für Kryptografen. Im IT-Betrieb ist sie aber zuerst eine Bestands- und Verantwortungsfrage. Wenn heute niemand sauber sagen kann, welche Zertifikate, VPN-Strecken, Signaturen, Schlüsselverfahren, Identitätsdienste und externen Schnittstellen in einem Service stecken, wird eine spätere Umstellung auf quantenresistente Verfahren nicht zur geplanten Modernisierung, sondern zum riskanten Änderungsfenster.

Der Auslöser ist klar: NIST hat die ersten drei Standards für Post-Quantum-Kryptografie als FIPS 203, FIPS 204 und FIPS 205 veröffentlicht. Sie beschreiben Verfahren für Schlüsselaustausch und digitale Signaturen, die gegen künftige Angriffe durch leistungsfähige Quantencomputer ausgelegt sind. CISA empfiehlt Organisationen, dafür eine Roadmap, ein kryptografisches Inventar und Gespräche mit Herstellern aufzubauen. Für ITSM-Generalisten heißt das: Das Thema gehört nicht erst in ein Security-Labor, sondern in Servicekatalog, Configuration Management, Change Management, Lieferantensteuerung und Risikobewertung.

Die größte Lücke liegt oft nicht im Algorithmus

In technischen Diskussionen steht schnell die Frage im Vordergrund, welches Verfahren künftig eingesetzt wird. NIST nennt mit ML-KEM, ML-DSA und SLH-DSA konkrete Bausteine. Für den Alltag eines IT-Service-Managers beginnt die Arbeit jedoch eine Ebene früher. Ein Service kann nach außen einfach wirken und intern trotzdem mehrere kryptografische Abhängigkeiten haben: TLS-Zertifikate am Load Balancer, Signaturen in Software-Updates, Schlüssel in mobilen Apps, VPN-Verbindungen zu Dienstleistern, S/MIME oder PGP in Fachprozessen, API-Authentifizierung, Hardware-Sicherheitsmodule, Backup-Verschlüsselung und Auditarchive.

Solange diese Abhängigkeiten nicht im Servicekontext sichtbar sind, bleibt jede Migrationsplanung unscharf. Dann ist Post-Quantum-Kryptografie ein weiteres Projekt, das im Sicherheitsbereich startet und erst im Change-Fenster merkt, dass Fachverfahren, Lieferanten, Netzwerk, IAM und Betrieb gemeinsam betroffen sind. Genau hier wird aus Kryptografie ein ITSM-Thema: Wer den Service verantwortet, muss wissen, welche Verschlüsselung für Verfügbarkeit, Integrität, Nachvollziehbarkeit und Compliance relevant ist.

Ein kryptografisches Inventar ist mehr als eine Zertifikatsliste

Die CISA-Empfehlung zur Quantum-Readiness betont ausdrücklich ein kryptografisches Inventar. Der Begriff klingt trocken, ist aber der operative Kern. Eine reine Liste ablaufender Zertifikate reicht nicht. Nützlich wird das Inventar erst, wenn es mit Services, Datenklassen, Schnittstellen, Eigentümern, Herstellern und Änderungsfenstern verbunden ist.

Für ITSM-Teams stellt sich deshalb eine praktische Frage: Kann ein Service Owner in wenigen Minuten sehen, welche kryptografischen Verfahren in seinem Service produktiv genutzt werden, ob sie von einem internen Team oder einem Lieferanten kontrolliert werden, ob es Testumgebungen für neue Verfahren gibt und welche Abhängigkeiten bei einer Umstellung mitgetestet werden müssen? Wenn die Antwort nein lautet, ist die erste Maßnahme nicht der Austausch eines Algorithmus. Die erste Maßnahme ist Transparenz.

Besonders kritisch sind langlebige Daten und langlebige Nachweise. Einige Informationen müssen über Jahre vertraulich oder beweiskräftig bleiben. Wenn ein Angreifer verschlüsselte Daten heute sammelt und später entschlüsseln kann, entsteht ein Risiko, das nicht am Tag der Migration beginnt. Deshalb reicht es nicht, nur neue Verbindungen künftig anders abzusichern. Organisationen müssen auch bewerten, welche bestehenden Daten, Archivbestände und Signaturprozesse langfristig Schutz brauchen.

Herstellersteuerung wird zur Pflichtdisziplin

Kaum eine Organisation betreibt alle kryptografischen Komponenten selbst. Firewalls, VPN-Gateways, Cloud-Dienste, SaaS-Plattformen, Identitätsanbieter, Endpoint-Management, CI/CD-Werkzeuge und Fachanwendungen bringen eigene Kryptografie mit. Damit wird Post-Quantum-Migration zu einer Lieferantenfrage. CISA nennt den Austausch mit Technologieanbietern ausdrücklich als Vorbereitungsschritt.

Für den Einkauf oder das Vendor Management reicht ein allgemeines „PQC-ready“ in der Produktfolie nicht. Benötigt werden belastbare Antworten: Welche Komponenten sind betroffen? Welche Roadmap gibt es? Welche Protokolle werden unterstützt? Welche Hybridverfahren sind geplant? Wie werden Zertifikate, Schlüsselmaterial und Signaturen migriert? Welche Versionen sind nötig? Gibt es Testpfade, Rollback-Optionen und Kompatibilitätsgrenzen? Wer diese Fragen nicht früh stellt, verlagert das Risiko in spätere Vertrags-, Upgrade- und Betriebsdiskussionen.

Auch hier hilft ITSM-Denken. Lieferanteninformationen gehören nicht isoliert in ein Beschaffungsdokument, sondern an die betroffenen Services. Wenn ein zentraler Identitätsdienst, ein Remote-Access-Gateway oder ein Update-Mechanismus erst spät PQC-fähig wird, beeinflusst das andere Services. Die Abhängigkeit muss im Portfolio sichtbar sein, sonst planen Teams lokal sauber und scheitern an einer gemeinsamen Komponente.

Change Management braucht Testfälle statt Grundsatzfolien

Die Umstellung auf quantenresistente Verfahren wird nicht überall gleichzeitig passieren. Es wird Übergangsphasen geben, in denen klassische und neue Verfahren nebeneinanderstehen. Genau in solchen Phasen entstehen Betriebsrisiken: ältere Clients verstehen neue Verfahren nicht, Appliances brauchen Firmwarestände, Monitoring erkennt neue Fehlermuster nicht, Zertifikatsketten werden anders geprüft, Signaturen werden größer, Performanceprofile verändern sich oder ein Partner kann den neuen Pfad noch nicht nutzen.

Ein belastbarer Change-Prozess muss deshalb konkrete Testfälle enthalten. Funktioniert die Anmeldung? Läuft die Schnittstelle unter Last? Erkennt das Monitoring Verbindungsabbrüche? Können Zertifikate erneuert und zurückgerollt werden? Sind Notfallkontakte beim Lieferanten bekannt? Gibt es eine Entscheidung, welcher Service zuerst migriert und welcher bewusst wartet? Ohne solche Details wird PQC-Migration schnell zu einer abstrakten Sicherheitsinitiative, die im Betrieb erst sichtbar wird, wenn Nutzer einen Fehler melden.

Was ITSM-Teams jetzt vorbereiten können

Der sinnvolle Start ist klein, aber verbindlich. Erstens sollten Organisationen kritische Services identifizieren, bei denen Vertraulichkeit, Identität, Signaturen oder Langzeitnachweise eine zentrale Rolle spielen. Zweitens sollten sie für diese Services die kryptografischen Abhängigkeiten erfassen: Zertifikate, Protokolle, Schlüsselorte, Appliances, Cloud-Dienste, Lieferanten und Datenklassen. Drittens sollten Service Owner und Security gemeinsam festlegen, welche Informationen künftig in CMDB, Servicekatalog oder Architekturrepository gepflegt werden.

Viertens braucht es Lieferantenfragen als Standardbestandteil von Reviews und Verlängerungen. Fünftens sollten Testumgebungen so vorbereitet werden, dass neue Verfahren nicht nur technisch aktiviert, sondern im Serviceverhalten beobachtet werden können. Und sechstens gehört das Thema in Risiko- und Continual-Improvement-Runden. Post-Quantum-Kryptografie ist kein einmaliges Update, sondern eine mehrjährige Veränderung der Vertrauenskette.

Der operative Kern: Wer besitzt die Vertrauenskette?

Quantenfeste Kryptografie wird nicht daran scheitern, dass es keine Standards gibt. Die ersten Standards sind da, weitere Entwicklungen laufen. Sie wird dort schwierig, wo Organisationen ihre Vertrauenskette nicht besitzen: niemand kennt alle Zertifikate, niemand ordnet Signaturen Services zu, niemand fragt Lieferanten verbindlich, niemand testet Schnittstellen realistisch, niemand verbindet Sicherheitsroadmap und Change-Kalender.

Für ITSM- und IT-Management-Generalisten ist genau das die Chance. Sie müssen nicht die Mathematik hinter ML-KEM erklären können. Sie müssen aber dafür sorgen, dass Services, Abhängigkeiten, Risiken und Verantwortlichkeiten sichtbar sind. Wer damit früh beginnt, macht aus Post-Quantum-Kryptografie keinen Panikwechsel, sondern eine steuerbare Betriebsmodernisierung.

Quellen: NIST CSRC zu den freigegebenen Post-Quantum-FIPS-Standards und zum PQC-Projekt; CISA Quantum-Readiness: Migration to Post-Quantum Cryptography und CISA Post-Quantum Cryptography Initiative.