Post-Quanten-Kryptografie einführen: Migrationsplan für Unternehmen

Am Montagmorgen meldet das Security-Team einen neuen extern erreichbaren Dienst. Die Anwendung nutzt TLS, die Zertifikate kommen automatisch aus einer zentralen PKI, und die Datenbank enthält Vertragsunterlagen mit langen Aufbewahrungsfristen. Auf die einfache Frage, welche kryptografischen Verfahren, Schlüssel und Abhängigkeiten dahinterstehen, gibt es aber keine vollständige Antwort. Genau an diesem Punkt beginnt die Einführung von Post-Quanten-Kryptografie, kurz PQC: nicht mit dem Austausch einzelner Zertifikate, sondern mit Transparenz.

Quantencomputer bedrohen nicht jede heute eingesetzte Kryptografie in gleicher Weise. Besonders betroffen sind Verfahren mit Public-Key-Kryptografie, etwa RSA und elliptische Kurven für Schlüsselaustausch und digitale Signaturen. Symmetrische Verschlüsselung und Hashfunktionen bleiben grundsätzlich relevant, benötigen aber je nach Schutzbedarf angepasste Schlüsselgrößen und eine saubere Bewertung. Für dein Unternehmen zählt vor allem eine Frage: Welche Daten, Systeme und Signaturen müssen noch vertrauenswürdig oder geheim sein, wenn leistungsfähige Quantencomputer verfügbar werden?

Infografik zu Post-Quanten-Kryptografie einführen: Migrationsplan für Unternehmen (KI-generiert).

Warum du jetzt planen solltest

Viele Daten haben eine lange Schutzdauer. Das betrifft beispielsweise personenbezogene Daten, Entwicklungsunterlagen, medizinische Informationen, Finanzdaten, Geheimhaltungsvereinbarungen oder strategische Planungen. Ein Angreifer kann verschlüsselte Kommunikation heute aufzeichnen und später entschlüsseln. Dieses Risiko wird häufig als „Harvest now, decrypt later“ bezeichnet.

Hinzu kommt die technische Realität: Kryptografie steckt an weit mehr Stellen als in einem Webserver-Zertifikat. Sie ist in VPNs, WLANs, E-Mail-Verschlüsselung, Software-Signaturen, Datenbankverbindungen, Identitätsdiensten, Backups, Hardware-Sicherheitsmodulen und Maschinenidentitäten eingebaut. Gerade bei langlebigen Plattformen, eingebetteten Geräten und externen Schnittstellen kann ein Wechsel mehrere Jahre Vorbereitung erfordern.

Die gute Nachricht: Du musst nicht auf einen einzelnen Stichtag warten und auch nicht blind Verfahren austauschen. PQC ist eine planbare Modernisierung der Kryptografie. Die Grundlagen dafür sind bekannte Aufgaben aus Architektur, Inventarisierung, Change-Management, Test und Betrieb.

Die Krypto-Inventur: Finde die tatsächlichen Abhängigkeiten

Eine Krypto-Inventur beantwortet nicht nur, welche Algorithmen im Unternehmen zugelassen sind. Sie zeigt, wo sie tatsächlich verwendet werden, wer sie betreibt und welche Folgen ein Austausch hätte. Dokumentiere dabei sowohl technische Details als auch fachliche Schutzanforderungen.

Beginne mit den wichtigsten Bereichen:

• Externe und interne TLS-Verbindungen, inklusive Load Balancer, Reverse Proxies, APIs und Service Meshes
• VPN-Verbindungen zwischen Standorten, zu Cloud-Umgebungen und zu Dienstleistern
• Zertifizierungsstellen, ausstellende CA-Systeme, Zertifikatsprofile und Sperrlisten
• Schlüsselmanagement, Hardware-Sicherheitsmodule, Cloud-Key-Management und Secrets-Management
• Digitale Signaturen für Software, Dokumente, E-Mails, Firmware und Container-Images
• Identitäts- und Zugriffsplattformen, besonders föderierte Anmeldung und Service Principals
• Datenbanken, Datensicherungen, Archivsysteme und verschlüsselte Dateifreigaben
• Netzwerkkomponenten, WLAN-Controller, Firewalls, Router, IoT- und OT-Geräte
• Eigenentwicklungen sowie eingekaufte Software mit kryptografischen Bibliotheken

Inventurfeld	Beispiel	Warum es für PQC wichtig ist
Schutzobjekt	Vertragsarchiv, API, VPN-Tunnel	Priorisierung nach Schutzbedarf
Verfahren und Protokoll	RSA, ECC, TLS, IPsec	Betroffenheit und Migrationspfad erkennen
Schlüssel und Zertifikate	Laufzeit, Aussteller, Speicherort	Wechselaufwand und Betriebsrisiko bewerten
Verantwortlichkeit	Plattform-Team, Fachbereich, Dienstleister	Entscheidungen und Tests verbindlich steuern
Abhängigkeiten	HSM, Client-Versionen, Partner-Schnittstellen	Kompatibilitätsprobleme früh sichtbar machen

