Risikobewertung durch Quantencomputer: vom Krypto-Inventar zum Migrationsplan

Das Wichtigste im Überblick

• Die Bewertung beginnt bei der Schutzdauer. Entscheidend ist, wie lange ein Datenbestand vertraulich bleiben muss. Reicht diese Dauer über den Zeitraum hinaus, in dem ein kryptografisch relevanter Quantencomputer verfügbar sein könnte, unterliegen die Daten bereits heute dem Risiko, aufgezeichnet und später entschlüsselt zu werden (Quelle: EU-Kommission, Post-Quantum Cryptography). Das Jahr 2035 taugt dabei als Planungshorizont, nicht als technische Grenze.
• Ohne belastbare Bestandsaufnahme keine Priorisierung. Eine belastbare Bestandsaufnahme der kryptografischen Verfahren ist die Voraussetzung dafür, die Reihenfolge der Migration nachvollziehbar zu begründen. Die Roadmap der EU-Mitgliedstaaten sieht vor, dass alle Mitgliedstaaten bis Ende 2026 mit der Umstellung beginnen, und zählt den Aufbau kryptografischer Inventare zu diesen ersten Schritten (Quellen: EU-Kommission, Roadmap; EU-Kommission, Post-Quantum Cryptography).
• Schlüsseleinigung und Signaturen folgen unterschiedlichen Pfaden. Für die hybride Schlüsseleinigung in TLS 1.3 liegt mit RFC 10024 ein Standards-Track-RFC mit drei definierten Gruppen vor (X25519MLKEM768, SecP256r1MLKEM768 und SecP384r1MLKEM1024), und die Implementierungen sind verfügbar (Quelle: RFC 10024). Für öffentlich vertrauenswürdige TLS-Serverzertifikate im Web-PKI-Modell ist die normative und operative Grundlage für ML-DSA-Zertifikate im CA/Browser-Forum im September 2026 noch nicht abgeschlossen. Das gilt auch Mitte Oktober 2026 (Quelle: CA/Browser Forum, Ballots der Server Certificate Working Group).
• Der Engpass ist häufig fehlende Transparenz über den eigenen Kryptobestand. In der von Ponemon Institute durchgeführten und von Entrust gesponserten Studie vom 27. Januar 2026 nennen 41 Prozent der Befragten den mangelnden Überblick über ihre kryptografischen Assets als größtes Hindernis für die Quantenreife; 43 Prozent geben an, ihre Zertifikate vollständig im Blick zu haben (Quelle: Entrust, Pressemitteilung vom 27.01.2026). Das sind Selbstauskünfte der Befragten.
• Die Lieferkette bestimmt Ihren Takt. Bei OT-Komponenten, Zahlungsterminals und eingebetteten Systemen können Produktlebenszyklen über den empfohlenen Zielterminen liegen. Zu unterscheiden sind dabei vier Dinge: die technische Abhängigkeit vom Hersteller, der Support-Lebenszyklus des Produkts, Anforderungen an Zertifizierung und Validierung sowie die Austauschbarkeit der Hardware.

Wie bewerten Sie das Quantenrisiko methodisch?

Den Rahmen dafür liefert die Ungleichung von Mosca. Sie stellt drei Zeiträume gegenüber:

1. X ist die Schutzdauer: Wie viele Jahre muss ein Datenbestand vertraulich bleiben? Die Größe lässt sich aus rechtlichen, vertraglichen und wirtschaftlichen Anforderungen ableiten, ist aber selten exakt bekannt.
2. Y ist die Migrationsdauer: Wie viele Jahre braucht Ihre Organisation, um die betroffenen Systeme umzustellen? Sie ist eine Schätzung und hängt von Herstellersupport, Zertifizierungsanforderungen, PKI-Abhängigkeiten, Firmware- und Hardwarezyklen, Test- und Freigabeprozessen, der Anwendungsarchitektur, der Krypto-Agilität und Abhängigkeiten zu Dritten ab.
3. Z bezeichnet den verbleibenden Zeitraum bis zu einem Zeitpunkt, an dem ein kryptografisch relevanter Quantencomputer verfügbar sein könnte. Z ist eine Schätzung eines Zeitfensters und kein bekannter Countdown.
4. X + Y > Z

