Softwarehersteller in DACH suchen keine weitere Signatur-App. Sie suchen eine E-Signatur Alternative Deutschland, die als API in der eigenen SaaS bleibt, eIDAS-fest ist und keine Drittlands-Jurisdiktion auf Mandantenverträge legt. Viele globale Plattformen werben mit EU-Rechenzentren. Das beantwortet die falsche Frage: Wo liegen die Bytes – nicht welches Recht den Betreiber bindet.
Was bedeutet Whitelabel E-Signatur wirklich?
Whitelabel heißt nicht: Ihr Logo im Footer einer fremden Signaturseite. Für Softwarehersteller bedeutet es, dass der gesamte Abschluss in Ihrer UX bleibt – Session, Corporate Design, Audit-Logs unter Ihrem Mandanten. Der Endkunde soll nicht merken, dass im Hintergrund eine Signatur-Engine arbeitet. Er soll merken, dass Ihre Plattform den Vertrag schließt.
Viele Anbieter nennen sich White-Label und liefern Co-Branding: Redirect aus Ihrer App, Login auf fremder Domain, E-Mails vom Signaturportal. Das ist für ISVs, die Mandantenverträge verarbeiten, kein Multiplikator-Modell. Es erzeugt Medienbruch, Support-Tickets außerhalb Ihres Ticketsystems und Reibung im Vertrieb, wenn der Kunde fragt, warum er ein zweites Konto braucht.
Die eIDAS-Verordnung definiert elektronische Signaturen und Vertrauensdienste auf EU-Ebene – unabhängig davon, ob Sie EES, FES oder QES einsetzen. Rechtliche Einordnung finden Sie bei der eIDAS-Verordnung auf EUR-Lex. Produktseitig geht es um die Einbettung: API, Whitelabel, Hosting. Beides muss zusammenpassen.
Für Entscheider in Produkt und Engineering lautet die Kurzversion: Whitelabel ist erreicht, wenn kein Schritt der Signatur-Strecke den Nutzer zwingt, Ihre Software zu verlassen oder eine zweite Identität beim Signaturanbieter anzulegen. Alles andere ist ein Kompromiss – und Kompromisse skalieren schlecht über hunderte Mandanten.
Anforderungen, an denen Whitelabel-Anbieter scheitern
Bevor Sie einen Anbieter binden, prüfen Sie diese Linien. Fehlt eine, zahlen Sie sie später in Engineering-Zeit:
- Mandantentrennung: Envelope, Zertifikate, Webhooks und Audit je Tenant – kein globaler Posteingang mit einer tenantId als einzigem Schutz.
- UX ohne Redirect: Signatur in Ihrer Session, nicht Portal-Login auf fremder Domain.
- Versand in Ihrem Namen: E-Mail, Link, SMS über Ihre Strecke und Absender – nicht die Marke des Signaturanbieters.
- eIDAS für Softwarehersteller: EES, FES, QES und elektronische Siegel in derselben API; Qualifizierung über QTSP-Partner wie Sign8, ohne dass die Engine selbst QTSP wäre.
- Deutsches Hosting: Verarbeitung auf STACKIT und Deutscher Telekom – keine Drittlands-Jurisdiktion auf Mandantenverträgen.
- On-Premise ohne Feature-Verlust: volle Pipeline lokal, wenn der Kunde kein SaaS darf – nicht nur eine Schlüssel-Appliance.
Das Bundesamt für Sicherheit in der Informationstechnik ordnet Vertrauensdienste und Sicherheitsanforderungen im nationalen Kontext ein – hilfreich für Ausschreibungen mit hohen Anforderungen: BSI zu Vertrauenswürdigen Dienstleistungen.
On-Premise und Whitelabel: kein Entweder-oder
Regulierte Mandanten verlangen On-Premise. Viele Angebote liefern eine Appliance für Schlüssel, während Workflow und Dokumente in einer Auslands-Cloud bleiben. Das bricht Whitelabel und Souveränität gleichzeitig.
Echtes On-Premise bedeutet denselben Funktionsumfang wie SaaS: EES, FES, QES, Siegel, Whitelabel, Versand per E-Mail, Link, SMS, REST-API – im eigenen Rechenzentrum. Sign2x stellt beide Betriebsmodi ohne Feature-Schnitt. Mehr dazu im Blog zu On-Premise E-Signatur.
RFP schreiben: Anforderungen statt Markennamen
Schreiben Sie in der Ausschreibung Funktionen, nicht Vendor-Listen. Diese Formulierungen trennen echtes Whitelabel von Marketing:
- „Signatur vollständig in unserer UX, ohne Portal-Login des Anbieters.“
- „Versandkanäle E-Mail, Link, SMS unter unserer Marke und Domain.“
- „Mandantentrennung auf Envelope-, Webhook- und Audit-Ebene.“
- „Hosting und Verarbeitung ausschließlich in Deutschland, Betreiber ohne Drittlands-Jurisdiktion.“
- „eIDAS EES, FES, QES und Siegel über angebundenen QTSP; Engine kein QTSP.“
- „On-Premise mit gleichem API-Umfang wie SaaS.“
Wer EU-Server eines ausländischen Mutterkonzerns als Souveränität verkauft oder On-Premise nur als Add-on mit Feature-Verlust anbietet, fällt an diesen Sätzen durch. Sign2x ist für Multiplikatoren gebaut: API-first, Whitelabel, bis zu 20 % niedrigere Lizenzkosten gegenüber vergleichbaren Anbietern.
Häufige Fragen
Was muss eine Whitelabel-Signatur für ISVs können?
Mandantentrennung auf Envelope- und Webhook-Ebene, Signatur in Ihrer UX ohne fremdes Portal, Versand unter Ihrer Marke (E-Mail, Link, SMS), eIDAS-Level inklusive Siegel, Hosting ohne Drittlandzugriff und optional On-Premise ohne Feature-Verlust.
Wie unterscheidet sich Whitelabel von Co-Branding?
Co-Branding zeigt zwei Marken – Redirect, fremde Domain, Absender des Signaturanbieters. Whitelabel zeigt nur Ihre Marke auf der gesamten Strecke: UI, Versand, Abschluss und Audit in Ihrer Software.
Reicht ein iFrame für Multi-Tenant-SaaS?
Ein iFrame kann Demos beschleunigen, bindet Nutzer aber an fremde Domain und Session. Für produktive Multi-Tenant-Architekturen ist eine native REST-API mit Whitelabel in der eigenen Oberfläche der robustere Weg.
Ist Sign2x ein QTSP?
Nein. Sign2x ist die Signatur- und Workflow-Engine. Qualifizierte Signaturen und Siegel laufen über angebundene QTSPs wie Sign8. Die Engine hostet in Deutschland auf STACKIT und Deutscher Telekom.
Warum gehört deutsches Hosting zu Whitelabel?
Whitelabel betrifft auch Vertragsdaten und Metadaten. Liegen diese unter Drittlands-Jurisdiktion, tragen ISVs das Risiko – auch wenn die UI Ihre Marke zeigt. Verarbeitung in Deutschland ohne Cloud-Act-Exposition schließt diese Lücke.
