Post-Quanten-Kryptografie: Mit dem Krypto-Inventar jetzt anfangen

Ein Quantencomputer, der RSA-2048 knackt, existiert heute nicht. Trotzdem lohnt sich die Beschäftigung damit schon jetzt, weil verschlüsselte Daten heute mitgeschnitten und später gelesen werden können und weil die Umstellung bei den meisten Unternehmen Jahre dauert. Dieser Artikel zeigt, was Standards und Fahrpläne sagen, wie du ohne Panik ein Krypto-Inventar aufbaust und wie ein Zwölf-Monats-Plan für ein Unternehmen mit rund 100 Mitarbeitenden aussieht.

Was ist "Harvest now, decrypt later" und warum betrifft es dich schon heute?

Bei "Harvest now, decrypt later" (auf Deutsch etwa: jetzt einsammeln, später entschlüsseln) zeichnet ein Angreifer verschlüsselten Datenverkehr oder gestohlene verschlüsselte Backups heute auf und wartet, bis er sie entschlüsseln kann. Er muss dafür keine Schwachstelle ausnutzen, sondern nur Zugriff auf die verschlüsselten Daten haben und genug Speicherplatz. Das BSI beschreibt genau diese Bedrohung ("store now, decrypt later") als Gefahr für die Langzeitsicherheit.

Ob das für dich relevant ist, hängt von einer einfachen Überlegung ab, die als Mosca-Ungleichung bekannt ist: Du addierst die Zeit, die deine Daten vertraulich bleiben müssen (X), und die Zeit, die deine Migration dauert (Y). Ist die Summe größer als die Zeit, bis ein leistungsfähiger Quantencomputer existiert (Z), hast du ein Problem. Z kennt niemand seriös. X und Y kennst du dagegen selbst.

Ein Rechenbeispiel: Ein Maschinenbauer mit 100 Mitarbeitenden speichert Konstruktionszeichnungen, die 15 Jahre vertraulich bleiben sollen. Die Migration seiner Systeme dauert realistisch fünf Jahre. Die Daten müssen also 20 Jahre halten, und jede Übertragung, die heute mit klassischem Schlüsselaustausch läuft, kann in dieser Zeit mitgeschnitten worden sein. Eine Speiseplan-Mail der Kantine dagegen ist nach einer Woche wertlos.

Was bricht ein Quantencomputer, und was nicht?

Zwei Algorithmen bestimmen die Diskussion. Shors Algorithmus löst Faktorisierung und diskreten Logarithmus effizient. Damit fallen RSA, Diffie-Hellman (DH) und die Verfahren auf elliptischen Kurven (ECC, ECDH, ECDSA, Ed25519). Grovers Algorithmus beschleunigt die Suche in unsortierten Datenmengen und halbiert damit rechnerisch die effektive Schlüssellänge symmetrischer Verfahren. AES-256 behält dadurch ein Sicherheitsniveau von rund 128 Bit und bleibt nutzbar. Hashfunktionen wie SHA-256 und SHA-3 sind ebenfalls kaum betroffen.

Das Problem sitzt also nicht in deiner Festplattenverschlüsselung oder deinen AES-256-Backups, sondern an den Stellen, an denen Schlüssel ausgehandelt oder Identitäten bestätigt werden. Genau dort verwenden fast alle Protokolle RSA, DH oder ECC.

Warum Signaturen später dran sind als der Schlüsselaustausch

Beim Schlüsselaustausch schlägt "Harvest now, decrypt later" sofort zu, weil der Mitschnitt von heute später lesbar wird. Bei Signaturen funktioniert das nicht: Ein Angreifer kann eine heutige Signatur nicht rückwirkend fälschen, er kann erst fälschen, wenn er den Quantencomputer hat. Deshalb setzen Fahrpläne den Schlüsselaustausch früher an als die Signaturen. Ausnahme sind Signaturen, die sehr lange gelten sollen: Firmware-Signaturen für Geräte mit 15 Jahren Lebensdauer, archivierte Verträge und Wurzelzertifikate einer privaten PKI.

Was sagen NIST, BSI und EU zur Post-Quanten-Migration?

Es gibt keinen einzelnen Stichtag, sondern mehrere Fahrpläne, die sich ergänzen. Die folgende Tabelle zeigt den Stand im Oktober 2026.

