AES vs QES per API: Leitfaden für Produktmanager und Architekten

SES, AES und QES im Blick: drei Stufen, drei Beweislogiken

Die eIDAS-Verordnung kennt drei Stufen elektronischer Signaturen, und jede erfüllt eine andere Aufgabe. Wer als Produktmanager oder Architekt eine Signaturfunktion in ein SaaS-Produkt einbaut, muss diese Stufen nicht auswendig zitieren, aber ihre Beweislogik verstehen. Denn aus der Stufe folgen Identifikationsaufwand, Nutzererlebnis, Kosten und Haftung. In diesem Leitfaden bleiben wir bei den Begriffen SES (einfache Signatur), AES (fortgeschrittene Signatur) und QES (qualifizierte Signatur). Im Deutschen sprechen wir von einfachen, fortgeschrittenen und qualifizierten Signaturen, wobei die Abkürzungen im Produktkontext gängiger sind.

Die einfache Signatur (SES) ist die niedrigste Stufe. Sie umfasst praktisch jede elektronische Zustimmung, die einem Dokument zugeordnet ist, etwa das Antippen einer Zeichnung oder das Setzen eines Häkchens mit Protokollierung. Rechtlich wird ihr die Wirkung nicht abgesprochen, aber der Beweiswert hängt stark von den Begleitumständen ab: Wer hat wann zugestimmt, und wie belegen Sie das? SES eignet sich für Vorgänge, bei denen das Gesetz keine besondere Form verlangt und das Streitrisiko gering ist.

Die fortgeschrittene Signatur (AES) stellt höhere Anforderungen. Sie muss dem Unterzeichner eindeutig zugeordnet sein, dessen Identifizierung ermöglichen, mit Mitteln erstellt werden, die der Unterzeichner mit hohem Maß an Vertrauen unter seiner alleinigen Kontrolle halten kann, und so mit den Daten verbunden sein, dass nachträgliche Änderungen erkennbar sind. Das ist mehr als ein Häkchen: Es braucht ein technisches Verfahren, das Identität und Integrität absichert, und es braucht Protokolle, die das belegen.

Die qualifizierte Signatur (QES) ist die höchste Stufe. Sie beruht auf einem qualifizierten Zertifikat und einer qualifizierten Signaturerstellungseinheit und wird von einem qualifizierten Vertrauensdiensteanbieter erbracht. Ihre rechtliche Besonderheit: Sie steht der handschriftlichen Unterschrift gleich. Wo das Gesetz die Schriftform verlangt und die elektronische Form zulässt, ist die QES der Weg dorthin. Die Beweislogik ist hier am stärksten, weil eine Vermutung zugunsten der Echtheit besteht und der Anbieter von der Aufsicht geprüft wird.

Die eine harte Unterscheidung dieses Leitfadens lautet: AES und QES unterscheiden sich nicht in der Technik des Klickens, sondern in der Verantwortungskette. Bei AES verantworten Sie als Anbieter des Produkts mit Ihrem Signaturdienst die Zuordnung und Integrität. Bei QES verantwortet ein qualifizierter Vertrauensdiensteanbieter Identifikation, Zertifikat und Signaturerstellung unter Aufsicht. Diese Verschiebung der Verantwortung erklärt, warum QES mehr Aufwand bedeutet und warum sie nur dort eingesetzt werden sollte, wo sie gebraucht wird.

Ein Missverständnis hält sich hartnäckig: dass eine höhere Stufe immer die bessere Wahl sei. Das stimmt nicht. QES erhöht Hürden für Nutzer, verursacht Kosten pro Vorgang und verlängert Prozesse. Wer sie für jeden Vorgang erzwingt, verliert Abschlüsse, ohne Rechtssicherheit zu gewinnen, die das Gesetz gar nicht verlangt. Umgekehrt ist AES bei Formvorschriften, die QES verlangen, schlicht unzureichend. Die Kunst liegt in der Zuordnung: die richtige Stufe für den richtigen Vorgang. Einen allgemeinen Überblick bietet der Beitrag SES, AES und QES in SaaS.

Wann AES reicht: der pragmatische Normalfall

In der Praxis ist AES für die große Mehrheit der Geschäftsvorgänge in SaaS-Produkten die richtige Stufe. Dazu zählen Rahmenverträge zwischen Unternehmen, Auftragsbestätigungen, Datenschutzvereinbarungen, Auftragsverarbeitungsverträge, interne Richtlinien mit Bestätigung, Einverständniserklärungen und viele Verträge, für die weder Gesetz noch Vereinbarung eine Schriftform vorsehen. Hier zählt, dass Sie im Streitfall belegen können, wer zugestimmt hat und dass das Dokument nicht verändert wurde. Genau dafür ist AES gebaut.

