SAP IdM End of Life: Was jetzt zählt – und welche Optionen du hast

Definition

SAP IdM End of Life bezeichnet das absehbare Ende von Wartung und Support für SAP Identity Management (SAP IdM) und die daraus folgende Notwendigkeit, Identity Management und Access Management neu zu organisieren.

Es ist keine reine Produktmigration, sondern eine Transition von Prozessen, Integrationen und Governance in ein dauerhaft betreibbares Zielbild.

Einleitung

Wenn SAP IdM Richtung Wartungsende läuft, ist das kein Thema, das man „später mal“ löst. Identity-Workflows hängen an HR, SAP-Systemen, Verzeichnissen, Rollen, Schnittstellen und Audit-Anforderungen. Wartung, Change und Betrieb werden mit der Zeit teurer und riskanter. Gute Planung reduziert Komplexität und verhindert, dass du am Ende nur ein altes Rollenchaos in ein neues System umziehst.

Was das End-of-Life für Identity Management bedeutet

Mit einem IdM-Produkt im End-of-Life-Modus steigen typischerweise drei Risiken: Sicherheitslücken bleiben länger offen, Integrationen brechen bei Änderungen in Zielsystemen schneller, und Compliance-Nachweise werden schwieriger, weil Workarounds zunehmen.

Entscheidungsrelevant ist deshalb nicht nur „welches Tool“, sondern auch: Wer betreibt es, wie wird Access Governance (Freigaben, Reviews, SoD) umgesetzt, und wie bleibt der Identity-Lifecycle (Joiner, Mover, Leaver) verlässlich?

Nachfolger-Optionen: Ersatz, Ergänzung oder Neuaufbau

In der Praxis gibt es drei Pfade für eine SAP-IdM-Ablösung. Welcher passt, hängt von vorhandenen Systemen, Cloud-Strategie, IGA-Anforderungen und Integrationsgrad ab.

• Microsoft Entra ID als IAM-Kern: sinnvoll, wenn Microsoft 365 bereits zentral ist und SSO, MFA, Conditional Access und Identity Access Management vereinheitlicht werden sollen. Vorteil: weniger verstreute Identitäten, konsistenter Zugriff, schnelleres On-/Offboarding über Standardschnittstellen.

• Entra ID plus IGA (z. B. SailPoint, Omada, One Identity, Saviynt, midPoint): sinnvoll, wenn Identity Governance and Administration (IGA) mit Access Reviews, SoD, rezertifizierten Rollen und starkem Antrags-/Genehmigungsprozess geschäftskritisch ist.

• SAP-nahe Zielbilder (z. B. SAP Cloud Identity Services als Baustein): sinnvoll, wenn SAP-Landschaft dominiert und Provisioning/Integration in SAP-Systeme im Vordergrund steht. Trotzdem muss Governance meist separat sauber gelöst werden.

Warum Microsoft Entra ID oft der pragmatischste Startpunkt ist

Entra ID bringt Identity und Access näher an den tatsächlichen Betrieb: einheitliche Authentifizierung, klare Richtlinien für Zugriffe und weniger Sonderwege. Der Nutzen ist nicht „mehr Features“, sondern weniger Reibung im Alltag: schnellere Bereitstellung von Accounts, weniger manuelle Admin-Tickets und ein klarer Hebel gegen kompromittierte Zugangsdaten durch MFA und Conditional Access.

Wichtig für die Erwartung: Entra ID ersetzt nicht automatisch komplette IGA-Prozesse aus SAP IdM. Wenn du umfangreiche Governance-Administration brauchst, gehört das als eigenes Arbeitspaket in Planung, Architecture und Transition.

Migration-Playbook: sicher in 6 Schritten

Der Erfolg hängt davon ab, ob du zuerst Ordnung schaffst und dann migrierst, nicht umgekehrt.

• 1) Inventarisieren: alle Identities (inkl. Non-Human Identities), Rollen, Policies, Workflows, Connectors/APIs, Zielsysteme, Ausnahmen und Customization.

• 2) Zielbild definieren: was ist IAM (SSO, MFA, Conditional Access), was ist IGA (Anträge, Reviews, SoD), was ist PAM/PIM (Privileged Access)?

• 3) Daten- und Rollenbereinigung: Dubletten, verwaiste Accounts, Rollenwildwuchs. Das spart später Zeit und senkt Risiko.

• 4) Integrationen bauen und testen: Provisioning-Strecken, HR-Quelle, SAP S/4HANA, Verzeichnisse, Anwendungen. Pilot mit klaren Erfolgskriterien.

• 5) Transition in Wellen: kritische Anwendungen zuletzt, Parallelbetrieb mit Rückfallplan, Change-Kommunikation.

• 6) Betrieb & Governance festziehen: Runbooks, Ownership, regelmäßige Access Reviews, Reporting für Compliance und Audits.

Risikobewertung und Security während der Transition

Die Migration ist eine Hochrisiko-Phase, weil Berechtigungen sich bewegen. Typische Risikotreiber sind fehlende Verantwortliche für Access Rights, ungelöste SoD-Konflikte und „temporäre“ Admin-Rechte, die bleiben.

Bewährte Leitplanken sind:

• Zero-Trust-Logik: Zugriff wird über Identität, Kontext und Policy entschieden, nicht über Netzwerkannahmen.

• Privileged Access Management: privilegierte Rollen zeitlich begrenzen (z. B. über PIM), lückenlos protokollieren.

• Nachweisfähigkeit: jede Änderung an Rollen, Zuweisungen und Ausnahmen dokumentieren, damit Compliance und Governance auch während der Transition tragen.

Integration, Datenmigration und Architektur-Anpassungen

Die wichtigste Architektur-Entscheidung ist die Quelle der Wahrheit für Identitäten: HR, Entra ID, SAP-Systeme oder ein IGA-System. Danach folgt die Integrationsstrategie: Standard-Connectoren und APIs bevorzugen, Sonderentwicklungen minimieren.

Bei der Datenmigration gilt: nicht „alles rüberkopieren“, sondern nur das, was für Identity Lifecycle und Access Management wirklich gebraucht wird. Jede geerbte Ausnahme erhöht dauerhaft Maintenance und Operations-Aufwand.

Checkliste zur Orientierung (ohne Download)

• Scope: Systeme, Identitäten, Rollen, kritische Anwendungen, Eigentümer je Anwendung.

• Kontrollen: MFA/Conditional Access, PIM/PAM, Logging, Access Reviews, SoD-Regeln.

• Plan: Pilot, Wellenplan, Parallelbetrieb, Rollback, Abnahme und Betriebsübergabe.

Wann externe Unterstützung sinnvoll wird

Externe Expertise lohnt sich, wenn du viele Integrationen, komplexe Rollenmodelle oder strenge Compliance-Anforderungen hast und intern niemand die Zeit für Inventar, Bereinigung und sauberes Testing freischaufeln kann. Spätestens wenn mehrere Teams (SAP, AD/Entra, HR, Security) involviert sind, entscheidet ein klarer Plan über Kosten, Zeitaufwand und Risiko.