SAP IDM End of Life

SAP announced the sunset of SAP Identity Management (SAP IDM) in February 2024. Mainstream maintenance ends December 31, 2027, with extended maintenance available through 2030 at added cost, and SAP has confirmed there is no successor product. That’s more than enough runway for most software transitions. Yet years in, a large share of SAP IDM customers still haven’t started migrating, and many haven’t even settled on where they’re migrating to.

That’s not procrastination. It’s a reasonable response to a genuinely hard problem: SAP IDM has been a deeply embedded, heavily customized execution layer for a long time, and nothing on the market replaces it in a single swap.

The SAP IDM EOL creates a gap for customers running Access Control or IAG, since both rely on an external identity source of truth. There is no other SAP solution that supports identity governance and administration features including user administration, synchronization, joiner mover leaver automation, and identity mapping.

What SAP IDM Actually Does

SAP IDM handles joiner-mover-leaver processing, role and permission assignment, connector synchronization, and approval chains. Once a request is approved, whether through IDM’s own workflow or a separate risk check, IDM is the piece that fulfills it: creating the account, assigning the role, and deprovisioning it later.

SAP picked up what became SAP IDM through its 2008 acquisition of Maxware, originally to replace SAP’s older Centralized User Administration (CUA) tool for managing accounts across multiple SAP systems. It’s licensed at no cost to SAP customers for SAP-to-SAP use, with fees applying only once it’s connected to non-SAP systems, which is part of why customization ran deep at many of the roughly 2,000 organizations that use it today.

SAP IDM was never SAP’s SoD or access-risk analysis engine. That job has typically belonged to SAP GRC Access Control, which runs the risk check upstream and approvals and then passes the request to IDM for fulfillment. IDM’s role sits downstream of governance, not inside it, which is exactly why removing it isn’t as simple as removing a single application.

With SAP IDM sunsetting, SAP is left with a real gap in its own portfolio. SAP GRC Access Control and SAP Cloud Identity Access Governance (IAG) both depend on an external identity source of truth to function, and SAP IDM has historically been that source for many customers.

Why It’s So Hard to Replace

The honest answer is that nothing on the market is a like-for-like match. Comparing SAP IDM to its would-be successors is closer to apples and oranges than a straight product swap. The successor has to both integrate with SAP as well as support the surrounding infrastructure already in place, which often includes SAP Access Control, ServiceNow, and other systems the identity data flows through today.

SAP’s own recommended path splits the job in two. SAP has partnered with Microsoft to position Microsoft Entra ID as its recommended enterprise-wide identity lifecycle platform, while SAP Cloud Identity Services (Identity Authentication, Identity Provisioning, and Identity Directory) handles the SAP-specific integration layer underneath it. In practice, Entra doesn’t support the depth of SAP-specific integration that SAP IDM customers have relied on, which leaves a real gap for any organization running SAP at scale.

SAP Cloud Identity Access Governance (IAG) covers access risk and governance analysis instead, a different function entirely: it was never positioned or intended as a replacement for SAP IDM’s fulfillment role. None of these pieces add up to a direct substitute for what SAP IDM’s Identity Center has actually been doing, which leaves organizations to decide what fills that specific execution role themselves.

Underneath all of that, SAP IDM ships with its own developer environment, and most customers used it. Years of internal development means years of custom connectors, workflows, and business logic that exist nowhere in a vendor’s default configuration. Whatever replaces SAP IDM has to account for that custom logic explicitly, not just point new connectors at old systems and assume equivalence.

The Scale Problem

Many SAP IDM customers are large enterprises running 500 or more connected systems, each with its own provisioning rules, approval chains, and edge cases built up over a decade or more. That scale multiplies the customization problem rather than simplifying it: a migration plan that works for a mid-sized SAP landscape doesn’t automatically scale to one with hundreds of unique system integrations.

It also means more people have a stake in the outcome. IT operations, security, HR-driven provisioning, and compliance all depend on SAP IDM doing its job correctly, so a replacement decision needs buy-in across all of them, not just the team that happens to own the SAP IDM box today. That’s a slower process than a typical infrastructure swap, and it’s part of why so many organizations are still in the evaluation phase this far into the timeline.

Three Views of the Same Deadline

The SAP IDM end of life reads differently depending on which part of the organization is looking at it. A replacement plan that only answers one of these views will run into the other two eventually.

For the IAM Manager

The immediate concern is lifecycle automation: joiner-mover-leaver processing, connector logic, and the approval workflows SAP IDM has executed for years. Before selecting a replacement, it’s worth mapping exactly which workflows and connectors are custom-built versus standard, since that determines how much of the current setup can carry over versus needs to be rebuilt.

For the SAP GRC Administrator

