Wählen Sie keinen Post-Quanten-Algorithmus, bevor Sie wissen, wo in Ihrer IT-Landschaft Public-Key-Kryptografie steckt. Das NIST hat im August 2024 FIPS 203, 204 und 205 veröffentlicht und empfiehlt Organisationen, jetzt mit der Migration zu beginnen. Die Standards sagen, wohin Sie wechseln sollen. Was Sie heute tatsächlich einsetzen, sagen sie nicht, und genau das herauszufinden, ist der zeitaufwendige Teil.
Was die Fristen von Ihnen verlangen
Laut der Projektseite des NIST werden quantenanfällige Algorithmen gemäß dem Übergangsfahrplan in NIST IR 8547 bis 2035 als veraltet eingestuft und schließlich aus den Standards entfernt, wobei Hochrisikosysteme deutlich früher wechseln sollen. Die Seite zum Entwurf von IR 8547 verzeichnet, dass die finale Fassung ihn am 27. Oktober 2026 ersetzt hat. Unsere Quellen nennen weder die betroffenen Standards noch die früheren Termine für Hochrisikosysteme; lesen Sie diese im Originaltext des NIST nach.
Das britische NCSC übersetzt den Fahrplan in Meilensteine, gegen die eine IT-Abteilung Budgets planen kann, und zwar in seinem Leitfaden zu PQC-Migrationsfristen:
| Bis | Was das NCSC erwartet |
|---|---|
| 2028 | Migrationsziele definieren, eine vollständige Bestandsaufnahme (Discovery) durchführen, einen ersten Plan erstellen |
| 2031 | Frühe, höchstpriorisierte Migration durchführen; den Plan zu einer vollständigen Roadmap verfeinern |
| 2035 | Migration aller Systeme, Services und Produkte abschließen |
Die Inventur liefert die Grundlage für alle drei Aufgaben bis 2028. Ist sie dünn, sind die beiden anderen reine Spekulation.
Was auf die Liste gehört
Ziel ist alles, was auf asymmetrischer Public-Key-Kryptografie beruht, die laut NCSC von Quantencomputern gebrochen werden kann. Der Abschnitt zur Discovery beim NCSC umfasst diese Bereiche:
- Systeme und Services, die Sie betreiben, für interne Nutzer und für Externe;
- Produkte, die Sie herstellen oder einsetzen und die eine Funktion in den Bereichen Kryptografie, Sicherheit, Kommunikation oder Datenverarbeitung haben;
- Softwareanwendungen sowie Netzwerkhardware wie Router, Switches, Gateways, VPNs und Basisstationen;
- mobile Geräte, Server und Workstations;
- IoT- und ICS-Geräte mit Kommunikationsfunktion, an Nutzer ausgegebene Token sowie im Feld installierte Geräte und Sensoren;
- die Daten, die Sie vorhalten, ihre erwartete Lebensdauer und ihr Wert für Angreifer sowie ihr Schutz bei der Übertragung und im ruhenden Zustand.
Zertifikate werden in dieser Liste nicht genannt, auch wenn das NCSC einen eigenen Abschnitt zur Enterprise-PKI hat. Nehmen Sie öffentliche Webzertifikate, interne CAs, Clientzertifikate und Code-Signing-Schlüssel als eigene Zeilen auf; das ist unsere Einschätzung, nicht die des NCSC. Ergänzen Sie auch Managed-Service-Provider.
Das ist kein formales Asset-Register. Halten Sie für jedes System Art, Umfang, Version, Patch-Stand und Abhängigkeiten fest; eine Zeile pro System genügt.
Wo Inventuren scheitern
Drei Stellen verdienen einen gezielten Blick, weil keine davon in einem Zertifikatsexport oder einer Paketliste auftaucht: in Anwendungscode oder Konfiguration fest eingebaute Schlüssel, in einem HSM gehaltene Signaturschlüssel und Firmware in Embedded- und Feldgeräten, die sich nicht wie ein Server aktualisieren lassen. Das NCSC nennt langlebige Hardware und seltene Austauschzyklen als Einschränkung, und bei diesen Geräten greift sie am stärksten.
In einer Woche zur Liste
Beginnen Sie Top-down bei den Kernservices und ihren Abhängigkeiten und gehen Sie dann Bottom-up vor, wo diese Sicht endet. Eine praktikable Aufteilung für ein kleines Team:
- Tag eins. Erfassen Sie die wichtigsten Services und die Daten, die jeder verarbeitet, und markieren Sie Daten, die über Jahre geheim bleiben müssen. Versenden Sie die unten stehende Lieferanten-E-Mail noch am selben Tag, denn Antworten brauchen am längsten.
- Tag zwei und drei. Exportieren Sie Zertifikatslisten aus jeder CA, die Sie betreiben, und fragen Sie jedes Team, das Zertifikate einkauft, nach seiner Liste. Ergänzen Sie VPN- und Remote-Access-Konfigurationen. Sammeln Sie SBOMs, Lockfiles oder Paketlisten für Software, die Sie entwickeln und betreiben, und durchsuchen Sie sie nach kryptografischen Bibliotheken und Versionen. Durchsuchen Sie Repositories und Konfigurationsverzeichnisse nach eingecheckten privaten Schlüsseln und Zertifikaten; jeder Treffer wird zu einer Zeile, und ein privater Schlüssel in einem Repository muss ohnehin behoben werden.
- Tag vier. Lassen Sie einen TLS-Scanner über externe und interne Endpunkte laufen und prüfen Sie die SSH-Hostschlüssel sowie die VPN- bzw. IPsec-Proposals, die Ihre Gateways anbieten. Vergleichen Sie die Ergebnisse mit Ihren Zeilen; Scan-Ergebnisse dienen der Gegenprobe, nicht als Ersatz.
- Tag fünf. Führen Sie alles zusammen, markieren Sie Lücken und tragen Sie "unbekannt" ein, wo Sie etwas nicht bestätigen konnten.
Lieferantenfragen, die in eine E-Mail passen:
- Welche Ihrer Produkte oder Services, die wir nutzen, setzen auf Public-Key-Kryptografie, und welche Bibliotheken und Versionen enthalten sie?
- Wie sieht Ihr PQC-Migrationsplan aus, mit Terminen?
Das NCSC sagt, Sie sollten sicherstellen, dass Managed-Service-Provider diese Bewertungen für die Services durchführen, die sie für Sie betreiben. Die schriftliche Nachfrage ist unsere Empfehlung, wie Sie das erreichen.
Von der Liste zum Plan
Wählen Sie für jede Zeile eine der NCSC-Strategien: In-place-Migration, Re-Platforming, Service abschalten, bis zum End-of-Life weiterbetreiben oder das Risiko tolerieren. Systeme ohne Public-Key-Kryptografie erfordern keine Maßnahmen.
Sortieren Sie die Zeilen zuerst nach Lebensdauer und Wert der geschützten Daten, dann nach der Abhängigkeit von langlebiger Hardware.
Rechnen Sie damit, dass Alt und Neu eine Zeit lang parallel laufen. Bevorzugen Sie Produkte mit Kryptoagilität, die also alternative Algorithmen-Suites problemlos unterstützen, und legen Sie vorab fest, wann Sie die klassische Unterstützung beenden.
Erst dann wählen Sie Algorithmen. Das NIST erwartet, dass ML-KEM (FIPS 203) für den Schlüsselaustausch sowie ML-DSA (FIPS 204) und SLH-DSA (FIPS 205) für Signaturen das Fundament der meisten Implementierungen bilden. FIPS 203 enthält einen Planungshinweis zu einem Problem, das in einer künftigen Revision korrigiert werden soll; prüfen Sie daher die Errata, bevor Sie danach implementieren. Das NIST standardisiert Falcon und HQC noch; auf der PQC-Projektseite behalten Sie Änderungen im Blick.
Bei der Discovery unterstützt Sie unser Beratungsteam mit entsprechenden Assessments.
So fangen Sie an
- Benennen Sie einen Verantwortlichen, reservieren Sie eine Woche und senden Sie die Lieferanten-E-Mail am ersten Tag.
- Legen Sie pro System eine Zeile an: Verantwortlicher, Zweck, Einsatzort der Public-Key-Kryptografie, Versionen, Abhängigkeiten, Datenlebensdauer, Lieferant, gewählte Strategie, Zieltermin.
- Sammeln Sie Zertifikate, VPN-Konfigurationen und SBOMs und führen Sie dann die TLS-, SSH- und Repository-Suchen durch.
- Prüfen Sie fest eingebaute Schlüssel, HSM-gestützte Signaturen und Embedded-Firmware von Hand und markieren Sie alles Unbestätigte als "unbekannt".
- Sortieren Sie die Zeilen nach Datenlebensdauer und Hardwareabhängigkeit und geben Sie jeder eine NCSC-Strategie und einen Zieltermin, damit die Tabelle zu Ihrem Plan für 2028 wird.
- Lesen Sie die finale IR 8547 für die Termine zur Ausmusterung bei hohem Risiko und setzen Sie interne Termine vor 2035, wo sie es verlangt.