Eine Zahl solltest du dir merken: Bei höchstsensiblen Daten sind es nach BSI-Lesart noch gut vier Jahre bis Ende 2030. Bei einer Migration, die Zertifikate, Hardware und Lieferanten betrifft, ist das knapp.

Gibt es eine gesetzliche Pflicht zum Krypto-Inventar?

Uns ist keine gesetzliche Frist bekannt, nach der ein Unternehmen bis zu einem bestimmten Tag ein Krypto-Inventar vorlegen muss. Anbieter-Blogs behaupten gelegentlich, NIS2-Betreiber müssten bis Dezember 2025 ein Inventar haben. Eine Quelle dafür haben wir nicht gefunden, und im Richtlinientext steht es nicht. Was NIS2 verlangt, ist allgemeiner: Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung gehören zu den Mindestmaßnahmen (Artikel 21 Absatz 2 Buchstabe h der NIS2-Richtlinie). Wer ein Konzept nachweisen will, das den Stand der Technik berücksichtigt, kommt an den Empfehlungen der BSI-Richtlinie kaum vorbei. Das ist keine Rechtsberatung, klär Zweifelsfälle mit deiner Rechtsabteilung oder Kanzlei.

Welche Verfahren sind betroffen und was ersetzt sie?

Die Tabelle zeigt die Verfahren, die in deiner IT mit hoher Wahrscheinlichkeit vorkommen, ihr Quanten-Risiko und den vorgesehenen Ersatz.

Die Größe der Daten ändert sich spürbar. Ein ML-KEM-768-Schlüssel ist rund 1,2 KB groß, eine ML-DSA-65-Signatur rund 3,3 KB, eine Ed25519-Signatur dagegen 64 Bytes. Das spielt bei Embedded-Geräten mit knappem Speicher und bei Protokollen mit festen Paketgrößen eine Rolle, und es ist ein Grund, warum eine Umstellung nicht über Nacht per Schalter geht.

Warum ist das Krypto-Inventar der erste Schritt?

Du kannst nur umstellen, was du findest. Die meisten mittelständischen Unternehmen wissen, wie viele Server sie haben, aber nicht, wo überall RSA oder ECC steckt: in Zertifikaten, in Konfigurationsdateien, in Bibliotheken, in Firmware von Geräten, bei Dienstleistern. Ein Krypto-Inventar ist die strukturierte Liste dieser Stellen. Die EU empfiehlt es im Fahrplan als einen der ersten Schritte, und der Netzwoche-Autor spricht von einem "Inventarproblem" statt von einem Kryptoproblem.

Dein bestehendes Asset-Inventar ist die Grundlage, aber nicht das Inventar selbst. Es beantwortet "Welche Systeme haben wir?", das Krypto-Inventar fragt "Welche Verfahren nutzt jedes System, wofür, mit welcher Schlüssellänge und wer pflegt das?".

Wo stecken RSA, ECC und DH in einem typischen Unternehmen?

Gehe diese Orte systematisch durch. Die Liste deckt für ein Unternehmen mit 100 Mitarbeitenden den größten Teil ab:

• TLS an Webservern, Load Balancern und Reverse Proxys: Zertifikate (meist RSA oder ECDSA) und der Schlüsselaustausch (ECDHE).
• VPN und Fernzugriff: IPsec/IKEv2, OpenVPN, WireGuard, SSL-VPN der Firewall. Beim VPN steckt der Schlüsselaustausch in der Konfiguration, oft mit Voreinstellungen, die niemand angeschaut hat.
• SSH: Host- und Benutzerschlüssel (RSA, Ed25519), Schlüsselaustausch der Server.
• Zertifikate und interne PKI: Wurzel- und Zwischenzertifikate, Zertifikate für Clients, WLAN (802.1X), Smartcards, Mail (S/MIME).
• Code-Signing und Software-Updates: Signaturen für eigene Software, Treiber, Skripte, Installationspakete.
• E-Mail-Transport und -Verschlüsselung: STARTTLS zwischen Mailservern, S/MIME, PGP.
• Backups und Archive: Hybridverschlüsselung der Backup-Schlüssel (oft RSA), langfristig archivierte Dokumente, signierte PDFs.
• Identität und Single Sign-on: SAML- und OIDC-Signaturschlüssel, JWT-Signaturen, Kerberos.
• IoT und OT: Maschinensteuerungen, Gebäudetechnik, Kameras, Messgeräte. Dort steckt Kryptografie oft in Firmware, die sich nicht oder nur mit großem Aufwand austauschen lässt.
• SaaS und Cloud: Microsoft 365, ERP im Hosting, CRM, Zahlungsdienste. Die Kryptografie liegt beim Anbieter, aber die Verbindung zu dir ist deine Verantwortung.
• Eigene Software und Bibliotheken: Alles, was selbst entwickelt wird und OpenSSL, Bouncy Castle oder System-APIs aufruft.

