SSO, SCIM und Passkeys im SaaS-Vertrag: Identitätsverwaltung, Offboarding und Haftung regeln

Am Montag verlässt ein Administrator das Unternehmen. Sein Konto wird in Entra ID deaktiviert, doch die Deprovisionierung beim wichtigen SaaS-Anbieter scheitert unbemerkt. Das Benutzerkonto bleibt aktiv, eine vorhandene Sitzung läuft weiter und der frühere Mitarbeiter kann weiterhin auf sensible Daten zugreifen. Solche Fälle entstehen selten wegen fehlender Technik. Meist fehlen klare vertragliche Vorgaben dafür, wer welche Systeme pflegt, wie Fehler erkannt werden und wer für Verzögerungen beim Rechteentzug einsteht.

Single Sign On, SCIM und Passkeys verschieben die Benutzerverwaltung an die Schnittstelle zwischen deinem Unternehmen, dem Identity Provider und dem SaaS-Anbieter. Entra ID, Okta oder vergleichbare Systeme können Zugänge zentral steuern. Das reduziert den Aufwand und erhöht die Sicherheit, ersetzt aber keine vertragliche Regelung. Denn die technische Anbindung funktioniert nur innerhalb klar definierter Voraussetzungen, die im Betrieb auch eingehalten werden müssen.

Infografik zu SSO, SCIM und Passkeys im SaaS-Vertrag: Identitätsverwaltung, Offboarding und Haftung regeln (KI-generiert).

Identitätsverwaltung als Vertragsgegenstand verstehen

Viele SaaS-Verträge behandeln Anmeldung und Benutzerkonten nur am Rand. Häufig steht dort lediglich, dass der Dienst SSO „unterstützt“. Das genügt nicht. Entscheidend ist, welche Authentifizierungsverfahren, Schnittstellen und Sicherheitsfunktionen in deinem gebuchten Tarif tatsächlich enthalten sind und welche Verantwortung jede Partei trägt.

Der Vertrag oder eine technische Anlage sollte mindestens festhalten:

• welchen Identity Provider du einsetzen darfst
• ob SAML, OpenID Connect oder beide Verfahren verfügbar sind
• ob und in welchem Umfang SCIM für automatisiertes Provisioning und Deprovisioning bereitsteht
• welche Attribute zwischen Identity Provider und SaaS-Dienst übertragen werden
• welche Rollen, Gruppen und Berechtigungen automatisiert zugeordnet werden können
• ob lokale Benutzerkonten neben SSO erlaubt bleiben
• wie Passkeys eingerichtet, wiederhergestellt und entzogen werden
• welche Protokolle der Anbieter bereitstellt und wie lange sie verfügbar bleiben

Diese Punkte sind nicht nur Technikdetails. Sie bestimmen, ob du den Zugriff auf Geschäfts-, Kunden- oder Personaldaten wirksam kontrollieren kannst.

Bei personenbezogenen Daten ist die Identitätsverwaltung außerdem Teil des Datenschutzkonzepts. Zugriffsprotokolle, Benutzerkennungen und Rolleninformationen können selbst personenbezogene Daten sein. Der SaaS-Vertrag, die Datenschutzvereinbarung und die tatsächliche Konfiguration dürfen sich nicht widersprechen. Die Grundlagen dazu behandeln wir auch im Beitrag SaaS-Verträge, AVV und Datenschutz.

SSO: Verantwortlichkeiten zwischen Kunde und Anbieter trennen

Bei SSO authentifiziert dein Identity Provider die Nutzerin oder den Nutzer. Der SaaS-Anbieter vertraut dieser Anmeldung und gewährt auf dieser Grundlage Zugang. Daraus folgt jedoch nicht, dass der Anbieter von jeder Verantwortung für Zugriffsschutz befreit ist.