Der praktische Wert liegt darin, dass zwei der drei Größen erhebbar und steuerbar sind, auch wenn keine davon exakt bekannt ist: X und Y können Sie aus Ihren Anforderungen und Ihrer Systemlandschaft ableiten, Z nicht. X + Y > Z ist dabei eine Entscheidungsregel und kein Naturgesetz. Aus ihr lässt sich unter Annahmen über Z ein spätester sinnvoller Startzeitpunkt ableiten: erwarteter Bedrohungszeitpunkt minus Migrationsdauer, abzüglich einer Sicherheitsmarge (Quelle: Michele Mosca, Cybersecurity in an Era with Quantum Computers: Will We Be Ready?, IEEE Security & Privacy 16(5), 2018; frei zugänglich als Preprint).

Eine belastbare Bewertung lässt sich in vier aufeinander aufbauende Arbeitsschritte gliedern. Sie sind logisch verzahnt, aber nicht streng sequenziell: Besonders kritische Systeme lassen sich schon vor einem vollständigen Inventar erkennen und vorziehen.

1. Schutzdauer je Datenklasse festlegen. Für jede Klasse von Informationen wird bestimmt, wie viele Jahre Vertraulichkeit oder Authentizität rechtlich, vertraglich oder wirtschaftlich gefordert sind.
2. Kryptografische Abhängigkeiten kartieren. Für jede Datenklasse wird die Kette erfasst, die sie schützt: Anwendung, Protokoll, kryptografischer Mechanismus, Schlüssel oder Zertifikat, Bibliothek oder Hardware-Sicherheitsmodul und die Abhängigkeit zum Hersteller. Das betrifft Übertragung, Speicherung, Authentisierung und Signatur.
3. Migrationsdauer je System schätzen. Die Migrationsdauer hängt neben den eigenen Ressourcen insbesondere von der Änderungsfähigkeit des Systems, der Verfügbarkeit PQC-fähiger Herstellerprodukte, Test- und Freigabeprozessen sowie externen technischen und regulatorischen Abhängigkeiten ab.
4. Gegen die empfohlenen Zieltermine prüfen. Das BSI empfiehlt in seiner Technischen Richtlinie, klassische asymmetrische Verfahren zur Schlüsseleinigung ab Ende 2031 nicht mehr allein einzusetzen, für höchstsensitive Anwendungen ab Ende 2030; für Signaturen nennt es Ende 2035 (Quelle: BSI, Pressemitteilung vom 11.02.2026). Die Roadmap der EU-Mitgliedstaaten sieht die Umstellung der Hochrisiko-Anwendungen spätestens bis Ende 2030 vor (Quelle: EU-Kommission, Post-Quantum Cryptography). Beides sind Empfehlungen und Zieltermine, keine unmittelbar geltenden gesetzlichen Fristen für Unternehmen.

Das Ergebnis ist keine einzelne Risikozahl, sondern eine priorisierte Liste von Systemen mit einem empfohlenen Migrations- bzw. spätesten Starttermin und den dafür maßgeblichen Annahmen. Diese Liste benötigen Vorstand und Aufsicht.

Welche Daten haben eine lange Schutzdauer?

Entscheidend ist nicht eine gesetzliche Aufbewahrungsfrist, sondern wie lange Vertraulichkeit oder Authentizität einer Information rechtlichen oder wirtschaftlichen Wert hat. Gesetzliche Fristen sind dafür ein Indiz. Das Jahr 2035 dient dabei lediglich als Beispiel für einen Planungshorizont. In einem typischen deutschen Industrie- oder Finanzunternehmen finden sich regelmäßig die folgenden Bestände; die Zeitspannen sind Beispielwerte, keine allgemeinen Schutzdauern.

