SAP IDM replacement is a governance decision, not migration

At a glance

What this is: This is an editorial analysis of SAP IDM end-of-life planning, arguing that replacement should be treated as a governance redesign rather than a simple platform migration.

Why it matters: It matters because manufacturing identity programmes often need cross-system lifecycle control, contractor governance, and audit evidence that a like-for-like replacement will not restore on its own.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read OpenIAM's analysis of SAP IDM replacement and manufacturing governance

Context

SAP IDM replacement is an identity governance problem first and a software selection problem second. In manufacturing environments, the real issue is whether the next architecture can govern SAP, adjacent enterprise systems, contractor populations, and plant operations with one coherent lifecycle model.

The article argues that SAP IDM's end of mainstream maintenance should be used to correct legacy gaps rather than preserve them. That is a useful framing for NHI, IAM, and lifecycle teams because migration pressure often pushes organisations toward familiar tooling instead of the governance outcomes auditors actually test.

Key questions

Q: What is the biggest failure mode when organisations replace SAP IDM too late?

A: The biggest failure mode is rushed migration that copies legacy custom logic, access exceptions, and incomplete role cleanup into the new platform. That usually creates a second generation of the same governance debt, while also increasing audit exposure and cutover risk. Teams should treat late replacement as a control design problem, not only a tooling deadline problem.

Q: Why is SAP Cloud Identity Services not a full SAP IDM replacement?

A: SAP Cloud Identity Services covers SAP authentication, federation, and provisioning, but it does not natively recreate SAP IDM's broader lifecycle governance across non-SAP systems. Manufacturing environments usually need cross-application access reviews, contractor control, and evidence production beyond the SAP boundary. That is why it is part of a replacement architecture, not a complete substitute.

Q: How should manufacturing companies handle contractor identity in an SAP IDM replacement?

A: They should treat contractors as a separate governance population with their own onboarding, approvals, reviews, and revocation rules. Contractor access often does not originate in HR, which means employee-centric automation will miss key lifecycle events. A replacement should include ownership, site-level accountability, and explicit offboarding for third-party identities.

Q: Who should own the SAP IDM replacement decision?

A: Ownership should sit across IAM, SAP architecture, compliance, and the business teams that manage plant operations. This is not just an identity tool choice. It is a decision about control scope, audit evidence, and how access governance will work across SAP, connected systems, and non-human identities over the next decade.

Technical breakdown

Why SAP IDM reached a governance ceiling

SAP IDM was built to orchestrate joiner, mover, leaver workflows for SAP-centric estates, with access requests, approvals, provisioning, deprovisioning, and certification. Its limits were structural: it did not natively enforce segregation of duties, it did not govern non-SAP applications well, and it did not solve contractor governance at manufacturing scale. Those gaps mattered because the platform automated lifecycle movement but did not define the full governance boundary. Practical implication: replacement planning must start with the control model, not the target product shortlist.

Practical implication: map which governance controls were never native to SAP IDM before choosing a successor.

How SAP Cloud Identity Services and Entra ID split the problem

SAP Cloud Identity Services and Microsoft Entra ID each solve part of the landscape, but neither recreates SAP IDM's wider governance footprint. SAP Cloud Identity Services focuses on SAP ecosystem authentication, federation, and provisioning, while Entra ID handles enterprise federation and directory-centric identity functions. Neither one alone closes manufacturing requirements such as SoD validation, business-context access reviews, or non-SAP lifecycle governance. The architectural mistake is treating federation coverage as equivalent to governance coverage. Practical implication: design a layered identity architecture where federation, provisioning, and governance are intentionally separated.

Practical implication: separate federation scope from governance scope before you decide which control owns each system.

Why manufacturing identity governance needs plant-aware lifecycle logic

Manufacturing identity is not just employee identity at scale. Plant transfers, contractors, seasonal labour, third-party service providers, and operational technology create lifecycle events that do not follow office-centric mover workflows. A plant transfer can change approval chains, cost centres, system entitlements, and physical-site dependencies at once. Contractor access may exist outside the HR system entirely, which breaks assumptions behind HR-sourced automation. Practical implication: the replacement model has to treat plant-specific lifecycle events as first-class governance cases, not exceptions buried in workflow logic.

Practical implication: model plant transfers and contractor onboarding as distinct lifecycle patterns with their own approvals and reviews.

NHI Mgmt Group analysis

