Single Sign-On im Mittelstand: ein Login für alle Systeme

Single Sign-On (SSO) heißt Einmalanmeldung: Ihre Mitarbeiter melden sich einmal zentral an und erreichen danach alle angebundenen Anwendungen ohne neues Passwort. Ein Identitätsanbieter prüft die Anmeldung und bestätigt sie den Anwendungen über Standards wie SAML oder OpenID Connect. SSO beendet den Passwort-Wildwuchs — sicher wird es aber erst zusammen mit Mehr-Faktor-Authentifizierung.

1. Was ist Single Sign-On — und wie läuft eine Anmeldung ab?

Das Bundesamt für Sicherheit in der Informationstechnik bringt es in einem Satz auf den Punkt: Single-Sign-On bedeutet übersetzt Einmalanmeldung (Quelle: BSI). Ein zentraler Anbieter — der Identitätsanbieter oder Identity Provider — übernimmt die Prüfung, wer Sie sind. Alle angeschlossenen Anwendungen verlassen sich auf dieses Urteil, statt eigene Passwörter zu verwalten.

Der Ablauf ist immer derselbe, egal ob Warenwirtschaft, Buchhaltung oder Projekt-Tool:

1. Sie rufen die Anwendung auf. Sie erkennt, dass keine gültige Sitzung besteht.
2. Die Anwendung leitet Sie an Ihren Identitätsanbieter weiter.
3. Dort melden Sie sich an — mit Passwort oder Passkey und mit zweitem Faktor. Besteht die Sitzung schon, entfällt dieser Schritt und Sie merken vom Umweg nichts.
4. Der Identitätsanbieter schickt eine signierte Bestätigung an die Anwendung zurück. Sie enthält, wer Sie sind und wie Sie sich angemeldet haben — aber nie Ihr Passwort.
5. Die Anwendung prüft die Signatur und öffnet Ihre Sitzung.

Wichtig für die Einordnung: SSO ist kein Passwortmanager. Ein Passwortmanager speichert viele Passwörter und füllt sie ein — die Anwendungen behalten ihre eigene Benutzerverwaltung. Bei SSO existiert für die angebundene Anwendung gar kein separates Passwort mehr. Das ist der Grund, warum SSO das Offboarding tatsächlich löst und ein Passwortmanager nur ordnet.

2. Was SSO im Mittelstand wirklich löst — und was nicht

SSO wird gern als Bequemlichkeits-Feature verkauft. Der eigentliche Wert liegt woanders: in der Kontrolle darüber, wer wann worauf zugreift. Diese Probleme löst es messbar:

• Passwort-Wildwuchs endet. Ein starkes Anmeldeverfahren statt zwölf schwacher Passwörter, die sich nur in der angehängten Ziffer unterscheiden.
• Offboarding wird zu einem Handgriff. Sie sperren das zentrale Konto und beenden die Sitzungen — alle angebundenen Anwendungen sind damit zu. Ohne SSO ist Offboarding eine Suchaufgabe.
• Schatten-IT wird sichtbar. Sobald Anwendungen über den Identitätsanbieter laufen, sehen Sie in den Anmeldeprotokollen, welche Dienste tatsächlich genutzt werden — auch die, die nie jemand freigegeben hat.
• Richtlinien gelten überall gleich. Anforderungen an Anmeldung, Geräte oder Standorte legen Sie einmal fest, statt sie in jeder Anwendung nachzubauen.
• Der Support wird entlastet. Passwort-Zurücksetzungen sind ein Dauerbrenner in jedem Helpdesk. Weniger Passwörter bedeuten weniger Tickets.

Genauso wichtig ist die andere Seite. Diese Erwartungen erfüllt SSO nicht — und wer sie mitverkauft bekommt, wird nach dem Projekt enttäuscht sein:

• SSO regelt nicht, wer was darf. Es beantwortet nur die Frage „Wer sind Sie?". Welche Rechte jemand in der Warenwirtschaft hat, entscheidet weiterhin die Anwendung.
• SSO schützt nicht automatisch vor Phishing. Wer Anmeldedaten samt Einmalcode auf einer gefälschten Seite eingibt, öffnet ohne phishing-resistente Verfahren wie Passkeys alle Türen auf einmal.
• SSO erreicht nicht jede Anwendung. Ältere Branchensoftware ohne SAML- oder OpenID-Connect-Unterstützung bleibt außen vor und braucht einen eigenen Plan.
• SSO ersetzt keine Kontoverwaltung. Ohne SCIM bleiben lokale Konten in den Anwendungen bestehen, selbst wenn das zentrale Konto gesperrt ist.
• SSO reduziert kein Risiko, es verschiebt es. Aus vielen kleinen Angriffszielen wird ein großes. Was das bedeutet, steht in Abschnitt 4.