Zwei Kategorien werden dabei meist übersehen.

• Backups und Archive verlängern den Zeitraum, in dem verschlüsselte Daten für einen späteren Entschlüsselungsversuch verfügbar bleiben. Wer Sicherungen bei einem Dienstleister ablegt, sollte deren Aufbewahrungsdauer deshalb in die Bewertung einbeziehen.
• Schlüsselmaterial in Geräten. Ein Ladepunkt, eine Steuerung oder ein Messgerät mit einem Vertrauensanker, der in ROM, OTP-Speicher oder eFuses hinterlegt ist, lässt sich je nach Architektur nicht durch ein Softwareupdate ablösen. Entscheidend ist, ob die Architektur einen PQC-fähigen bzw. alternativen Signatur- und Vertrauenspfad oder einen Austausch des Vertrauensankers vorsieht.

Wie entsteht ein belastbares Krypto-Inventar?

Ein kryptografisches Inventar (englisch: Cryptographic Inventory), oft Krypto-Inventar genannt, ist kein Zertifikatsverzeichnis. Es erfasst für jedes System die Verfahren und Schlüssellängen, die Protokolle und Dienste, die Zertifikate und Vertrauensketten, die beteiligten Anwendungen, Bibliotheken und Hardware-Sicherheitsmodule, die geschützten Daten, die Eigentümerschaft und die Dauer eines Verfahrenswechsels (Quelle: NCCoE, Migration to Post-Quantum Cryptography). Dabei hält es auch die Beziehungen fest: Asset, Anwendung, Protokoll, kryptografischer Mechanismus, Schlüssel oder Zertifikat, Abhängigkeit, Schutzbedarf und Migrationsoption. Das macht die spätere Priorisierung nachvollziehbar.

Praktisch bewährt sich eine Kombination aus vier Quellen, weil keine allein vollständig ist.

• Netzwerkseitige Erfassung. Aktive Scans und passive Beobachtung des TLS- und SSH-Verkehrs zeigen, welche Handshakes tatsächlich zustande kommen. Diese Erfassung kann Schatten-IT sichtbar machen. Ruhende, rein interne oder selten genutzte kryptografische Funktionen erfasst diese Quelle nicht.
• CA-/PKI-Systeme, ACME-Daten, Zertifikatsmanagement und CT-Logs. Interne Zertifizierungsstellen und PKI-Systeme, ACME-Daten, das Zertifikatsmanagement sowie die Logs der Certificate Transparency (CT-Logs) für öffentlich ausgestellte Zertifikate.
• Quellcode und Build-Pipelines. Statische Analyse findet fest verdrahtete Algorithmen, eigene Krypto-Implementierungen und veraltete Bibliotheken, die im Netzverkehr nie sichtbar werden.
• Beschaffungs- und Vertragsunterlagen. Für Systeme, die Sie nicht scannen dürfen oder können, ist die Herstellerauskunft eine wichtige bzw. teilweise einzige realistische Quelle. Diese Auskunft sollte schriftlich und mit Datum erfolgen.

Wie so eine Bestandsaufnahme praktisch abläuft, beschreibt das NCCoE in „Quantum Readiness: Cryptographic Discovery“ (NIST SP 1800-38B). Der Band ist noch Entwurf, die Methodik aber bereits gut nutzbar (Quelle: NCCoE, NIST SP 1800-38). Für die Zielarchitektur kommt NIST CSWP 39 „Considerations for Achieving Crypto Agility“ dazu, zuletzt aktualisiert im Juni 2026 (Quelle: NIST, CSWP 39upd1).

Der Aufwand ist überschaubar, wenn man ihn begrenzt. Als eigene Programmheuristik hat sich bewährt, zunächst die geschäftskritischen Systeme abzudecken und den Rest im laufenden Betrieb nachzuziehen: Ein Inventar, das nach wenigen Monaten den Großteil der kritischen Systeme abbildet, ist für die Priorisierung wertvoller als eines, das nach zwei Jahren vollständig ist. Belegte Branchenwerte gibt es dafür nicht.