Du bist typischerweise verantwortlich für die Pflege der Identitäten im eigenen Verzeichnisdienst. Dazu gehören insbesondere Eintritt, Rollenwechsel, Abwesenheiten und Austritte. Ebenso verantwortest du die Absicherung des Identity Providers, etwa durch Mehrfaktor-Authentifizierung, starke Administratorkonten und passende Richtlinien.

Der SaaS-Anbieter muss dagegen sicherstellen, dass seine SSO-Implementierung korrekt arbeitet. Er darf etwa nicht akzeptieren, dass manipulierte oder abgelaufene Anmeldetoken verwendet werden. Er muss die vereinbarten Protokolle, Zertifikate und kryptografischen Verfahren unterstützen und Änderungen so ankündigen, dass du deine Konfiguration rechtzeitig anpassen kannst.

Wichtig ist auch die Frage lokaler Konten. Manche Anbieter erlauben weiterhin die Anmeldung mit Benutzername und Passwort, selbst wenn SSO aktiv ist. Das kann für einen Notfall sinnvoll sein, eröffnet aber einen Umgehungsweg. Vereinbare deshalb ausdrücklich:

• ob lokale Konten zulässig sind
• welche Rollen lokale Konten haben dürfen
• wer solche Konten anlegen und löschen darf
• ob für lokale Konten Mehrfaktor-Authentifizierung verpflichtend ist
• wie ihre Nutzung protokolliert und regelmäßig überprüft wird

Ein bloßes Verbot lokaler Konten kann problematisch werden, wenn dein Identity Provider ausfällt. Besser ist ein streng kontrolliertes Notfallverfahren.

SCIM: Provisioning ist kein Selbstläufer

SCIM automatisiert das Anlegen, Ändern und Löschen von Benutzerkonten. In der Praxis wird SCIM oft als Komfortfunktion eingeführt. Vertragsrechtlich und organisatorisch ist es aber ein zentraler Sicherheitsprozess. Wenn die Schnittstelle fehlschlägt, können Mitarbeitende falsche Rechte erhalten oder ausgeschiedene Personen behalten ihren Zugang.

Lege daher verbindlich fest, welche SCIM-Vorgänge unterstützt werden. Dazu zählen das Anlegen, Aktualisieren, Sperren und Löschen von Konten sowie die Zuordnung und Entziehung von Gruppen oder Rollen. Besonders wichtig ist die Unterscheidung zwischen Deaktivierung und Löschung. Eine Deaktivierung beendet idealerweise den Zugriff, erhält aber Protokolle und Zuordnungen. Eine Löschung kann Daten, Arbeitsstände oder Nachweise beeinträchtigen.

Für den Vertrag sind folgende Fragen entscheidend:

• Wird ein deaktivierter Benutzer im Identity Provider beim SaaS-Anbieter unverzüglich gesperrt?
• Welche maximale Bearbeitungszeit gilt für einen SCIM-Vorgang?
• Wie reagiert der Dienst, wenn die Schnittstelle nicht erreichbar ist?
• Werden fehlgeschlagene Vorgänge sichtbar protokolliert und gemeldet?
• Wer kontrolliert regelmäßig, ob Verzeichnis und SaaS-Benutzerbestand übereinstimmen?
• Können Rollenänderungen über SCIM zuverlässig erfolgen oder sind manuelle Schritte nötig?
• Was geschieht mit Eigentum an Dateien, Workflows oder Freigaben eines deaktivierten Kontos?

Formuliere nicht nur ein abstraktes Ziel wie „zeitnahe Deprovisionierung“. Vereinbare einen messbaren Ablauf. Beispielsweise kann der Anbieter verpflichtet sein, eine empfangene Deaktivierung ohne schuldhaftes Zögern umzusetzen, Fehler zu protokollieren und bei wiederholtem Fehlschlagen einen definierten Supportweg bereitzustellen.

Der Anbieter darf dabei nicht pauschal für Fehler in deinem Identity Provider haften. Er muss aber für Fehler in seiner Schnittstelle, fehlerhafte Verarbeitung gültiger SCIM-Anfragen und unzureichende Fehlerhinweise einstehen. Umgekehrt musst du sicherstellen, dass relevante Austritte und Berechtigungsänderungen im führenden Verzeichnisdienst tatsächlich gepflegt werden.