3. SAML, OpenID Connect und SCIM: drei Begriffe, die im Angebot stehen werden

Sie brauchen keine Protokoll-Vorlesung, um SSO zu beauftragen. Aber diese drei Abkürzungen tauchen in jedem Angebot und in jeder Software-Dokumentation auf — und der Unterschied zwischen den ersten beiden und der dritten entscheidet darüber, ob Ihr Offboarding funktioniert.

SAML 2.0 ist der Veteran: Die OASIS hat ihn am 1. März 2005 als Standard verabschiedet; er beschreibt XML-Bestätigungen über Authentifizierung, Attribute und Berechtigungen (Quelle: OASIS). Sie treffen ihn vor allem bei etablierter Unternehmens-Software. OpenID Connect ist der modernere Weg — die OpenID Foundation beschreibt ihn als Authentifizierungsprotokoll auf Basis des OAuth-2.0-Frameworks. OAuth 2.0 selbst regelt nur Berechtigungen; OpenID Connect ergänzt die Identität in Form eines signierten ID-Tokens (Quelle: OpenID Foundation). Für Ihre Auswahl heißt das schlicht: Nehmen Sie, was die Anwendung anbietet. Beide Verfahren sind ausgereift.

SCIM spielt in einer anderen Liga — und wird deshalb regelmäßig übersehen. Die Abkürzung steht für System for Cross-domain Identity Management und ist als RFC 7643 (Datenmodell) und RFC 7644 (Protokoll) seit September 2015 als Standards Track veröffentlicht (Quelle: IETF Datatracker). SCIM meldet niemanden an. Es sorgt dafür, dass ein neues Konto in der angebundenen Anwendung automatisch entsteht, Änderungen ankommen und ein gesperrtes Konto auch dort deaktiviert wird. Merksatz: SSO regelt die Anmeldung, SCIM die Konten. Wer nur SSO einführt, hat schöne Logins und weiterhin verwaiste Konten.

4. Warum SSO ohne MFA das Risiko vergrößert

Das ist der unangenehme Teil, den Anbieterseiten selten so deutlich formulieren. Wenn ein Konto den Zugang zu allen Systemen öffnet, wird dieses eine Konto zum lohnendsten Angriffsziel im Unternehmen. Das BSI schreibt dazu in seinen Cyber-Sicherheitsempfehlungen:

„Ist der zentrale Account geknackt, sind alle Accounts geknackt." (Quelle: BSI, Cyber-Sicherheitsempfehlungen zum Accountschutz)

Die Empfehlung des BSI ist entsprechend eindeutig: ein starkes Passwort für das zentrale Konto und zusätzlich eine Zwei-Faktor-Authentisierung. Aus unserer Projektpraxis würden wir noch schärfer formulieren: Mehr-Faktor-Authentifizierung ist kein Zusatzmodul des SSO-Projekts, sie ist dessen Voraussetzung. Ein SSO-Rollout ohne zweiten Faktor tauscht zwölf mittelmäßig geschützte Türen gegen eine einzige, ebenso mittelmäßig geschützte Haupttür.

Beim zweiten Faktor gibt es Qualitätsunterschiede. Einmalcodes per SMS oder App sind besser als nichts, lassen sich aber abfischen. Phishing-resistente Verfahren wie Passkeys nach dem FIDO2-Standard oder zertifikatbasierte Anmeldung sind an das echte Anmeldeziel gebunden und laufen auf einer gefälschten Seite ins Leere — Microsoft empfiehlt sie ausdrücklich für die besonders kritischen Notfallkonten (Quelle: Microsoft Learn). Welche Grundmaßnahmen darüber hinaus zählen, haben wir im Praxis-Leitfaden zur IT-Sicherheit im Mittelstand gebündelt.

Zur Lizenzfrage, die an dieser Stelle immer kommt: Microsoft Entra ID ist in Microsoft-365-Abonnements bereits enthalten, und die Sicherheitsstandards mit Mehr-Faktor-Authentifizierung stehen laut Microsoft allen Kunden zur Verfügung. Wer feiner steuern will — etwa Anmeldungen nach Standort, Gerät oder Anwendung unterscheiden —, braucht den bedingten Zugriff und damit Entra ID P1; risikobasierte Richtlinien setzen Entra ID P2 voraus (Quelle: Microsoft Learn, Stand 18.06.2026).