Nach welchen Kriterien priorisieren Sie die Migration?

Aus der Kombination ergeben sich drei Wellen, deren Zuordnung im Einzelfall zu prüfen ist. In die erste gehören kurzfristig migrierbare Kommunikationspfade mit langlebigen Inhalten: VPN- und TLS-Verbindungen zu Standorten, Cloud-Anbietern und Dienstleistern sowie Backup- und Archivierungsstrecken. In die zweite gehören zentrale Dienste für PKI, Signatur und Authentisierung. In die dritte gehören schwer migrierbare Systeme, also eingebettete Systeme, OT und alles, was über Hersteller läuft. Die Vorarbeit für die dritte Welle beginnt sofort, weil Herstellerabstimmung, Zertifizierung und Hardwaretausch dort die längsten Vorlaufzeiten haben.

Diese Reihenfolge folgt der Sachlogik der Bedrohung. Bei HNDL-Angriffen ist die heute aufgezeichnete verschlüsselte Kommunikation besonders dann gefährdet, wenn der verwendete Mechanismus zur Schlüsseleinigung später durch einen kryptografisch relevanten Quantencomputer gebrochen werden kann. HNDL steht für Harvest Now, Decrypt Later: Angreifer zeichnen verschlüsselte Daten heute auf und versuchen, sie später zu entschlüsseln. Bei Signaturen wirkt das Risiko anders: Eine Fälschung setzt einen kryptografisch relevanten Quantencomputer voraus. Bei langlebigen signierten Artefakten zählt allerdings, ob ihre Authentizität auch nach Eintritt der Quantenbedrohung noch zuverlässig überprüfbar ist.

Wie sieht ein realistischer Fahrplan bis 2031 aus?

In den ersten beiden Jahren überwiegen Bestandsaufnahme, Tests und Konfigurationsarbeit, und zwar parallel: Inventar, Risikobewertung und Piloten im ersten Jahr, erste produktive Migration und Krypto-Agilität im zweiten. Die aufwändigeren Positionen kommen danach: die Erneuerung von Feldgeräten, die Anpassung eigener Anwendungen und je nach Hersteller ein Firmware-Upgrade oder ein Austausch von Hardware-Sicherheitsmodulen.

Welche Fehler kosten am meisten Zeit?

