The SAP Identity Management Challenge and What to Do About It

For many years, SAP Identity Management (IdM) was the reference point for identity inside SAP landscapes. It gave SAP teams one place to handle provisioning and lifecycle basics: creating users, assigning roles, and supporting joiner/mover/leaver processes in a way that felt centralized and controllable.

That reference point has now disappeared. SAP has retired IdM and has not replaced it with a single equivalent product that spans both SAP and non-SAP systems in a unified way. Instead, SAP has moved towards a modular identity ecosystem that includes SAP Access Control, SAP Cloud Identity Services on SAP BTP, and integrations with external identity platforms such as Microsoft Entra, SailPoint, and others.

Each of these tools performs a specific function, but none of them individually replicate the end-to-end capability that organizations associated with IdM. This creates a perceived gap, particularly for organizations that expected a like-for-like replacement.

In reality, the issue is not that identity management capabilities no longer exist in SAP, but that they are now distributed across multiple systems that must be integrated. SAP initially pointed customers toward Microsoft Entra, but Entra on its own is not designed to handle SAP’s authorization and governance complexity out of the box. This leaves customers stitching together multiple solutions to cover authentication, provisioning, and access governance.

For SAP teams, the shift from a known, centralized reference point to an ecosystem where the solution is spread across tools, integration work, and operating decisions has created an identity crisis in SAP.

In this blog, we’ll explain why the challenge of identity management in SAP isn’t easily solved, where Entra helps (and where it leaves SAP teams doing the heavy lifting), what fragmentation tends to lead to in practice, and where to start if you want to get control back.

Why the post-IdM challenge isn’t easily solved

Identity management in SAP has never been a simple “plug in a provider and you’re done” problem. Even before IdM was retired, SAP environments had their own internal logic for access, roles, and authorizations, and that logic sits underneath almost every core business process. But when retiring the central reference point that was SAP IdM without a single clear replacement, what was already complex becomes harder to manage consistently, in large part because you’re dealing with scale and variation across both the business and the technology stack.

SAP identity spans business domains and technical estates

In practice, that complexity of identity management in SAP comes from two places. First, SAP typically spans a wide footprint across finance, procurement, supply chain, HR, and manufacturing — with each domain bringing different access requirements and governance expectations. Second, the technical estate itself is rarely a single system anymore. Most organizations operate a combination of on-premise platforms such as ECC or S/4HANA, cloud applications like SuccessFactors and Ariba, SAP BTP extensions, and a wide range of non-SAP SaaS tools, including platforms such as Microsoft 365 and ServiceNow. Identity, therefore, must operate across environments with different provisioning mechanisms, different security models, and different integration patterns.

This challenge is compounded by the number of identity types involved. It is not just employees. Contractors, vendors, service accounts, and increasingly non-human and agentic identities all need to be created, governed, and removed reliably. The more varied these identities are, and the more systems they touch, the more likely it becomes that teams fall back on workarounds, manual steps, or inconsistent processes just to keep the business moving.

Losing the “anchor” increases integration and operating burden

That complexity is harder to manage without a central anchor. For all its limitations, IdM did provide one place to coordinate basic SAP provisioning and lifecycle workflows, including joiner, mover, and leaver processes, role mapping, and in some cases, access requests. It wasn’t cloud-native and it wasn’t built for modern SaaS ecosystems, but it gave teams a consistent mechanism to work from.

Once you remove that anchor, the work doesn’t disappear, but it does change shape. Instead of one place to orchestrate core workflows, teams must decide where requests happen, where approvals live, which system is authoritative for identity data, how provisioning is triggered across SAP and non-SAP systems, and how exceptions are handled. Those choices become harder to make when the underlying landscape varies across platforms and user types.

Why Entra isn’t a turnkey answer for SAP governance

Microsoft Entra was initially endorsed by SAP as an alternative to IDM. However, it is optimized for authentication and general identity administration, rather than SAP’s authorization and governance model. Entra can handle single sign-on and conditional access well, and it can support provisioning, but it is closer to a bag of tools than a ready-made identity operating model. It also relies on you to configure and build what you need.