Wie erhebst du das Inventar, ohne ein Großprojekt zu starten?

Kombiniere vier Quellen, statt auf ein Werkzeug zu hoffen:

1. Netzwerk- und Endpunktscans. TLS-Scanner wie sslyze, testssl.sh oder die Funktionen deiner Schwachstellen-Scanner zeigen Protokollversionen, Cipher Suites und Zertifikate aller erreichbaren Dienste.
2. Zertifikatsquellen. Certificate-Transparency-Logs für öffentliche Domains, die Zertifikatsverwaltung deiner internen CA, Exporte aus Load Balancern und Firewalls.
3. Konfiguration und Quellcode. Suche in Konfigurationsmanagement, Skripten und Repositories nach Algorithmen und Bibliotheken. Bei eigener Software hilft ein Build-Scan.
4. Befragung. Fachverantwortliche und Dienstleister wissen, welche Geräte und Verfahren im Einsatz sind, die kein Scanner sieht.

Für das Format hat sich die Cryptographic Bill of Materials (CBOM) etabliert. Sie erweitert das Prinzip der Software-Stückliste auf Kryptografie und ist seit Version 1.6 Teil von CycloneDX, das als ECMA-424 standardisiert ist. Wenn du ohnehin eine SBOM nach dem Cyber Resilience Act erstellst, ist das ein sinnvoller Einstieg. Für den Mittelstand reicht anfangs auch eine Tabelle, solange sie die Felder enthält, die du für Entscheidungen brauchst.

Was gehört in einen Eintrag des Krypto-Inventars?

In ISMS Lite kannst du Systeme und Dienstleister samt Eigentümer, Schutzbedarf und Abhängigkeiten als Assets pflegen. Die eingesetzten Verfahren kannst du in den technischen Angaben des Assets festhalten. So bleibt die Kryptografie nicht in einer separaten Tabelle liegen, die nach drei Monaten veraltet ist.

Wie priorisierst du nach Schutzdauer und Schutzbedarf?

Nach dem Inventar hast du meist mehr Fundstellen, als du in einem Jahr umstellen kannst. Priorisiere deshalb nach zwei Fragen: Wie lange müssen die Daten vertraulich bleiben (Schutzdauer), und wie hoch ist ihr Schutzbedarf? Das passt zur Risikobewertung im ISMS, die du ohnehin führst.

Der zweite Blick gilt Daten, die außerhalb deiner Kontrolle liegen. Backups bei einem Dienstleister, Mails an Kunden und Daten bei Cloud-Anbietern können von Dritten mitgeschnitten werden. Hier hast du die Wahl zwischen eigener Umstellung und Druck auf den Lieferanten.

Was bedeutet Krypto-Agilität und warum brauchst du sie?

Krypto-Agilität heißt, dass du Algorithmen, Schlüssellängen und Zertifikate austauschen kannst, ohne die Anwendung neu zu bauen. Das klingt nach Theorie, ist aber längst Alltag: Die Laufzeit öffentlicher TLS-Zertifikate sinkt nach dem Beschluss des CA/Browser Forums von 398 Tagen auf 200 Tage seit dem 15. März 2026, auf 100 Tage ab dem 15. März 2027 und auf 47 Tage ab dem 15. März 2029. Wer Zertifikate heute noch von Hand erneuert, bekommt das spätestens 2027 zu spüren. Das gilt für öffentlich vertrauenswürdige Zertifikate, nicht für deine interne PKI, aber die Lehre ist dieselbe.