• Auf noch fehlende Standards warten. FIPS 206 für FN-DSA ist der geplante Signaturstandard, HQC ein zusätzlicher KEM. Den Entwurf von FIPS 206 bezeichnete NIST im September 2025 als „basically written“, er wartete auf Freigabe (Quelle: NIST, FIPS 206 Status Update); final ist FIPS 206 auch im Oktober 2026 nicht (Quelle: NIST, Post-Quantum Cryptography News). HQC wurde am 11. März 2025 zur Standardisierung ausgewählt; NIST kündigte einen öffentlichen Entwurf in etwa einem Jahr und die Finalisierung für 2027 an, also etwa zwei Jahre nach der Auswahl. Der Entwurf lag bis Oktober 2026 nicht vor (Quellen: NIST, Auswahl von HQC; NIST, Post-Quantum Cryptography News). ML-KEM, ML-DSA und SLH-DSA sind dagegen seit August 2024 standardisiert (Quellen: FIPS 203; FIPS 204; FIPS 205). Wer die gesamte Migration an die ausstehenden Standards koppelt, wird die Migration unnötig verzögern, obwohl die Schlüsseleinigung bereits umstellbar ist.
• Das Inventar an ein einzelnes Werkzeug delegieren. Kein einzelnes Discovery-Verfahren erfasst alle kryptografischen Abhängigkeiten: Verträge, Speicherabbilder von Feldgeräten und selten laufende Anwendungen bleiben außen vor. Deshalb ist ein mehrschichtiger Ansatz aus Netzbeobachtung, Code- und Konfigurationsanalyse, PKI-Daten und Herstellerauskünften nötig.
• Krypto-Agilität als Produkt kaufen. Produkte können Agilität unterstützen, ersetzen aber keine Entscheidungen zu Architektur, Prozessen und Zuständigkeiten: zentrale Krypto-Bibliotheken, konfigurierbare Verfahren, automatisierte Zertifikatserneuerung.
• Die Zertifikatslaufzeiten übersehen. Das CA/Browser Forum hat mit Ballot SC-081v3 (Abstimmung bis 11. April 2025) beschlossen, die maximale Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Serverzertifikate schrittweise zu senken: 200 Tage seit 15. März 2026, 100 Tage ab 15. März 2027, 47 Tage ab 15. März 2029 (Quelle: CA/Browser Forum, Ballot SC-081v3).
• Dienstleister und Tochtergesellschaften ausklammern. Externe Abhängigkeiten müssen in die PQC-Risikoanalyse und Migrationsplanung einbezogen werden; für regulierte Unternehmen kommen dafür zusätzlich konkrete Anforderungen an Lieferketten- bzw. IKT-Drittparteirisiken hinzu. Das sind die Sicherheit der Lieferkette nach § 30 Absatz 2 Nummer 4 BSIG für besonders wichtige und wichtige Einrichtungen und das Management des IKT-Drittparteienrisikos nach DORA für die erfassten Finanzunternehmen (Quellen: § 30 BSIG; DORA, Verordnung (EU) 2022/2554). Eine unmittelbare Pflicht, heute PQC einzusetzen, folgt daraus nicht. Die Abhängigkeiten der Lieferkette laufen am besten als eigene Discovery-/Abhängigkeitsspur parallel zu den technischen Wellen.

Woran messen Sie den Fortschritt?

• Abdeckungsgrad des Inventars. Anteil der geschäftskritischen Systeme im definierten Betrachtungsbereich mit erfasster Kryptografie. Zielwert 100 Prozent dieses Bereichs bis Ende 2026.
• Anteil hybrid geschützter Verbindungen. Anteil der TLS- und SSH-Sitzungen mit post-quantensicherem Schlüsselaustausch. Als externe Referenz lassen sich die Cloudflare-Werte heranziehen, die allerdings zwei verschiedene Messgrößen sind und sich nicht zu einer gemeinsamen Quote verrechnen lassen: Beim menschlich erzeugten Datenverkehr lag der Anteil im April 2026 bei über 65 Prozent (Quelle: Cloudflare, Post-Quantum Roadmap), bei den Origin-Servern im Februar 2026 bei etwa 10 Prozent (Quelle: Cloudflare Blog, 27.02.2026) und im September 2026 bei über 12 Prozent (Quelle: Cloudflare, Automatic key exchange for origins).
• Automatisierungsgrad der Zertifikate. Anteil der Zertifikate, die ohne manuellen Eingriff erneuert werden, und darüber hinaus der Reifegrad des Zertifikatsbetriebs: vollständige Inventarisierung, automatische Ausstellung und Erneuerung, Ablaufüberwachung, automatisierter Rollout, Rollback sowie ein Algorithmus- und Schlüsselwechsel ohne manuelle Änderungen. Diese Kennzahl entscheidet über die Machbarkeit ab 2027.
• Herstellerdeckung. Anteil der kritischen Herstellerabhängigkeiten mit dokumentierter PQC-Unterstützung, verbindlichem Upgradepfad und geplantem Verfügbarkeitsdatum.

Fazit: Die Bewertung ist der günstigste Teil des Programms

Eine belastbare Quantenrisikobewertung lässt sich für einen priorisierten Scope oft innerhalb von Wochen aufbauen; die anschließende Migration kann sich dagegen über mehrere Jahre erstrecken. Wer die Bewertung überspringt, verteilt dieselbe Arbeit ungeordnet über den gesamten Zeitraum und verliert die Möglichkeit zu priorisieren. Vollständig abgeschlossen sein muss sie dafür nicht: Kritische Systeme inventarisieren, Risiken bewerten, erste hybride Migrationen durchführen und das Inventar parallel vervollständigen ist der praktikable Weg.