In an SAP context, that is a major ask. SAP permissions are rarely a simple on/off switch. Rather, they are granular and often conditional on organizational context, which is what makes risk and segregation-of-duties decisions harder. Without SAP-specific guardrails or out-of-the-box workflows for requesting, evaluating, and governing access, teams end up engineering the workflow layer and stitching Entra into SAP-aware controls. Currently, there are no platforms available that provide a comprehensive solution to this challenge.

What fragmentation leads to in practice

When identity management is split across multiple tools and teams, the impact is usually felt in both productivity and risk. The common pattern is not that organizations "lose" identity capability, but that they pay for fragmentation through time, inconsistency, and control gaps. This results in:

• Slow onboarding and lost productivity because provisioning and approvals are distributed across tools and teams, creating manual handoffs and delays before new starters can do their job.
• Workarounds that become permanent because the “right” process is too difficult to execute at speed, especially under delivery pressure.
• Overprovisioned access because it is simpler to copy an existing user, grant broad access “just in case,” or avoid redesigning roles when ownership is unclear.
• Higher compliance and audit overhead because it becomes harder to evidence who approved access, why it was granted, and whether it still aligns to policy.
• More residual risk because SAP's fine-grained permissions make it easy to accumulate conflicting or inappropriate access over time, particularly when governance is not consistently enforced across systems.

Avoiding these impacts is not done by swapping one product for another. Rather, solving the SAP identity management challenge typically means designing how multiple components work together and putting clear ownership around the decisions that matter most: where identity is mastered, where requests and approvals happen, how provisioning is triggered, and which tool is responsible for SAP-aware governance.

What a modern SAP identity architecture looks like

A modern SAP identity architecture is not based on a single system. Expecting one platform to manage fine-grained SAP authorizations and govern access across your entire application estate is usually an unrealistic demand. The more realistic goal is an integrated set of layers.

In practice, that means separating responsibilities. You need an authoritative identity source, such as HR or a directory service, an enterprise identity layer such as Microsoft Entra for authentication and core identity services, and an identity governance layer to provide enterprise-wide visibility and lifecycle controls.

Where SAP differs is in the depth of governance required. SAP’s access model is granular and context-driven, so you typically need SAP-aware tooling (either SAP-native tools such as SAP Access Control or SAP IAG, or specialist platforms such as Pathlock) to handle SAP-specific risk, segregation of duties, and fine-grained access decisions properly.

Enterprise platforms such as SailPoint can then play a different role: surfacing access across the wider estate and providing a single place to see who has access to what across SAP and non-SAP systems, even if the SAP-specific “governance brain” sits elsewhere. Pathlock can also provide this broader identity view, but it is typically stronger on SAP-native governance than on enterprise-wide identity coverage. The key principle is not consolidation for its own sake, but controlled integration, with clearly defined responsibilities across each layer and clean handoffs between enterprise identity and SAP-specific governance.

Where organizations should start

Most organizations are not starting from a clean slate, so the first step should not be selecting tools but rather understanding the current identity landscape.

This includes identifying where identities are stored, how provisioning currently works, how SAP and non-SAP systems interact, and where manual processes or exceptions exist. It is also important to understand how roles are defined and governed in practice.

From there, organizations can define a target operating model for identity governance and build a realistic integration strategy. The organizations that succeed are those that design identity architecture around how their business actually operates, rather than attempting to force a single platform to solve a fundamentally distributed problem.

This is also where many teams get stuck. There are too many dependencies, edge cases, and design trade-offs to work through quickly, and it is easy to invest effort in the wrong place without realizing it, leading to the feeling of a wider identity crisis. Bringing in experienced external support can help you assess what you have today, set realistic expectations, and focus your time on the changes that will make the biggest difference.

Book an SAP identity management workshop to map your current landscape, clarify ownership and operating model decisions, and define a practical roadmap for a modern SAP identity architecture.