Post-Quanten-Kryptografie in der Unternehmens-IT: Warum 2026 das Krypto-Inventar wichtiger ist als der erste Pilot

Viele IT-Organisationen diskutieren Post-Quanten-Kryptografie noch immer wie ein fernes Forschungsthema. Das passt nicht mehr zur Lage. NIST hat seine ersten finalen Standards für Post-Quanten-Verfahren bereits veröffentlicht: FIPS 203 für ML-KEM als Key-Encapsulation-Mechanismus, FIPS 204 für ML-DSA und FIPS 205 für SLH-DSA für digitale Signaturen. Damit ist die Debatte nicht mehr theoretisch. Die Frage lautet 2026 nicht mehr, ob Unternehmen sich vorbereiten müssen, sondern wo sie mit vertretbarem Risiko anfangen.

Genau hier machen viele Teams den ersten Fehler. Sie suchen sofort nach einem sichtbaren Pilotprojekt, etwa für TLS, VPN oder ein besonders modernes Kundenportal. Das klingt entschlossen, ist operativ aber oft die falsche Reihenfolge. Die eigentliche Hürde liegt meist nicht im ersten Algorithmuswechsel, sondern in der fehlenden Transparenz: Niemand weiß sauber, in welchen Services, Produkten, Zertifikaten, Signaturketten, HSM-Prozessen und Drittanwendungen klassische Public-Key-Kryptografie heute konkret steckt.

ENISA hat schon früh darauf hingewiesen, dass hybride Implementierungen und das Beimischen vorab geteilter Schlüssel sinnvolle Übergangsmaßnahmen sein können. Genau deshalb sollte 2026 nicht als Jahr des großen Umbaus missverstanden werden, sondern als Jahr der belastbaren Vorbereitung. Wer jetzt ohne Inventar pilotiert, produziert vor allem schöne Architekturfolien. Wer zuerst sein Krypto-Inventar aufbaut, schafft dagegen die Grundlage für Priorisierung, Beschaffung und kontrollierte Migration.

1. Nicht jede Kryptonutzung hat dieselbe Dringlichkeit

Ein häufiger Managementfehler besteht darin, alle kryptografischen Einsatzfelder gleich zu behandeln. Das führt entweder zu Aktionismus oder zu Stillstand. In der Praxis müssen IT-Leitungen mindestens drei Klassen unterscheiden: erstens Daten und Kommunikationsbeziehungen mit langer Vertraulichkeitsdauer, zweitens Signatur- und Vertrauenskette-Systeme, drittens kurzlebige Standardverbindungen mit überschaubarem Schutzbedarf.

Besonders relevant ist das für das bekannte Risiko „harvest now, decrypt later“. Wenn Daten heute abgegriffen und später mit leistungsfähigerer Technik entschlüsselt werden könnten, steigt die Priorität schon vor einer breiten produktiven PQC-Einführung. Das betrifft nicht jedes System gleich. Entwicklungsartefakte mit kurzer Lebensdauer sind anders zu bewerten als sensible Vertragsdaten, Gesundheitsdaten, geistiges Eigentum oder langfristig prüfrelevante Dokumente. Ein gutes Krypto-Inventar beginnt deshalb nicht bei Algorithmen, sondern bei Schutzdauer und Geschäftswirkung.

2. Ein Krypto-Inventar ist keine Zertifikatsliste

Viele Unternehmen glauben, sie seien schon weit, weil sie ihre Zertifikate aus der PKI oder vom externen Certificate Manager exportieren können. Das reicht nicht. Ein belastbares Krypto-Inventar muss die Verwendung kryptografischer Verfahren entlang realer Services sichtbar machen. Dazu gehören unter anderem TLS-Terminierung, VPN-Gateways, interne Service-Meshes, Code-Signing-Prozesse, IAM- und SSO-Komponenten, E-Mail-Signaturen, MDM- und Geräteidentitäten, Backup-Verschlüsselung, Datenbank-Treiber, API-Gateways und Abhängigkeiten in Standardsoftware.

Entscheidend ist die Verknüpfung mit Service-Ownern, Laufzeiten und technischen Abhängigkeiten. Sonst entsteht nur eine lange Komponentenliste ohne Steuerungswert. Die Kernfrage lautet: Welcher geschäftskritische Service ist betroffen, wenn eine Bibliothek, ein HSM, ein Gateway oder ein externer Anbieter Post-Quanten-Verfahren noch nicht oder nur eingeschränkt unterstützt? Erst diese Sicht macht aus Inventarisierung eine Managementaufgabe.

3. Lieferanten- und Plattformabhängigkeiten müssen vor dem Pilot offenliegen