Bei der praktischen Einführung wird schnell die zweite Frage wichtig: Passkeys gibt es nicht in einer Variante. Synchronisierte Passkeys liegen verschlüsselt beim Anbieter und lassen sich nicht durch eine Attestierung auf Hersteller und Modell prüfen; gerätegebundene Passkeys auf einem Sicherheitsschlüssel oder in Microsoft Authenticator schon. Für privilegierte Konten und Administratoren ist deshalb die gerätegebundene Variante die sicherere Wahl. Wie Sie diese Unterscheidung in einen Rollout übersetzen — und dass Passkeys in Microsoft Entra ID selbst keine Zusatzlizenz kosten, ihre Erzwingung über den bedingten Zugriff aber schon —, zeigt unser Beitrag Passkeys im Unternehmen.

Seit Oktober 2024 nimmt Microsoft Ihnen die Entscheidung teilweise ab: Für das Azure-Portal, das Entra Admin Center, das Intune Admin Center und das Microsoft-365-Admin-Center wird der zweite Faktor erzwungen, seit dem 1. Oktober 2025 zusätzlich für Azure CLI, Azure PowerShell und die Control-Plane-Schnittstelle. Beide Fenster zum Verschieben dieses Starts sind mittlerweile geschlossen. Welche Stichtage gelten, warum Notfallkonten davon nicht ausgenommen sind und wie ein Rollout aussieht, bei dem niemand ausgesperrt wird, haben wir im Beitrag zu MFA im Unternehmen einführen zusammengetragen.

5. Rollout in fünf Schritten: die Reihenfolge entscheidet

Die meisten gescheiterten SSO-Projekte scheitern nicht an der Technik, sondern an der Reihenfolge. Wer zuerst die einfachen Anwendungen anbindet und die Aufräumarbeit hinten anstellt, verteilt bestehende Unordnung auf mehr Systeme. Diese Abfolge hat sich in unseren Projekten bewährt:

Rechnen Sie für ein mittelständisches Unternehmen nicht mit einem Wochenendprojekt, aber auch nicht mit einem Jahresvorhaben. Der Aufwand steckt in Schritt 1 und in der Abstimmung mit den Fachbereichen, nicht in der Konfiguration. Wenn die Microsoft-365-Umgebung ohnehin ansteht, bündeln Sie beides — wie eine saubere Einführung aussieht, beschreibt unser Beitrag Microsoft 365 im Unternehmen einführen. Für verteilte Teams zahlt derselbe Schritt doppelt ein: Zugriff von unterwegs wird erst mit zentraler Identität und klaren Richtlinien beherrschbar, wie unser Leitfaden zum Einrichten von Homeoffice-Arbeitsplätzen zeigt.

6. Typische Stolpersteine — und wie wir sie umgehen

Fünf Punkte tauchen in fast jedem Projekt auf. Keiner davon ist ein Ausschlusskriterium, aber jeder kostet Zeit, wenn er erst nach der Beauftragung auffällt:

Der dritte Punkt verdient eine Ergänzung, weil er die häufigste Sorge im Gespräch ist: Ja, Sie machen sich vom Identitätsanbieter abhängig. Microsoft führt den Ausfall eines Identitätsanbieters selbst als einen der Gründe an, aus denen Notfallkonten existieren müssen — die Empfehlung lautet, mindestens zwei reine Cloud-Konten vorzuhalten, sie von blockierenden Zugriffsrichtlinien auszunehmen und ihre Funktion mindestens alle 90 Tage zu prüfen (Quelle: Microsoft Learn, Stand 04.06.2026). Diese Abhängigkeit ist beherrschbar. Der Zustand davor — niemand weiß, wer noch welchen Zugang hat — ist es nicht.

Bleibt die Frage nach den Anwendungen, die sich weder per SSO noch per SCIM anbinden lassen. Hier hilft oft eine gezielte Schnittstelle, die Stammdaten und Konten zwischen den Systemen abgleicht; wie wir solche Verbindungen bauen, beschreibt unsere Leistung zur individuellen Datenintegration.

7. Was NIS2 an Zugriffskontrolle verlangt

Zuerst die Klarstellung, damit kein falscher Eindruck entsteht: Kein Gesetz schreibt Single Sign-On vor. Wer Ihnen SSO als NIS2-Pflicht verkauft, überdehnt den Gesetzestext. Was das seit dem 6. Dezember 2025 geltende deutsche Umsetzungsgesetz jedoch verlangt, liegt sehr nah an dem, was ein sauberes SSO-Projekt ohnehin erzeugt.