SAP IDM rarely operated alone. In most landscapes, SAP GRC Access Control ran the segregation of duties (SoD) and sensitive-access risk checks, and SAP IDM executed what was approved. Migration means accounting for both halves of that relationship: where the risk analysis happens going forward, and what executes the access change once a request clears it, including existing mitigating controls and emergency access processes that depend on both pieces working together.

For the CIO

The SAP IDM deadline rarely arrives on its own. It usually overlaps with an S/4HANA migration, a broader cloud transition, or a consolidation initiative already competing for budget and attention. Industry estimates put a large-enterprise IAM or IGA migration at 18 to 36 months, which means a program that starts planning in 2027 is already working against the deadline rather than ahead of it. The relevant question is whether the replacement reduces the number of identity and access tools the organization operates going forward, or adds one more point solution to a landscape that already has too many.

The Cost Was Never a Forcing Function

SAP IDM is licensed at no cost to SAP customers for SAP-to-SAP use, with fees only applying once it’s connected to non-SAP systems. That pricing is a large part of why so many organizations run it: low or zero license cost meant it rarely came up in budget reviews, rarely got scrutinized the way a paid platform would, and rarely had a clear owner accountable for its long-term roadmap. There was never a bill forcing anyone to ask what happens when SAP stops supporting it. Now there’s a deadline instead, without the years of budget conversations that usually precede a platform replacement.

What to Look For in a Replacement

Whatever replaces SAP IDM’s execution role needs to cover ground that’s easy to underestimate from the outside:

• An accurate map of current customization: custom connectors, workflows, and business logic need to be documented before they can be replaced, not discovered mid-migration.
• A clear split between risk analysis and fulfillment: know where SoD and sensitive-access checks will happen and what executes the approved change and make sure the two stay connected the way SAP GRC Access Control and SAP IDM were.
• Integration with existing infrastructure: larger companies will often have existing system managing access and system authorizations. These may include ServiceNow IT tickets or SAP Access Control.
• Cross-application coverage: if SAP IDM’s connectors also touched non-SAP systems, the replacement needs to cover that scope too, not just the SAP-native piece.
• Governance for non-human identities: service accounts and integration users provisioned through the same workflows need the same lifecycle discipline as human identities.
• Audit-ready evidence: approval chains, exceptions, and provisioning history need to produce documentation automatically, since that’s often what SAP IDM has been generating for audit purposes all along.

Where the Replacement Fits on the Maturity Curve

Most organizations moving off SAP IDM aren’t just replacing one tool with another. They’re moving up a maturity curve for how identity and access are governed:

• Documented policies: the fundamental framework for how users get access.
• Basic automation: fusing those policies into IGA tooling that automates provisioning and review.
• Combined identity governance and access controls: monitoring the risk tied to access as it’s granted, retained, and used.
• Continuous controls monitoring: extending that into ongoing risk quantification rather than periodic checks.

Knowing which stage an organization is starting from, and which one it’s aiming for, helps set realistic expectations for how much the SAP IDM replacement project actually needs to cover.

A Practical Way to Evaluate Vendors

Before comparing feature checklists, ask each candidate replacement, including SAP’s own recommended path, to answer these directly:

Where Pathlock Nexus Fits

Pathlock Nexus is a modern IGA platform built with the flexibility and SAP depth this specific transition requires. It combines a configurable workflow engine with deep, native SAP integrations, so it can support most SAP IDM scenarios out of the box and be extended to cover the rest without falling back to custom code.

• Deep SAP integration: connectivity built for SAP ERP systems specifically, not adapted from a generic identity platform after the fact.
• A flexible, configuration-based workflow engine: custom SAP IDM logic gets mapped into configuration rather than rebuilt as new custom scripts.
• Coverage beyond SAP: the same governance extends to non-SAP applications like Workday, Salesforce, and Oracle, closing the gap that Microsoft Entra ID and SAP Cloud Identity Services leave open for non-SAP integration depth.
• Integrated risk analysis and provisioning: the Access Risk Analysis module runs SoD and sensitive-access checks before fulfillment, and the Compliant Provisioning module takes on the joiner-mover-leaver execution work SAP IDM has been doing, keeping governance and execution connected instead of splitting them across separate tools.

Today, Pathlock Nexus’ Application Access Governance already integrates with SAP GRC Access Control and provides a phased migration path to take over the fulfillment role SAP IDM currently plays: connecting to the surrounding SAP systems for visibility first, then moving the lifecycle and provisioning work over, rather than a single cutover. Existing workflows and SAP GRC Access Control risk rules get mapped into Pathlock’s configuration-based workflow engine, rather than requiring SAP IDM’s custom scripts to be rebuilt as custom code again.

FAQ