Der Gewinn liegt im Nutzererlebnis. Eine AES-Strecke kommt mit einer schlanken Identifikation aus, etwa der Bestätigung über einen verifizierten Zugang, eine Einmal-Authentifizierung oder eine zusätzliche Prüfung, die zur Einordnung des Risikos passt. Das reduziert Aufwand und Abbrüche, und es lässt sich vollständig in Ihre Oberfläche einbetten. Wie das ohne Medienbruch gelingt, beschreibt der Beitrag White-label Signatur-API ohne Medienbruch.

Bei der Entscheidung für AES lohnt eine nüchterne Risikobewertung. Wie hoch ist der Streitwert? Wie wahrscheinlich ist ein Bestreiten der Unterschrift? Wer sind die Beteiligten, und wie gut kennen sie sich? Welche Nachweise haben Sie ohnehin, etwa Vertragsbeziehung, E-Mail-Verkehr oder Kundenkonto? Bei Verträgen zwischen Geschäftspartnern mit laufender Beziehung ist das Streitrisiko meist gering, bei Erstkontakten mit hohem Wert höher. Dokumentieren Sie diese Abwägung, denn sie dient später als Begründung, warum Sie eine Stufe gewählt haben.

Besonders wichtig ist die Protokollierung. AES lebt davon, dass Sie belegen können, was geschehen ist: Wer wurde eingeladen, wann wurde das Dokument geöffnet, welche Identifikation fand statt, wann wurde signiert, und ist das Dokument seither unverändert? Diese Angaben kommen als Ereignisse aus der Signaturstrecke und gehören in Ihre eigene Datenhaltung. Wie Sie sie sauber verarbeiten, zeigt Webhook State Management für E-Signatur-Events.

Eine Grenze sollten Sie kennen: AES ersetzt keine gesetzlich vorgeschriebene Schriftform. Wenn ein Vorgang laut Gesetz oder Vereinbarung die Schriftform verlangt und die elektronische Form zulässt, genügt AES nicht, dann braucht es QES. Für Vorgänge, bei denen das Gesetz sogar die elektronische Form ausschließt, hilft auch QES nicht. Prüfen Sie diese Fragen mit Ihrer Rechtsberatung, statt sie im Produktteam zu raten.

Ein pragmatischer Tipp für Produktteams: Bauen Sie die Stufe als Konfiguration pro Vorlage oder Vorgangstyp, nicht als globale Einstellung. So können Sie in einem Mandanten Verträge mit AES und Arbeitsunterlagen mit QES führen, ohne zwei Produkte zu pflegen. Die Stufe ist dann eine Eigenschaft des Dokumenttyps, die Ihre Rechtsabteilung festlegt, nicht eine technische Entscheidung des Entwicklungsteams.

Wann QES Pflicht wird: Form, Risiko und Marktanforderung

QES wird in drei Konstellationen relevant. Die erste ist die gesetzliche Form: Wo das Gesetz die Schriftform verlangt und die elektronische Form erlaubt, ersetzt die QES die handschriftliche Unterschrift. Beispiele finden sich im Zivilrecht an mehreren Stellen, und es gibt zugleich Bereiche, in denen die elektronische Form ausgeschlossen ist, etwa bei bestimmten arbeitsrechtlichen Erklärungen. Die Details hängen vom Einzelfall und vom aktuellen Recht ab. Prüfen Sie deshalb jeden Dokumenttyp rechtlich, bevor Sie ihn digitalisieren.

Die zweite Konstellation ist die vertragliche oder regulatorische Anforderung. Manche Branchen, Behörden oder Großkunden verlangen QES, auch wenn das Gesetz es nicht zwingend vorsieht, etwa aus Gründen der Beweissicherheit oder interner Richtlinien. Im Finanz- und Immobilienumfeld begegnet Ihnen das häufig. Hier ist QES eine Marktanforderung, die Sie in Ihrem Produkt abbilden müssen, wenn Sie in diesen Märkten verkaufen wollen. Für geldwäscherechtlich geprägte Szenarien lohnt der Blick in den Beitrag GwG, Ident und QTSP bei E-Signatur.

Die dritte ist die Risikoentscheidung: Der Vorgang ist wertvoll oder streitanfällig genug, dass Sie maximale Beweiskraft wollen, auch ohne Zwang. Das ist legitim, aber es sollte eine bewusste Entscheidung sein, die Kosten und Reibung einpreist. Eine bewährte Praxis ist die gestaffelte Strecke: AES als Standard und QES als Option für Vorgänge ab einem bestimmten Wert oder für bestimmte Vertragspartner. Das erlaubt, Reibung dort einzusetzen, wo sie sich lohnt.

