SAP IDM end of life shifts identity governance toward cloud models

At a glance

What this is: SAP IDM retirement is a forced move from legacy, script-heavy identity management to cloud-first governance and partner-led migration.

Why it matters: It matters because IAM teams must rework lifecycle, provisioning, and access governance across SAP and non-SAP estates, not just replace a product.

By the numbers:

• According to experts, a typical IAM migration takes between 18 and 36 months for a large organization.
• SAP will provide full support, including bug fixes, security patches, and support for new browser versions and operating systems, until 31st December 2027.

👉 Read Pathlock's analysis of SAP IDM end of life and migration paths

Context

SAP IDM end of life turns identity governance into a migration problem, not a product refresh. When a legacy IDM platform reaches its final functional release, organisations have to decide how provisioning, access reviews, and lifecycle controls will continue across SAP and connected SaaS systems.

The primary issue is not just SAP support timing. It is the move away from custom-scripted identity logic toward cloud identity services, cloud IGA, and partner-led governance for hybrid SAP estates that now include S/4HANA, SuccessFactors, BTP, and non-SAP applications.

Key questions

Q: What breaks when SAP IDM is retired before workflows are redesigned?

A: What breaks first is continuity of lifecycle control. If workflows, approvals, and provisioning logic remain tied to SAP IDM, organisations can lose reliable joiner-mover-leaver execution, consistent SoD analysis, and timely revocation across connected applications. The result is not just inconvenience. It is residual access, audit gaps, and a migration that preserves old risk instead of removing it.

Q: When should organisations prioritise SAP IDM replacement over other IAM work?

A: Organisations should prioritise SAP IDM replacement when the retirement timeline becomes shorter than the time needed to inventory, redesign, test, and cut over identity workflows. If migration typically takes 18 to 36 months, waiting until the final maintenance window creates avoidable operational and compliance risk.

Q: How do you know if a cloud identity model is actually governing SAP access?

A: You know it is working when provisioning, access review, SoD analysis, and revocation all operate across SAP and non-SAP systems with clear policy ownership. If the cloud model only handles login or only handles a subset of applications, then governance is fragmented and legacy risk has simply moved elsewhere.

Q: Who is accountable for access risk during an SAP IDM migration?

A: Accountability sits with the identity, application, and governance owners together, because migration changes both technical control paths and compliance evidence. In practice, IAM, SAP security, audit, and business application teams must share ownership of cutover decisions, offboarding logic, and access certification until the old platform is fully retired.

Technical breakdown

Why SAP IDM's script-heavy architecture is becoming a migration constraint

SAP IDM 8.0 was built around Java-based identity logic, NetWeaver, a Virtual Directory Server for LDAP integration, and a central SQL-backed identity store. That architecture can work well for tightly controlled environments, but it becomes brittle when organisations need API-driven provisioning, SCIM synchronisation, and faster change management across SaaS and hybrid estates. The article’s key technical point is that modern identity governance increasingly depends on configuration, not bespoke code. Practical implication: teams should inventory every custom workflow, connector, and script that will fail or become expensive to support after retirement.

Practical implication: map every custom workflow and connector before the retirement window closes.

Cloud identity services, SCIM, and the new SAP integration model

SAP Cloud Identity Services shifts the operational model toward Identity Authentication, Identity Provisioning, and Identity Directory, with standards such as SAML, OIDC, SCIM, and X.509 carrying the integration load. That matters because provisioning and authentication are being separated into clearer service layers, while identity data moves through standard interfaces rather than embedded IDM logic. In practice, this reduces dependence on internal scripts but increases the need for strong policy design and attribute quality. Practical implication: organisations should test whether their identity sources, attributes, and provisioning rules survive a move to standard interfaces.

Practical implication: validate attribute quality and provisioning rules before shifting to standard interfaces.

Why lifecycle governance now has to span SAP and non-SAP systems

The article shows that SAP customers no longer manage only SAP accounts. They now govern employees, contractors, partners, and machine identities across SAP ECC, S/4HANA, BTP, Entra ID, Workday, Salesforce, and other SaaS systems. That means joiner-mover-leaver workflows, access certification, and segregation of duties checks have to operate across domains, not inside a single directory. The practical change is that lifecycle governance must become cross-application governance, with revocation, SoD analysis, and audit evidence following the identity everywhere it has access. Practical implication: design lifecycle controls for the full connected estate, not only the SAP core.

Practical implication: extend lifecycle controls and SoD checks across the full connected estate.

Threat narrative

Attacker objective: The objective is to exploit governance delay and identity sprawl to preserve access longer than the organisation can safely defend it.

1. Entry occurs through long-lived legacy identity workflows, custom scripts, and stale entitlements that persist while migration is delayed.
2. Escalation happens when over-privileged accounts, orphaned identities, or weak SoD enforcement remain active across SAP and connected systems.
3. Impact is wider audit exposure, delayed offboarding, and increased blast radius during the retirement window as controls lag behind the new operating model.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Snowflake breach — Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Legacy IDM retirement is really a governance redesign, not a tooling swap. SAP IDM end of life exposes how much enterprise identity control still depends on custom code, local connectors, and assumptions about stable application boundaries. Once identity spans SAP, SaaS, contractors, and cloud platforms, the old model of a single scripted hub stops being sufficient. Practitioners should treat the migration as a re-architecture of governance scope, not a lift-and-shift exercise.