Offboarding braucht Fristen, Kontrollen und einen manuellen Ersatzweg

Das Offboarding ist der kritische Moment der Identitätsverwaltung. Im Streitfall reicht es nicht, darauf zu verweisen, dass SCIM „normalerweise“ funktioniert. Du brauchst nachvollziehbare Prozesse für den Normalfall, für Schnittstellenfehler und für besonders kritische Austritte.

Definiere deshalb unterschiedliche Fälle. Bei einem regulären Austritt kann die automatische Deaktivierung ausreichen, sofern sie überwacht wird. Bei einem sicherheitsrelevanten Vorfall, einer fristlosen Trennung oder dem Verdacht auf Missbrauch muss ein beschleunigter manueller Sperrweg möglich sein.

Der Vertrag sollte regeln, über welchen Kanal du eine dringende Sperrung anfordern darfst, welche Informationen dafür erforderlich sind und welche Reaktionszeit der Anbieter schuldet. Diese Reaktionszeit gehört in das Support- und Servicekonzept, nicht in eine unverbindliche Produktbeschreibung. Wie du Störungsklassen sauber abgrenzt, erläutern wir in Support-Level und Störungsklassen abgrenzen.

Eine praxistaugliche Offboarding-Checkliste umfasst:

• Austritt oder Rechtewechsel im führenden Verzeichnisdienst erfassen
• erfolgreiche SCIM-Verarbeitung technisch bestätigen
• vorhandene SaaS-Sitzungen und API-Token widerrufen
• privilegierte Rollen gesondert prüfen
• Eigentum an Daten, Dashboards und Workflows übertragen
• lokale Notfallkonten kontrollieren
• Abweichungen zwischen Identity Provider und SaaS-Dienst regelmäßig abgleichen
• Protokollnachweise für kritische Sperrungen sichern

Plane außerdem regelmäßige Rezertifizierungen ein. Fachverantwortliche sollten prüfen, ob Rollen, Gruppen und privilegierte Konten noch erforderlich sind. Das ist besonders wichtig, wenn der SaaS-Anbieter eigene Berechtigungsmodelle verwendet, die sich nicht vollständig über SCIM abbilden lassen.

Passkeys: Passwortlos anmelden, Wiederherstellung kontrollieren

Passkeys verringern Risiken durch schwache oder wiederverwendete Passwörter. Sie basieren in der Regel auf einem kryptografischen Schlüsselpaar und können an Geräte, Plattformen oder Synchronisationsdienste gebunden sein. Im SaaS-Vertrag genügt es nicht, die Unterstützung von Passkeys zu erwähnen. Du musst verstehen, welche Wiederherstellungswege der Anbieter zulässt.

Ein Passkey ist nur so sicher wie sein Rücksetzprozess. Wenn ein Nutzer den Zugang über eine E-Mail-Adresse, einen Helpdesk-Anruf oder eine alternative Anmeldung wiederherstellen kann, entsteht möglicherweise ein schwächerer Umgehungsweg. Vereinbare daher Mindestanforderungen für die Kontowiederherstellung und für besonders privilegierte Rollen.

Kläre insbesondere:

• ob Passkeys verpflichtend, optional oder nur ergänzend zu anderen Verfahren nutzbar sind
• ob Passkeys mit Hardware-Sicherheitsschlüsseln funktionieren
• ob synchronisierte Passkeys zulässig sind und welche Risiken du akzeptierst
• wie Verlust oder Gerätewechsel behandelt werden
• welche Identitätsprüfung bei der Wiederherstellung erforderlich ist
• ob Administratoren Passkeys zurücksetzen können und wie dies protokolliert wird
• ob ein Wechsel von Passkey auf Passwort ohne deine Freigabe möglich ist