SAP IDM replacement is a governance decision because the old platform already encoded a partial control model. It automated lifecycle tasks, but it never enforced SoD, never fully governed non-SAP systems, and never solved contractor identity at manufacturing scale. Replacing the product without replacing those assumptions simply preserves the same audit exposure under a new interface.

The named concept here is governance scope drift. As soon as SAP becomes only one part of a broader manufacturing identity estate, the governance boundary has to move with it. If the replacement architecture still treats SAP as the centre and everything else as peripheral, access review, evidence, and risk decisions will continue to lag the actual operational perimeter.

SAP Cloud Identity Services plus Entra ID is a split architecture, not a complete governance answer. One handles SAP ecosystem depth, the other handles enterprise federation, but manufacturing auditors do not test those domains in isolation. They test whether lifecycle, reviews, and risk controls remain coherent across SAP, plant systems, contractors, and connected applications. Practitioners should evaluate the architecture as a governance fabric, not as separate product islands.

Manufacturing replacement programmes fail when they assume employee-centric JML logic will cover contractor and plant identity. That assumption breaks because the most consequential identities in manufacturing often sit outside the HR system, move across physical sites, and inherit different approval structures. The implication is that lifecycle governance must be designed around operating context, not employment status alone.

The migration window should be used to remove legacy control debt, not repackage it. A like-for-like replacement keeps SoD checking reactive, keeps cross-system governance fragmented, and keeps evidence production tied to the old estate shape. The opportunity is to redraw the control boundary before migration pressure locks the organisation into another decade of partial coverage.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, which means hidden access often persists long after the original business need has changed.
• For lifecycle governance, see NHI Lifecycle Management Guide for offboarding, rotation, and visibility patterns that apply to non-human access estates.

What this signals

Governance scope drift: the next platform will only improve outcomes if it expands the control boundary beyond SAP, because manufacturing audit scope now includes contractors, plant systems, service accounts, and connected applications. Teams that preserve SAP-only assumptions will keep producing partial evidence for a broader operational estate.

The practical signal is that IAM, SAP, and compliance teams should plan for cross-domain lifecycle ownership now, not during cutover. With the Ultimate Guide to NHIs, the pattern is clear: non-human access visibility remains weak, and that weakness becomes more expensive when migration timelines compress decision-making.

For practitioners

• Define the governance outcome before selecting a platform Document which controls must be enterprise-wide, which remain SAP-specific, and which must apply to contractors, plant transfers, and service accounts. Use that control map to evaluate replacement options instead of comparing feature lists.
• Separate SoD detection from lifecycle orchestration Preserve SAP GRC risk logic where it already works, but require the replacement design to add preventive SoD validation at request and provisioning time. Avoid architectures that only detect conflicts after access has already been granted.
• Model contractor and plant access as distinct lifecycle paths Do not force contractor onboarding and plant transfer events through the same HR-driven workflow used for standard employees. Build approval, review, and offboarding paths that reflect site-specific governance and third-party accountability.
• Build service account governance into the migration scope Inventory integration users, batch accounts, and other non-human identities before cutover. Tie ownership, review cadence, and offboarding responsibility to the replacement design so the post-migration estate does not inherit hidden access paths.

Key takeaways

• SAP IDM end of maintenance is a governance reset point, not just a product retirement date.
• The main risk is carrying SAP IDM's old control gaps into a new stack that still cannot govern contractors, plant transfers, and non-human identities coherently.
• Manufacturing teams should use the migration to redefine control scope, preserve SoD value, and build evidence across the full identity estate.

Key terms

• Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Lifecycle Governance: Lifecycle governance is the set of controls that cover creation, assignment, review, rotation, and retirement of identities and credentials. For NHIs, it is the difference between a temporary automation asset and a persistent access risk. Strong lifecycle governance keeps ownership and expiry tied to actual business use.

What's in the full article

OpenIAM's full analysis covers the operational detail this post intentionally leaves for the source:

• A manufacturing-focused replacement planning model for SAP IDM end-of-maintenance decisions
• The governance gap analysis across SAP, Microsoft Entra ID, SAP Cloud Identity Services, contractors, and plant operations
• The migration questions that separate a like-for-like swap from a real identity governance redesign
• The coexistence model for SAP GRC, lifecycle workflows, and enterprise access evidence

👉 OpenIAM's full article covers the replacement questions, governance trade-offs, and manufacturing-specific requirements in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building identity governance capability across human and non-human estates, it is worth exploring.