Für die Architektur folgt daraus: Planen Sie von Anfang an für mehrere Stufen, auch wenn Sie zunächst nur AES brauchen. Das heißt, die Stufe gehört in Ihr Datenmodell, in die Vorgangsanlage und in Ihre Ereignisse. Ihre Oberfläche sollte Platz für zusätzliche Schritte haben, etwa die Identifikation bei QES. Und Ihre Texte sollten an der richtigen Stelle erklären, was der Nutzer gerade tut. Wer das nachträglich einbaut, muss Datenmodell und Oberfläche umbauen, was deutlich teurer ist.

Auch der zeitliche Aspekt zählt. QES-Vorgänge dauern länger, weil Identifikation und Zertifikatserstellung hinzukommen. Ihre Prozesse sollten Wartezustände aushalten, etwa durch Erinnerungen, Fristen und saubere Statusanzeigen. Ein Vertrag, der zwei Tage auf die Identifikation eines Unterzeichners wartet, darf nicht in einem Zustand hängen, den Ihr System nicht versteht. Das Zustandsmodell aus Webhook State Management hilft dabei.

Payload und Identifikation: was Ihre API-Anfrage festlegt

In der Integration spiegelt sich die Stufe in der Anfrage, mit der Sie einen Signaturvorgang anlegen. Konzeptionell legen Sie fest: Welches Dokument soll signiert werden? Wer sind die Unterzeichner und in welcher Rolle und Reihenfolge? Welche Signaturstufe gilt? Welches Identifikationsverfahren ist erforderlich? Welche Referenzen aus Ihrem System sollen mitlaufen? Wohin sollen Ereignisse gehen? Die genauen Feldnamen und Werte entnehmen Sie der Dokumentation im Developer Hub, wir beschreiben hier die Logik.

Die Dokumentenseite ist meist unkritisch: Sie übergeben ein Dokument, oft ein PDF, und gegebenenfalls Positionen für Signaturfelder. Wichtig ist, dass Sie das Dokument vor der Übergabe finalisieren. Änderungen nach dem Start einer Signaturstrecke sind ein häufiger Fehler, weil sie zu Versionskonflikten führen. Berechnen Sie vor dem Start eine Prüfsumme und halten Sie sie in Ihrer Datenhaltung fest. So können Sie später belegen, dass das signierte Dokument dem übergebenen entspricht.

Die Unterzeichnerseite enthält Name, Kontaktweg und Rolle. Bei AES und QES kommen Daten hinzu, die für die Identifikation gebraucht werden. Ein Grundsatz der Datensparsamkeit: Übergeben Sie nur, was für die gewählte Stufe nötig ist. Je mehr Sie vorab übermitteln, desto mehr müssen Sie später begründen, schützen und löschen. Die DSGVO verlangt Zweckbindung und Minimierung, und das gilt auch für Signaturdaten.

Die Identifikation ist bei AES und QES der Bereich mit den meisten Entscheidungen. Je nach Verfahren kann sie über eine bestehende Authentifizierung, über Identitätsdokumente, über eID oder über bankgestützte Verfahren laufen. Welche Verfahren in welcher Stufe verfügbar sind, hängt von Anbietern und Partnern ab. Für Ihr Produkt zählen drei Eigenschaften: Wie hoch ist die Abbruchquote, wie lange dauert es, und welche Nachweise bleiben erhalten? Orientieren Sie sich an Ihren Nutzern, nicht an der Technik. Ein Verfahren, das Ihre Zielgruppe nicht mag, ist kein gutes Verfahren.

Bei den Ereignissen legen Sie fest, welche Zustandswechsel Ihr System erreichen sollen. Für AES und QES sind Identifikationsereignisse besonders wichtig, weil sie belegen, dass die Prüfung stattgefunden hat und mit welchem Ergebnis. Speichern Sie diese Ereignisse unverändert in Ihrer Historie. Bei Audits, etwa im Kontext von DORA oder NIS-2, sind genau diese Daten das Material, mit dem Sie Abläufe belegen. Mehr dazu liefert der Beitrag DORA Artikel 30 und der Signatur-Audit-Trail.

