SAP IDM sunset is forcing a multi-year IAM migration rethink

At a glance

What this is: This is an analysis of SAP IDM’s sunset and the migration rethink it forces, with the core finding that replacement must be treated as a long-running IAM and governance programme, not a quick platform move.

Why it matters: It matters because IAM, IGA, PAM, and identity architecture teams must plan for process redesign, integration rework, and audit continuity before support deadlines compress the programme window.

By the numbers:

• SAP has set 31st December 2027 as the end of mainstream maintenance for SAP Identity Management 8.0.
• Extended support is available until the end of 2030.
• Enterprise replacement timelines typically take 18 to 36 months.

Context

SAP IDM’s sunset is a governance and operating-model problem first, and a product-selection problem second. When a long-running identity platform reaches end of mainstream maintenance, the real challenge is preserving provisioning, approvals, SoD checks, and audit evidence while the underlying control plane changes.

For organisations with SAP-heavy estates, the issue is not limited to SAP-native workflows. Many programmes have accumulated custom logic, legacy integrations, and cross-system dependencies that cannot be recreated safely in a single cutover, which is why replacement planning has to start long before support expiration.

The article’s core message is that waiting until the maintenance deadline turns an identity migration into an emergency. That is atypical for mature IAM programmes, but common where identity governance has been allowed to harden around one platform for too long.

Key questions

Q: What breaks when SAP IDM is retired before its governance workflows are replaced?

A: The main failure is not authentication, it is lifecycle control. If provisioning, approvals, and revocation were embedded in SAP IDM, retiring it too early can leave joiner, mover, and leaver processes split across manual steps and disconnected systems. That increases privilege creep, weakens auditability, and makes offboarding incomplete. The migration target must preserve the control path, not just the user interface.

Q: Why does an SAP IDM sunset create compliance and operational risk?

A: Because identity controls do not stop being needed when the platform reaches end of support. If provisioning, certifications, and Segregation of Duties checks are not preserved during migration, organisations can lose evidence, introduce access gaps, or miss policy violations while the new environment is still stabilising.

Q: What are the signs that an SAP IDM migration is carrying too much technical debt?

A: Look for deeply nested custom workflows, unclear ownership of old approval logic, undocumented integrations, and repeated efforts to mimic legacy behaviour exactly in the target platform. Those are strong signals that the programme is re-platforming complexity rather than simplifying 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.

Technical breakdown

Why SAP IDM sunset creates migration complexity

SAP IDM sunset is not just a licence or support event. Identity management platforms sit at the centre of provisioning, approvals, role mapping, and policy enforcement, so retirement of the platform affects the control paths that keep access consistent across SAP and non-SAP systems. In practice, the problem is that the business process often depends on platform-specific scripts, connectors, and exception handling that are difficult to re-create cleanly. Once those controls are tied to one product, the migration has to preserve both state and behaviour, not just data. That is why timeline, inventory, and dependency discovery matter before selection begins.

Practical implication: Map every IDM workflow, integration, and custom rule before choosing a replacement path.

Why custom logic becomes migration debt

SAP IDM environments often contain JavaScript, SQL, and bespoke approval logic that has accreted over years of business change. Those customisations are valuable only if they still reflect current business policy, because the same logic can become technical debt when moved into a modern IGA stack. Clean-core design reduces that burden by favouring standardised workflows and configuration over re-implementing every legacy exception. The technical issue is not whether custom logic is possible, but whether it is still necessary, supportable, and auditable in the target model. Migration projects fail when they copy old complexity forward unchanged.

Practical implication: Rationalise custom rules before migration instead of recreating them verbatim in the new platform.

How hybrid IAM and federation shape the target architecture

The article points to modern alternatives that rely on API-first integration, federation standards such as SAML 2.0 and OIDC, and SCIM-based provisioning. That matters because a replacement platform has to support both SAP-specific systems and wider enterprise applications without forcing one control model onto every environment. A hybrid architecture can preserve SAP depth while extending governance across cloud services, HR systems, and downstream business applications. The architectural question is whether the target state can sustain lifecycle automation, access requests, certifications, and audit evidence across the full estate without creating a second disconnected identity silo.

Practical implication: Choose a target architecture that governs SAP and non-SAP systems under one lifecycle model.

Breaches seen in the wild