Automatisierte Scans helfen, vor allem bei TLS-Endpunkten und Zertifikaten. Sie ersetzen aber keine fachliche Bewertung. Ein Scan erkennt beispielsweise ein RSA-Zertifikat, aber nicht zwingend, ob es für eine Schnittstelle mit einem langjährigen Geschäftspartner unverzichtbar ist. Kombiniere daher technische Erhebung, Architekturunterlagen, CMDB-Daten, Vertragsinformationen und Gespräche mit Systemverantwortlichen.

Priorisieren statt alles gleichzeitig migrieren

Nach der Inventur brauchst du eine Reihenfolge. Nicht jede kryptografische Nutzung ist gleich dringend. Bewerte Systeme anhand von vier Kriterien:

• Vertraulichkeitsdauer: Wie lange müssen die Daten geheim bleiben?
• Integritätsdauer: Wie lange muss eine Signatur oder ein Nachweis überprüfbar sein?
• Exponiertheit: Ist das System öffentlich erreichbar oder über externe Netze verbunden?
• Migrationsfähigkeit: Lassen sich Software, Hardware, Bibliotheken und Partner zeitnah umstellen?

Ein öffentlich erreichbarer Dienst mit kurzlebigen, wenig sensiblen Daten kann technisch einfacher sein als ein Archiv mit vertraulichen Unterlagen. Umgekehrt kann ein alter VPN-Endpunkt für einen Produktionsstandort ein hohes Risiko darstellen, obwohl er nicht aus dem Internet erreichbar ist. Entscheidend ist die Kombination aus Schaden, Schutzdauer und Umsetzbarkeit.

Lege daraus drei Arbeitskörbe an:

• Sofort untersuchen: langlebige vertrauliche Daten, externe Schnittstellen, zentrale PKI, Software-Signaturen und nicht mehr unterstützte Kryptografie
• Geplant modernisieren: aktuelle Plattformen mit klarer Roadmap und vorhandenen Update-Pfaden
• Beobachten und absichern: Systeme ohne verfügbare PQC-Unterstützung, bei denen zunächst Segmentierung, Zugriffsschutz und Lieferantensteuerung nötig sind

Ein gutes Sicherheitsprogramm verbindet diese Arbeit mit bestehenden Maßnahmen. Bei der NIS2-Umsetzung für IT-Administratoren gehören nachvollziehbare Risiken, Verantwortlichkeiten und belastbare Betriebsprozesse ebenfalls zu den zentralen Themen.

Hybride Verfahren als kontrollierter Übergang

In der Übergangsphase sind hybride Ansätze besonders wichtig. Dabei schützt eine Verbindung mit klassischer Kryptografie und einem PQC-Verfahren gleichzeitig. Die Absicht ist klar: Die Sicherheit soll nicht allein von der neuen oder allein von der bisherigen Technik abhängen.

Für den Schlüsselaustausch ist ML-KEM ein zentraler Standard. Für digitale Signaturen stehen unter anderem ML-DSA und SLH-DSA bereit. Entscheidend ist jedoch nicht nur der Algorithmusname. Prüfe, ob ihn deine eingesetzte TLS-Bibliothek, dein Webserver, dein VPN-Gateway, dein Betriebssystem, deine HSM-Firmware und deine Client-Landschaft tatsächlich unterstützen.

Hybride Verfahren reduzieren nicht automatisch jedes Risiko. Sie können größere Schlüssel, Zertifikate oder Handshakes erzeugen. Das kann Auswirkungen auf Paketgrößen, Latenzen, MTU-Probleme, ältere Clients und Inspecting Proxies haben. Plane deshalb keine Produktivumstellung ohne Messwerte.

Auch Zertifikate brauchen besondere Aufmerksamkeit. Eine PKI-Migration umfasst mehr als neue Schlüsselpaare. Prüfe Zertifikatsvorlagen, Enrollment-Prozesse, Laufzeiten, Sperrkonzepte, Vertrauenskeystore, Anwendungen mit fest hinterlegten Zertifikaten und die Fähigkeit externer Partner, neue Signaturalgorithmen zu validieren. Die Umstellung der PKI ist ein mehrstufiges Programm, kein einmaliger Austausch.

Testumgebung: Was du vor dem Rollout prüfen musst

Richte eine isolierte Testumgebung ein, die deine relevanten Kommunikationswege realistisch abbildet. Dazu gehören mindestens ein Server, unterschiedliche Client-Versionen, ein Proxy oder Load Balancer, die PKI und das zentrale Monitoring. Für VPNs brauchst du beide Endpunkte sowie typische Routing- und Firewall-Regeln.

Teste nicht nur, ob sich eine Verbindung aufbauen lässt. Prüfe auch diese Punkte:

• Funktionieren klassische, hybride und gegebenenfalls PQC-fähige Verbindungen wie vorgesehen?
• Welche Clients, Bibliotheken oder Geräte scheitern bei neuen Zertifikaten oder Cipher Suites?
• Verändert sich die Dauer eines TLS-Handshakes oder eines VPN-Verbindungsaufbaus?
• Bleiben Monitoring, Entschlüsselungsproxies, IDS und SIEM-Auswertungen funktionsfähig?
• Lassen sich Zertifikate sperren, erneuern und bei einem Fehler zurückrollen?
• Sind Logeinträge eindeutig genug, um Algorithmus, Zertifikat und Fehlerursache zu erkennen?

Dokumentiere Testergebnisse als Entscheidungsgrundlage. Ein erfolgreicher Laborversuch ist noch keine Betriebsfreigabe. Erst wenn Last, Fehlerszenarien, Rollback und Support-Prozesse geprüft sind, ist ein begrenzter Pilot sinnvoll.

Schlüsselmanagement und Identitäten nicht vergessen

PQC betrifft auch Maschinenidentitäten. Service Principals, Workload Identities, API-Schlüssel und Zertifikate verbinden Anwendungen mit Cloud-Diensten und internen Plattformen. Wenn diese Identitäten unübersichtlich wachsen, wird jede kryptografische Migration unnötig riskant.

Eine gute Vorbereitung besteht aus zentralen Eigentümern, kurzen und kontrollierten Laufzeiten, nachvollziehbaren Berechtigungen und automatisierter Erneuerung. Der Beitrag Microsoft Entra Workload Identities absichern: Service Principals, Managed Identities und KI-Agenten kontrollieren zeigt, warum Inventar und Governance bei nicht menschlichen Identitäten so wichtig sind.

Prüfe zudem die Fähigkeiten deines Schlüsselmanagements. Nicht jedes HSM und nicht jeder Cloud-Dienst unterstützt neue Verfahren sofort in gleicher Weise. Kläre mit Herstellern, welche Roadmap, Firmware, APIs und Betriebsgrenzen gelten. Verlange dabei konkrete Aussagen zur Unterstützung, zu Leistungswerten, Exportmöglichkeiten und Migrationswerkzeugen.

Welche Kompetenzen dein Team braucht

Administratoren müssen Protokolle, Zertifikatsketten, PKI-Prozesse, Netzwerkpfade und Monitoring verstehen. Entwickler benötigen zusätzlich Kenntnisse über Krypto-Bibliotheken, sichere Voreinstellungen, Zertifikatsprüfung, Secrets-Management und Abhängigkeiten in Build-Pipelines.

Wichtig ist vor allem Kryptoagilität. Damit ist die Fähigkeit gemeint, Algorithmen, Schlüsselgrößen und Konfigurationen kontrolliert austauschen zu können, ohne Anwendungen jedes Mal grundlegend neu zu bauen. Gute Architektur trennt Geschäftslogik von kryptografischen Details, vermeidet fest codierte Algorithmen und hält Bibliotheken aktuell.

Auch sichere Software-Lieferketten gehören dazu. Wenn du kryptografische Bibliotheken oder Komponenten aktualisierst, musst du wissen, welche Anwendung welche Version nutzt. Eine SBOM für den Cyber Resilience Act erstellen hilft dabei, Abhängigkeiten strukturiert sichtbar zu machen.

Dein 90-Tage-Startplan

Du brauchst für den Einstieg kein umfassendes Großprojekt. Starte mit einem klar abgegrenzten Vorgehen:

• Benenne eine technische und eine fachliche Koordination für die PQC-Vorbereitung.
• Erstelle innerhalb der ersten Wochen eine Inventur der externen TLS-Endpunkte, VPNs, PKI-Systeme und langlebigen Daten.
• Definiere Priorisierungskriterien und entscheide über die ersten Pilotkandidaten.
• Kläre bei Herstellern und Dienstleistern PQC-Roadmaps, Update-Pfade und Supportgrenzen.
• Baue eine Testumgebung für mindestens einen TLS- und einen VPN-Anwendungsfall auf.
• Teste hybride Konfigurationen, dokumentiere Kompatibilität und plane einen kontrollierten Pilotbetrieb.
• Überführe Ergebnisse in Standards für Architektur, Beschaffung, Entwicklung und Betrieb.

PQC-Migration ist kein isoliertes Security-Thema. Sie betrifft Plattformen, Netzwerke, Entwicklung, Compliance, Einkauf und Fachbereiche. Je früher du Abhängigkeiten sichtbar machst, desto weniger hektisch werden spätere Umstellungen.

Passende Seminare und Termine zu Security, Netzwerken, Microsoft und Cloud findest du bei uns auf cmt.de. Für die systematische Qualifizierung eines Teams ist auch unser Beitrag Weiterbildung fürs IT-Team planen: so geht’s eine praktische Grundlage.