Ein letzter Hinweis zur Architektur: Kapseln Sie die Stufenlogik in einer Komponente. Statt an zehn Stellen zu prüfen, ob QES gilt, fragen Ihre Module eine zentrale Stelle, welche Anforderungen ein Dokumenttyp hat. Diese Stelle kennt Stufe, Identifikationsverfahren, Texte und Folgeprozesse. Wenn das Gesetz oder ein Kunde etwas ändert, ändern Sie es an einer Stelle. Das klingt selbstverständlich und wird in gewachsenen Systemen trotzdem selten umgesetzt.

Typische Fehlentscheidungen bei der Stufenwahl

Aus Beratungsgesprächen kennen wir vier Fehlentscheidungen, die sich wiederholen. Die erste ist die Pauschalstufe: Das Team entscheidet einmal, dass „alles mit QES“ laufen soll, weil das sicher klingt. Das Ergebnis sind längere Strecken, höhere Kosten und Nutzer, die abbrechen, obwohl für die Mehrzahl der Vorgänge AES genügt hätte. Die zweite ist die Unterschätzung: Ein Dokumenttyp läuft jahrelang mit AES, bis jemand feststellt, dass das Gesetz hier eine Form verlangt. Dann muss nachgerüstet werden, und alte Vorgänge sind angreifbar.

Die dritte Fehlentscheidung ist die Verwechslung von Identifikation und Stufe. Eine strenge Identifikation macht eine Signatur nicht automatisch zur QES, und eine QES-Strecke ohne saubere Dokumentation der Prüfung ist ein Risiko. Stufe und Identifikation sind verwandt, aber nicht dasselbe, und beides gehört in Ihr Datenmodell als getrennte Eigenschaften. Die vierte ist die Vernachlässigung des Nutzers: Eine rechtlich perfekte Strecke, die Nutzer nicht verstehen, erzeugt Supportaufwand und Abbrüche. Erklären Sie jeden Schritt in einem Satz. Das gilt besonders bei QES, wo Nutzer häufig zum ersten Mal ein qualifiziertes Zertifikat sehen. Sagen Sie vorab, wie lange der Vorgang dauert, welche Unterlagen bereitliegen sollten und was am Ende passiert. Ein kurzer Hinweis wie „Sie benötigen einen Ausweis und etwa fünf Minuten“ senkt die Abbruchquote spürbar, weil er Unsicherheit nimmt, bevor sie entsteht. Testen Sie solche Texte mit echten Nutzern und passen Sie sie an die Sprache Ihrer Zielgruppe an.

Ein praktisches Gegenmittel ist ein Stufenregister: eine Liste aller Dokumenttypen Ihres Produkts mit Stufe, rechtlicher Grundlage, Verantwortlichem und Datum der letzten Prüfung. Das Register ist kein Aufwandsmonster, sondern eine Tabelle, die Ihre Rechtsberatung einmal pro Jahr durchgeht. Ergänzen Sie in der Tabelle eine Spalte für Ausnahmen, etwa Vorgänge, die auf Kundenwunsch eine höhere Stufe erhalten, und eine für Dokumenttypen, die bewusst außerhalb der digitalen Strecke bleiben. Es verhindert, dass Entscheidungen im Kopf einzelner Personen liegen, und es liefert Auditoren und Kunden eine klare Antwort auf die Frage, warum Sie welche Stufe verwenden.

Zwei Beispiele machen den Unterschied greifbar. Eine Software für Personaldienstleister lässt Rahmenverträge mit Kundenunternehmen per AES zeichnen, weil die Parteien einander kennen und der Streitwert überschaubar ist. Für bestimmte personalrechtliche Dokumente prüft dieselbe Software dagegen, ob das Gesetz Schriftform verlangt, und lässt die Erklärung gegebenenfalls außerhalb der elektronischen Strecke. Eine Plattform für Immobilienverwaltung nutzt für Mieterkommunikation SES, für Verwaltungsverträge AES und für Verträge mit hoher Bindungswirkung QES. In beiden Fällen ist die Stufe eine bewusste, dokumentierte Konfiguration und keine Nebenwirkung der Implementierung.

Partner-QTSP bei QES: wer trägt was

Sign2x ist kein qualifizierter Vertrauensdiensteanbieter. Wir sind die API-Schicht, die SES, AES und QES in Ihr Produkt bringt. Für QES arbeiten wir mit Partner-QTSPs zusammen, etwa Sign8. Der Partner übernimmt die Teile, die der Gesetzgeber qualifizierten Anbietern vorbehält: Identifikation nach den geltenden Anforderungen, Ausstellung des qualifizierten Zertifikats und Erstellung der qualifizierten Signatur. Wir orchestrieren den Ablauf, liefern Ihnen die Ereignisse und kümmern uns um Betrieb und Integration.