Die regulatorische Lage gibt der Aufgabe einen Rahmen. Nach der Roadmap der EU-Mitgliedstaaten sollen bis Ende 2026 die Umstellung beginnen und erste Inventare entstehen, bis Ende 2030 die Hochrisiko-Anwendungen migriert sein (Quellen: EU-Kommission, Roadmap; EU-Kommission, Post-Quantum Cryptography). Ab Ende 2031 sollen klassische asymmetrische Verfahren zur Schlüsseleinigung nach BSI-Empfehlung nicht mehr allein eingesetzt werden (Quelle: BSI, Pressemitteilung vom 11.02.2026). Diese drei Eckdaten liefern einen belastbaren äußeren Zeitrahmen für die Programmplanung. Die Priorisierung innerhalb dieses Rahmens ergibt sich aus Schutzdauer, Exponierung, Abhängigkeiten, Migrationsdauer, Hersteller-Fahrplänen, Systemkritikalität und technischer Änderbarkeit.

Wie können die nächsten Schritte aussehen?

1. Fünf Datenklassen bewerten. Nehmen Sie die fünf wichtigsten Datenklassen. Deren Schutzdauer in Jahren können Sie gemeinsam mit Recht und Fachbereich für einen ersten priorisierten Scope in einem halbtägigen Workshop abschätzen. Eine vollständige juristische Datenklassifizierung ist das noch nicht.
2. Ein Pilotinventar erstellen. Wählen Sie einen abgegrenzten Bereich, etwa das Rechenzentrum oder die Außenanbindung, und erfassen Sie diesen Bereich vollständig. Der Pilot liefert die Aufwandsschätzung für den Rest.
3. Herstellerabfrage versenden. Eine standardisierte Anfrage an die wichtigsten Lieferanten der priorisierten Systeme. Gefragt sind PQC-Algorithmen und Parametersätze, betroffene Produktkomponente, Protokoll oder Schnittstelle, Hybridunterstützung, Version und Verfügbarkeitsdatum, Firmware- und Hardwareabhängigkeiten sowie der Supportzeitraum.
4. Krypto-Richtlinie prüfen. Die Durchführungsverordnung (EU) 2024/2690 zu NIS2 konkretisiert die Anforderungen für bestimmte Kategorien, darunter Anbieter von DNS-Diensten, TLD-Namenregister, Cloud-, Rechenzentrums- und CDN-Dienste, Managed Service Provider und Managed Security Service Provider, Online-Marktplätze, Suchmaschinen, Plattformen sozialer Netzwerke und Vertrauensdiensteanbieter. Verlangt wird in Abschnitt 9 eine Kryptografie-Richtlinie mit Festlegungen zu kryptografischen Maßnahmen, Protokollen, Algorithmen und Schlüsselmanagementverfahren, die gegebenenfalls einem Ansatz der Krypto-Agilität folgt und regelmäßig überprüft wird (Quelle: Durchführungsverordnung (EU) 2024/2690). Fehlt das in Ihrer Richtlinie, ist das eine dokumentierte Lücke.
5. Erste Welle starten. Den hybriden Schlüsselaustausch dort, wo Sie beide Seiten kontrollieren, zunächst pilotieren und anschließend produktiv ausrollen. Details dazu im Beitrag zur Umsetzung der NIST-PQC-Standards in Unternehmensnetzwerken.
   
    

Weiterführende Informationen finden Sie in nachfolgenden Artikeln: Quantum Computing & Post-Quantum Security im Überblick und Einführung in Post-Quantum-Cryptography. Orange Cyberdefense unterstützt Risikobewertung und Inventarisierung im Rahmen des Post-Quantum-Cryptography-Transformation-Service.