Wer ist für die Umstellung verantwortlich: Ihre IT, der Integrator oder der Softwarehersteller?

Ausgabe 07 der Reihe „Post-Quanten-Sicherheit in der deutsch-slowenischen Lieferkette“. Für IT-Leitung und Einkauf in Unternehmen, deren Systeme von mehreren Partnern gebaut und betrieben werden.

Eine einzige Frage, drei Antworten. „Wer stellt die Signatur unserer EDI-Bestellungen um?“ Die eigene IT sagt: „Das macht der Hersteller.“ Der Hersteller sagt: „Das ist Konfiguration beim Kunden.“ Der Integrator sagt: „Dafür sind wir nicht beauftragt.“ Alle drei haben recht. Deshalb passiert nichts.

In diesem Beitrag: Was sich seit Dezember geändert hat · Fünf Arten von Zuständigkeit · Die vier Fragen je Komponente · Was beim Auftraggeber liegt · Beispiel · Was daraus folgt · Neue Verträge mit Entwicklern · Die Matrix in vier Schritten · Die Frage an Hersteller und Integrator · Anhang: Matrix

Seit dem 6. Dezember 2025 ist das deutsche NIS-2-Umsetzungsgesetz in Kraft. Damit gilt das neue BSI-Gesetz für deutlich mehr Unternehmen als bisher: besonders wichtige und wichtige Einrichtungen müssen nach § 30 BSIG Risikomanagementmaßnahmen umsetzen, darunter Konzepte für den Einsatz von Kryptografie und die Sicherheit der Lieferkette. Die Registrierung beim BSI ist für Unternehmen, die bereits bei Inkrafttreten erfasst waren, bis zum 6. März 2026 vorgesehen.

Das Gesetz sagt, dass Sie Ihre Kryptografie und Ihre Lieferkette im Griff haben müssen. Es sagt nicht, wer in Ihrer Lieferkette welche Änderung vornimmt. Das bleibt Ihre Aufgabe, und sie ist schwieriger, als es klingt, weil kaum ein Geschäftssystem heute aus einer Hand stammt.

Auch für Unternehmen außerhalb des Anwendungsbereichs gilt dasselbe praktisch: Wer nicht weiß, wer eine Änderung vornehmen kann, kann sie nicht planen. Die EU-Roadmap zur Post-Quanten-Kryptografie nennt deshalb die Abstimmung mit Produkt- und Dienstleistungsanbietern als einen der ersten Schritte.

Die Zuständigkeit für eine kryptografische Änderung hängt davon ab, wo die Kryptografie lebt:

Wichtig ist, dass eine Funktion mehrere Arten zugleich berühren kann. Die Signatur einer EDI-Nachricht kann im Standardprodukt eingebaut sein (Hersteller), über ein Zertifikat gesteuert werden (Betreiber) und über ein vom Integrator gebautes Mapping an den Partner gehen (Integrator). Dann braucht die Umstellung alle drei, in der richtigen Reihenfolge.

Für jede Komponente mit Kryptografie im Register aus Ausgabe 04 lassen sich vier Fragen stellen. Ihre Antworten entscheiden über die Zuständigkeit:

1. Wem gehört der Quellcode, und wer darf ihn ändern? Bei Individualentwicklung ist das häufig ungeklärt. Wer Nutzungsrechte, aber keine Änderungsrechte hat, kann nicht einfach einen anderen Entwickler beauftragen.
2. Wer hält die Schlüssel? Signaturschlüssel liegen beim Hersteller, beim Entwickler, in Ihrer Infrastruktur oder in einem Hardware-Sicherheitsmodul. Wer den Schlüssel hat, entscheidet faktisch über die Umstellung mit.
3. Läuft ein Vertrag, der Änderungen abdeckt? Ein Wartungsvertrag für ein Standardprodukt deckt neue Versionen ab, ein abgeschlossenes Integrationsprojekt meistens nichts.
4. Wann endet die Unterstützung? Eine Version, deren Support 2027 endet, wird keine Post-Quanten-Verfahren mehr bekommen. Das Supportende ist für die Planung oft wichtiger als jede Ankündigung.

Die technische Entscheidung, wie ein Hersteller sein Produkt umstellt, liegt nicht bei Ihnen und sollte es auch nicht. Bei Ihnen liegt:

• die Zuordnung: Für jede Komponente steht fest, wer ändert, unter welchem Vertrag;
• die Reihenfolge: Wenn drei Parteien beteiligt sind, legen Sie fest, wer zuerst liefert;
• die Lücken: Wo niemand zuständig ist, entscheiden Sie, ob ein Vertrag geschlossen, eine Komponente ersetzt oder ein Restrisiko getragen wird.

Ein Hersteller, ein Integrator und ein Dienstleister können jeweils ihre Arbeit gut machen und trotzdem gemeinsam scheitern, wenn niemand die Reihenfolge bestimmt.

Denken Sie an einen Großhändler für Sanitär- und Heizungstechnik in Sachsen. Er betreibt:

• ein Standard-ERP mit Wartungsvertrag beim Hersteller;
• eine EDI-Anbindung an Hersteller und Großkunden, vor vier Jahren von einem Integrator eingerichtet;
• ein B2B-Portal für Installateure, individuell entwickelt von einem Softwarehaus in Ljubljana, das es heute auf Abruf pflegt;
• einen Zahlungsdienst in der Cloud.

Bei der Zuordnung ergeben sich folgende Antworten:

Die wichtigste Zeile ist die zweite. Das Portal ist das jüngste System, aber das am schwersten umzustellende, weil seine Kryptografie im Code steckt und niemand geklärt hat, ob der Großhändler einen anderen Entwickler beauftragen dürfte. Das Softwarehaus ist kooperativ, aber sein Angebot setzt einen Wartungsvertrag voraus, den es nie gab.

• Supportende gehört ins Register. Es ist das Datum, ab dem eine Komponente keine neuen Verfahren mehr bekommt, und damit der späteste Zeitpunkt für eine Entscheidung.
• Individualentwicklung braucht eine Rechteklärung. Wem gehört der Code, wer darf ändern, wo liegt der Build? Die Antwort gehört in jeden neuen Vertrag mit einem Entwickler und in jeden alten, der noch gilt.
• Integratoren nicht vergessen. Abgeschlossene Projekte sind die häufigste Lücke. Eine kleine Rahmenvereinbarung für Anpassungen ist billiger als eine Neuausschreibung im Notfall.
• Herstellerangaben schriftlich einholen. Mündliche Ankündigungen auf Messen sind keine Planungsgrundlage, so überzeugend sie am Stand auch klingen.

Für bestehende Individualentwicklungen lässt sich die Rechtslage oft nur nachträglich klären. Für neue Aufträge lässt sie sich vorab regeln, mit vier Punkten, die jeder Entwicklungsvertrag enthalten sollte, auch ohne Post-Quanten-Bezug:

• Quellcode und Build: Übergabe oder Hinterlegung des Quellcodes einschließlich der Anleitung, wie daraus eine lauffähige Version entsteht.
• Änderungsrechte: das Recht, Änderungen selbst oder durch Dritte vornehmen zu lassen, mindestens für sicherheitsrelevante Anpassungen.
• Schlüssel: Signatur- und Anmeldeschlüssel werden in der Infrastruktur des Auftraggebers erzeugt und verwahrt, nicht beim Entwickler.
• Austauschbarkeit: kryptografische Verfahren werden nicht fest im Code verdrahtet, sondern über eine Konfiguration oder eine zentrale Stelle gewählt. Wie das architektonisch aussieht, behandelt die Ausgabe zur Kryptoagilität im Juli 2026.

Ein Softwarehaus, das diese Punkte ablehnt, ist nicht unseriös. Es sagt Ihnen aber, dass Sie für die Lebensdauer der Software an es gebunden sind. Das ist eine Entscheidung, die Sie bewusst treffen sollten, nicht beim ersten Notfall entdecken.

1. Komponenten aus dem Register übernehmen, nicht Systeme: Ein ERP besteht aus mehreren Komponenten mit verschiedener Zuständigkeit.
2. Je Komponente die vier Fragen beantworten (Code, Schlüssel, Vertrag, Supportende).
3. Zuständigkeit eintragen und bestätigen lassen. Wer als zuständig eingetragen ist, sollte das schriftlich bestätigen.
4. Lücken der Geschäftsführung vorlegen mit drei Optionen: Vertrag schließen, Komponente ersetzen, Risiko tragen.

„Welche kryptografischen Funktionen sind in Ihrem Produkt fest eingebaut, welche sind konfigurierbar, und ab welcher Version ändert sich das?“

Die Frage trennt sauber, was der Hersteller liefern muss und was Ihr Betrieb einstellen kann. Sie zwingt außerdem zu einer Versionsangabe, und Versionen lassen sich mit Ihrem Supportplan abgleichen.

Die slowenische Ausgabe stellt die Frage aus Sicht des Lieferanten, der wissen muss, was er an seinen eigenen Systemen ändern darf: »Kdo sme spremeniti kriptografijo v vašem sistemu?« (auf Slowenisch). Vorherige Ausgabe: PQC-Anforderungen an Lieferanten.

Eine Zeile je Komponente mit Kryptografie. Die Matrix ergänzt das Register (Ausgabe 04) und die RACI-Matrix (Ausgabe 05). In der slowenischen Ausgabe inhaltlich gleich.

Grenze der Vorlage: Die Matrix zeigt Zuständigkeiten, keine Rechtslage. Ob Änderungsrechte bestehen, klärt im Zweifel die Rechtsabteilung anhand der Verträge.

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

Nächste Ausgabe (2. 2. 2026): „Quantensichere Lieferketten beginnen nicht mit Vertragsstrafen“

Quellen (Stand 5. 1. 2026): Gesetz zur Umsetzung der NIS-2-Richtlinie (NIS2UmsuCG), in Kraft seit 6. 12. 2025, insbesondere § 30 BSIG; NIS Cooperation Group, „A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography“, Version 1.1 (Juni 2025).

Wenn Ihre Matrix mehr leere Felder als Namen hat: Schreiben Sie uns.