SAP IDM retirement raises urgent renewal choices for manufacturers

At a glance

What this is: SAP IDM’s confirmed retirement forces manufacturing firms to choose between a narrow SAP-native migration, a temporary maintenance extension, or a broader IGA replacement.

Why it matters: IAM and IGA teams need to treat the retirement as a governance redesign moment because SAP-only lifecycle controls, attestation, and SoD handling may no longer be enough for broader enterprise identity coverage.

By the numbers:

• After December 2027, SAP will no longer release security patches, bug fixes, or compliance updates for SAP IDM.
• An SAP IDM migration typically takes 16 to 24 weeks for a standard implementation.
• Extended maintenance ended in December 2025.

👉 Read OpenIAM's analysis of SAP IDM retirement and migration options

Context

SAP IDM retirement is an identity lifecycle governance problem first and a product lifecycle event second. For manufacturing organisations, the issue is whether joiner-mover-leaver controls, access requests, and attestation continue to function cleanly once the system that orchestrates them is no longer under mainstream support.

The question now is not whether to replace SAP IDM, but which governance boundary to redraw. Some teams only need SAP-centric lifecycle control, while others should use the retirement to fix broader IGA sprawl across SAP, Microsoft, ServiceNow, Workday, and Salesforce.

Key questions

Q: What happens when SAP IDM is retired before a replacement is ready?

A: The organisation loses supported identity lifecycle infrastructure, which means no new patches, no compliance updates, and no vendor-backed fixes for workflow or integration issues. Access requests, approvals, and attestations may continue for a while, but the control plane itself becomes a liability. Teams should plan cutover before support ends, not after the platform is already unsupported.

Q: When should manufacturing companies decide between SAP-native replacement and broader IGA?

A: The decision should happen at the next renewal cycle, not near the final maintenance cutoff. If the organisation only governs SAP access, SAP IAS and IPS may be enough. If it also needs governed lifecycle control across non-SAP systems, a broader IGA platform is usually the better operating model.

Q: What breaks when SAP IDM is kept running after mainstream support ends?

A: The immediate break is supportability, followed by security and audit confidence. Unsupported identity management creates a gap between business dependence and vendor assurance, and auditors will increasingly treat that as a control weakness. The longer the delay, the more migration choices narrow toward urgent, costlier options.

Q: Who is accountable if an unsupported SAP IDM instance causes access-control failures?

A: Accountability sits with the organisation’s identity, SAP, and control owners, not with a vendor still providing mainstream support. Once mainstream maintenance ends, the business is knowingly operating unsupported infrastructure, so internal ownership for risk acceptance, migration planning, and audit response becomes the critical issue.

Technical breakdown

What SAP IDM loses after mainstream maintenance ends

SAP IDM is more than a provisioning utility. It holds identity lifecycle workflows, approval chains, and attestation logic that were often customised over years to match SAP role models and HR processes. When mainstream maintenance ends, the platform no longer receives security patches, compliance updates, or fixes aligned to SAP’s evolving authorisation model. That matters because the system itself becomes part of the audit surface, not just the control plane for other systems. In practice, the retirement creates both technical debt and governance debt at the same time.

Practical implication: document every SAP IDM workflow, integration, and approval path before you decide whether it can be migrated or must be redesigned.

Why SAP IAS and IPS only solve part of the problem

SAP Identity Authentication Service and Identity Provisioning Service replace core authentication and provisioning functions, but they do not recreate the full governance depth of SAP IDM. Complex access request workflows, attestation campaigns, and non-SAP governance often sit outside that pair. In other words, IAS and IPS can be a viable replacement for a narrower identity boundary, but they do not automatically solve enterprise-wide lifecycle governance. The architectural trade-off is between keeping the model SAP-bound and accepting a smaller control surface, or expanding the programme beyond SAP.

Practical implication: map which controls disappear if you move to IAS and IPS, especially attestation and non-SAP workflow coverage.

How third-party IGA changes the control model

A third-party IGA platform shifts the conversation from replacement to governance expansion. Instead of only preserving SAP identity processes, it can unify provisioning, certifications, and Segregation of Duties controls across SAP and adjacent enterprise systems. That reduces the need to manage separate control planes for access lifecycle and SoD review. The architectural benefit is not simply more features. It is the ability to govern identity state across the systems that manufacturing companies actually rely on, rather than treating SAP as an isolated island.

Practical implication: assess whether your replacement should cover SAP alone or become the enterprise control point for lifecycle and SoD governance.

NHI Mgmt Group analysis

SAP IDM retirement exposes a lifecycle control dependency, not just a software upgrade problem. When a core identity system reaches end of support, the organisation’s joiner-mover-leaver process, attestation cadence, and audit defensibility all inherit product risk. That makes migration timing a governance decision, not a procurement afterthought. Manufacturing teams should treat the retirement as a control continuity test, because lifecycle governance only works while the platform behind it remains supported and changeable.

