QTSP-Partner für ISVs: Qualifikation nicht selbst bauen

Das Risiko einer einzigen QTSP-Abhängigkeit ehrlich benennen

Wer als Softwarehersteller qualifizierte elektronische Signaturen (QES) anbieten will, steht früh vor einer Grundsatzfrage: Bauen wir die Qualifikation selbst, oder arbeiten wir mit einem qualifizierten Vertrauensdiensteanbieter (QTSP) zusammen? Unsere Antwort lautet klar: Bauen Sie sie nicht selbst. Ein QTSP ist ein regulierter Anbieter, der von der Aufsicht geprüft wird und strenge Anforderungen an Technik, Organisation, Personal und Sicherheit erfüllt. Diese Anforderungen sind in der eIDAS-Verordnung verankert, und die Erfüllung ist kein Nebenprojekt eines Produktteams.

Mit dieser Antwort verbindet sich aber ein Risiko, das viele Anbieter ungern erwähnen, und wir nennen es deshalb ausdrücklich: die Abhängigkeit von einem einzelnen Partner. Wenn Ihre gesamte QES-Funktion auf einem QTSP ruht, hängen Verfügbarkeit, Preisgestaltung, Weiterentwicklung, Identifikationsverfahren und Standort Ihrer Funktion von dessen Entscheidungen ab. Fällt der Partner aus, ändert er seine Bedingungen oder stellt er ein Verfahren ein, trifft das Ihre Kunden, und sie wenden sich an Sie, nicht an den Partner.

Für regulierte Kunden ist das Konzentrationsrisiko ohnehin ein Thema. Finanzunternehmen müssen im Rahmen von DORA Drittparteirisiken steuern und Ausstiegsstrategien für kritische Dienstleister vorhalten. Auch NIS-2 stellt Anforderungen an die Sicherheit der Lieferkette. Wer als ISV solche Kunden bedient, wird gefragt werden: Was passiert, wenn Ihr Signaturpartner ausfällt? Haben Sie Alternativen? Wie sieht der Ausstieg aus? Diese Fragen sind berechtigt, und eine ehrliche Antwort ist wertvoller als ein Versprechen.

Wir sagen deshalb offen, was wir nicht versprechen. Wir versprechen keinen automatischen oder nahtlosen Wechsel zwischen mehreren QTSPs zur Laufzeit, und wir behaupten keine fertige Mehr-Partner-Strecke, die ein Ausfall unbemerkt auffängt. Was wir anbieten, ist eine API-Schicht, die Ihr Produkt von den Eigenheiten eines einzelnen Partners entkoppelt, soweit das technisch und rechtlich möglich ist. Ob und wie weitere Partner angebunden werden, ist eine Frage der Architektur, der Verträge und der Aufsicht, die wir im Einzelfall mit Ihnen klären.

Die eine harte Unterscheidung dieses Beitrags lautet: Entkopplung ist nicht Redundanz. Eine saubere Abstraktion bedeutet, dass Ihr Produkt nicht an die Besonderheiten eines Partners gekettet ist und Sie langfristig wechseln oder erweitern können. Redundanz bedeutet, dass ein zweiter Partner tatsächlich bereitsteht, vertraglich, technisch und organisatorisch. Das eine ist eine Frage des Designs, das andere eine Frage von Verträgen, Betrieb und Kosten. Wer beides vermischt, verspricht mehr, als er hält.

Daraus folgt für ISVs eine pragmatische Haltung. Behandeln Sie die QTSP-Abhängigkeit wie jede andere Lieferantenabhängigkeit: dokumentieren Sie sie, bewerten Sie das Risiko, definieren Sie einen Umgang damit, und kommunizieren Sie ehrlich gegenüber Kunden. Für viele Anwendungsfälle genügt ein einzelner, gut ausgewählter Partner, besonders wenn QES nur für einen Teil der Vorgänge nötig ist und AES als Rückfallebene für nicht zwingend qualifizierte Dokumente zur Verfügung steht. Für andere, besonders kritische Fälle sollten Sie früh über einen Zweitpartner sprechen.

API und QTSP: wer welche Rolle trägt

