Bildquelle: extern
Post-Quanten-Kryptografie im Unternehmensbetrieb: Welche 5 Vorarbeiten IT-Leitungen 2026 nicht mehr vertagen sollten
Post-Quanten-Kryptografie klingt in vielen Unternehmen noch immer wie ein Thema für Forschungslabore, nicht für den laufenden Betrieb. Genau das wird 2026 zunehmend riskant. Denn das operative Problem beginnt nicht erst an dem Tag, an dem ein großer Quantencomputer existiert. Es beginnt viel früher, nämlich dort, wo Unternehmen heute sensible Daten mit Verfahren schützen, die künftig angreifbar sein könnten, und gleichzeitig gar nicht wissen, an welchen Stellen diese Kryptografie überhaupt verbaut ist.
NIST hat im August 2024 die ersten drei finalisierten Post-Quanten-Standards veröffentlicht und Systemverantwortliche ausdrücklich dazu aufgefordert, mit der Integration zu beginnen, weil die vollständige Umstellung Zeit braucht. CISA betont in seiner PQC-Initiative, dass Identifikation und Inventarisierung gefährdeter Systeme der erste Schritt jeder Vorbereitung ist. Und das britische NCSC nennt inzwischen sogar grobe Zielmarken: Bis 2028 sollen große Organisationen ihre Migrationsziele definiert, ihr Inventar aufgebaut und einen initialen Plan erstellt haben. Das ist kein Alarmismus, sondern ein realistischer Hinweis auf die Länge des Umbaus.
Für IT-Leitungen folgt daraus eine nüchterne Botschaft: 2026 ist nicht das Jahr der flächendeckenden Migration, wohl aber das Jahr, in dem die Vorarbeiten verbindlich werden sollten. Fünf Aufgaben gehören jetzt auf die Betriebsagenda.
1. Ein Kryptografie-Inventar pro kritischem Service aufbauen
Viele Organisationen wissen, welche Anwendungen kritisch sind. Sie wissen aber deutlich seltener, welche kryptografischen Abhängigkeiten in diesen Services stecken. Genau hier beginnt die eigentliche Arbeit. Es reicht nicht, eine Liste von Zertifikaten oder VPN-Gateways zu pflegen. Nötig ist eine servicebezogene Sicht: Welche Verfahren schützen den externen Zugriff? Welche Protokolle laufen zwischen internen Komponenten? Welche Zertifikate, Schlüssel, HSMs, Libraries und Identitätsdienste hängen daran?
Praktisch sollte das Inventar mindestens fünf Bereiche erfassen: Internet-exponiertes TLS, interne Service-zu-Service-Kommunikation, VPN- und Remote-Zugänge, E-Mail- und Dateiverschlüsselung sowie Signaturketten für Software, Firmware oder Container-Artefakte. Wer das nicht je kritischem Service zusammendenkt, landet schnell bei unverbundenen Teillisten, die für Priorisierung wenig taugen.
Der operative Mehrwert ist sofort spürbar. Schon das Inventar deckt veraltete Libraries, Schatten-PKIs, schlecht dokumentierte Zertifikatsketten und unklare Zuständigkeiten auf. Genau deshalb ist diese Vorarbeit keine Zukunftswette, sondern klassische Betriebshygiene.
2. Daten mit langer Schutzdauer separat priorisieren
Nicht jede verschlüsselte Information ist gleich dringend. Entscheidend ist, wie lange Vertraulichkeit erhalten bleiben muss. Cloudflare verweist in seinem Überblick zum Stand des post-quantenfähigen Internets auf das bekannte Risiko „harvest now, decrypt later“: Datenverkehr kann heute mitgeschnitten und in Zukunft entschlüsselt werden, sobald leistungsfähige Quantenrechner verfügbar sind. Für Unternehmen ist das vor allem dort relevant, wo Informationen über viele Jahre sensibel bleiben.
Dazu gehören zum Beispiel Konstruktionsdaten, Gesundheitsinformationen, Vertragsunterlagen, sensible Personalakten, sicherheitsrelevante Betriebsdaten oder langfristig schützenswerte Kundendaten. Für solche Daten reicht es nicht, pauschal auf spätere Produktupdates der Hersteller zu hoffen. Sie brauchen eine gesonderte Priorisierung im Architektur- und Risikomodell.
Eine praxistaugliche Frage lautet: Welche Daten wären für uns in sieben bis zehn Jahren noch kritisch, wenn sie rückwirkend offengelegt würden? Wo die Antwort klar ja lautet, sollte die PQC-Vorbereitung früher ansetzen als in weniger sensiblen Bereichen. So entsteht eine sinnvolle Reihenfolge statt einer teuren Gießkanne.
3. Hersteller- und Provider-Roadmaps endlich vertraglich greifbar machen
Die meisten Unternehmen werden Post-Quanten-Kryptografie nicht allein über Eigenentwicklungen einführen, sondern über Produkte, Plattformen und Dienstleister. Genau deshalb ist Vendor-Management ein Kernpunkt der Vorbereitung. NCSC macht deutlich, dass PQC-Migration typischerweise über mehrere Investitions- und Führungszyklen läuft. Wer in dieser Zeit keine belastbaren Aussagen seiner Hersteller bekommt, plant blind.
Relevant sind dabei keine Marketingfolien, sondern vier konkrete Nachweise: Welche Produkte erhalten PQC-Unterstützung in welchem Zeitraum? Wo sind hybride Verfahren geplant, also Übergangsmodelle mit klassischer und post-quantenfähiger Kryptografie? Welche Komponenten müssen ersetzt statt aktualisiert werden? Und welche Auswirkungen gibt es auf Performance, Schlüssellängen, Zertifikatsmanagement oder Protokollkompatibilität?
Für IT-Einkauf und Architektur heißt das: Abhängigkeiten zu Firewalls, Load Balancern, VPN-Lösungen, PKI-Stacks, IoT-Komponenten, OT-Systemen, MDM-Plattformen und Signaturdiensten gehören in eine gemeinsame Roadmap. Wer diese Diskussion erst im Beschaffungszyklus 2028 beginnt, wird unnötig teuer migrieren.
4. Krypto-Agilität statt Einzelprojekt aufbauen
Der größte Fehler wäre, Post-Quanten-Kryptografie als einmaliges Sonderprojekt zu behandeln. In Wirklichkeit geht es um Krypto-Agilität, also die Fähigkeit, Verfahren, Schlüsseltypen, Zertifikatsprofile und kryptografische Bibliotheken mit vertretbarem Aufwand auszutauschen. Genau diese Flexibilität entscheidet später darüber, ob eine Migration kontrolliert oder hektisch verläuft.
NIST hat seine Standards nicht als Endpunkt formuliert, sondern als Startpunkt für Implementierungen. Das ist wichtig, weil viele Umgebungen heute noch zu starr gebaut sind. Algorithmen sind fest im Code verdrahtet, Zertifikatslaufzeiten unpraktisch lang, Geräte nur schwer aktualisierbar und Änderungen an Protokollen nur mit großen Release-Projekten möglich.
Praktisch beginnt Krypto-Agilität an unspektakulären Stellen: zentrale Verwaltung kryptografischer Parameter, sauber gepflegte Certificate Lifecycles, automatisierte Zertifikatsverteilung, versionsfähige TLS-Konfigurationen, testbare Fallback-Szenarien und eindeutige Change-Verantwortung. Wer diese Grundlagen sauberzieht, bereitet nicht nur PQC vor, sondern reduziert auch heutige Betriebsrisiken.
5. Mit kleinen Pilotbereichen anfangen, nicht mit der gesamten Landschaft
2026 braucht noch niemand die komplette Unternehmens-IT auf einmal umzubauen. Aber fast jede größere Organisation sollte einen begrenzten Pilot definieren. Geeignet sind Bereiche mit überschaubarer Komplexität und hohem Lerneffekt, etwa ein externer Testdienst, eine abgegrenzte B2B-Schnittstelle, ausgewählte TLS-Endpunkte oder eine interne PKI-Teststrecke.
Solche Piloten sollen nicht sofort Perfektion liefern. Ihr Zweck ist, reale Fragen früh sichtbar zu machen: Welche Clients und Gegenstellen verhalten sich sauber? Wo entstehen Latenz- oder Größenprobleme? Welche Monitoring-Signale fehlen? Wie verändern sich Zertifikatsprozesse, Dokumentation und Runbooks? Cloudflare zeigt mit seiner bereits messbaren PQC-Nutzung im TLS-Umfeld, dass der Übergang operativ nicht mehr nur Theorie ist. Für Enterprise-Teams ist genau jetzt der richtige Zeitpunkt, Erfahrungen kontrolliert im Kleinen zu sammeln.
Wichtig ist nur, dass Pilotierung nicht zur Alibi-Aktivität wird. Ein Pilot ohne Inventar, Priorisierung und Hersteller-Roadmap produziert schöne Folien, aber wenig Migrationsfähigkeit.
Was IT-Leitungen 2026 konkret festziehen sollten
- Kritische Services priorisieren: Für die 10 bis 20 wichtigsten Services ein kryptografisches Inventar mit Verantwortlichen aufbauen.
- Langfristig sensible Daten markieren: Datenklassen identifizieren, bei denen „harvest now, decrypt later“ realen Schaden verursachen würde.
- Provider verbindlich abfragen: PQC-Roadmaps, Austauschbedarf und Übergangsverfahren in Architektur- und Einkaufsreviews aufnehmen.
- Krypto-Änderungen operationalisieren: PKI-, Zertifikats- und TLS-Änderungen als wiederholbaren Betriebsprozess organisieren.
- Pilot mit klarer Lernfrage starten: Nicht „PQC ausprobieren“, sondern konkrete Hypothesen zu Kompatibilität, Monitoring und Rollback prüfen.
Post-Quanten-Kryptografie ist 2026 damit vor allem eine Management- und Betriebsaufgabe. Nicht weil morgen alles umgestellt sein muss, sondern weil die Organisation jetzt verstehen muss, wo sie überhaupt kryptografisch verwundbar, träge oder abhängig ist. Wer diese Vorarbeiten sauber angeht, wird später kontrolliert migrieren. Wer weiter wartet, sammelt vor allem Unklarheit an.
