Die Migration zu Post-Quanten-Kryptografie ist vor allem ein Inventarproblem. Kein Unternehmen kann sicher ersetzen, was es nicht auffindet, klassifiziert und mit Geschäftsprozessen verknüpft. Das Risiko liegt nicht nur in alten Servern oder abgelaufenen Zertifikaten. Es findet sich in eingebetteten Bibliotheken, Drittanbieterintegrationen, Industrieanlagen, Backups mit langen Aufbewahrungsfristen und Protokollen, die Netzwerke ohne klaren Eigentümer durchqueren.
Der Ausgangspunkt ist eindeutig: feststellen, wo die Organisation Public-Key-Kryptografie einsetzt, die durch Quantenfortschritte gefährdet ist, und entscheiden, was zuerst geändert werden muss. Das NIST strukturiert den Migrationsweg in Phasen, mit ausdrücklichem Schwerpunkt auf kryptografischer Transparenz, Risikomanagement, Interoperabilität und Tests. Die aktualisierte NCCoE-Leitlinie unterstreicht, dass die Einführung von Post-Quanten-Kryptografie ein umfassendes Inventar erfordert, nicht ein isoliertes Produktupdate.
Warum ist das kryptografische Inventar die erste relevante Lieferung?
Weil der Algorithmus für die Personen, die das Geschäft betreiben, selten sichtbar ist. Eine Anwendung kann TLS für den Transport, X.509-Zertifikate für die Authentifizierung, eine Kryptografiebibliothek zum Signieren von Dateien und einen Schlüsseltresor zum Schutz von Geheimnissen verwenden. Jede Schicht kann einen eigenen Lieferanten, Aktualisierungszyklus und Kritikalitätsgrad haben.
Kryptografisches Inventar ist die strukturierte Erfassung von Assets, Algorithmen, Schlüsseln, Zertifikaten, Protokollen, Bibliotheken, Abhängigkeiten und Verantwortlichen, die die kryptografischen Kontrollen des Unternehmens bilden. Es unterscheidet sich von einem herkömmlichen IT-Inventar. Eine CMDB zeigt, dass ein Server existiert. Das kryptografische Inventar muss zeigen, wie er Daten schützt, welche Verbindungen er herstellt, welche Schlüssel er nutzt und welche Folgen entstehen, wenn der Mechanismus geändert werden muss.
Die Dringlichkeit ergibt sich nicht aus einer exakten Prognose, wann ein kryptografisch relevanter Quantencomputer verfügbar sein wird. Sie ergibt sich aus der Dauer des Übergangs. Sensible Daten können heute abgegriffen und künftig entschlüsselt werden – ein Szenario, das als harvest now, decrypt later bekannt ist: Verschlüsselte Inhalte werden heute gesammelt, um sie zu brechen, sobald ausreichende Rechenkapazität verfügbar ist. Der 2026 veröffentlichte globale Bericht von DigiCert stellte einen wichtigen Kontrast zwischen Executive Awareness und technischer Umsetzung fest: Das Risikobewusstsein wächst, doch die Asset-Erkennung und die Bereitstellung quantenresistenter Zertifikate stehen in weiten Teilen der Organisationen noch am Anfang. Zum Bericht.
Das Inventar ist daher keine Dokumentation für Audits. Es ist der Mechanismus, der eine langfristige Bedrohung in kurzfristige operative Entscheidungen überführt.
Was sollte in den Umfang des Inventars aufgenommen werden?
Der Umfang muss dem Informationsfluss folgen, nicht nur der Serverliste. Beginnen Sie mit vier Evidenzgruppen.
1. Daten mit langer Vertraulichkeitsdauer
Klassifizieren Sie Informationen, deren Wert über Jahre besteht: geistiges Eigentum, klinische Daten, Finanzunterlagen, Verträge, Preisstrategien, Zugangsdaten, biometrische Daten und personenbezogene Informationen mit gesetzlicher Aufbewahrungspflicht. Erfassen Sie für jede Klasse, wie lange sie vertraulich bleiben muss.
Dieses Zeitfenster bestimmt die Priorität. Daten, die in sechs Monaten an Relevanz verlieren, können einen schrittweisen Ansatz tolerieren. Ein Bestand, der zehn Jahre vertraulich bleiben muss, sollte frühzeitig in den Plan aufgenommen werden, auch wenn das zugehörige System für die Verfügbarkeit nicht kritisch erscheint.
2. Einsatzpunkte von Public-Key-Kryptografie
Erfassen Sie, wo RSA, Elliptic-Curve-Kryptografie, Diffie-Hellman, digitale Signaturen und Zertifikate eingesetzt werden. Dazu gehören TLS, VPN, SSH, Unternehmens-E-Mail, APIs, Code Signing, föderierte Authentifizierung, mobile Geräte, Unternehmens-Wi-Fi, DNSSEC, BGP, interne PKI und Machine-to-Machine-Integrationen.
Eine aktuelle Überprüfung weit verbreiteter Protokolle zeigt, dass TLS und Signal bei hybriden Mechanismen für den Schlüsselaustausch weiter fortgeschritten sind, während für SSH und IPsec Standards verfügbar sind, die produktive Einführung jedoch weniger verbreitet ist. Die Studie hebt außerdem hervor, dass die Migration der Authentifizierung tendenziell komplexer ist als der Schlüsselaustausch – insbesondere wenn Signaturgrößen Protokoll- und Gerätegrenzen beeinflussen. Lesen Sie die vergleichende Analyse.
3. Unsichtbare Implementierungen im Code und in der Softwarelieferkette
Suchen Sie nach kryptografischen Bibliotheken, die in Anwendungen, Containern, SDKs, Firmware, Appliances und Legacy-Paketen eingebettet sind. Häufig gibt es Abhängigkeiten, die veraltete Algorithmen einsetzen, ohne dass das Produktteam davon weiß. Führen Sie Software Composition Analysis, Repository-Inspektionen, Image-Scans und Prüfungen der von kritischen Anwendungen aufgerufenen Bibliotheken durch.
Beziehen Sie Versionen ein. Zu wissen, dass eine Anwendung OpenSSL, Java, .NET, ein Cloud-SDK oder eine Authentifizierungsbibliothek verwendet, reicht nicht aus. Die Fähigkeit zur Einführung von Post-Quanten-Algorithmen hängt von Versionen, Parametern, Protokollkompatibilität und dem Verhalten der Clients ab.
4. Dritte und Managed Services
SaaS, Cloud-Anbieter, Payment Gateways, Identitätsplattformen, CDNs, B2B-Partner und Gerätehersteller müssen in das Inventar aufgenommen werden. Erfassen Sie für jeden Lieferanten, welche Daten verschlüsselt werden, wer die Schlüssel kontrolliert, welche Algorithmen genutzt werden, wie Aktualisierungen erfolgen und ob ein öffentlicher Migrationsplan existiert.
Ein wiederkehrender Fehler besteht darin, den eingekauften Service als sichere Blackbox zu behandeln. Bei einem Post-Quanten-Übergang muss der Vertrag Transparenz über Zeitplan, Kompatibilität, Verantwortung für Tests und Alternativen schaffen, falls der Lieferant die Anpassung verzögert.
Wie wird technische Erkennung in geschäftliche Priorität überführt?
Die Asset-Liste wird umfangreich sein. Der Wert liegt darin, eine konsistente Priorität zuzuweisen. Ein praktikabler Ansatz besteht darin, jedes Element anhand von fünf Dimensionen zu bewerten: Datensensibilität, Vertraulichkeitsdauer, externe Exposition, operative Abhängigkeit und Migrationsaufwand.
Die externe Exposition misst, ob ein Asset öffentliche Verbindungen entgegennimmt, Partner integriert oder über nicht vertrauenswürdige Netzwerke kommuniziert. Die operative Abhängigkeit misst die Auswirkungen, falls die kryptografische Änderung Inkompatibilitäten, Authentifizierungsfehler oder Performance-Einbußen verursacht. Der Migrationsaufwand berücksichtigt Legacy-Systeme, nicht unterstützte Firmware, Lieferantenabhängigkeit, spezialisierte Hardware und die Anzahl externer Clients.
Das Ergebnis sollte keine intransparente Bewertung sein. Verwenden Sie klare Kategorien:
- Welle 1: langlebige Daten, exponierte Services, zentrale Authentifizierung, PKI und Integrationen mit hohem Volumen.
- Welle 2: kritische interne Anwendungen, VPNs, Entwicklungsplattformen, Code Signing und Konnektivität zwischen Standorten.
- Welle 3: Assets mit geringerer Exposition, Laborumgebungen, Anwendungen in der Ablösung und Geräte, die von physischer Erneuerung abhängen.
Es gibt einen wesentlichen Unterschied zwischen Vertraulichkeit und Authentizität. Die Umstellung des Schlüsselaustauschs bei externen Verbindungen kann zunächst das Risiko der Abfangung und künftigen Speicherung reduzieren. Die Migration von Signaturen betrifft dagegen Zertifikate, Tokens, Softwareupdates und Vertrauenskaetten. Beide Bereiche benötigen eine eigene Governance, auch wenn sie in derselben Anwendung auftreten.
Wie lässt sich die Migration ohne operative Unterbrechungen organisieren?
Die Antwort lautet: nach Fähigkeiten migrieren, nicht nach Produkten. Ein reifes Unternehmen entscheidet nicht einfach, „PQC zu aktivieren“. Es schafft die Voraussetzungen, Änderungen sicher zu testen, einzuführen, zu messen und zurückzunehmen.
Beginnen Sie mit einer Validierungsumgebung, die realen Datenverkehr, Clients, Geräte und Richtlinien nachbildet. Testen Sie Schlüssel- und Signaturgrößen, Latenz, Paketfragmentierung, CPU-Verbrauch, Grenzen von Load Balancern, Proxy-Kompatibilität und das Verhalten älterer Clients. Bei Protokollen mit hohem Volumen können kleine Größenunterschiede Kosten und Performance verändern.
Setzen Sie anschließend, wo möglich, hybride Mechanismen ein. Hybride Kryptografie kombiniert während des Übergangs einen klassischen mit einem Post-Quanten-Mechanismus. Damit wird Kompatibilität gewahrt und zugleich Schutz gegen Quantenrisiken integriert. Sie ersetzt nicht die vollständige Migration, reduziert jedoch das Risiko, unmittelbar von einer einzigen umfassenden Änderung abhängig zu sein.
Die von Meta im April 2026 veröffentlichte Erfahrung zeigt, dass die Migration eine Koordination von Inventar, Protokoll-Engineering, Performance-Tests und Abhängigkeitskontrolle erfordert. Das Unternehmen betont, dass die Erkennung kryptografischer Nutzung Bereitstellungsentscheidungen vorausgehen muss und dass die Herausforderungen je nach Kontext des jeweiligen Service variieren. Die technischen Erkenntnisse sind bei Meta Engineering detailliert beschrieben.
Definieren Sie zudem Rollback-Kriterien. Wenn eine Änderung zu mehr Fehlern, Inkompatibilität mit einem kritischen Client oder Auswirkungen außerhalb des Latenzbudgets führt, muss das Team die Konfiguration deaktivieren können, ohne Server manuell wiederherzustellen. Diese Anforderung unterscheidet einen kontrollierten Piloten von einer riskanten Produktionsänderung.
Was ist Kryptoagilität und warum sollte sie zur Architekturanforderung werden?
Kryptoagilität ist die Fähigkeit, kryptografische Algorithmen, Schlüssel, Parameter und Bibliotheken zu ersetzen oder neu zu konfigurieren, ohne ganze Systeme neu zu schreiben. Sie ist kein spezifisches Produkt. Sie ist eine architektonische Eigenschaft.
Eine kryptoagile Anwendung vermeidet fest im Code verankerte Algorithmen. Sie zentralisiert Richtlinien, verwendet standardisierte APIs, trennt Geschäftslogik von kryptografischer Implementierung und verfügt über Mechanismen zur Schlüsselrotation. Sie erfasst zudem, wo jedes Zertifikat verwendet wird, und ermöglicht das Testen neuer Konfigurationen in begrenzten Gruppen.
Das Fehlen dieser Fähigkeit schafft kryptografische Schulden. Sie werden sichtbar, wenn eine scheinbar einfache Änderung Anpassungen in Hunderten von Repositories, die Neukompilierung von Clients, Updates physischer Geräte und die Neuverhandlung externer Integrationen erfordert. Je höher diese Schulden sind, desto früher sollte das Asset erkannt und behandelt werden, auch wenn seine finale Migration erst später erfolgt.
Nehmen Sie Anforderungen an Kryptoagilität in Beschaffung und Vertragsverlängerungen auf. Konkrete Fragen helfen: Unterstützt der Lieferant die vom NIST definierten Post-Quanten-Standards? Gibt es Unterstützung für hybride Modi? Wie lang ist die Aktualisierungsfrist für Managed-Versionen? Kann die Konfiguration über eine API automatisiert werden? Funktioniert der ältere Client weiterhin? Wie informiert das Unternehmen über Algorithmusänderungen?
Das NIST hat bereits Post-Quanten-Standards veröffentlicht, die in mehreren Szenarien zum Schutz von Informationen implementiert werden können. Damit verschiebt sich die Diskussion von Forschung zu Engineering-Planung, auch wenn die Einführung weiterhin von der Reife jedes Protokolls und Lieferanten abhängt. Die offizielle PQC-Seite des NIST fasst die verfügbaren Standards zusammen.
Wer sollte das Post-Quanten-Migrationsprogramm steuern?
Die Verantwortung darf nicht auf das Kryptografieteam beschränkt bleiben – sofern ein solches vorhanden ist. Das Programm benötigt Sponsoring aus Security, Architektur, Plattform, Entwicklung, Infrastruktur, Recht, Einkauf und von Datenverantwortlichen. Jeder Bereich kontrolliert einen Teil der Risikofläche.
Richten Sie ein schlankes Komitee mit monatlichen Entscheidungen und einfachen Kennzahlen ein. Die wichtigsten sind: Anteil der Assets mit abgeschlossener Erkennung; Anteil der Daten, die nach Vertraulichkeitsdauer klassifiziert sind; Abdeckung bewerteter Lieferanten; Anteil der Zertifikate und Integrationen mit eindeutigem Verantwortlichen; kritische Assets, die für hybride Tests geeignet sind; sowie Ausnahmen mit Behandlungsfrist.
Vermeiden Sie, ausschließlich den „migrierten Prozentsatz“ zu messen. Diese Kennzahl kommt spät und kann überhastete Änderungen fördern. Vor der Migration ist die Verringerung unbekannter Zonen das beste Fortschrittssignal. Ein Asset ohne Verantwortlichen, ohne identifizierten Algorithmus oder ohne Aktualisierungsnachweis ist ein Risiko, das nicht korrekt priorisiert werden kann.
Die Aufgabe der Governance besteht darin, Entscheidungen nachvollziehbar zu halten. Jede Ausnahme muss den Grund, die betroffenen Daten, die kompensierende Kontrolle, den beteiligten Lieferanten, den Executive Owner und das Überprüfungsdatum erfassen. In regulierten Umgebungen zeigt diese Disziplin zudem, dass die Organisation den Übergang als architektonisches Risiko und nicht als punktuelle Reaktion auf einen Technologietrend behandelt.
Welcher 90-Tage-Plan schafft echte Dynamik?
In den ersten 30 Tagen legen Sie Umfang, Asset-Taxonomie und Risikokriterien fest. Wählen Sie drei bis fünf Datenflüsse mit hoher Vertraulichkeit aus. Benennen Sie Verantwortliche für Systeme, Zertifikate, Schlüssel und Integrationen. Parallel dazu richten Sie die Erfassung von Evidenz durch Netzwerk-Scans, Zertifikatsmanagement, Repositories und Observability-Tools ein.
Zwischen Tag 31 und 60 konsolidieren Sie die Erkenntnisse in einem einzigen Inventar. Identifizieren Sie Algorithmen, Protokolle, Versionen, Abhängigkeiten und Lücken bei der Verantwortlichkeit. Klassifizieren Sie die Assets in die drei Wellen. Versenden Sie technische Fragebögen an kritische Lieferanten und eröffnen Sie Remediation-Pläne für Assets ohne Support oder ohne realisierbare Aktualisierung.
Zwischen Tag 61 und 90 wählen Sie zwei kontrollierte Testfälle aus. Einer kann eine externe TLS-Verbindung mit hybrider Unterstützung sein. Der andere kann eine interne Anwendung mit hohem Datenwert und vorhersehbarem Änderungszyklus sein. Messen Sie Performance, Kompatibilität, Fehler und operativen Aufwand. Legen Sie dem Executive Committee zum Abschluss eine Risikokarte vor, nicht nur eine Liste von Technologien.
Der Post-Quanten-Übergang wird lang sein. Das Unternehmen, das mit Inventar, Priorität und Kryptoagilität beginnt, gewinnt Entscheidungsfreiheit. Wer auf ein endgültiges Datum wartet, wird tendenziell zu spät feststellen, dass das größte Problem nicht der Algorithmus war: Es wusste nicht, wo er eingesetzt wurde.
Quer o passo a passo aplicado ao seu cenário?
Comece pelo e-mail — sem cadastro longo.
