Sie fordern Quantensicherheit von Lieferanten. Kennen Sie Ihre eigenen kryptografischen Abhängigkeiten?

Ausgabe 04 der Reihe „Post-Quanten-Sicherheit in der deutsch-slowenischen Lieferkette“. Für Enterprise-Architektur, IT-Governance und die Verantwortlichen für Lieferantenanforderungen.

Ein Fragebogen geht an zweihundert Lieferanten. Frage 14: „Setzen Sie quantensichere Verfahren ein?“ Die Antworten kommen zurück, und niemand im Haus kann sie bewerten. Denn niemand weiß, welche Verfahren auf der eigenen Seite der Verbindungen laufen, um die es geht.

Worum es geht: warum ein Auftraggeber zuerst seine eigenen kryptografischen Abhängigkeiten kennen muss, bevor er von Lieferanten etwas verlangt, und wie ein erstes Register entsteht. Was dieser Beitrag nicht behandelt: Werkzeuge zur automatischen Erkennung im Detail und das Format eines vollständigen Kryptoinventars (CBOM). Beides folgt im März 2026.

In diesem Beitrag: Warum die eigene Seite zuerst · Wo Kryptografie steckt · Wer verantwortlich ist · Beispiel · Was ein Register verändert · Drei Missverständnisse · Vier Quellen · Die Frage an Ihren Lieferanten · Anhang: Register

Jede Verbindung zu einem Lieferanten hat zwei Enden, und Sie betreiben eines davon. Ein Schlüsselaustausch ist so stark wie das, worauf sich beide Seiten einigen. Eine Signatur ist so viel wert wie die Prüfung, die der Empfänger durchführt. Wer vom Lieferanten Post-Quanten-Verfahren verlangt, aber auf dem eigenen Gateway nur klassische anbietet, bekommt im besten Fall eine teure Zusage, die technisch nie zur Anwendung kommt.

Dazu kommt ein zweiter, weniger offensichtlicher Grund: Ohne eigenes Register können Sie Antworten nicht prüfen. Ein Lieferant schreibt „TLS 1.3, hybrider Schlüsselaustausch vorgesehen“. Stimmt das für die Verbindung zu Ihnen? Das wissen Sie nur, wenn Sie wissen, was Ihr Endpunkt aushandelt.

Die Erwartung, das eigene Inventar zu kennen, ist nicht neu. Der IT-Grundschutz des BSI fordert seit Jahren im Baustein CON.1 (Kryptokonzept) ein Krypto-Kataster. Die EU-Roadmap zur Post-Quanten-Kryptografie vom Juni 2025 nennt „mature cryptographic asset management“ als ersten unverzichtbaren Schritt für jede Organisation und empfiehlt dafür ein standardisiertes Format wie CBOM, die kryptografische Erweiterung der Software-Stückliste. Sie nennt das ausdrücklich einen „no-regret move“: Ein Inventar hilft beim Schwachstellen- und Incident-Management auch ohne Quantencomputer.

Die häufigste falsche Annahme lautet: Kryptografie, das ist die Verschlüsselung von Verbindungen, und die macht die Firewall. Tatsächlich steckt Public-Key-Kryptografie an vielen Stellen, die niemand so nennt:

• Verbindungen: TLS auf Webservern, Lastverteilern, APIs, Mailservern; VPN (IPsec/IKEv2, SSL-VPN); SSH und SFTP; Datenbankverbindungen.
• Identität und Vertrauen: interne Zertifizierungsstellen, Active-Directory-Zertifikatsdienste, Smartcards und Token, WLAN mit Zertifikatsanmeldung, Single Sign-on mit signierten Token.
• Signaturen: Codesignatur eigener Software, Signatur von Firmware-Updates, digital signierte Dokumente und Rechnungen, Lizenzdateien, die eine Software beim Start prüft.
• Geschäftsintegrationen: EDI über AS2 (signiert und verschlüsselt mit S/MIME-Verfahren), OFTP2 in der Automobilindustrie, Bank- und Zahlungsschnittstellen, Portale von Kunden und Lieferanten.
• Daten im Ruhezustand: Backups und Archive, deren symmetrische Schlüssel mit RSA geschützt sind; verschlüsselte E-Mails in Postfächern.
• Betriebstechnik: OPC-UA-Verbindungen mit Zertifikaten, Fernwartungszugänge, signierte Steuerungsprogramme.