Diese Aufteilung hat praktische Folgen. Erstens: Bei QES sind mehrere Parteien beteiligt, und Ihre Verträge sollten klären, wer wofür verantwortlich ist. Zweitens: Die Verfügbarkeit und Qualität der QES-Strecke hängt auch vom Partner ab, und Sie sollten das in Ihrer Kommunikation mit Kunden berücksichtigen. Drittens: Daten fließen zum Partner, und Ihre Dokumentation der Auftragsverarbeitung und Ihre Lieferkettendokumentation müssen das abbilden. Der Beitrag QTSP-Partner für ISVs vertieft das.

Zur Souveränität: Sign2x läuft auf der Open Sovereign Cloud (OSC) von T-Systems, einem europäischen Betrieb unter europäischem Recht. Das bezieht sich auf unsere Plattform. Bei QES kommt der Partner-QTSP hinzu, dessen Standort und Rechtsrahmen Sie ebenfalls prüfen sollten. Fragen Sie nach Verarbeitungsort, Eigentümerstruktur und Unterauftragnehmern, genau wie bei jedem Dienstleister in Ihrer Kette. Eine allgemeine Einordnung bietet Cloud Act vs Datensouveränität.

Ob ein QTSP aktuell als qualifiziert gilt, lässt sich öffentlich nachprüfen: Die Mitgliedstaaten führen Vertrauenslisten, und in Deutschland ist die Bundesnetzagentur als Aufsichtsstelle für Vertrauensdienste zuständig. Für Ihre Sorgfaltsdokumentation lohnt es, den Status Ihres Partners in Ihren Unterlagen festzuhalten und regelmäßig zu prüfen. Das ist im Zweifel ein Beleg dafür, dass Sie bei der Auswahl sorgfältig vorgegangen sind.

Für die Praxis empfehlen wir eine einfache Entscheidungsmatrix pro Dokumenttyp: Gilt eine gesetzliche Form? Verlangt der Kunde QES? Wie hoch ist der Streitwert? Wie viele Vorgänge erwarten wir? Welche Reibung nehmen Nutzer hin? Aus den Antworten ergibt sich die Stufe, und die Matrix dient als Dokumentation. Wer ohnehin unsicher ist, startet mit dem Sign2x Quiz und klärt offene Fragen im Help Center. Anwendungsfälle zeigt die Seite Use Cases, weitere Beiträge finden Sie im Sign2x Blog.

Zum Schluss: Wenn Sie eine Strecke von AES auf QES erweitern, planen Sie den Test mit echten Nutzern ein. QES-Strecken enthalten Schritte, die Nutzer nicht kennen, und kleine Unklarheiten in Texten führen zu Abbrüchen. Ein kurzer Test mit zehn Personen aus Ihrer Zielgruppe deckt die größten Probleme auf. Im Beitrag Von der Sandbox zur ersten QES-Strecke beschreiben wir den technischen Weg bis zum ersten funktionierenden Vorgang.

AES und QES in der Sandbox ausprobieren

Weiterführend: GwG-konforme Signatur-API für ISVs und eIDAS 2.0 und die EUDI Wallet für SaaS-Relying-Parties. Hinweise zur Informationssicherheit beim BSI.

Häufige Fragen

Was ist der Unterschied zwischen AES und QES?

AES ordnet die Signatur eindeutig dem Unterzeichner zu und macht Änderungen erkennbar. QES beruht zusätzlich auf einem qualifizierten Zertifikat eines qualifizierten Vertrauensdiensteanbieters und steht der handschriftlichen Unterschrift gleich.

Wann reicht AES aus?

Für die meisten Geschäftsvorgänge ohne gesetzliche Schriftform, etwa Rahmenverträge, Auftragsbestätigungen oder Einverständniserklärungen. Prüfen Sie Formvorschriften jeweils rechtlich.

Wann brauche ich QES?

Wenn das Gesetz die Schriftform verlangt und die elektronische Form zulässt, wenn Kunden oder Regulierung QES verlangen oder wenn Sie bewusst maximale Beweiskraft wählen.

Ist Sign2x ein qualifizierter Vertrauensdiensteanbieter?

Nein. Sign2x ist die API-Schicht für SES, AES und QES. Für QES läuft die Qualifikation über einen Partner-QTSP wie Sign8.

Kann ich mehrere Stufen im selben Produkt nutzen?

Ja. Legen Sie die Stufe pro Dokumenttyp oder Vorlage fest und kapseln Sie die Logik in einer Komponente, damit AES und QES nebeneinander laufen.