Die gleiche Automatisierung, die kurze Zertifikatslaufzeiten beherrschbar macht, hilft bei der Post-Quanten-Migration. Wie schmerzhaft es wird, wenn niemand weiß, wo ein Zertifikat steckt, zeigen auch die ablaufenden Secure-Boot-Zertifikate. Praktische Bausteine für Krypto-Agilität:

• Algorithmen konfigurierbar halten. Keine fest verdrahteten Verfahren in eigener Software, sondern Konfiguration oder zentrale Bibliotheken.
• Zertifikate automatisieren. ACME für öffentliche Zertifikate, eine interne CA mit Automatisierung für den Rest. Ein Secrets-Management hilft bei der Verwaltung von Schlüsseln und Zertifikaten.
• Abstraktionsschichten nutzen. Eine zentrale TLS-Terminierung (Reverse Proxy, Load Balancer) ist leichter umzustellen als 40 einzelne Dienste.
• Lieferantenverträge anpassen. Verlange Update-Zusagen für kryptografische Verfahren, nicht nur für Sicherheitslücken.
• Aktuell bleiben. Eine neue Bibliotheksversion bringt Post-Quanten-Unterstützung oft ohne eigenen Aufwand mit.

Was sind hybride Verfahren und was kannst du heute schon nutzen?

Ein hybrides Verfahren kombiniert ein klassisches mit einem Post-Quanten-Verfahren, sodass die Verbindung sicher bleibt, solange mindestens eines der beiden hält. Das BSI empfiehlt Post-Quanten-Verfahren ausdrücklich möglichst nur in Kombination mit klassischen Verfahren. Der Grund: ML-KEM und seine Verwandten sind jünger und weniger lang untersucht als RSA und ECC. Eine Hybridlösung fängt einen möglichen Fehler im neuen Verfahren ab.

Für den Schlüsselaustausch gibt es bereits einsatzfähige Lösungen:

• TLS 1.3: X25519MLKEM768 ist in Chrome und Firefox seit Ende 2024 voreingestellt, und OpenSSL 3.5 (April 2025) nutzt es standardmäßig. Damit läuft ein Teil des Webverkehrs bereits hybrid, ohne dass jemand etwas getan hat. Das schützt allerdings nur den Schlüsselaustausch, die Zertifikate bleiben klassisch signiert.
• SSH: OpenSSH 10.0 (April 2025) verwendet mlkem768x25519-sha256 standardmäßig.
• VPN: Bei IPsec kann IKEv2 nach RFC 9370 mehrere Schlüsselaustausche kombinieren. Bei WireGuard lässt sich der optionale symmetrische Pre-Shared-Key als Übergangsschutz einsetzen, wenn du ihn sicher verteilst. Welche Produkte das unterstützen, musst du beim Hersteller erfragen.
• Signaturen: Hier ist die Lage weniger weit. Für Firmware sind LMS und XMSS bereits standardisiert, für Zertifikate und Code-Signing hängt es von Herstellern, Browsern und Zertifizierungsstellen ab.

Der einfachste Pilot für ein Unternehmen mit 100 Mitarbeitenden: einen Reverse Proxy mit OpenSSL 3.5 oder neuer in einer Testumgebung aufsetzen, hybriden Schlüsselaustausch aktivieren und mit aktuellen Browsern testen. Prüfe dabei, ob Middleboxen wie Firewalls und Inspektionssysteme die größeren Handshake-Pakete akzeptieren. Das ist die häufigste Fehlerquelle.

TLS 1.2 kann keinen hybriden Austausch. Wenn du noch Dienste mit TLS 1.2 betreibst, ist die Umstellung auf TLS 1.3 daher die Voraussetzung.

Wie fragst du Lieferanten und Dienstleister ab?

Ein großer Teil deiner Kryptografie liegt nicht in deiner Hand: bei Herstellern von Firewalls, ERP-Anbietern, Cloud-Diensten und Wartungsfirmen. Diese Abhängigkeit gehört in dein Lieferantenmanagement. Ergänze deinen Sicherheitsfragebogen für Lieferanten um wenige, konkrete Fragen:

1. Welche asymmetrischen Verfahren (RSA, ECC, DH) setzt das Produkt oder der Dienst ein, und wofür?
2. Gibt es eine Roadmap für Post-Quanten-Verfahren (ML-KEM, ML-DSA, SLH-DSA), und bis wann ist sie umgesetzt?
3. Unterstützt das Produkt hybriden Schlüsselaustausch (z. B. X25519MLKEM768)?
4. Lässt sich die Kryptografie per Update austauschen, oder ist sie in Hardware oder Firmware fest verbaut?
5. Wie lange gibt es Sicherheitsupdates für das Produkt?
6. Sind die Daten, die bei euch liegen, mit Verfahren geschützt, die ihren Wert über 10 Jahre halten?
7. Gibt es eine CBOM oder eine vergleichbare Auskunft über die verwendete Kryptografie?

Bei Cloud-Anbietern sind Prüfberichte nach BSI C5:2026 ein guter Ansatzpunkt für Aussagen zu Kryptografie und Schlüsselmanagement. Die Frage nach dem Post-Quanten-Fahrplan beantworten sie nicht von selbst, also frag nach. Verlass dich nicht auf die Aussage "Wir verschlüsseln alles": Der Anbieter beantwortet damit meist die Frage nach AES, nicht die nach dem Schlüsselaustausch.

Die Antworten gehören ins Inventar. Dienstleister mit unbefriedigender Antwort bekommen eine Frist und ein Wiedervorlagedatum, bei kritischen Diensten eine Eskalation im Vertragsgespräch.

Wie sieht der Zwölf-Monats-Plan für ein Unternehmen mit 100 Mitarbeitenden aus?

Der Plan startet im November 2026, passt damit zum EU-Meilenstein "bis Ende 2026 beginnen" und rechnet mit einer kleinen IT-Abteilung ohne eigenes Krypto-Team. Der Aufwand ist eine Planungsannahme, kein Messwert, und hängt stark davon ab, wie viele Altsysteme du hast.

Wichtig an diesem Plan ist, was er nicht enthält: kein flächendeckender Austausch im ersten Jahr. Der Plan sichert die Grundlage, damit der Austausch in den Jahren 2 bis 4 planbar wird. Wer jetzt anfängt, hat bis Ende 2030 noch vier Jahre Zeit, die Priorität-1-Systeme umzustellen.

Wie dokumentierst du Post-Quanten-Kryptografie im ISMS?

Auditoren fragen nicht nach Quantencomputern, sondern nach einem nachvollziehbaren Umgang mit Risiken. Dafür reicht eine saubere Kette von Dokumenten:

• Richtlinie: Die Regeln zu Algorithmen und Schlüsseln stehen in deiner Kryptografie-Richtlinie. Ergänze einen Abschnitt, der den Umgang mit Post-Quanten-Verfahren und die Quellen (BSI TR-02102, NIST) benennt.
• Inventar: Das Krypto-Inventar mit Datum und Version belegt, dass du weißt, wo Kryptografie steckt.
• Risikobewertung: Das Quanten-Risiko für Langzeitdaten gehört als eigenes Risiko ins Risikoregister, mit Eintrittswahrscheinlichkeit, Schutzdauer und Risikoeigner.
• Maßnahmen: Inventar, Lieferantenabfrage, Pilot und Umstellung der Priorität-1-Systeme werden als Maßnahmen mit Verantwortlichen und Terminen geführt.
• Entscheidungen: Akzeptierst du ein Risiko, etwa weil ein Altsystem nicht umstellbar ist, hältst du Begründung und Wiedervorlage fest.
• Management Review: Der Stand der Migration gehört als fester Punkt in den jährlichen Bericht an die Leitung.

Das passt zu den Anforderungen der Norm an Kryptografie (ISO 27001 Annex A, Control 8.24). In ISMS Lite legst du Risiko, Maßnahmen und Fristen an und verknüpfst sie mit den betroffenen Assets und Dienstleistern. Welche Felder du für die Kryptografie pflegst, entscheidest du selbst.

Checkliste: Krypto-Inventar in 4 Wochen

Woche 1: Vorbereitung und Umfang

• Verantwortliche Person benennen (meist IT-Leitung oder ISB)
• Geltungsbereich festlegen: Standorte, Cloud-Dienste, OT, eigene Software
• Bestehendes Asset-Inventar und Dienstleisterliste als Ausgangsbasis exportieren
• Vorlage für Inventar-Einträge festlegen (Felder siehe Tabelle oben)
• Ansprechpartner in Fachabteilungen, bei OT und bei Dienstleistern benennen