IAS and IPS are a boundary reduction, not a governance replacement. The SAP-native path preserves familiar integration points, but it narrows the identity problem back to SAP’s own ecosystem. That may be acceptable where SAP is the full universe of governed access, but it leaves broader identity estates fragmented. The implication is that teams need to decide whether SAP is their control boundary or merely one domain inside a wider identity programme.

Lifecycle blind spots: SAP IDM’s retirement is really a retirement of embedded assumptions about stable workflows, stable integrations, and stable support. Those assumptions were designed for long-lived on-premises identity systems. They fail once the platform itself becomes unsupported and the surrounding application estate keeps changing. The implication is that practitioners must rethink whether their current lifecycle model is tied too tightly to one vendor boundary.

The sunset creates a useful forcing function for identity governance maturity. Many manufacturing environments still run separate tools or manual processes for SAP access, non-SAP access, and SoD review. The retirement makes that separation harder to justify. A broader IGA model can align lifecycle control, certification, and conflict detection across the enterprise, which is where the governance value now sits. Teams should use the transition to decide whether they want a replacement system or a stronger operating model.

The renewal cycle is the real decision point because delay compresses every downstream choice. Migration work, custom workflow mapping, connector testing, and user change management all consume calendar time. If the conversation starts only when support is already expiring, the organisation will optimise for speed rather than fit. The practical conclusion is simple: the renewal date should drive the migration plan, not the other way around.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• 23.7% of organisations share secrets through insecure methods such as email or messaging applications.
• The broader lesson is captured in NHI Lifecycle Management Guide, which shows why lifecycle controls must be designed before support windows close.

What this signals

SAP IDM retirement is a reminder that identity programmes fail when lifecycle ownership is tied too closely to one product boundary. Teams that still treat SAP access, non-SAP access, and SoD review as separate control islands will feel the migration pressure first, because the operating model itself becomes the constraint.

Lifecycle dependency debt: this is the point at which a supported identity platform stops being a convenience and becomes a control requirement. Manufacturing teams should expect sharper audit scrutiny around whether lifecycle processes remain supported, documented, and testable once the old platform exits maintenance.

A useful reference point is the NHI Lifecycle Management Guide, because the same lifecycle discipline applies when the governed estate spans human users, service accounts, and other non-human identities.

For practitioners

• Inventory SAP IDM dependencies now List every workflow, connector, approval chain, and HR integration that SAP IDM currently supports. Use that inventory as the migration requirements baseline before any vendor conversations begin.
• Separate SAP-only controls from enterprise-wide controls Identify which access processes are truly SAP-bound and which also govern Microsoft, ServiceNow, Workday, or Salesforce. That distinction determines whether IAS and IPS are sufficient or whether a broader IGA platform is justified.
• Map renewal timing to the 2027 deadline Align budget, procurement, and implementation milestones with the December 2027 mainstream maintenance cutoff. Starting in 2026 leaves room for testing, parallel run, and controlled cutover.
• Reassess SoD ownership during the migration Decide whether Segregation of Duties stays in a separate SAP GRC or spreadsheet process, or becomes part of the replacement IGA scope. That choice should be explicit before implementation starts.

Key takeaways

• SAP IDM retirement turns identity lifecycle continuity into a deadline-driven governance issue for manufacturing firms.
• The scale of the problem is not just support loss, but the risk of losing attestation, provisioning, and SoD coverage at the same time.
• The safest path is to choose a migration model before renewal pressure forces a narrow, expensive decision.

Key terms

• Identity Lifecycle Management: The set of processes that create, modify, review, and remove access as people and systems change. In practice, it covers joiner-mover-leaver workflows, approvals, and periodic attestation. For SAP-heavy environments, it is the control fabric that keeps access aligned with business roles and audit expectations.
• Segregation of Duties: A control model that prevents one identity from holding conflicting permissions that could enable fraud, error, or unauthorised change. In SAP environments, it is usually enforced through a separate governance layer or rule engine. It is not the same thing as provisioning, and it must be managed alongside lifecycle workflows.
• Mainstream Maintenance: The vendor support period during which a product receives normal security patches, bug fixes, and compatibility updates. Once mainstream maintenance ends, the product may still run, but the surrounding governance model weakens because the platform itself is no longer actively supported.

What's in the full article

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

• A step-by-step comparison of the three SAP IDM migration paths, including when each path is most appropriate.
• A practical migration readiness checklist for organisations that need to brief SAP, procurement, and audit stakeholders.
• A longer breakdown of SAP IDM feature parity, including workflow, attestation, and SoD considerations.
• A manufacturer-focused discussion of timing, renewal planning, and implementation sequencing.

👉 OpenIAM's full article covers the three migration paths and the renewal planning 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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.