Um das Risiko richtig einzuordnen, hilft eine klare Rollentrennung. Der QTSP erbringt die qualifizierten Vertrauensdienste: Er prüft die Identität des Unterzeichners nach den geltenden Anforderungen, stellt ein qualifiziertes Zertifikat aus, betreibt oder stellt die qualifizierte Signaturerstellungseinheit bereit und erstellt die qualifizierte Signatur. Er haftet dafür im Rahmen der Verordnung und steht unter Aufsicht. In Deutschland ist die Bundesnetzagentur als Aufsichtsstelle für Vertrauensdienste zuständig.

Die API-Schicht, also Sign2x, erbringt keine qualifizierten Vertrauensdienste. Sign2x ist kein QTSP. Wir stellen Ihrem Produkt die Funktionen bereit, die eine Signaturstrecke braucht: Vorgänge anlegen, Dokumente und Unterzeichner verwalten, Schritte steuern, Ereignisse liefern, Mandanten trennen und Marken abbilden. Für SES und AES sichert die Strecke Zuordnung und Integrität. Für QES bindet sie den Partner-QTSP ein, etwa Sign8, und stellt sicher, dass das Ergebnis im Vorgang nachvollziehbar ist.

Als dritte Partei kommt Ihr Produkt dazu, also der ISV. Sie entscheiden, welche Stufe für welchen Dokumenttyp gilt, wie die Oberfläche aussieht, wie Nutzer geführt werden und wie Ergebnisse weiterverarbeitet werden. Sie tragen die Verantwortung für das Produktdesign und die Kommunikation gegenüber Ihren Kunden. Und Ihr Kunde trägt die Verantwortung dafür, dass die gewählte Stufe für seinen Vorgang rechtlich passt. Vier Parteien, vier Rollen, und jede sollte in Verträgen und Dokumentation benannt sein.

Die Rollenteilung hat praktische Vorteile. Sie zwingt zur Klarheit darüber, wer wofür einsteht, und sie schützt vor Haftungsunschärfen. Wenn etwa ein Zertifikat gesperrt wird, liegt das beim QTSP. Wenn eine Oberfläche Nutzer in die Irre führt, liegt es bei Ihnen. Wenn ein Webhook nicht ankommt, liegt es bei der Integration. Wer diese Zuordnung kennt, löst Störungen schneller und kommuniziert sie ehrlicher. Mehr zur Rollenverteilung im Kontext von Geldwäscheprävention liefert der Beitrag GwG-konforme Signatur-API für ISVs.

Die Rollentrennung hilft auch bei der Stufenwahl. Wenn Sie wissen, dass QES einen Partner einbindet, mit Identifikation, Zeitbedarf und Kosten, wägen Sie bewusster ab, wo Sie sie einsetzen. Eine Entscheidungshilfe bietet der Beitrag AES vs QES per API. In vielen Fällen ist AES die pragmatische Wahl, QES die Ausnahme für Vorgänge mit gesetzlicher Form oder besonderem Beweisbedarf. Das reduziert die Abhängigkeit schon strukturell, weil nur ein Teil Ihrer Vorgänge den Partner braucht.

Was ISVs orchestrieren: der Partner als Baustein in Ihrem Produkt

Wenn Sie mit einem QTSP-Partner arbeiten, gibt es Aufgaben, die bei Ihnen bleiben, auch wenn die Qualifikation extern liegt. Die erste ist die Konfiguration: Welche Dokumenttypen laufen mit QES, welche Identifikationsverfahren sind erlaubt, welche Texte erscheinen vor der Signatur? Diese Entscheidungen gehören in eine Konfiguration, die Ihre Rechtsberatung verantwortet, nicht in verstreute Codestellen. So können Sie Änderungen nachvollziehen und bei Bedarf anpassen, ohne die Anwendung zu verändern.

Die zweite Aufgabe ist die Zustandsführung. QES-Vorgänge dauern länger als einfache Signaturen und enthalten Schritte, die außerhalb Ihrer Kontrolle liegen: Identifikation, Zertifikatsausstellung, Signaturerstellung. Ihr System muss diese Zwischenzustände verstehen und Nutzern verständlich machen. Das gelingt mit einem Zustandsmodell, wie es der Beitrag Webhook State Management für E-Signatur-Events beschreibt: Ereignisse werden empfangen, in einer Historie gespeichert und in fachliche Zustände übersetzt, auch wenn der Partner Zeit braucht.

