SAP-IDM-Aus 2027: Neue Angriffspfade durch die Hintertür der Migration
05.07.2026 sap idmidentity governanceiam migrationangriffsfläche
Ein festes Enddatum, ein diffuses Sicherheitsrisiko
Am 31. Dezember 2027 endet die Mainstream-Wartung für SAP Identity Management (IdM) 8.0 – mainstream maintenance for SAP Identity Management 8.0 ends on December 31, 2027, wobei Kunden mit kostenpflichtiger Extended Maintenance die Lösung bis 2030 betreiben können, danach ist endgültig Schluss. Besonders brisant für Sicherheitsverantwortliche: SAP wird kein Nachfolgeprodukt liefern. Was auf den ersten Blang wie ein reines Lifecycle-Thema aussieht, entpuppt sich bei genauerem Hinsehen als handfestes DFIR-Problem – denn IdM-Systeme sitzen an der Quelle jeder Provisionierungs- und Berechtigungsentscheidung im Unternehmen.
Die Ausgangslage ist für die meisten SAP-Bestandskunden real: Mit über 440.000 SAP-Kunden wird die Abkündigung von SAP IdM und die Ablösung von SAP GRC viele betreffen. Zusätzlich verschärfend: SAP GRC Access Control 12.0 läuft mit demselben Enddatum aus, und der Nachfolger SAP GRC for HANA 2026 setzt eine HANA-Datenbank sowie S/4HANA Foundation voraus – Organisationen auf Nicht-HANA-Datenbanken benötigen daher zusätzlich eine Datenbankmigration. Zwei kritische Sicherheitskomponenten laufen also parallel aus, was die Komplexität massiv erhöht.
Warum aus einem Wartungsende ein Angriffspfad wird
Das eigentliche Risiko liegt nicht im plötzlichen Totalausfall, sondern in einem schleichenden Kontrollverlust. Ein Anbieter bringt es auf den Punkt: SAP-IdM läuft für viele Organisationen im Hintergrund und wird kaum beachtet – das ändert sich, wenn die Mainstream-Wartung endet. Das Risiko ist nicht, dass SAP IDM am 31. Dezember 2027 aufhört zu funktionieren, sondern dass es aufhört, gepatcht zu werden, keine Sicherheitsupdates mehr erhält und nicht mehr als gepflegte interne Kontrolle auditierbar ist. Für Compliance-Frameworks wie SOX oder DORA bedeutet das: der Betrieb von Governance-Infrastruktur auf nicht mehr unterstützter Software erzeugt bereits ein Audit-Risiko, bevor die Software selbst technische Probleme entwickelt.
Konkrete Präzedenzfälle zeigen, wie real dieses Risiko ist. Bereits 2021 war SAP IdM von der kritischen Log4j-Schwachstelle betroffen – Kunden mussten prüfen, ob ihr SAP-Identity-Management-System von der Zero-Day-Sicherheitslücke in der Log4j-Bibliothek (u.a. CVE-2021-44228) betroffen war. Nach 2027 bzw. spätestens 2030 gibt es für vergleichbare Funde schlicht keinen Patch mehr. Die zugrundeliegende Architektur bietet dafür reichlich Angriffsfläche: SAP IDM 8.0 ist eine Java-basierte Lösung, die auf SAP NetWeaver läuft und für LDAP-Integrationen auf den Virtual Directory Server (VDS) sowie für den Identity Store auf eine zentrale SQL-Datenbank setzt – ein klassischer Java/NetWeaver-Stack, für den in den letzten Jahren wiederholt kritische Schwachstellen bekannt wurden, etwa die 2025 aktiv ausgenutzte NetWeaver-Lücke CVE-2025-31324.
Die eigentliche Gefahrenzone: der Migrationsprozess selbst
Aus DFIR-Sicht ist nicht das Enddatum 2027 das größte Risiko, sondern die Übergangsphase davor. Typische Migrationsprojekte dauern laut Experten 18 bis 36 Monate für eine große Organisation und laufen damit häufig über Jahre im Parallelbetrieb – mit doppelten Provisionierungspfaden, doppelten Berechtigungsquellen und entsprechend mehr Angriffsfläche für Fehlkonfigurationen.
Besonders kritisch sind dabei drei Aspekte, die in Incident-Response-Fällen typischerweise übersehen werden:
Verwaiste Konten als Einfallstor. Ein häufiger Sicherheitslücke sind verwaiste Kontraktoren-, Lieferanten- und externe Nutzerkonten, die auch nach Projektende aktiv bleiben oder Zugriff auf Ressourcen behalten. Migrationsprojekte, die unter Zeitdruck stehen, überspringen die Bereinigung solcher Alt-Accounts – ein klassisches Ziel für Identity-basierte Angriffe.
Technische Identitäten und Service-Accounts. Moderne, cloud-native Identitätslösungen müssen Just-in-Time-Provisionierung unterstützen, woran SAP IDM architektonisch scheiterte, und ein breiteres Spektrum an Identitäten verwalten, einschließlich Bots, IoT-Geräten und Service-Accounts. Genau diese nicht-menschlichen Identitäten werden bei Migrationen häufig unvollständig migriert oder bleiben in Alt-Systemen mit weitreichenden Rechten bestehen, ohne dass ein sauberes Monitoring existiert.
Kein Like-for-Like-Ersatz. SAP bietet mit IAG, IPS, IAS und IDS zwar Cloud-Alternativen an, doch diese Cloud-basierten Tools bieten nicht die volle Funktionalität eines zentralen IdM-Systems für jedes Unternehmen und sind nicht für die Verwaltung von Nicht-SAP-Systemen konzipiert. Wer daher hybride Zwischenlösungen mit mehreren parallelen Governance-Schichten baut, riskiert genau jene Sichtbarkeitslücken, die forensische Aufklärung nach einem Vorfall erschweren – fehlende zentrale Audit-Trails, inkonsistente Provisionierungslogs und keine einheitliche Quelle der Wahrheit für “Wer hatte wann welchen Zugriff”.
Was DFIR-Teams jetzt tun sollten
Sicherheitsverantwortliche sollten die IdM-Ablösung nicht als reines Projektthema der IAM-Abteilung behandeln, sondern aktiv als Risikofaktor in die eigene Bedrohungsmodellierung aufnehmen: Bestandsaufnahme aller Konten und technischer Identitäten vor Migrationsbeginn, lückenlose Protokollierung des Parallelbetriebs für spätere forensische Rekonstruktion, und ein realistischer Zeitplan, der nicht erst kurz vor 2027 beginnt. Wer die Migration verschleppt und in die kostenpflichtige Extended Maintenance bis 2030 flüchtet, verschiebt das Problem nur – ohne dass sich das Grundrisiko eines unpatchbaren, aber weiterhin zentralen Identitätssystems verändert.
← Zurück zur Übersicht