KI-Betrug zielt auf die Wahrnehmungsebene: Stimme, Gesicht, Dokumentenoptik, Schreibstil. Genau dort, wo Menschen entscheiden, ob etwas vertrauenswürdig ist, sind die Kosten für überzeugende Fälschungen kollabiert. Eine geklonte Stimme aus drei Sekunden Audiomaterial, ein Deepfake-Gesicht im Live-Videocall, eine bis ins Layout perfekt nachgebaute Rechnung mit getauschter IBAN: Diese Angriffe sind in den letzten 18 Monaten dokumentiert worden, im Schweizer Mittelland (Schwyzer CEO-Fraud im Januar 2026, mehrere Millionen Franken Schaden), in deutschen Handwerksbetrieben (Dachdecker im September 2025, beinahe 27'000 Euro nach IBAN-Manipulation) und in Personalabteilungen in ganz Europa, wo nordkoreanische Operateure mit synthetischen Identitäten Anstellungsverträge unterzeichnet haben. Wer die Fälle ausführlich nachlesen möchte, findet sie auf unserer Übersichtsseite zu KI-Betrug.

Als Schweizer Trust Service Provider zeigen wir hier auf, wie Sie technisch auf solche Angriffe antworten können – wie Sie vom «Sieht authentisch aus» zu «Lässt sich kryptografisch verifizieren» kommen. Wir zeigen, wie diese Verschiebung architektonisch funktioniert, gegen welche Angriffsklassen sie wirkt, wo ihre Grenzen liegen und wie sich ein Signaturservice in eine bestehende Systemlandschaft einbinden lässt.

Dabei behaupten wir nicht, qualifizierte elektronische Signaturen (QES) oder regulierte Siegel seien immun gegen KI. Sie schützen gegen drei bestimmte Angriffe: solche auf die Integrität eines Dokuments, die Authentizität des Ausstellers bzw. Signierenden und die Bindung einer Signatur bzw. eines Siegels an die Identität einer Person oder Organisation.

Der Beitrag richtet sich an Security Officers, Application Architects und Enterprise Architects, die die Frage beantworten müssen, wie eine Signaturlösung tatsächlich in ihren Stack passt und welche regulatorischen Anker dabei zu beachten sind. Er ergänzt unseren Praxisleitfaden für funktional Verantwortliche, der dieselben sechs Use Cases aus prozessualer Sicht beleuchtet.

1. Die Schicht-Verschiebung: von Wahrnehmung zu Verifikation

KI hat die Wahrnehmungsebene unsicher gemacht. Kryptografische Signaturen und Siegel machen Vertrauen zu einer technisch eindeutigen Entscheidung.

Generative KI hat die Kosten für überzeugende Fälschungen auf der Wahrnehmungsebene drastisch gesenkt. Stimmen für einen Anruf lassen sich aus drei Sekunden Audio rekonstruieren. Gesichter werden live im Videocall ersetzt. Dokumentenlayouts werden perfekt repliziert, oft inklusive der spezifischen Schriftarten und Druckartefakte einer Vorlage. Schreibstile lassen sich aus wenigen Trainingsdaten imitieren. Die Angriffsfläche, die in den letzten zwei Jahren gewachsen ist, ist genau die, mit der Menschen Vertrauenswürdigkeit bewerten.

Kryptografische Signaturen und Siegel agieren nicht auf dieser Ebene. Sie versuchen nicht, den Fälscher auf der Wahrnehmungsebene zu schlagen. Sie ersetzen die probabilistische Bewertung durch einen Menschen mit einer deterministischen technischen Verifikation: Bei elektronischen Signaturen und Siegeln wird der Dokumenteninhalt über asymmetrische Kryptografie an eine Identität gebunden – im zweiten Teil dieses Artikels zeigen wir im Detail, wie das funktioniert. Doch zunächst zu den Punkten, die Angreifer mit KI neu oder in grösserem Umfang als bisher bekannt ausnutzen.

2. Fünf KI-Angriffsvektoren und wo die Lücke schliesst

Fünf konkrete Angriffsklassen aus dem realen Bedrohungsbild – welche Lücke wird genutzt, wie schliessen QES oder Siegel sie, und wo liegen die Grenzen des jeweiligen Falls.

Vektor 1: Deepfake-Videointerviews bei Einstellungen

Angriff: Ein Bewerber mit synthetischer oder gestohlener Identität besteht das Videointerview mit einem Live-Deepfake, lädt einen generierten Ausweisscan hoch und reicht gefälschte Diplome und Referenzen ein. Pindrop, ein US-Anbieter für Voice-Fraud-Detection, fand 2025 in einer einzigen Stellenausschreibung über 800 Bewerbungen, von denen mehr als ein Drittel vollständig fabriziert war.

Lücke: Visueller und konversationeller Eindruck reicht nicht mehr für eine Identitätsentscheidung. Die menschliche Erkennung von Deepfakes liegt knapp über Zufallsniveau.

Schliessung: Die Ausstellung einer QES verlangt einen formellen Identifikationsprozess gegen ein amtliches Ausweisdokument mit physischen oder NFC-basierten Sicherheitsmerkmalen, durchgeführt von einem zertifizierten Trust Service Provider nach einem auditierten Verfahren. Die Signatur am Arbeitsvertrag bedeutet damit nicht mehr «die Person sah echt aus im Video», sondern «die Person hat die qualifizierte Identifikation bestanden und hält einen privaten Schlüssel, der an diese verifizierte Identität gebunden ist». Diese Hürde ist substanziell höher als das Bestehen eines Videointerviews. Wer den Vertrag fälschen will, muss damit nicht mehr nur überzeugende audiovisuelle Outputs erzeugen, sondern die Trust-Infrastruktur selbst angreifen: das regulierte Identitätsprüfungsverfahren und die alleinige Kontrolle über den privaten Schlüssel des verifizierten Unterzeichners.

Grenzen: QES verhindert deepfake-basierte Interviews nicht, jedoch einen effektiven Vertragsabschluss durch eine nicht identifizierte Person. Der Schutz liegt also nicht im Interview, sondern beim Vertragsschluss.

Vektor 2: Voice-cloned Anweisungen oder kompromittierte E-Mail-Konten

Angriff: Ein Telefonat mit geklonter Stimme oder ein gehacktes Mail-Konto eines Geschäftspartners triggert Änderungen an Verträgen, Bankverbindungen oder Lieferadressen. Der Schwyzer CEO-Fraud im Januar 2026 ist der dokumentierte Schweizer Beispielfall: mehrere Millionen Franken nach Asien überwiesen, ausgelöst durch eine geklonte Stimme am Telefon.

Lücke: Verbale oder mailbasierte Anweisungen werden in vielen Organisationen als Autorisierung akzeptiert, obwohl sie keine kryptografische Bindung an eine identifizierte Person tragen.

Schliessung: QES verlagert die Autorisierung aus dem verbalen oder Mail-Kanal heraus. Ein überzeugender Anruf allein kann keine Signatur erzeugen. Der legitime Schlüsselinhaber muss beim Trust Service Provider einen Authentifizierungs- und Signatur-Aktivierungsprozess durchlaufen. In Remote-QES-Architekturen umfasst dieser eine Multi-Faktor-Authentifizierung in Verbindung mit einer SCAL2-konformen Signaturbestätigung. Damit autorisiert der Unterzeichner explizit den spezifischen kryptografischen Signaturvorgang gemäss einem regulierten Prozess, der seine alleinige Kontrolle sicherstellt. Nur die tatsächlich verantwortliche Person bei einem Partnerunternehmen kann diese Unterschrift leisten.

Grenzen: Wenn der nachgelagerte Prozess weiterhin verbale Anweisungen ohne Signaturschritt akzeptiert, hilft QES nicht. Genau das war im Schwyzer Fall die Schwachstelle: die Überweisungen liefen ausserhalb eines Vertragsprozesses, direkt aus Telefonanweisungen heraus. Die Architektur muss die Signatur als harte Vorbedingung für Vertragsänderungen, Zahlungsanweisungen und Lieferänderungen verlangen, sonst bleibt die Lücke offen.

Vektor 3: KI-manipulierte Rechnungen im Übertragungsweg

Angriff: Eine PDF-Rechnung wird zwischen Aussteller und Empfänger abgefangen. Ein KI-Werkzeug ersetzt die IBAN, das Layout bleibt perfekt erhalten, der Empfänger merkt nichts. Im Dachdecker-Fall vom September 2025 hatten Angreifer Zugang zum E-Mail-Postfach des Inhabers, manipulierten die IBAN im PDF und leiteten die Rechnung weiter. Nur eine aufmerksame Buchhalterin verhinderte die Zahlung.

Lücke: Der Empfänger kann visuell nicht erkennen, ob das PDF unterwegs verändert wurde. Eine geänderte IBAN sieht genauso aus wie die ursprüngliche.

Schliessung: Das regulierte elektronische Siegel des Ausstellers bindet den Dokumenteninhalt über seinen kryptografischen Hash an die ausstellende Organisation. Jede Modifikation nach dem Siegeln, einschliesslich einer einzelnen geänderten Ziffer in der IBAN, verändert den Dokumenten-Hash und invalidiert das Siegel kryptografisch. Das Verifikationswerkzeug des Empfängers, jeder gängige PDF-Reader oder der kostenlose Validator des Bundes, signalisiert das automatisch.

Grenzen: S/MIME schützt den Mailkanal, aber nur, solange die E-Mail im Originalkanal bleibt und ein Schlüsseltausch erfolgt ist. Das Siegel schützt das Dokument selbst, unabhängig vom Übertragungsweg und auch beim mehrfachen Weiterleiten oder Ausdrucken. Beide Mechanismen ergänzen sich; keiner ersetzt den anderen vollständig.

Vektor 4: Synthetische Identitäten bei Kontoeröffnung und Policenabschluss

Angriff: KYC-Prozesse werden mit KI-generierten oder gestohlenen Identitäts-Artefakten überwunden, die für automatisierte Prüfungen authentisch aussehen. Ein deutscher Tierkrankenversicherer hat 2024 und 2025 mehrere Fälle dokumentiert, in denen Hundeoperationen mit KI-generierten Röntgenbildern und gefälschten Rechnungen vorgetäuscht wurden, basierend auf Identitäten, die rein maschinell erzeugt waren.

Lücke: Bildbasierte Prüfung hilft nicht gegen hochwertige Fälschungen. Eine PDF-Kopie eines Ausweises ist trivial generierbar.

Schliessung: QES verhindert synthetischen Identitätsbetrug nicht primär auf der Dokumentenebene, sondern auf der Ebene der Identitätsfeststellung. Bevor ein qualifiziertes Zertifikat ausgestellt werden kann, muss der Antragsteller einen regulierten Identitätsprüfungsprozess bei einem Trust Service Provider durchlaufen, der auf amtlichen Ausweisdokumenten und auditierten Verifikationsverfahren basiert, wo möglich mit biometrischer Chip-Auslesung. Er ist gegen einen definierten regulatorischen Standard auditierbar, namentlich FINMA-Rundschreiben 2016/7, eIDAS-Anforderungen und ETSI TS 119 461. Synthetische Identitäten überleben diesen Schritt nicht, weil sie kein authentisches Ausweisdokument zur Verfügung stellen können.

Grenzen: Echte gestohlene Identitäten in Kombination mit weiteren Angriffselementen (gestohlener Ausweis plus Deepfake plus mitwirkende Person für die Liveness-Prüfung) bleiben ein Restrisiko. Die Hürde liegt aber substanziell höher als bei rein bildbasierten Prüfungen, und die Schweizer E-ID sowie das EUDI Wallet werden diesen Schutz künftig weiter verstärken.

Vektor 5: KI-generierte gefälschte Zertifikate und Diplome

Angriff: Ein Bewerber legt ein gefälschtes Diplom einer renommierten Universität vor. Optisch ist es vom Original nicht zu unterscheiden, weil generative KI Layout, Siegel, Unterschrift und Papiertextur überzeugend nachbildet. Google Threat Intelligence hat in den nordkoreanischen IT-Worker-Programmen erfundene Abschlüsse europäischer Universitäten dokumentiert, die genau auf diese Weise erzeugt wurden.

Lücke: Visuelle Inspektion eines PDF kann einen hochwertigen KI-Fake nicht von einem echten Dokument unterscheiden. Ein Rückruf bei der ausstellenden Institution skaliert nicht.

Schliessung: Das regulierte elektronische Siegel der ausstellenden Institution bindet das Credential an die verifizierte juristische Identität der Institution. Die Verifikation gegen offizielle Trust-Anker wie die EU Trusted List oder die Swiss Trusted List verwandelt die Authentizitätsprüfung von einer subjektiven menschlichen Bewertung in einen deterministischen kryptografischen Verifikationsprozess.

Grenzen: Wer das Credential nicht prüft, ist nicht geschützt. Der Schutz funktioniert nur, wenn die empfängerseitige Verifikation in den Geschäftsprozess eingebaut ist. Eine HR-Abteilung, die Diplome nur visuell sichtet, profitiert auch von gesiegelten Diplomen nicht. Die Architektur des Verifikationsschritts ist also genauso wichtig wie das Siegeln selbst.

3. Wie eine Signatur tatsächlich entsteht: der Prozess in fünf Schritten

Eine Signatur durchläuft fünf Schritte vom Dokumenterstellen bis zum Verifizieren beim Empfänger. Wer den Ablauf kennt, kann sauber argumentieren, an welcher Stelle welcher Trust-Anker greift und wie am besten in die Architektur integriert wird.

Das gleiche Prinzip gilt sinngemäss für Siegel, nur dass dort die Identität einer Organisation gebunden wird, nicht einer natürlichen Person.

Schritt 0 (einmalig): Identifikation des Unterzeichners

Bevor jemand eine QES überhaupt nutzen kann, muss er sich gegenüber dem Trust Service Provider identifizieren. Das ist kein Schritt in jedem Signaturvorgang, sondern eine einmalige Hürde vor der ersten Nutzung, vergleichbar mit einer Kontoeröffnung. Der TSP prüft die Person gegen ein amtliches Ausweisdokument, typischerweise per Video-Identifikation, per Auto-Identifikation auf dem Smartphone (basierend auf ETSI TS 119 461) oder künftig per Schweizer E-ID. Das Verfahren ist gegen einen regulatorischen Standard auditiert.

Nur mit einer auf dem erforderlichen Niveau verifizierten Identität kann ein qualifiziertes Zertifikat ausgestellt werden, das diese verifizierte Identität an einen privaten Schlüssel im HSM des TSP bindet. Genau dieser Schritt ist der eigentliche Hebel gegen KI-Betrug: Synthetische Identitäten und reine Bildscan-Ausweise scheitern hier. Wer in der späteren Signaturoperation den Schlüssel auslöst, ist nachweislich die Person, deren Identität der TSP einmalig formell verifiziert hat.

Schritt 1: Dokument wird erstellt

Im Ausgangssystem entsteht das Dokument, etwa eine Rechnung aus dem ERP, ein Vertrag aus dem Contract-Lifecycle-Management oder ein Diplom aus dem Campus-Management-System. Das Dokument liegt zu diesem Zeitpunkt als unsignierte Datei vor, typischerweise als PDF, alternativ als XML oder anderes strukturiertes Format. Der Inhalt ist final, denn jede spätere Änderung würde eine Signatur ungültig machen.

Architektur-Hinweis: Der Punkt der Dokumentenerstellung ist auch der natürliche Punkt für die Signatur- oder Siegelintegration. Je näher die Signatur am Erstellungspunkt ansetzt, desto schwerer wird das Dokument unterwegs manipulierbar.

Schritt 2: Hash wird berechnet

Es wird ein kryptografischer Hash des Dokuments berechnet, typischerweise SHA-256. Dieser Hash ist eine eindeutige Kurzfassung des Inhalts. Würde das Dokument auch nur um eine einzige Ziffer geändert, ergäbe der Hash einen komplett anderen Wert.

Bei cloud-basierten Services wird das Dokument für diese Verarbeitung in das Signatur-Portal hochgeladen, zum Beispiel den Signatur-Service Web von SwissSign. Beim Hash-Signing hingegen wird nur dieser Hash an den Trust Service Provider übermittelt, nicht das Dokument selbst. Das Dokument verbleibt damit in der Kontrolle der ausstellenden Organisation.

Schritt 3: Trust Service Provider signiert den Hash mit dem privaten Schlüssel des Unterzeichners

Beim TSP wartet der private Schlüssel des Unterzeichners in einem zertifizierten Hardware Security Module (HSM). Bevor er für die Signaturoperation freigegeben wird, muss sich der Unterzeichner mit einer Multi-Faktor-Authentifizierung authentifizieren, die die alleinige Kontrolle (sole control) über den privaten Schlüssel sicherstellt. Diese Authentifizierung greift auf das Identifikationsergebnis aus Schritt 0 zurück: Nur die einmalig verifizierte Person kann den ihr zugeordneten Schlüssel auslösen. Genau das erfüllt die rechtliche Anforderung der «alleinigen Kontrolle» über den Schlüssel.

Erst nach erfolgreicher Authentifizierung wird der Hash des Dokuments signiert. Das Ergebnis ist ein kryptografischer Wert (der «signierte Hash»), der nur mit genau diesem Schlüssel hätte erzeugt werden können. Bei einer qualifizierten Signatur wird zusätzlich ein qualifizierter Zeitstempel angehängt, der den Signaturzeitpunkt nachweisbar fixiert. Genau dieser Zeitstempel ist im Schweizer Recht erforderlich, damit die QES der handschriftlichen Unterschrift gleichgestellt ist.

Schritt 4: Signatur wird ins Dokument eingebettet und ausgegeben

Der signierte Hash wird nun zusammen mit dem Zertifikat des Unterzeichners und den Zeitstempel-Daten in das Dokument eingebettet, nach einem standardisierten ETSI-Profil (für PDF ist das PAdES gemäss ETSI EN 319 142, siehe Abschnitt 4).

Das Dokument ist jetzt signiert und kann ausgegeben werden, also per E-Mail versendet, in einem Portal bereitgestellt, archiviert oder anderweitig verteilt. Wichtig: Die Signatur ist Teil des Dokuments und reist mit ihm. Auch nach mehrfachem Weiterleiten, Speichern oder Ausdrucken bleibt sie im PDF-Reader prüfbar.

Schritt 5: Empfänger verifiziert die Signatur

Der Empfänger öffnet das Dokument in einem PDF-Reader oder einem speziellen Validator (etwa dem kostenlosen Validator des Bundes). Die Software führt automatisch drei Prüfungen durch.

Erstens, die Integritätsprüfung. Der Hash des aktuellen Dokuments wird neu berechnet und mit dem Hash in der Signatur verglichen. Stimmen beide überein, wurde das Dokument seit der Signatur nicht verändert. Stimmen sie nicht überein, ist die Signatur «gebrochen» und der Reader zeigt eine deutliche Warnung.

Zweitens, die Zertifikatsprüfung. Das eingebettete Zertifikat wird gegen die offizielle Trust List geprüft, also die EU Trusted List für eIDAS oder die Schweizer Trusted List für ZertES. Damit wird sichergestellt, dass das Zertifikat von einem anerkannten Trust Service Provider ausgestellt wurde und zum Zeitpunkt der Signatur gültig war.

Drittens, die Identitätsprüfung. Der Reader zeigt an, wer signiert hat: bei einer QES eine natürliche Person mit verifiziertem Namen, bei einem Siegel eine Organisation mit verifiziertem Eintrag im Handelsregister oder einem vergleichbaren Verzeichnis. An dieser Stelle schliesst sich der Kreis zu Schritt 0: Der Empfänger kann sich darauf verlassen, dass die angezeigte Identität durch den TSP formell verifiziert wurde.

Die Verifikation ist binär: alle drei Prüfungen erfolgreich, oder die Signatur ist ungültig. Das ist genau die Verschiebung, die wir in Abschnitt 1 beschrieben haben: weg von «sieht authentisch aus», hin zu «verifiziert gegen eine Vertrauenskette».

Was das für die Langlebigkeit bedeutet

Eine Signatur hat ein Verfallsdatum, weil das zugrundeliegende Zertifikat irgendwann abläuft, typischerweise nach drei Jahren. Damit ein Dokument auch in zehn oder zwanzig Jahren noch verifizierbar ist, kommt das PAdES-LTV-Profil zum Einsatz. Es bettet alle nötigen Validierungsdaten direkt ins Dokument ein: das Zertifikat, die zum Signaturzeitpunkt gültigen Sperrlisten und qualifizierte Zeitstempel. Damit funktioniert die Verifikation auch dann noch, wenn die ursprünglichen Online-Dienste längst nicht mehr erreichbar sind. Für Langzeitarchivierung, Audits und spätere Rechtsstreitigkeiten ist das die Voraussetzung, um signierte Dokumente beweistauglich zu halten.

4. Regulatorischer Rahmen für Signaturen und Siegel

Diese Liste ist zur Orientierung gedacht, nicht erschöpfend. Sie deckt die Standards ab, die in den meisten Architektur- und Compliance-Diskussionen tatsächlich auftauchen.

• eIDAS 2.0 (Verordnung EU 2024/1183): QES rechtlich gleichwertig zur handschriftlichen Unterschrift in der gesamten EU. Neue Vertrauensdienst-Kategorien einschliesslich Qualified Electronic Attestation of Attributes. EUDI-Wallet-Mandate für öffentliche und regulierte Sektoren bis Ende 2026.

• ZertES (Schweiz): QES gleichwertig zur handschriftlichen Unterschrift. Wichtige Schweizer Spezifität: Schweizer QES verlangt einen qualifizierten Zeitstempel für die Schriftform-Gleichwertigkeit, was eIDAS so nicht explizit fordert.

• Lücke zwischen beiden Rechtsräumen: Keine automatische gegenseitige Anerkennung zwischen Schweizer QES und EU-QES. Verhandlungen laufen. Organisationen, die grenzüberschreitend zwischen CH und EU operieren, müssen für beide Rechtsräume planen. SwissSign ist als Qualified Trust Service Provider für beide zertifiziert.

• FINMA-Rundschreiben 2016/7: Video- und Online-Identifizierungs-Anforderungen für regulierte Finanzintermediäre. QES kann bestimmte manuelle Verifikationsschritte ersetzen. Aktuell in Teilrevision; die Anhörung lief bis 27. Februar 2026 und integriert die Schweizer E-ID als neuen Identifikationsweg.

• ETSI-Signaturprofile: PAdES (ETSI EN 319 142) für PDF, XAdES (ETSI EN 319 132) für XML, CAdES (ETSI EN 319 122) für binäre und formatunabhängige Signaturen. Baseline-Profile B-B, B-T, B-LT, B-LTA decken unterschiedliche Langlebigkeitsanforderungen ab.

5. Integration: wo Signaturservices tatsächlich andocken

Drei Deployment-Modelle

Grundsätzlich bieten Trust Service Provider oder Signaturdienste drei Modelle an, die sich hinsichtlich ihrer Vertraulichkeit und Integration unterscheiden: cloud-basierte Signaturdienste, Integration in Ihre Systeme oder der Betrieb in der eigenen Infrastruktur.

SwissSign ist der einzige Schweizer TSP, der alle drei Modelle aus einer Hand anbietet und für alle das gleiche Schweizer Souveränitätsniveau garantiert. Die Wahl des Modells bei SwissSign folgt daher Ihrer Netzwerktopologie, Datenkontroll-Anforderungen, regulatorischen Constraints und Ihrem operativen Modell.

• Web-Service: Niederschwelliger Einstieg für punktuelle oder volumenmässig kleine Anwendungen, ohne Integration. Das Unternehmen lädt PDFs hoch, der Signaturprozess läuft hosted bei SwissSign. Mehr Details auf der Produktseite Web-Service.

• REST-API: Schnellste Time-to-Deploy, in der Schweiz gehostet. Standardmässig erfolgt die Dokumentenverarbeitung über die SwissSign-API. Hash-Signing als optionales Feature für Anwendungsfälle mit strengen Vertraulichkeitsanforderungen, bei denen Dokumente die Organisationsgrenze nicht überqueren sollen. Mehr Details auf der Produktseite REST-API.

• On-Premises: Die SwissSign-Software läuft innerhalb der Unternehmensgrenzen und übernimmt Dokumentenverarbeitung, Workflow, Branding und die Anbindung an Kundensysteme. Hash-Signing ist integraler Bestandteil: Nur der Hash wird zur Signaturoperation an die SwissSign-Trust-Infrastruktur übermittelt, das Dokument selbst verlässt die Kundenumgebung nie. Der Souveränitätsgewinn liegt in der vollständigen Kontrolle über Dokumente, Metadaten, Workflows und Audit-Daten. Relevant bei strikter Datenresidenz, Netzwerk-Segmentierung oder Mandantentrennung. Mehr Details auf der Produktseite On-Premises.

Integrationspunkte in bestehender Infrastruktur

• ERP und Kernprozesse: Signatur am Punkt der Dokumentenerstellung, Batch-Sealing für hohe Output-Volumina wie Rechnungen, Statements oder Policen. Typische Integration über die Signaturservice-API von der Dokumentengenerierungs-Schicht aus.

• Document Management und Archiv: Signierte Dokumente werden in WORM-konformen Archiven abgelegt. PAdES-LTV stellt Verifizierbarkeit über Jahrzehnte sicher, ohne Abhängigkeit von Online-Diensten.

• Identity and Access Management: Step-up-Authentifizierung über bestehende Corporate IdPs (SAML, OIDC), optional mit mobilem zweiten Faktor. Signieren ist ein Schritt im IAM-Flow, nicht ein paralleles System.

• SIEM und Audit-Logging: Jede Signaturoperation produziert ein auditierbares Event mit Request, Authentifizierung, Schlüsselnutzung, Zeitstempel und Verifikation. Diese Events fliessen über Syslog oder API in bestehende SIEM-Pipelines.

• Mobile und Customer-facing Apps: Signaturflüsse werden in bestehende Apps via SDK oder über Redirect-basierte Flows eingebettet. Relevant für Banking, Versicherung und E-Government-Bürgerportale.

Branchenspezifische Hinweise

• Core Banking (Avaloq, Temenos, Finnova, FNZ): Integration typischerweise auf der Document-Output-Layer. Tiefere Analyse in unserem Beitrag zu Implementierungsherausforderungen in Finanzinstituten.

• Versicherungs-Kernsysteme: Integration bei Policen-Generierung und Claims-Workflow.

• Public-Sector-Dokumentensysteme: Integration mit bestehenden E-Government-Plattformen, oft als Shared Service über kantonale oder kommunale Behörden hinweg.

6. Sicherheits-Architektur-Überlegungen

Sechs Themen, die ein Security Officer prüfen wird.

• Zero-Trust-Ausrichtung: mTLS zwischen Komponenten, Step-up-Authentifizierung pro Signaturoperation, Least-Privilege-Enforcement, Mikrosegmentierung der Signatur-Infrastruktur.

• Audit und Beweissicherheit: Nicht-abstreitbare Logs für regulatorische Aufsicht und forensische Untersuchung. Jede Signaturoperation ist nachvollziehbar bis zur Authentifizierung des Unterzeichners. Bei On-Premises landen die anwendungsseitigen Audit-Daten in der Kundeninfrastruktur, die kryptografischen Operationen werden zusätzlich beim TSP protokolliert.

• Post-Quantum-Bereitschaft: Monitoring der NIST-Post-Quantum-Standards (FIPS 203 bis 205). Migrationspfad existiert: Das architektonische Pattern bleibt gültig, nur die zugrundeliegenden Algorithmen wechseln. Die Migration verantwortet SwissSign als TSP.

7. Referenzeinsatz im Schweizer Markt

PostFinance: Hash-Signing-API für Kreditkartenanträge

PostFinance, eines der grössten Schweizer Finanzinstitute mit rund 2,5 Millionen Privat- und Geschäftskunden, hat die qualifizierte elektronische Signatur von SwissSign in den Kreditkartenantrags-Prozess integriert. Die Architektur basiert auf der Hash-Signing-API: Dokumente verlassen das PostFinance-System nicht, nur der kryptografische Hash wird an den SwissSign-Service übermittelt. Die Signaturlösung ist mit Bankident PostFinance verknüpft, sodass bestehende Kunden einen Kreditkartenantrag durchgängig digital signieren können, ohne sich erneut identifizieren zu müssen.

«Wir wollten unsere bereits verifizierten Identitäten für den E-Signaturprozess nutzen. Entscheidend war für uns, dass die Lösung keinen zusätzlichen Aufwand auf Kundenseite durch eine erneute Identifikation erzeugt. Die Signaturlösung von SwissSign hat das mühelos ermöglicht und uns einen schnelleren und komfortableren Prozess für unsere Kunden ermöglicht.» — Teodoro Pizzino, Customer Journey Owner Credit Cards bei PostFinance

• Deployment-Modell: REST-API mit Hash-Signing

• Trust-Service-Komponenten: QES, Identitätsanbindung über Bankident PostFinance

• Geschäftsergebnis: vollständig digitaler Kreditkartenprozess ohne Medienbruch, reduzierte Abbruchrate

Kanton Aargau: kantonsweite Trust-Service-Plattform

Der Kanton Aargau hat SwissSign Anfang 2026 mit dem Aufbau einer zentralen Lösung für elektronische Signaturen, regulierte Siegel und qualifizierte Zeitstempel beauftragt. Die Beschaffung erfolgte über die gemeinsamen Rahmenbedingungen von eOperations Switzerland. Die Plattform wird in der Verwaltung des Kantons sowie für angeschlossene Gemeinden nutzbar sein. Künftig können behördliche Verfügungen oder Verwaltungsmitteilungen mit einem elektronischen Siegel versehen werden, das die Authentizität und Integrität bestätigt. Verträge oder Vereinbarungen werden mit QES direkt im Browser unterzeichnet, und qualifizierte Zeitstempel sichern den Erstellungs- oder Eingangszeitpunkt von Dokumenten in digitalen Postfächern und Archiven nachweisbar ab.

• Deployment-Modell: zentrale Trust-Service-Plattform für Kanton und angeschlossene Gemeinden

• Trust-Service-Komponenten: QES, regulierte Siegel, qualifizierte Zeitstempel

• Anwendung: Verfügungen, Vereinbarungen, digitale Postfächer, Langzeitarchivierung

egovpartner / Kanton Zürich: Standardlösung für Gemeinden

Im Rahmen einer zentralen Beschaffung von egovpartner wurde SwissSign 2025 als Anbieter einer Standardlösung ausgewählt, die alle Gemeinden und Städte im Kanton Zürich beziehen können. Damit lässt sich die rechtsverbindliche elektronische Signatur in bestehende Fachanwendungen oder direkt im Browser integrieren, ohne dass jede Gemeinde einen eigenen Beschaffungsprozess durchlaufen muss. Anwendungsbereiche reichen von Bewilligungen über Verträge und Protokolle bis zu internen Freigaben.

• Deployment-Modell: abhängig von der Wahl der einzelnen Gemeinden

• Trust-Service-Komponenten: QES, optional regulierte Siegel

• Anwendung: einmalige Rahmenbeschaffung, individuelle Aktivierung pro Gemeinde

8. Warum jetzt der richtige Zeitpunkt ist

• eIDAS 2.0 Timeline: Bis zum 24. Dezember 2026 müssen alle EU-Mitgliedstaaten mindestens ein zertifiziertes EUDI Wallet für ihre Bürger bereitstellen. Ein Jahr später sind regulierte Sektoren wie Banken, Telcos, Healthcare und sehr grosse Online-Plattformen verpflichtet, das Wallet als Authentifizierungsmethode zu akzeptieren, sofern Nutzer es vorlegen. Die Wallet-Nutzung selbst bleibt für Bürger freiwillig. Heute geplante Architekturen sollten die Akzeptanz des EUDI Wallet antizipieren, damit sie 2027 nicht aufholen müssen.

• E-Rechnungsmandate: EU ViDA und das deutsche B2B-E-Rechnungsmandat treten schrittweise in Kraft. Empfangspflicht in Deutschland seit 1. Januar 2025, Versandpflicht ab 1. Januar 2027 für Unternehmen mit mehr als 800'000 Euro Umsatz, ab 1. Januar 2028 für alle inländischen B2B-Umsätze. Pflicht ist das strukturierte Format (XRechnung, ZUGFeRD), nicht das Siegel. Wer aber Authentizität und Integrität tatsächlich nachweisbar machen will, braucht ein Siegel zusätzlich zur Format-Compliance. Strukturierte und verifizierbare Rechnungen wechseln damit vom Best Practice zum Wettbewerbsvorteil.

• Schweizer E-ID-Rollout: Mit dem für 2026 erwarteten Rollout reduziert die Schweizer E-ID die Friktion bei der QES-Ausstellung und in bürgerseitigen Workflows. Heute geplante Architekturen sollten diese Integration antizipieren, damit sie bei Aktivierung der E-ID nicht nachgerüstet werden müssen.

Häufig gestellte Fragen

Dieser Beitrag gibt die Ansichten von SwissSign wieder und stellt keine Rechtsberatung dar.