• SAP SQL Anywhere Monitor hard-coded credentials (CVE-2025-42890): Hard-coded credentials in SAP SQL Anywhere Monitor scored CVSS 10.0 (CVE-2025-42890); SAP removed the tool, and no exploitation was seen.
• SAP Kubernetes secrets exposure 2023: Kubernetes secrets committed to GitHub exposed 203 valid registry credentials, including SAP artifact repository access. SAP closed it after Aqua's report.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Lifecycle governance breaks down when identity platforms are treated as interchangeable tools. SAP IDM sunset shows that provisioning, approvals, and certification flows are part of the control architecture, not just the software layer. If those flows are copied into a new platform without redesign, the organisation preserves the same governance debt under a different interface. The practitioner conclusion is that migration scope must include control design, not only platform selection.

Multi-year migration windows change the risk model for identity programmes. When enterprise replacement takes 18 to 36 months and support deadlines are fixed, delay becomes a control risk. The longer teams wait, the more they compete for implementation talent, budget, and internal subject matter expertise at the same time. That pushes identity work from a planned modernisation into a constrained delivery exercise, which raises the chance of gaps in access governance, testing, and audit readiness.

Clean-core thinking is now an identity governance requirement, not a design preference. The central named concept here is migration debt carryover: legacy custom logic, dependencies, and approval paths that survive into the replacement platform unchanged. That debt is what makes a sunset painful, because the programme inherits yesterday’s exceptions instead of converting them into standardised policy. Practitioners should treat simplification as part of control integrity, not an optional optimisation.

SAP-centric governance no longer scales as a standalone identity strategy. The article makes clear that organisations need identity controls that extend beyond SAP into cloud, HR, and other enterprise systems. That pushes the market toward cross-enterprise governance models where audit evidence, lifecycle management, and SoD operate across mixed estates. The implication for practitioners is that platform selection now has to reflect the full identity perimeter, not a single application family.

Audit continuity is the real test of any replacement path. Support deadlines matter because the last months of a legacy platform’s life are where unsupported workflows, brittle integrations, and rushed cutovers collide. The governance question is whether the replacement can preserve certifications, evidence trails, and risk controls during transition. If it cannot, the organisation may end up with a technically migrated system and a weakened compliance position.

From our research library:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Read next: NHI Lifecycle Management Guide

What this signals

Migration debt carryover: the biggest risk is not platform retirement itself, but the tendency to transplant obsolete approval paths, custom scripts, and integration assumptions into the replacement system. That creates a new tool with the same governance failure modes, which is why simplification has to happen before cutover, not after.

SAP IDM sunset also changes how teams should think about identity architecture over the next budget cycle. The programme is no longer a single replacement decision; it is a staged redesign of lifecycle controls, audit evidence, and enterprise integration that must survive both SAP and non-SAP estates.

Identity teams should expect the migration to expose where their governance model is overly dependent on one application family. That pressure is useful if it forces consolidation of workflows, cleaner role design, and better separation between policy and platform implementation.

For practitioners

• Inventory the full IDM control surface Document every SAP IDM workflow, custom rule, connector, approval path, and exception so the migration scope includes governance logic as well as data objects.
• Rationalise legacy customisation before selection Separate current business requirements from inherited scripts and remove workflows that no longer support policy, audit, or operational value.
• Sequence the migration by control criticality Move identity lifecycle and access request flows first, then certifications, SoD, and emergency access, so the most sensitive controls are validated early.
• Run parallel validation before cutover Operate the legacy and target platforms side by side long enough to compare provisioning outcomes, policy decisions, and audit artefacts.
• Recheck SAP and non-SAP coverage together Confirm that the target platform can govern SAP systems, cloud services, and HR-linked identity flows under one lifecycle and evidence model.

Key takeaways

• SAP IDM sunset is a governance redesign problem as much as a platform retirement problem.
• Enterprise replacement timelines are measured in years, not quarters, so delay quickly becomes delivery risk.
• The control that matters most is whether the new environment can preserve lifecycle, access, and audit logic without carrying forward legacy complexity.

Key terms

• Identity migration debt: The unresolved operational and governance work that accumulates when identity dependencies are discovered late or left behind during platform replacement. It shows up as manual exceptions, duplicated approvals, or lingering credentials that keep the old control model alive.
• Clean Core: A clean core is an SAP operating model that keeps the digital core minimally customised and pushes extensions into supported layers. For identity governance, that means access controls, SoD rules, and audit evidence must work through stable interfaces instead of embedded modifications that break during upgrades.
• 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.
• 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.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.