SAP IDM Sunset 2027: New Attack Paths Through the Migration Back Door
05.07.2026 sap idmidentity governanceiam migrationangriffsfläche
A Fixed Deadline, a Diffuse Security Risk
Mainstream maintenance for SAP Identity Management (IdM) 8.0 ends on December 31, 2027 — mainstream maintenance for SAP Identity Management 8.0 ends on that date, and customers opting for paid extended maintenance can operate the solution until 2030, but beyond that, it’s over for good. What makes this particularly relevant for security teams: SAP will not deliver a successor product. At first glance this looks like a pure lifecycle housekeeping issue. Look closer, though, and it becomes a genuine DFIR problem — IdM systems sit at the source of every provisioning and access decision in the enterprise.
The scale of exposure is significant: with over 440,000 SAP customers, the sunsetting of SAP IdM and replacement of SAP GRC will impact many. Adding to the pressure, SAP GRC Access Control 12.0 mainstream maintenance ends on the same date, and its successor, SAP GRC for HANA 2026, requires a HANA database and S/4HANA Foundation — organizations on non-HANA databases face an additional database migration first. Two critical security-relevant components are sunsetting simultaneously, compounding complexity for already stretched IAM and security teams.
Why an End-of-Maintenance Date Becomes an Attack Path
The real danger isn’t a sudden hard shutdown — it’s a slow erosion of control. One vendor puts it bluntly: SAP IDM often runs as background infrastructure that nobody thinks about — that changes once mainstream maintenance ends. The risk isn’t that SAP IDM stops working on December 31, 2027; the risk is that it stops being patched, stops receiving security updates, and stops being auditable as a maintained internal control. For compliance frameworks such as SOX or DORA, this translates directly into audit exposure: running governance infrastructure on unsupported software creates an audit risk even before the software itself develops technical problems.
This isn’t theoretical. SAP IdM was already affected by the critical Log4j vulnerability in 2021 — customers had to determine whether their SAP Identity Management system was affected by the zero-day security vulnerability in the Log4j library, including CVE-2021-44228. After 2027 (or 2030 at the latest), comparable findings simply won’t get patched. The underlying architecture offers plenty of surface for such issues: SAP IDM 8.0 is a Java-based solution running on SAP NetWeaver that relies on the Virtual Directory Server (VDS) for LDAP-based integrations and a central SQL database for its Identity Store — a classic Java/NetWeaver stack that has repeatedly seen critical vulnerabilities, including the actively exploited NetWeaver flaw CVE-2025-31324 in 2025.
The Real Danger Zone: The Migration Itself
From a DFIR perspective, the 2027 cutoff isn’t the biggest risk — the multi-year transition period leading up to it is. Typical migration projects run 18 to 36 months for a large organization, according to experts, meaning parallel operation of old and new systems for extended periods, with duplicated provisioning paths, duplicated authorization sources, and correspondingly more room for misconfiguration.
Three aspects are particularly prone to being overlooked in incident response scenarios:
Orphaned accounts as an entry point. A common security gap is orphaned contractor, vendor, and external user accounts that remain active or retain access to resources even after the project has ended. Migration projects running under deadline pressure routinely skip the cleanup of such legacy accounts — a classic target for identity-based attacks.
Technical identities and service accounts. Modern, cloud-native identity platforms must support Just-in-Time (JIT) access provisioning, a standard modern security requirement that SAP IDM struggled to integrate and manage, while also handling a broader set of identities including partners, contractors, non-human identities such as bots, IoT devices, and service accounts. These non-human identities are frequently migrated incompletely or left behind in legacy systems with broad privileges and no clean monitoring.
No like-for-like replacement. SAP does offer cloud alternatives — IAG, IPS, IAS, and IDS — but these cloud-based tools do not offer the full functionality of a central IdM system for every company and are not designed for managing non-SAP systems. Organizations building hybrid interim architectures with multiple parallel governance layers risk exactly the visibility gaps that hamper forensic reconstruction after an incident: fragmented audit trails, inconsistent provisioning logs, and no single source of truth for “who had access to what, and when.”
What DFIR Teams Should Do Now
Security teams should not treat the SAP IdM sunset as a purely IAM-departmental project item, but actively fold it into their own threat modeling: a full inventory of accounts and technical identities before migration begins, uninterrupted logging throughout the parallel-run phase to enable later forensic reconstruction, and a realistic timeline that doesn’t start scrambling only as 2027 approaches. Organizations that delay migration and retreat into paid extended maintenance until 2030 are only postponing the problem — the underlying risk of an unpatchable yet still central identity system remains unchanged.
← Back to overview