The Future of SAP SSO: Warum jetzt der Wechsel zum Secure Login Service ansteht

Seit vielen Jahren sorgt SAP Single Sign-On 3.0 dafür, dass sich Anwender einmal anmelden und anschließend nahtlos in der SAP GUI arbeiten. Die Lösung ist bewährt, stabil — und hat ein Ablaufdatum: Am 31.12.2027 endet die Wartung für SAP Single Sign-On 3.0. Wer die SAP GUI weiterhin per Single Sign-On absichern will, kommt am Nachfolger nicht vorbei: dem Secure Login Service (SLS) als Teil der SAP Cloud Identity Services. Die gute Nachricht: Der Wechsel ist weit mehr als eine Pflichtübung. Richtig geplant, wird er zum Hebel für eine moderne, einheitliche Authentifizierungsarchitektur.

Ausgangslage: Ein bewährtes Rückgrat läuft aus

SAP SSO 3.0 basiert auf einer eigenen On-Premise-Infrastruktur: Secure Login Server, Zertifikatsverteilung, Kerberos-Integration. Das funktioniert zuverlässig — solange sich die Welt drumherum nicht verändert. Genau das tut sie aber: Anwender arbeiten hybrid und von unterwegs, Sicherheitsanforderungen wachsen, und die Authentifizierung im Unternehmen wird zunehmend zentral über einen Corporate Identity Provider wie Microsoft Entra ID, Okta oder Ping gesteuert.

In dieser Welt ist eine separate, nur für SAP betriebene SSO-Infrastruktur ein Fremdkörper: eigene Server, eigene Zertifikatslogik, eigene Betriebsprozesse — und ein Login-Erlebnis, das für die SAP GUI anders funktioniert als für Fiori, die SAP Business Technology Platform (BTP) oder SuccessFactors. Mit dem Wartungsende zum 31.12.2027 setzt SAP hier einen klaren Schlusspunkt.

Warum der Wechsel mehr ist als Pflicht

Wer die Migration nur als Ablösungsprojekt versteht, verschenkt den eigentlichen Nutzen. Denn der Umstieg auf den Secure Login Service beantwortet gleich mehrere Fragen, die viele SAP-Kunden ohnehin auf der Agenda haben:

• Einheitliches Login-Erlebnis: Ein Anmeldeverfahren für SAP GUI, Fiori, BTP und SAP-Cloud-Anwendungen — statt paralleler Welten für klassische und webbasierte Zugriffe.
• Zero Trust und MFA: Die Authentifizierung läuft über den zentralen Identity Provider. Damit greifen Multi-Faktor-Authentifizierung und Conditional-Access-Richtlinien des Unternehmens auch für den GUI-Zugriff.
• Zentrale Governance: Anmelderichtlinien, Auditierbarkeit und Zugriffskontrolle werden an einer Stelle gesteuert — nicht in einer SAP-Insellösung.
• Weniger Infrastruktur: Der Betrieb eigener Secure-Login-Server entfällt vollständig.

Was der Secure Login Service technisch anders macht

Die eigentliche Herausforderung beim SSO für die SAP GUI war immer dieselbe: Die klassischen Protokolle DIAG und RFC sprechen keine moderne Web-Authentifizierung. Genau diese Lücke schließt der Secure Login Service. Er verbindet die tokenbasierte Anmeldung per SAML oder OpenID Connect mit der zertifikatsbasierten Absicherung der GUI-Verbindung (SNC).

Vereinfacht gesagt: Der Anwender authentifiziert sich über den Firmen-IdP — inklusive MFA und aller geltenden Richtlinien. Der Secure Login Service stellt daraufhin ein kurzlebiges X.509-Zertifikat aus, mit dem der Secure Login Client auf dem Endgerät die verschlüsselte und authentifizierte Verbindung zum SAP-System aufbaut. Die Legacy-Protokolle bleiben, die Authentifizierung dahinter wird modern. Dauerhafte Zertifikatsinfrastruktur im eigenen Rechenzentrum? Nicht mehr nötig.

Architektur: Was wird gebraucht — und was bleibt?

Die Zielarchitektur ist überschaubar und baut auf Komponenten auf, die viele Unternehmen bereits im Einsatz haben:

• SAP Cloud Identity Services (IAS und IPS): die zentrale Authentifizierungs- und Provisionierungsplattform, typischerweise im Proxy-Modus vor dem Corporate IdP.
• SLS-Lizenz: Die Lizenzierung des Secure Login Service erfolgt über den BTP Global Account.
• Corporate Identity Provider: Microsoft Entra ID, Okta, Ping oder ein vergleichbarer IdP bleibt die führende Instanz für Identitäten, MFA und Richtlinien.
• Secure Login Client (SLC): bleibt unverändert auf den Endgeräten — ein wesentlicher Punkt für den Rollout, denn eine flächendeckende Client-Neuverteilung entfällt.
• SAP-GUI-Konfiguration: Registry-Einträge und Token-Konfiguration steuern, wie sich die GUI mit dem neuen Dienst verbindet.

Gerade der letzte Punkt zeigt: Die Migration ist kein Big Bang auf der Client-Seite, sondern vor allem eine Frage sauberer Architektur- und Konfigurationsarbeit.

Typische Migrationsgründe aus der Praxis

In unseren Projekten begegnen uns immer wieder dieselben Auslöser — und selten ist das Wartungsende der einzige:

• Der GUI-Login soll dieselben MFA- und Conditional-Access-Richtlinien durchlaufen wie alle anderen Unternehmensanwendungen — häufig eine Auflage aus Audits oder Cyber-Versicherungen.
• Die bestehende SSO-Infrastruktur verursacht Betriebsaufwand und Spezialwissen-Abhängigkeiten, die niemand mehr vorhalten möchte.
• Parallel laufende Cloud-Initiativen (BTP, SuccessFactors, S/4HANA-Transformation) machen eine konsolidierte Identity-Architektur ohnehin erforderlich — der SLS-Umstieg fügt sich hier nahtlos ein.
• Fusionen, Carve-outs oder IdP-Wechsel erzwingen eine Neuordnung der Authentifizierungslandschaft.

Der Weg dorthin: sechs Phasen bis zum modernen SSO

Eine SLS-Migration betrifft potenziell jeden GUI-Anwender im Unternehmen. Entsprechend wichtig ist ein strukturiertes Vorgehen. Bewährt hat sich ein Plan in sechs Phasen:

1. Initiierung und Analyse: Bestandsaufnahme der heutigen SSO-Landschaft, Systeme, Benutzergruppen und Sonderfälle; Definition von Zielen und Scope.
2. Architektur und Design: Zielbild für SAP Cloud Identity Services, IdP-Anbindung, Zertifikats- und Namenskonzept, Sicherheitsanforderungen.
3. Proof of Concept: Validierung des Zusammenspiels von IdP, SLS, Secure Login Client und SAP GUI in einer Testumgebung — inklusive der kritischen Sonderfälle.
4. Enablement: Vorbereitung von Betrieb, Support und Key-Usern; Dokumentation und Kommunikationsplan.
5. Rollout und Hypercare: wellenweise Umstellung der Benutzergruppen mit definiertem Fallback auf die bestehende Lösung — das Wartungsende 2027 lässt dafür heute noch ausreichend Puffer.
6. Abschluss und Optimierung: Abschalten der Altinfrastruktur und Ausbau der neuen Möglichkeiten, etwa Device Trust oder Geo-Fencing.

Fazit: Wer früh plant, entscheidet selbst

Das Wartungsende von SAP Single Sign-On 3.0 zum 31.12.2027 ist gesetzt. Die Frage ist nicht, ob Sie migrieren — sondern unter welchen Bedingungen. Wer früh startet, kann die Migration in Wellen planen, Sonderfälle in Ruhe lösen und den Umstieg mit den eigenen Cloud- und Zero-Trust-Initiativen verzahnen. Wer wartet, migriert unter Termindruck und ohne Spielraum. Der Secure Login Service ist dabei kein bloßer Ersatz, sondern der Schritt zu einem einheitlichen, richtliniengesteuerten Login über die gesamte SAP-Landschaft hinweg — von der GUI bis zur Cloud.

Sie möchten wissen, wo Ihre SSO-Landschaft heute steht und wie Ihr Weg zum Secure Login Service aussieht? Wir begleiten Sie von der Analyse über das Architektur-Design bis zum Rollout — mit einem erprobten Vorgehensmodell und klaren Ergebnissen je Phase. Erfahren Sie mehr über unsere Leistungen im Identity & Access Management oder sprechen Sie uns direkt an.