PQC lässt sich nicht einfach an den Dienstleister delegieren

Ausgabe 05 der Reihe „Post-Quanten-Sicherheit in der deutsch-slowenischen Lieferkette“. Für Auftraggeber von IT-Dienstleistungen: Geschäftsführung, IT-Leitung, Einkauf.

Die Mail an den IT-Dienstleister ist schnell geschrieben: „Bitte machen Sie uns post-quanten-fähig. Angebot bis Monatsende.“ Das Angebot kommt pünktlich. Es enthält ein Firmware-Update für die Firewalls und einen Workshop. Es ist korrekt, es ist bezahlbar, und es löst den Teil des Problems, der am leichtesten umzustellen ist.

In diesem Beitrag: Warum der Auftrag nicht reicht · Drei Dinge, die beim Auftraggeber bleiben · Was ein Dienstleister leisten kann · Beispiel · Was sich organisatorisch ändert · Was im Vertrag fehlt · RACI in fünf Schritten · Die Frage an Ihren Dienstleister · Anhang: RACI-Matrix

Ein Dienstleister arbeitet in einem Vertragsumfang: bestimmte Systeme, bestimmte Leistungen, bestimmte Reaktionszeiten. Die Umstellung auf Post-Quanten-Kryptografie hält sich an keinen dieser Umfänge. Sie betrifft Systeme, die der Dienstleister betreibt, Software, die ein Hersteller liefert, Schnittstellen, die ein Integrator gebaut hat, und Verbindungen, deren anderes Ende bei Ihren Lieferanten liegt.

Die EU-Roadmap vom Juni 2025 beschreibt die Umstellung deshalb nicht als technisches Projekt, sondern als Aufgabe des Risikomanagements: Das Quantenrisiko soll in das Risikomanagement auf oberster Ebene aufgenommen und „auf Vorstandsebene“ diskutiert werden. Für Einrichtungen, die unter die NIS-2-Richtlinie fallen, kommt eine ausdrückliche Pflicht hinzu: Die Leitungsorgane müssen die Risikomanagementmaßnahmen billigen, ihre Umsetzung überwachen und können für Verstöße verantwortlich gemacht werden (Art. 20). Die deutsche Umsetzung ist Anfang November 2025 noch nicht in Kraft; die Richtung der Richtlinie ist aber seit 2022 bekannt.

Delegieren lässt sich Arbeit. Verantwortung für eine Risikoentscheidung lässt sich nicht delegieren, weder rechtlich noch praktisch, weil der Dienstleister die Grundlage der Entscheidung nicht kennt.

1. Das Risiko festlegen. Welche Informationen wie lange vertraulich bleiben müssen, welche Signaturen wie lange gültig, welche Prozesse kritisch sind: Das weiß nur das Unternehmen, dem sie gehören (Ausgabe 02). Ein Dienstleister kann fragen und moderieren. Entscheiden kann er nicht.
2. Prioritäten setzen. Ob zuerst die Konstruktionsdaten oder zuerst die Fernwartung umgestellt werden, ist eine Abwägung zwischen Schaden, Aufwand und Geld. Sie gehört der Geschäftsführung.
3. Das Ergebnis abnehmen. Was „umgestellt“ heißt, legt der Auftraggeber fest, bevor gearbeitet wird, nicht danach. Sonst prüft der Dienstleister seine eigene Arbeit gegen seine eigenen Maßstäbe.

Hinzu kommt eine vierte, unbequeme Aufgabe: Restrisiken tragen. Wo eine Umstellung nicht rechtzeitig möglich ist, entscheidet der Auftraggeber, ob er das Risiko akzeptiert, begrenzt oder das System ersetzt. Dieser Entscheidung widmen wir im Januar 2027 eine eigene Ausgabe.

Umgekehrt wäre es falsch, den Dienstleister auf ausführende Handgriffe zu reduzieren. Ein guter Dienstleister bringt mit:

• Bestandsaufnahme in den Systemen, die er betreibt, einschließlich Messung dessen, was tatsächlich ausgehandelt wird.
• Herstellerkenntnis: welche Produkte in welcher Version welche Verfahren unterstützen und wann.
• Umsetzung von Konfigurationen und Updates in seinem Vertragsumfang.
• Test und Dokumentation nach Kriterien, die der Auftraggeber vorgibt.
• Hinweise auf Abhängigkeiten außerhalb seines Umfangs, also genau dort, wo er nichts ändern kann.

Der letzte Punkt ist der wertvollste und wird am seltensten vereinbart. Ein Dienstleister, der nur liefert, was bestellt wurde, schweigt über das, was außerhalb liegt. Bitten Sie ihn ausdrücklich, zu benennen, was er nicht leisten kann und wer es stattdessen müsste.

Ein typischer Fall: Ein Kontraktlogistiker aus Nordrhein-Westfalen mit 400 Beschäftigten betreibt ein Lager für einen Industriekunden. Beteiligt sind:

• ein IT-Dienstleister, der Netz, Firewalls, VPN und Server betreibt;
• ein Softwarehersteller für das Lagerverwaltungssystem, als Standardprodukt mit Wartungsvertrag;
• ein slowenisches Softwarehaus, das vor drei Jahren die Schnittstelle zwischen Lagerverwaltung und dem EDI-System des Industriekunden entwickelt hat und sie heute auf Abruf pflegt;
• die interne IT mit zwei Personen, die vor allem Anwender betreut. Das füllt den Tag erfahrungsgemäß aus.

Der Industriekunde fragt im Rahmen seiner eigenen Lieferantenbewertung, wie der Logistiker die Umstellung auf Post-Quanten-Kryptografie plant. Die Geschäftsführung leitet die Frage an den IT-Dienstleister weiter.

Der Dienstleister antwortet gewissenhaft für seinen Umfang: Die Firewalls bekommen 2026 ein Update, das hybriden Schlüsselaustausch für VPN unterstützen soll; die Server-Betriebssysteme folgen mit den Herstellerzyklen. Über die Schnittstelle des Softwarehauses weiß er nichts, über die Lagerverwaltung nur, dass sie TLS spricht.

Die Antwort geht so an den Kunden. Sie ist nicht falsch. Aber sie beschreibt den Teil, der am einfachsten umzustellen ist, und lässt den Teil weg, der am längsten dauert: eine individuell entwickelte Schnittstelle, deren Quellcode beim slowenischen Softwarehaus liegt, und die Signatur der EDI-Nachrichten, die dort fest eingebaut ist. Niemand hatte gefragt, wer dafür zuständig ist. Also war es niemand.

• Ein Verantwortlicher auf Auftraggeberseite. Nicht der Dienstleister, nicht „die IT“. Eine Person mit Mandat, die das Gesamtbild hält und Entscheidungen vorbereitet.
• Zuständigkeit je Eintrag, nicht je Vertrag. Das Register aus Ausgabe 04 bekommt eine Spalte „verantwortlich für Umsetzung“. Einträge ohne Namen sind sofort sichtbar.
• Dienstleister als Berater, nicht als Ersatz. Ihre Kenntnis wird ausdrücklich angefragt, auch für Bereiche außerhalb ihres Betriebsumfangs, und gesondert vergütet.
• Abnahmekriterien vor dem Auftrag. Für jede Umstellung wird vorab festgelegt, woran der Auftraggeber erkennt, dass sie erledigt ist (dazu ausführlich im Dezember 2026).

Die meisten Betriebsverträge beschreiben Leistungen je System: Firewall betreiben, Server patchen, Störungen innerhalb von vier Stunden beheben. Für die Post-Quanten-Umstellung fehlen darin drei Dinge, die sich ohne großen Aufwand ergänzen lassen:

• Pflege des Registers für die betriebenen Systeme. Der Dienstleister hält die Einträge zu seinen Systemen aktuell: Verfahren, Zertifikate, Laufzeiten, Versionen. Er kennt sie ohnehin am besten.
• Jährliche Auskunft zu Herstellerplänen. Für die Produkte in seinem Umfang berichtet er einmal im Jahr, welche Hersteller wann welche Post-Quanten-Verfahren unterstützen wollen und was davon schon verfügbar ist.
• Hinweispflicht über den eigenen Umfang hinaus. Erkennt der Dienstleister eine kryptografische Abhängigkeit außerhalb seines Vertrags, etwa eine Schnittstelle eines Dritten, die ein Zertifikat seines Gateways nutzt, meldet er sie schriftlich.