Das neu gefasste BSI-Gesetz listet in § 30 Absatz 2 die Mindestmaßnahmen für betroffene Einrichtungen auf. Zwei Nummern sind hier einschlägig (Quelle: BSIG, gesetze-im-internet.de):

§ 30 Abs. 2 Nr. 9 BSIG: „Erstellung von Konzepten für die Sicherheit des Personals, die Zugriffskontrolle und für die Verwaltung von IKT-Systemen, -Produkten und -Prozessen"

§ 30 Abs. 2 Nr. 10 BSIG: „Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung, gesicherte Sprach-, Video- und Textkommunikation sowie gegebenenfalls gesicherte Notfallkommunikationssysteme innerhalb der Einrichtung"

Verlangt sind also ein Konzept für die Zugriffskontrolle und der Einsatz von Mehr-Faktor-Authentifizierung. Ein zentraler Identitätsanbieter mit dokumentierten Gruppen, protokollierten Anmeldungen und erzwungenem zweitem Faktor ist ein pragmatischer Weg, beides nachweisbar zu erfüllen — nicht der einzige, aber ein gut prüfbarer. Ob Ihr Unternehmen überhaupt unter das Gesetz fällt, klären Sie über Sektor und Größe; die Logik dahinter erklärt unser Beitrag zu den NIS2-Pflichten für Unternehmen.

Für alle anderen gilt derselbe Gedanke ohne Gesetzesdruck: Der Maßnahmenkatalog ist eine kostenlose Checkliste. Und spätestens wenn ein regulierter B2B-Kunde seinen Sicherheitsfragebogen schickt, ist die Frage nach der Zugriffskontrolle ohnehin auf dem Tisch.

8. Fazit: erst aufräumen, dann anbinden — und nie ohne zweiten Faktor

Single Sign-On ist im Mittelstand kein Prestigeprojekt, sondern eine Hygienemaßnahme. Es beendet den Passwort-Wildwuchs, macht Offboarding zu einem Handgriff und legt offen, welche Dienste im Unternehmen tatsächlich genutzt werden. Es ersetzt dafür weder die Rechtevergabe in den Fachanwendungen noch eine saubere Kontoverwaltung per SCIM — und ohne Mehr-Faktor-Authentifizierung verlagert es das Risiko, statt es zu senken.

Die praktische Kurzfassung: Verzeichnis aufräumen, zweiten Faktor scharf schalten, kritische Anwendungen zuerst anbinden, Notfallzugang einrichten und testen, Offboarding schriftlich festhalten. Wenn Sie ohnehin über Microsoft 365 arbeiten, ist der Identitätsanbieter bereits da — die Arbeit steckt in Ordnung und Reihenfolge, nicht in der Lizenz. Wir sortieren Lizenzstand, Verzeichnis und Anwendungen mit Ihnen und setzen den Rollout um: in der Beratung zu Office-365-Migration und Lizenzen oder als Teil einer breiteren Digitalisierungs-Beratung.

Stand: August 2026. Standards und Lizenzangaben nach OASIS, OpenID Foundation, IETF und Microsoft Learn; die vollständige Quellenliste finden Sie am Ende des Beitrags.

Hinweis: Die Ausführungen zu § 30 BSIG und zur NIS-2-Richtlinie sind allgemeine Information und ersetzen keine Rechtsberatung. Maßgeblich ist der amtliche Gesetzestext; Stand der hier zitierten Fassung ist August 2026. Ob und in welchem Umfang Ihr Unternehmen betroffen ist, klären Sie über die offiziellen Quellen oder eine fachkundige Rechtsberatung.

9. Häufige Fragen zu Single Sign-On

Was ist ein Single-Sign-on-Verfahren?

Ein Single-Sign-on-Verfahren ist eine Einmalanmeldung: Sie melden sich einmal bei einem zentralen Identitätsanbieter an und erreichen danach alle angebundenen Anwendungen ohne weitere Passworteingabe. Der Identitätsanbieter prüft Ihre Identität und bestätigt sie den Anwendungen über standardisierte Nachrichten — meist per SAML oder OpenID Connect (Quellen: BSI, OASIS, OpenID Foundation).

Wie funktioniert ein SSO technisch?

Rufen Sie eine Anwendung auf, leitet diese Sie an Ihren Identitätsanbieter weiter. Dort melden Sie sich an, idealerweise mit zweitem Faktor. Der Identitätsanbieter schickt der Anwendung eine signierte Bestätigung Ihrer Identität zurück, die Anwendung vertraut ihr und öffnet die Sitzung. Ihr Passwort sieht die Anwendung dabei nie.

Was ist SCIM und was hat es mit SSO zu tun?