Die dritte Aufgabe ist die Fehlerbehandlung. Partnerdienste sind keine Garantie für Fehlerfreiheit. Identifikationen scheitern, Verbindungen brechen ab, Zeitüberschreitungen treten auf. Ihr Produkt braucht definierte Wege: Wiederholung, alternatives Verfahren, Hinweis an den Nutzer, Eskalation an den Support. Wichtig ist, dass ein Partnerproblem nicht zu einem stillen Verlust von Vorgängen führt. Fehlerereignisse gehören in Ihre Überwachung, und der Support sollte wissen, wie er Nutzern bei typischen Problemen hilft.

Die vierte Aufgabe ist die Dokumentation der Lieferkette. Der Partner ist ein Teil Ihrer IKT-Lieferkette und gehört in Ihre Dokumentation: Name, Rolle, Standort, Daten, die an ihn fließen, Vertragsgrundlage, Ausstiegsregelung. Gegenüber regulierten Kunden ist das Pflichtstoff. Wie solche Nachweise aufgebaut werden, zeigt der Beitrag DORA Artikel 30 und der Signatur-Audit-Trail. Wir betonen: Das ist Evidence, keine Zertifizierung, und weder DORA noch NIS-2 kennen ein Siegel für Signatur-APIs oder Partnerschaften.

Die fünfte Aufgabe ist die Beobachtung des Partners. Prüfen Sie regelmäßig, ob der QTSP weiterhin als qualifiziert geführt wird, ob sich Bedingungen, Verfahren oder Standorte geändert haben und ob angekündigte Änderungen Ihre Strecke betreffen. Vertrauenslisten der Mitgliedstaaten machen den Status öffentlich einsehbar. Halten Sie Ihre Prüfung schriftlich fest: Das dient als Beleg für Sorgfalt und hilft, Veränderungen früh zu bemerken. Auch Entwicklungen wie die EUDI Wallet verändern Rollen, wie im Beitrag eIDAS 2.0 und die EUDI Wallet beschrieben.

Die sechste Aufgabe betrifft die Kommunikation gegenüber Kunden. Erklären Sie in Vertriebsunterlagen und Verträgen, dass QES über einen Partner läuft, wer er ist und welche Rolle er hat. Das mag wie ein Verkaufsnachteil wirken, ist aber das Gegenteil: Regulierte Kunden erwarten Transparenz und misstrauen Anbietern, die Lieferketten verschweigen. Eine klare, kurze Darstellung der Rollen beantwortet die meisten Rückfragen bereits vorab und schafft Vertrauen, das sich später in kürzeren Prüfzyklen auszahlt.

Ein Beispiel macht das greifbar. Ein ISV für Personalsoftware bietet Arbeitsverträge zur Signatur an. Befristungen und bestimmte Nachweise verlangen Schriftform, die qualifizierte Signatur ersetzt sie. Alle anderen Dokumente, etwa Datenschutzhinweise oder Zusatzvereinbarungen, laufen mit AES. Nur ein kleiner Teil der Vorgänge berührt also den Partner, und fällt dieser vorübergehend aus, bleibt der Großteil der Signaturen nutzbar. Das ist keine Redundanz, aber es begrenzt die Reichweite einer Störung erheblich und ist ehrlich kommunizierbar.

Ein zweites Beispiel betrifft das Onboarding bei Finanzdienstleistern. Dort sind Identifikation und qualifizierte Signatur oft gekoppelt, und der Partner ist für den Kunden sichtbar. Hier lohnt es sich, Verträge so zu gestalten, dass Daten und Nachweise bei einem Wechsel zurückgegeben werden und die Strecke im Produkt konfigurierbar bleibt. Ein späterer Wechsel bleibt dann ein Projekt mit klarem Umfang statt eines Neubaus. Wer das früh festhält, spart in der Prüfung viel Erklärungsaufwand.