Woche 2: Technische Erhebung

• TLS-Scan aller extern und intern erreichbaren Dienste
• Zertifikatsbestand erfassen: öffentliche Zertifikate (inklusive Certificate-Transparency-Suche) und interne CA
• VPN-Konfigurationen und SSH-Server auswerten (Schlüsselaustausch, Schlüsseltypen)
• Code-Signing-Zertifikate und Signaturschlüssel erfassen
• Backup-Software und Archive prüfen: Verfahren, Schlüsselablage, Aufbewahrungsdauer

Woche 3: Befragung und Lücken

• IoT-, OT- und Gebäudetechnik-Geräte mit Firmware-Stand und Herstellerangaben auflisten
• SaaS- und Cloud-Dienste auflisten und nach genutzter Kryptografie fragen
• Eigene Software und Bibliotheken auf Kryptografie-Aufrufe prüfen
• Lieferanten mit den sieben Fragen anschreiben
• Offene Punkte kennzeichnen: "unbekannt" ist ein gültiger Eintrag, solange ein Verantwortlicher und ein Termin dabeistehen

Woche 4: Bewertung und Ablage

• Jeden Eintrag nach Schutzdauer und Schutzbedarf einstufen
• Die Top-10-Fundstellen für die Priorität-1-Liste bestimmen
• Risiko im Risikoregister anlegen, Maßnahmen und Termine ableiten
• Ergebnis der Leitung vorstellen und Entscheidung dokumentieren
• Nächste Aktualisierung terminieren (mindestens halbjährlich)

Häufige Fehler bei der Post-Quanten-Vorbereitung

Warten, bis der Quantencomputer da ist. Wegen "Harvest now, decrypt later" ist der Zeitpunkt, an dem die Daten abgegriffen werden, das Problem, nicht der Zeitpunkt, an dem sie entschlüsselt werden. Bei langlebigen Daten bist du schon im Rennen.

Das Inventar nur aus dem Netzwerk-Scan bauen. Ein Scan sieht TLS-Endpunkte, aber keine Firmware, keine signierten Archive, keine Dienstleisterverbindungen und keinen Code. Ohne Befragung und Konfigurationsauswertung bleibt das Inventar lückenhaft, und die Lücken liegen oft in den kritischen Bereichen.

Alles gleichzeitig umstellen wollen. Wer jede Fundstelle migrieren will, scheitert an Budget und Personal. Priorisiere nach Schutzdauer und Schutzbedarf, und fang bei den Verbindungen an, die langlebige Daten transportieren.

Auf reine Post-Quanten-Verfahren setzen. Das BSI empfiehlt hybride Verfahren, weil ML-KEM und andere neue Verfahren noch jung sind. Ein Austausch ohne klassischen Anteil nimmt dir die Absicherung, falls ein Verfahren Schwächen zeigt.

Die Lieferanten vergessen. Firewall, ERP und Cloud-Dienste enthalten den größten Teil deiner Kryptografie. Wer nur eigene Systeme betrachtet, hat ein halbes Inventar und kann Risiken nicht beurteilen.

Fazit: Anfangen heißt zuerst zählen

Du musst jetzt nicht dein gesamtes Netzwerk umbauen. Du musst wissen, wo RSA, ECC und DH in deinem Unternehmen stecken, welche Daten dort lange vertraulich bleiben sollen und wann deine Lieferanten umstellen. Starte noch in diesem Monat mit den vier Wochen für das Inventar und leg das Ergebnis der Leitung vor, am besten dort, wo auch deine Risiken, Maßnahmen und Dienstleister mit ISMS Lite liegen.

Weiterführende Artikel

• Kryptografie-Richtlinie erstellen: Algorithmen, Schlüssellängen und Lifecycle
• Verschlüsselung im Unternehmen: Was, wo und wie verschlüsseln
• Verschlüsselung von ISMS-Daten: At Rest, In Transit und im Backup
• ISO 27001 A.8.24-8.34: Kryptografie, Entwicklung und Änderungsmanagement
• Secrets Management: Passwörter, API-Keys und Zertifikate sicher verwalten