SCIM steht für System for Cross-domain Identity Management und ist in den Standards RFC 7643 und RFC 7644 beschrieben (Standards Track, September 2015). SCIM legt Benutzerkonten in angebundenen Anwendungen automatisch an, aktualisiert und deaktiviert sie. SSO regelt die Anmeldung, SCIM die Kontoverwaltung — erst beides zusammen schließt die Offboarding-Lücke.

Wie aktiviere ich SSO im Unternehmen?

Sie brauchen einen Identitätsanbieter — im Mittelstand meist Microsoft Entra ID aus dem vorhandenen Microsoft-365-Abo. Dort legen Sie die Anwendung als Unternehmensanwendung an, hinterlegen die Verbindungsdaten aus der Anwendung, weisen Gruppen zu und testen mit einem Pilotkonto. Wichtig: Mehr-Faktor-Authentifizierung und Notfallzugang vorher einrichten.

Wie erstelle ich ein Single-Sign-On-Konto?

Ein eigenes SSO-Konto legen Sie gar nicht an — Sie nutzen Ihr bestehendes Firmenkonto. Die IT verbindet dieses Konto im Identitätsanbieter mit den Anwendungen; dort erscheinen Sie danach automatisch. Anwendungen mit SCIM erzeugen Ihr Konto sogar selbst. Privat entspricht dem das Anmelden mit einem Google- oder Microsoft-Konto bei Drittanbietern.

Welche Nachteile hat Single Sign-On?

Der größte Nachteil ist das Klumpenrisiko. Das BSI formuliert es klar: Ist der zentrale Account geknackt, sind alle Accounts geknackt. Dazu kommen die Abhängigkeit vom Identitätsanbieter bei Störungen, Altanwendungen ohne SSO-Unterstützung und Funktionen, die je nach Lizenzstufe kosten. Mehr-Faktor-Authentifizierung und ein Notfallzugang entschärfen die ersten beiden Punkte (Quelle: BSI).

Kostet Single Sign-On extra?

Microsoft Entra ID ist in Microsoft-365-Abonnements bereits enthalten — ein Identitätsanbieter ist also meist schon vorhanden. Sicherheitsstandards mit Mehr-Faktor-Authentifizierung stehen laut Microsoft allen Kunden zur Verfügung. Feinere Steuerung kostet extra: Bedingter Zugriff erfordert Entra ID P1, risikobasierte Richtlinien Entra ID P2 (Quelle: Microsoft Learn, Stand 18.06.2026).

10. Quellen & offizielle Informationen

Die Angaben in diesem Beitrag stützen sich auf folgende offizielle und normgebende Quellen (Stand August 2026). Externe Quellen öffnen in einem neuen Tab.

• Gesetze im Internet — § 30 BSIG (Risikomanagementmaßnahmen) — amtlicher Gesetzestext mit den wörtlich zitierten Nummern 9 und 10 des Absatzes 2 (Primärquelle).
• BSI — Single-Sign-On (Cyber-Sicherheitsempfehlungen, Accountschutz) — Definition, Risikokonzentration auf dem zentralen Konto und Empfehlung zur Zwei-Faktor-Authentisierung (offizielle Stelle).
• OASIS — SAML V2.0 (OASIS Standard) — Status, Genehmigungsdatum 1. März 2005 und Zweckbeschreibung des Standards (Normgeber).
• OpenID Foundation — How OpenID Connect works — OpenID Connect als Authentifizierungsprotokoll auf Basis von OAuth 2.0, ID-Token und UserInfo-Endpoint (Normgeber).
• IETF — RFC 7644: SCIM Protocol und RFC 7643: SCIM Core Schema — Protokoll und Datenmodell für die automatische Kontoverwaltung, September 2015, Standards Track (Normgeber).
• Microsoft Learn — Microsoft Entra-Lizenzierung — Zuordnung von bedingtem Zugriff (P1), risikobasierten Richtlinien (P2), Anwendungsproxy (P1/P2) und Sicherheitsstandards zu den Lizenzstufen; Stand 18.06.2026 (Hersteller-Primärquelle).
• Microsoft Learn — Konten für den Notfallzugriff verwalten — mindestens zwei reine Cloud-Notfallkonten, Ausschluss aus blockierenden Zugriffsrichtlinien, Prüfung mindestens alle 90 Tage; Stand 04.06.2026 (Hersteller-Primärquelle).
• EUR-Lex — Richtlinie (EU) 2022/2555 (NIS-2-Richtlinie) — europäische Grundlage des deutschen Umsetzungsgesetzes (Primärquelle).