Schließlich lohnt ein Blick auf die Kosten. Qualifizierte Dienste werden in der Regel pro Vorgang abgerechnet, und Identifikationsverfahren unterscheiden sich im Preis deutlich. Rechnen Sie nicht nur den Einzelpreis, sondern den Anteil der Vorgänge, die wirklich QES brauchen, die Abbruchquote bei der Identifikation und den Supportaufwand. Ein günstiger Preis mit hoher Abbruchquote kann teurer sein als ein höherer Preis mit sauberer Nutzerführung. Diese Rechnung gehört in jede Partnerbewertung.

Planen Sie außerdem einen jährlichen Review-Termin ein, an dem Produkt, Recht und Einkauf gemeinsam die Partnerübersicht durchgehen. Dabei prüfen Sie, ob sich Volumen, Dokumenttypen oder Kundenanforderungen verändert haben und ob die Aufteilung zwischen AES und QES noch passt. Ein kurzer, regelmäßiger Termin ist deutlich wirksamer als eine große Prüfung, die erst nach einem Vorfall stattfindet.

Fragen an Anbieter: eine Liste für die Partnerauswahl

Bei der Auswahl eines QTSP-Partners, aber ebenso bei der Bewertung jedes Signatur-Anbieters, helfen konkrete Fragen. Wir haben sie in sechs Gruppen geordnet und empfehlen, die Antworten schriftlich festzuhalten.

• Status und Aufsicht: Ist der Anbieter als QTSP geführt, für welche Dienste, seit wann, und welche Aufsichtsstelle ist zuständig?
• Verfahren und Stufen: Welche Identifikationsverfahren und Signaturniveaus sind produktiv verfügbar, und wie ist der Fahrplan für Änderungen, etwa im Zuge der EUDI Wallet?
• Standort und Eigentum: Wo werden Daten verarbeitet, wem gehört der Anbieter, welche Unterauftragnehmer sind beteiligt, und welches Recht gilt?
• Betrieb und Verfügbarkeit: Welche Verfügbarkeitsziele nennt der Anbieter, wie werden Störungen kommuniziert, und wie sieht der Support im Ernstfall aus?
• Vertrag und Ausstieg: Welche Kündigungs- und Ausstiegsregeln gelten, wie werden Daten und Nachweise zurückgegeben, und wie lange bleiben sie verfügbar?
• Integration und Daten: Welche Ereignisse und Nachweise liefert der Anbieter, in welchem Format, und wie lassen sie sich in Ihr Zustandsmodell einbinden?

Achten Sie auf die Qualität der Antworten, nicht nur auf ihr Vorhandensein. Ein Anbieter, der Verfügbarkeitszahlen ohne Messgrundlage nennt oder bei Eigentümerfragen ausweicht, gibt Ihnen ebenfalls eine Antwort. Wir empfehlen außerdem, einen kleinen Praxistest einzuplanen: einen Vorgang vom Start bis zum Abschluss mit echten Nutzern, inklusive Fehlerfall. Was auf dem Papier überzeugt, zeigt im Betrieb manchmal Schwächen, und umgekehrt.

Stellen Sie dieselben Fragen auch uns. Wir antworten gern und sagen offen, wo wir keine Zusagen machen können. Sign2x ist eine API-Schicht für SES, AES und QES, wir sind kein QTSP, und für QES arbeiten wir mit Partnern wie Sign8. Wenn Sie über Zweitpartner oder alternative Strecken nachdenken, ist das ein Gespräch wert, in dem wir Machbarkeit, Aufwand und Grenzen klären, ohne vorab etwas zu versprechen, das später nicht trägt.

Der Rahmen: Souveränität entlang der gesamten Kette

Souveränität endet nicht an der Grenze Ihrer Plattform. Sie umfasst die gesamte Kette, auch den Partner. Sign2x läuft auf der Open Sovereign Cloud (OSC) von T-Systems, einem europäischen Betrieb unter europäischem Recht. Das ist eine klare Aussage über unseren Teil der Kette. Für den QTSP-Partner sollten Sie die gleichen Fragen stellen: Standort, Eigentümerstruktur, Unterauftragnehmer, Rechtsrahmen. Wer nur die eigene Plattform souverän betreibt und den Partner nicht prüft, hat eine Lücke in der Argumentation.