Bei Konten mit weitreichenden Berechtigungen solltest du strengere Anforderungen vereinbaren als für Standardnutzer. Das kann etwa eine zusätzliche Freigabe, eine verpflichtende Protokollprüfung oder den Einsatz separater Administratorkonten betreffen.

Notfallzugänge ohne dauerhafte Hintertür

Fällt Entra ID, Okta oder ein anderer Identity Provider aus, kann ein SSO-gebundener SaaS-Dienst unerreichbar sein. Das kann den Geschäftsbetrieb erheblich beeinträchtigen. Notfallkonten sind deshalb oft sinnvoll, müssen aber eng kontrolliert werden.

Ein gutes Konzept sieht wenige, namentlich verantwortete Notfallkonten vor. Diese Konten dürfen nicht im Alltag verwendet werden. Sie brauchen starke, getrennt verwahrte Anmeldemittel, verpflichtende Mehrfaktor-Authentifizierung und eine lückenlose Protokollierung. Jede Nutzung sollte einen Sicherheitsalarm auslösen und nachträglich überprüft werden.

Vertraglich sollte der Anbieter garantieren, dass solche Konten nicht ohne dokumentierten Grund erweitert, herabgestuft oder abgeschaltet werden. Ebenso wichtig ist ein Verfahren, falls der Anbieter selbst den Zugang wegen eines Sicherheitsvorfalls einschränkt. Die vereinbarte Verfügbarkeit allein hilft nicht, wenn dein Team zwar die Anwendung erreicht, sich aber nicht mehr anmelden kann. Für belastbare Servicewerte lies auch Verfügbarkeit und Reaktionszeiten im SLA.

Protokollierung, Nachweise und Haftung verknüpfen

Wenn ein Zugriffsvorfall untersucht wird, brauchst du belastbare Nachweise: Wer hat sich wann angemeldet, über welches Verfahren, mit welcher Rolle und von welcher technischen Quelle? Der Vertrag sollte deshalb regeln, welche Ereignisse protokolliert werden, wie lange Logs abrufbar bleiben und ob du sie exportieren kannst.

Mindestens relevant sind erfolgreiche und fehlgeschlagene Anmeldungen, Änderungen an SSO- und SCIM-Konfigurationen, Rollenänderungen, Kontoerstellung, Deaktivierung, Löschung, Nutzung von Notfallkonten sowie administrative Passkey-Rücksetzungen. Achte darauf, dass Zeitstempel nachvollziehbar sind und relevante Daten nicht ohne Vorankündigung gelöscht werden.

Haftungsklauseln müssen zu diesen Pflichten passen. Es wäre widersprüchlich, wenn der Anbieter verbindliche Sperr- und Protokollpflichten übernimmt, seine Haftung für deren Verletzung aber praktisch vollständig ausschließt. Zugleich solltest du keine unbegrenzte Haftung für Fehler aus deinem eigenen Identity Provider akzeptieren. Entscheidend ist eine klare Ursachenabgrenzung. Die allgemeinen Gestaltungsmöglichkeiten zeigen wir im Beitrag Haftung im IT-Vertrag sinnvoll begrenzen.

Vor Vertragsabschluss empfehlen wir bei uns einen gemeinsamen Termin von IT-Sicherheit, IAM-Verantwortlichen, Einkauf, Fachbereich und Recht. Prüft nicht nur die Produktdokumentation, sondern testet die wichtigsten Abläufe: Neueinstellung, Rollenwechsel, Austritt, SCIM-Ausfall, Verlust eines Passkeys und Ausfall des Identity Providers. Passende Seminare und Termine findest du bei uns auf cmt.de.

Am Ende gilt: SSO, SCIM und Passkeys sind keine isolierten Login-Funktionen. Sie sind ein vertraglich abzusichernder Kontrollprozess für Identitäten, Berechtigungen und Nachweise. Wenn du technische Abhängigkeiten, Notfallwege und Haftungsfolgen früh regelst, bleibt der SaaS-Zugang auch unter Stress kontrollierbar.