Viele dieser Stellen gehören nicht der IT-Abteilung. Die Codesignatur gehört der Entwicklung, die Rechnungssignatur der Buchhaltung, die Fernwartung der Instandhaltung. Genau deshalb tauchen sie in keiner Übersicht auf.

Das Register braucht einen Eigentümer, sonst wird es ein Projektartefakt, das nach sechs Monaten veraltet ist. Bewährt hat sich eine Aufteilung:

Was nicht delegierbar ist: die Entscheidung, das Register zu führen, und das Mandat, Fachbereiche zur Mitarbeit zu verpflichten. Das ist eine Aufgabe der Geschäftsführung. Was delegierbar ist: das Messen, Scannen und Abfragen, auch an einen externen Dienstleister.

Ein Tier-1-Zulieferer in Niedersachsen, sagen wir, verschickt im Frühjahr einen Lieferantenfragebogen mit einem neuen Kapitel „Post-Quanten-Kryptografie“. Ein slowenischer Lieferant von Kunststoffbaugruppen antwortet sorgfältig: Die OFTP2-Verbindung laufe über TLS 1.3, die Zertifikate seien RSA-2048, eine Umstellung hänge vom Hersteller der EDI-Software ab, der für 2026 eine Version mit hybridem Schlüsselaustausch angekündigt habe.

Die Antwort landet im Einkauf und wird mit „teilweise erfüllt“ bewertet. Niemand fragt nach, denn niemand weiß, dass das eigene OFTP2-System des Tier-1 auf einer Version läuft, die TLS 1.3 gar nicht unterstützt. Die Verbindung handelt seit Jahren TLS 1.2 aus. Die sorgfältige Antwort des Lieferanten beschreibt eine Fähigkeit, die an der Grenze zum Auftraggeber endet.

Erst ein halbes Jahr später, beim Aufbau eines Registers, fällt die Lücke auf, und zwar auf der eigenen Seite. Der Lieferant war weiter als sein Kunde. Im Einkauf hat man das anschließend eher leise erzählt.

• Anforderungen werden konkret. Statt „quantensicher“ heißt es: „Für die OFTP2-Verbindung planen wir ab 2027 hybriden Schlüsselaustausch. Bitte bestätigen Sie, welche Version Ihrer Software das unterstützt.“
• Antworten werden prüfbar. Jede Lieferantenangabe lässt sich mit einem Eintrag auf Ihrer Seite vergleichen.
• Prioritäten werden begründbar. Im Zusammenspiel mit der Schutzdauer aus Ausgabe 02 entsteht eine Reihenfolge, die nicht vom Bauchgefühl abhängt.
• Abhängigkeiten von Herstellern werden sichtbar. Viele Einträge haben in der Spalte „änderbar durch“ einen Hersteller stehen. Das ist keine Schwäche des Registers, sondern sein wichtigstes Ergebnis: Dort entscheidet sich Ihr Zeitplan.

„Das macht unser Cloud-Anbieter.“ Für die Umsetzung in seinem Dienst stimmt das. Ins Register gehört der Dienst trotzdem, mit dem Eintrag „änderbar durch: Anbieter“. Sonst fehlt in Ihrer Übersicht genau die Stelle, an der Sie keinen Einfluss haben und deshalb früh nach dem Zeitplan fragen müssen.

„Wir haben TLS 1.3, also sind wir vorbereitet.“ TLS 1.3 ist eine gute Grundlage, aber kein Post-Quanten-Verfahren. Der Schlüsselaustausch läuft dort üblicherweise über elliptische Kurven, also klassisch. Quantensicher wird er erst mit zusätzlichen Gruppen, die ML-KEM einbeziehen, meist hybrid zusammen mit einem klassischen Verfahren. Ob Ihre Endpunkte solche Gruppen anbieten, steht nicht in der Versionsnummer, sondern in der Konfiguration und in der eingesetzten Bibliothek.