Warum der Standort allein nicht genügt, erläutert der Beitrag Cloud Act vs Datensouveränität, die technische und rechtliche Vertiefung liefern die Artikel Open Sovereign Cloud für die E-Signatur-API und Cloud Act und Open Sovereign Cloud bei E-Signatur. Wichtig ist die Haltung: Souveränität ist eine Eigenschaft der Kette, und Sie sind nur so stark wie das schwächste Glied. Das heißt nicht, dass jeder Partner perfekt sein muss, aber dass Sie wissen, wo die Grenzen liegen, und sie dokumentieren.

Hosting auf OSC ist eine Aussage über Betrieb und Jurisdiktion der Plattform. Es ist keine Zertifizierung Ihres Produkts und kein Ersatz für Ihre eigene Risikobewertung der Lieferkette. Auch Datenschutzfragen bleiben bei Ihnen: Die DSGVO verlangt klare Verantwortlichkeiten, Auftragsverarbeitungsverträge und Transparenz über Empfänger. Bei QES-Strecken fließen personenbezogene Daten zum Partner, und Ihre Dokumentation muss das abbilden, einschließlich Zweck, Rechtsgrundlage und Aufbewahrung.

Für ISVs mit besonderen Anforderungen, die keine Cloud-Strecke akzeptieren, besteht die Option eines Betriebs im eigenen Rechenzentrum. Bei QES bleibt der Partner-QTSP Teil der Kette, und je nach Konstellation müssen Verbindungen zum Partner möglich sein. Welche Teile lokal bleiben können, klären wir im Einzelfall. Pauschale Zusagen halten wir hier für unseriös, und wir sagen Ihnen lieber früh, wo Grenzen liegen.

Zum Abschluss ein Vorschlag für das weitere Vorgehen: Erstellen Sie eine einseitige Partnerübersicht für Ihr Produkt. Sie enthält die vier Rollen, die eingesetzten Partner mit Status und Standort, die Datenflüsse, die Ausstiegsregelung und den Zeitpunkt der letzten Prüfung. Diese Seite beantwortet einen Großteil der Fragen in Sicherheitsfragebögen und gibt Ihrem Vertrieb eine verlässliche Grundlage. Technische Grundlagen finden Sie im Developer Hub, Begriffe im Help Center, Praxisfälle unter Use Cases und weitere Beiträge im Sign2x Blog. Für ein Gespräch zu Ihrer Konstellation erreichen Sie uns über den Kontakt, zur Einordnung hilft das Sign2x Quiz.

Partnerarchitektur mit uns besprechen

Verwandte Beiträge: NIS-2 Nachweis über den Audit-Trail und Bulk-Signatur-API für Unternehmen. Hinweise zur Informationssicherheit beim BSI.

Häufige Fragen

Warum sollten ISVs die Qualifikation nicht selbst bauen?

Ein QTSP erfüllt strenge, beaufsichtigte Anforderungen an Technik, Organisation und Sicherheit. Das ist kein Nebenprojekt eines Produktteams. ISVs integrieren besser einen Partner über eine API-Schicht.

Ist Sign2x ein QTSP?

Nein. Sign2x ist die API-Schicht für SES, AES und QES. Für QES arbeiten wir mit Partner-QTSPs wie Sign8 zusammen.

Bietet Sign2x einen automatischen Wechsel zwischen mehreren QTSPs?

Nein, wir versprechen keinen automatischen oder nahtlosen Wechsel zwischen mehreren Partnern zur Laufzeit. Entkopplung im Design ist nicht dasselbe wie Redundanz im Betrieb. Zweitpartner klären wir im Einzelfall.

Wie reduziere ich die Abhängigkeit von einem Partner?

Setzen Sie QES nur dort ein, wo sie nötig ist, halten Sie Konfiguration und Zustandsmodell partnerunabhängig, dokumentieren Sie die Lieferkette und sprechen Sie bei kritischen Fällen früh über Zweitpartner.

Wo wird Sign2x gehostet?

Auf der Open Sovereign Cloud (OSC) von T-Systems. Für den QTSP-Partner sollten Sie Standort, Eigentum und Rechtsrahmen gesondert prüfen.