Post-Quanten-Migration wird in vielen Unternehmen weniger ein Eigenentwicklungsprojekt als ein Plattform- und Lieferantenthema. Selbst wenn das eigene Architekturteam bereit ist, ML-KEM oder neue Signaturverfahren zu testen, bleibt die Frage: Unterstützen Load Balancer, PKI-Komponenten, Java- und .NET-Laufzeiten, VPN-Appliances, HSMs, Smartcards, E-Mail-Gateways und SaaS-Anbieter den Weg mit? Und wenn ja, in welchem Modus, mit welchen Versionen und welchen betrieblichen Einschränkungen?

Genau deshalb sollte jede IT-Organisation 2026 eine einfache PQC-Abfrage in ihr Lieferantenmanagement aufnehmen. Vier Fragen reichen für den Start: Welche Roadmap gibt es für PQC-Unterstützung? Welche Verfahren und Betriebsmodi werden geplant? Welche Abhängigkeiten bestehen zu Drittprodukten oder Firmware? Und wie sieht die Migrationsstrategie für Bestandskunden aus? Wer diese Punkte nicht früh abfragt, verlagert das Risiko in spätere Beschaffungs- und Upgrade-Zyklen.

4. Der erste Pilot muss rückbaubar und messbar sein

Ein Pilot ist sinnvoll, aber nur an der richtigen Stelle. Schlechte Kandidaten sind hochkritische Kundenzugänge, stark heterogene Altlandschaften oder Schnittstellen mit vielen externen Parteien. Gute Kandidaten sind interne, klar abgegrenzte Verbindungen mit kontrollierbarem Client- und Server-Stack, sauberer Beobachtbarkeit und geringem politischem Schaden bei Rückbau.

Im Pilot sollten Teams nicht nur „funktioniert“ oder „funktioniert nicht“ dokumentieren. Relevant sind konkrete Betriebsmetriken: Handshake-Verhalten, Zertifikats- oder Schlüssellängen, Auswirkungen auf Latenz und Ressourcenverbrauch, Monitoring-Sichtbarkeit, Fehlerbilder im Fallback sowie Aufwand für Betrieb und Troubleshooting. So entsteht Wissen, das später für Standards und Rolloutfenster taugt. Ohne diese Messpunkte bleibt der Pilot eine Demo.

5. Governance kommt vor Rollout

Die größte operative Gefahr ist nicht, dass ein Unternehmen 2026 noch nicht flächendeckend post-quantensicher ist. Gefährlicher ist ein ungesteuerter Flickenteppich aus Einzelpiloten, Tool-Versprechen und unverbundenen Sicherheitsprojekten. Deshalb braucht PQC früh ein Governance-Modell. Dazu gehören ein verantwortlicher Owner auf Architektur- oder Security-Ebene, ein gemeinsames Reporting mit Infrastruktur, PKI und Anwendungsbetrieb sowie klare Kriterien für Priorisierung und Ausnahmen.

Ein pragmatisches Monatsreview reicht am Anfang völlig aus. Dort werden neue Erkenntnisse aus dem Inventar, Hersteller-Roadmaps, Pilotergebnisse und risikorelevante Services zusammengeführt. Genau an diesem Punkt entscheidet sich, ob PQC ein sinnvolles Mehrjahresprogramm wird oder ein weiterer Hype mit lose verteilten Aufgaben.

Was IT-Leitungen jetzt konkret tun sollten

• Krypto-Inventar serviceorientiert aufbauen: Nicht nur Zertifikate zählen, sondern kryptografische Abhängigkeiten auf geschäftskritische Services abbilden.
• Schutzdauer bewerten: Daten und Prozesse mit langer Vertraulichkeits- oder Nachweisfrist zuerst markieren.
• Lieferanten standardisiert befragen: PQC-Roadmaps für PKI, Netzwerk, HSM, Endgeräte und SaaS systematisch einsammeln.
• Einen rückbaubaren Pilot definieren: Bevorzugt intern, technisch kontrollierbar und mit klaren Messgrößen.
• Governance verankern: Monatliches Review für Inventarstand, Risiken, Roadmaps und Migrationsentscheidungen etablieren.

2026 ist für Unternehmens-IT nicht das Jahr des großen PQC-Showcases. Es ist das Jahr, in dem sich entscheidet, ob Organisationen ihre kryptografischen Abhängigkeiten endlich wie ein steuerbares Betriebsobjekt behandeln. Genau deshalb ist das Krypto-Inventar wichtiger als der erste Pilot. Wer diese Reihenfolge einhält, schafft echte Migrationsfähigkeit statt nur technischer Symbolpolitik.

Quellen

• NIST: Releases First 3 Finalized Post-Quantum Encryption Standards
• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
• NIST FIPS 205: Stateless Hash-Based Digital Signature Standard
• ENISA: Post-Quantum Cryptography, Current State and Quantum Mitigation