Cross-application lifecycle control is now the decisive control plane. The article makes clear that joiner-mover-leaver processes, access certification, and SoD analysis have to operate across SAP and non-SAP systems at the same time. That is where many programmes break, because the identity has already moved beyond the SAP core while accountability still sits in one tool or one team. Practitioners should redesign governance around the connected estate, not the legacy directory.

Policy-driven governance is replacing custom-scripted identity logic. SAP IDM’s retirement forces organisations away from bespoke JavaScript and toward configuration-based workflows, ABAC-style policy decisions, and standard interfaces such as SCIM and OIDC. This matters because maintainability, auditability, and upgrade resilience all improve when access rules are expressed as policy instead of code. Practitioners should assume script-heavy IDM customisation is technical debt that now has an expiry date.

Clean core identity governance is becoming an ERP survival requirement. The transition away from embedded IDM logic aligns with broader clean core programmes, where identity control must no longer depend on fragile ERP customisation. That shift reduces upgrade friction and makes compliance evidence easier to produce, but only if governance is rebuilt above the application layer. Practitioners should use the retirement window to separate identity policy from ERP code.

Lifecycle governance without offboarding discipline creates residual access debt: The failure mode here is not a missing feature, but a governance model that assumes deprovisioning can wait until the old platform is replaced. That assumption breaks when accounts, connectors, and approval paths outlive the system they were built around. The implication is that teams must reframe lifecycle ownership before the migration, because access persistence becomes the risk surface.

From our research:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to the 2026 Infrastructure Identity Survey.
• From our research: 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• From our research: Read Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the lifecycle controls that need to be rebuilt as legacy identity platforms are retired.

What this signals

Identity modernisation is becoming a governance programme, not a platform project. SAP IDM retirement will push teams to separate login, provisioning, certification, and audit evidence across multiple systems. That means the next phase of IAM work is less about replacing a directory and more about deciding where policy lives, who owns it, and how it stays auditable across SAP and SaaS estates.

Least-privilege discipline will matter more as the target architecture becomes more distributed. With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, the broader lesson is that legacy access patterns survive unless migration work actively removes them. Teams should use the SAP transition to eliminate stale entitlements, not re-host them in a new stack.

Cross-domain lifecycle control is the real test of readiness. Once identity spans SAP, non-SAP SaaS, contractors, and external partners, the operating model must prove it can revoke access quickly and certify it consistently. The practical signal is whether your programme can enforce lifecycle decisions without relying on the old IDM tool as the system of record.

For practitioners

• Build a migration inventory for every custom IDM workflow Catalogue scripts, connectors, approval chains, and exception paths in SAP IDM before the 2027 cutoff. Mark which flows can move to configuration, which need replacement, and which should be retired to avoid carrying legacy debt forward.
• Separate authentication from governance in the target architecture Use your identity provider for login and the governance layer for provisioning, certification, SoD, and revocation. That split reduces dependence on legacy IDM logic and makes hybrid SAP and non-SAP control paths easier to audit.
• Rebuild joiner-mover-leaver logic around business events Trigger provisioning and deprovisioning from HR, contractor, and project lifecycle changes rather than from manual tickets. Extend the same lifecycle rules to SAP, cloud apps, and partner access so revocation is consistent everywhere.
• Run pre-migration SoD and access-census reviews now Baseline current access, identify toxic combinations, and remove orphaned or over-entitled accounts before moving controls. Use the migration window to clean up privilege creep instead of reproducing it in the new stack.

Key takeaways

• SAP IDM end of life forces a governance redesign because the legacy platform cannot be treated as a simple upgrade path.
• The migration risk is measured in years, not weeks, which makes early inventory, lifecycle redesign, and SoD cleanup essential.
• Cloud-first identity governance only works if policy, provisioning, and offboarding are rebuilt for SAP and non-SAP systems together.

Key terms

• Identity Governance And Administration: Identity Governance and Administration is the control layer for how identities are created, approved, reviewed, and removed. In SAP migration contexts, it becomes the mechanism that keeps access policy separate from application code and makes lifecycle decisions auditable across connected systems.
• Joiner Mover Leaver Workflow: A joiner mover leaver workflow is the lifecycle process that grants, changes, or removes access as people or entities enter, change role, or exit. For SAP estates, the workflow must extend across SAP and non-SAP systems so offboarding and entitlement changes happen everywhere access exists.
• Segregation Of Duties: Segregation of duties is the control that prevents one identity from holding conflicting permissions that could enable misuse or fraud. In a hybrid SAP environment, it must evaluate roles and transactions across applications, not only inside one directory or one ERP instance.
• Clean Core: Clean core is the design principle of keeping custom logic out of the ERP core so upgrades, support, and compliance are easier to sustain. In identity terms, it means moving access policy and lifecycle logic into governed layers instead of embedding them in bespoke scripts.

Deepen your knowledge

NHI governance, agentic AI identity, machine identity security, IAM, human identity, identity lifecycle, secrets management, and workload identity 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 programme maturity, it is worth exploring.

This post draws on content published by Pathlock: SAP IDM End of Life Timelines. Read the original.