Keiner dieser Punkte verschiebt Verantwortung. Alle drei sorgen dafür, dass der Auftraggeber seine eigene Verantwortung auf der Grundlage vollständiger Informationen wahrnehmen kann. Der Aufwand ist überschaubar und lässt sich als Pauschale oder nach Aufwand vergüten. Teuer ist nur, ihn nicht zu vereinbaren: Dann kommt die Information erst, wenn jemand konkret danach fragt, und das ist meistens ein Kunde.

Die RACI-Matrix ist ein bewährtes Werkzeug, um Zuständigkeiten sichtbar zu machen: R führt aus (responsible), A trägt die Entscheidung und nimmt ab (accountable), C wird gefragt (consulted), I wird informiert (informed). Für die PQC-Umstellung funktioniert sie so:

1. Aufgaben auflisten, nicht Systeme. Die Vorlage im Anhang enthält zwölf Aufgaben von der Schutzdauer bis zum Restrisiko.
2. Beteiligte als Spalten anlegen: Geschäftsführung, Informationssicherheit, interne IT, Dienstleister, Integrator oder Auftragsentwickler, Softwarehersteller, Lieferant.
3. Je Aufgabe genau ein A vergeben. Zwei A heißen: keiner.
4. Mit allen Beteiligten durchgehen. Der Dienstleister muss sein R bestätigen, der Hersteller sein C. Was niemand bestätigt, ist offen.
5. Lücken als Aufgaben übernehmen. Eine leere Zeile ist kein Formfehler, sondern das wichtigste Ergebnis.

„Welche Einträge unseres Kryptografie-Registers liegen in Ihrem Vertragsumfang, welche nicht, und wen sehen Sie für die übrigen in der Verantwortung?“

Mit dieser Frage verlangen Sie nicht, dass der Dienstleister alles löst. Sie verlangen, dass er seine Grenze zieht und über sie hinaus Auskunft gibt. Ein Dienstleister, der diese Frage gern beantwortet, ist ein Partner für die Umstellung. Einer, der sie als Vorwurf versteht, ist ein Lieferant für Firmware-Updates.

Die slowenische Ausgabe stellt dieselbe Frage aus Sicht des Lieferanten, der seinen eigenen Dienstleistern vertraut: »To ureja naš IT-izvajalec. Ali res?« (auf Slowenisch). Vorherige Ausgabe: Sie fordern Quantensicherheit von Lieferanten.

Vorlage für ein Unternehmen mit interner und externer IT. Die Zuordnung zeigt eine typische Ausgangslage, keine Empfehlung für jeden Fall. In der slowenischen Ausgabe inhaltlich gleich.

Spalten: GF = Geschäftsführung · IS = Informationssicherheit/Verantwortliche Person PQC · IT = interne IT · DL = IT-Dienstleister (Betrieb) · INT = Integrator/Auftragsentwickler · HST = Softwarehersteller · LF = Lieferant bzw. Kunde am anderen Ende

Prüffragen: Hat jede Zeile genau ein A? Haben alle R ihr R bestätigt? Gibt es Zeilen, in denen das R bei jemandem liegt, mit dem kein Vertrag besteht?

Grenze der Vorlage: Die Matrix ersetzt keine Verträge. Sie zeigt, wo Verträge fehlen oder nicht passen.

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

Nächste Ausgabe (1. 12. 2025): „PQC-Anforderungen an Lieferanten: Ohne Zielvorgaben entsteht nur Bürokratie“

Quellen (Stand 3. 11. 2025): Richtlinie (EU) 2022/2555 (NIS 2), Art. 20 und 21; NIS Cooperation Group, „A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography“, Version 1.1 (Juni 2025), Abschnitt 6.2.

Wenn Sie Ihre Matrix einmal mit einem unbeteiligten Blick durchgehen möchten: Schreiben Sie uns.