„Ein Scanner findet alles.“ Ein Netzscan sieht, was über das Netz ausgehandelt wird. Er sieht nicht, womit eine Lizenzdatei signiert ist, welcher Schlüssel in einer Firmware steckt oder wie ein Backup seine Schlüssel schützt. Werkzeuge beschleunigen das Register erheblich, ersetzen aber nicht die Frage an die Menschen, denen die Prozesse gehören.

Ein erstes Register entsteht nicht durch ein Werkzeug, sondern durch vier Quellen, die sich gegenseitig ergänzen:

1. Konfiguration. Was ist auf Gateways, Servern, Lastverteilern eingestellt? Liefert verlässliche Angaben, aber nur für Systeme, die Sie selbst konfigurieren.
2. Zertifikate. Alle Zertifikate, die Ihre Systeme ausstellen oder vorzeigen, mit Algorithmus, Schlüssellänge und Laufzeit. Ein Scan des eigenen Netzes und der Zertifizierungsstellen-Datenbanken liefert in Tagen eine Übersicht, die mehr verrät als jedes Interview.
3. Netzverkehr. Was wird tatsächlich ausgehandelt? Eine passive Beobachtung an zentralen Punkten zeigt, ob die Konfiguration auch das ist, was passiert.
4. Hersteller. Was in Produkten fest eingebaut ist, wissen nur die Hersteller. Fragen Sie schriftlich und dokumentieren Sie Antwort und Datum.

Beginnen Sie mit den Systemen, über die Daten mit langer Schutzdauer zu Lieferanten fließen. Das Register muss nicht vollständig sein, um nützlich zu sein. Es muss ehrlich sein: „unbekannt“ ist ein zulässiger Eintrag, ein geschätzter Algorithmus nicht.

Mit eigenem Register ändert sich die Frage an den Lieferanten grundlegend. Statt nach einem Zustand fragen Sie nach einer Übereinstimmung:

„Auf unserer Seite der Verbindung X ist Verfahren Y eingestellt, und wir planen Z. Was ist auf Ihrer Seite eingestellt, und wer kann es ändern?“

Eine solche Frage kann ein Lieferant in wenigen Tagen beantworten, und die Antwort ist prüfbar. Sie zeigt außerdem, dass Sie Ihre Hausaufgaben gemacht haben, und das verändert den Ton jeder weiteren Abstimmung.

Die slowenische Ausgabe richtet dieselbe Aufgabe an die interne IT der Lieferanten: »Kriptografijo uporabljate vsak dan. Ali veste, kje vse?« (auf Slowenisch). Vorherige Ausgabe: Ihr slowenischer Zulieferer ist kein KRITIS-Betreiber.

Ein Grundregister, das ohne Spezialwerkzeug geführt werden kann, etwa als Tabelle im bestehenden Konfigurationsmanagement. In der slowenischen Ausgabe inhaltlich gleich.

Fundorte-Checkliste für die erste Runde: Webserver und Lastverteiler · VPN · SFTP und SSH · E-Mail (Transport und S/MIME) · EDI und Portale · interne CA und Smartcards · WLAN · Single Sign-on · Codesignatur · Firmware-Signatur · Dokument- und Rechnungssignatur · Lizenzprüfung · Backup-Verschlüsselung · OT-Fernwartung und OPC UA.

Grenze der Vorlage: Das Register beschreibt, was eingesetzt wird, nicht, ob es sicher ist. Die Bewertung entsteht erst zusammen mit Schutzdauer und Abhängigkeiten aus den Ausgaben 02 und 03.

Alle erschienenen Ausgaben der Reihe: Übersicht „Post-Quanten-Sicherheit in der Lieferkette“

Nächste Ausgabe (3. 11. 2025): „PQC lässt sich nicht einfach an den Dienstleister delegieren“

Quellen (Stand 6. 10. 2025): BSI IT-Grundschutz-Kompendium, Baustein CON.1 Kryptokonzept, Anforderung CON.1.A19; NIS Cooperation Group, „A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography“, Version 1.1 (Juni 2025), Abschnitt 6.2; CycloneDX 1.6 mit Erweiterung für kryptografische Bestandteile (CBOM), standardisiert als ECMA-424 (Juni 2024).

Wenn Sie für Ihr erstes Register einen Blick von außen brauchen: Schreiben Sie uns.