TL;DR: SAP’s SAP IDM 8.0 roadmap ends mainstream maintenance in 2027 and extended maintenance in 2030, pushing customers toward cloud-first identity governance, Microsoft Entra ID, SAP Cloud Identity Services, and partner-led migration paths according to Pathlock. The shift breaks the assumption that legacy IDM can be treated as a routine upgrade; it is a forced architecture change with lifecycle, compliance, and hybrid integration consequences.
At a glance
What this is: Pathlock analyses SAP IDM end of life and concludes that the retirement forces organisations into cloud-first identity governance rather than a simple product upgrade.
Why it matters: IAM, IGA, and SAP security teams have to re-plan lifecycle, compliance, and hybrid integration now because the legacy IDM model is being retired on a fixed timetable.
By the numbers:
- SAP Identity Management 8.0 mainstream maintenance ends on 31st December 2027, according to Pathlock.
- SAP IDM extended maintenance will be available until 2030 at an additional cost, according to Pathlock.
- A typical IAM migration takes between 18 and 36 months for a large organisation, according to Pathlock.
Context
SAP IDM end of life means the organisation has to replace an identity management operating model, not just renew a licence. The article frames this as a cloud-first shift in identity governance, with Microsoft Entra ID, SAP Cloud Identity Services, and partner services taking over different parts of the lifecycle.
For SAP-heavy estates, the practical issue is that identity logic has lived in custom scripts, legacy connectors, and on-premises workflows that do not map neatly to cloud-native governance. That creates migration, compliance, and integration work across SAP and non-SAP systems at the same time.
The article’s core message is that the retirement of SAP IDM is a structural transition, not a maintenance event. Organisations that defer planning risk being forced into compressed migration decisions across provisioning, certification, and audit readiness.
Key questions
Q: What should SAP teams do first when IDM end of life is approaching?
A: Start by mapping every live IDM workflow, dependency, and integration before selecting the replacement model. The first risk is not technical failure but migration blind spots, where joiner, mover, leaver logic and compliance evidence are left undocumented until the deadline is close.
Q: Why does SAP IDM retirement create more risk than a normal upgrade?
A: Because the article describes the final functional release, not a successor version. That means organisations are not moving to the next release in the same architecture, but to a cloud-first operating model that changes provisioning, governance, and audit ownership at the same time.
Q: Where do SAP IDM migrations usually fail in practice?
A: They fail when teams carry custom scripts, connector logic, and approval flows forward without redesigning them for the target governance layer. That leaves brittle dependencies in place and makes the new environment look modern while still behaving like the old one.
Q: What should organisations validate before replacing SAP IDM?
A: They should validate lifecycle workflows, connector coverage, role mappings, and audit outputs in parallel. A successor platform is only viable if it can preserve joiner-mover-leaver behaviour across SAP and non-SAP systems without weakening revocation or approvals.
Technical breakdown
Why SAP IDM retirement is a governance redesign, not an upgrade
SAP IDM 8.0 is described as the final functional release, which means there is no successor version that preserves the old operating model. That matters because identity governance is not only about provisioning accounts, but about how lifecycle logic, role assignment, approvals, and audit evidence are produced across systems. When the underlying platform stops evolving, organisations must move those controls into a different architecture. In this case, the article points toward cloud identity services, partner governance, and standardised integrations rather than a direct version-to-version replacement.
Practical implication: Treat the migration as an identity architecture programme, not a software patch cycle.
How cloud identity services change SAP lifecycle control
The article presents SAP Cloud Identity Services as the cloud coordination layer for authentication, provisioning, and directory synchronisation. Identity Authentication handles sign-in and MFA, Identity Provisioning moves identities through SCIM and related connectors, and Identity Directory keeps profile data aligned across applications. This is a different model from custom IDM scripting because the control plane is more configuration-led and more dependent on standard interfaces. For practitioners, the technical shift is from bespoke workflow code to governed identity services that can operate across SAP and non-SAP environments.
Practical implication: Map each IDM workflow to the cloud service that will own it before decommissioning legacy scripts.
Why hybrid SAP estates make lifecycle and compliance harder
The article shows that modern SAP environments are no longer limited to a single ERP stack. Organisations now combine ECC, S/4HANA, BTP, SuccessFactors, and external SaaS platforms, which means joiner, mover, leaver processes and segregation-of-duties analysis must span multiple systems. Legacy IDM struggled to handle cloud-native controls such as just-in-time access, and that gap becomes more visible as governance moves into hybrid estates. The technical challenge is not only connectivity, but maintaining a consistent control model across identities, roles, and audit evidence in different application domains.
Practical implication: Design governance around cross-application identity flows, not around one legacy repository.
Breaches seen in the wild
- 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.
- 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.
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
Legacy IDM end of life turns governance into an architecture decision: When SAP IDM reaches end of maintenance, the control problem is no longer how to keep an old platform running, but how to preserve lifecycle governance across a cloud-first estate. The article makes clear that organisations are being pushed toward a distributed model spanning SAP Cloud Identity Services, Microsoft Entra ID, and partner controls. Practitioners should read that as a programme redesign trigger, not a routine platform refresh.
The clean-core objective changes the identity operating model: Moving identity logic out of custom IDM scripts and into policy-driven cloud services reduces technical debt inside ERP, but it also changes where governance authority lives. That shift aligns with broader cloud identity patterns, where standard interfaces and configuration replace local code. The implication is that identity teams must stop treating custom workflow logic as a durable control layer.
Cloud-first identity governance is now the dominant SAP direction: The article shows SAP separating authentication, provisioning, and governance across specialised services rather than keeping them inside one monolithic IDM stack. That is a stronger signal about market direction than any individual product claim. For practitioners, the field is moving toward federated governance, where identity lifecycle, access approvals, and auditability are assembled from interoperable services.
Partner-led migration is becoming part of the governance model: SAP’s direction leaves no direct like-for-like replacement, so organisations must combine native SAP services with specialist governance partners for lifecycle, compliance, and hybrid integration. That is a notable shift in operating assumptions because the governance stack is now architected across vendors and domains. The practical conclusion is that sourcing, integration, and control ownership must be planned together.
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: Identity Security Programme Guide
What this signals
Cloud-first identity governance now has to absorb the control work legacy IDM used to hide: Organisations should expect provisioning, certification, and audit evidence to be separated across multiple services rather than concentrated in one platform. That increases the need for explicit ownership of lifecycle controls and makes integration design part of governance design.
SAP IDM retirement is also a clean-core signal: moving identity logic out of custom scripts reduces ERP technical debt, but it forces teams to standardise how governance is executed across SAP and non-SAP applications. The practical question is no longer whether identity management is cloud-based, but whether the programme can preserve control consistency across domains.
For practitioners
- Inventory every SAP IDM workflow Catalogue joiner, mover, leaver, certification, SoD, and emergency access processes before deadlines force a compressed migration plan.
- Separate lifecycle from governance functions Assign provisioning, authentication, directory sync, and access governance to the correct target services rather than carrying IDM logic forward unchanged.
- Prioritise hybrid integrations first Map SAP ECC, S/4HANA, BTP, SuccessFactors, and non-SAP SaaS dependencies early so migration sequencing reflects real control paths.
- Retire custom scripts deliberately Replace bespoke IDM scripts with configuration-based workflows or policy rules where possible, and isolate any remaining custom logic that still carries control decisions.
- Rebuild access review and SoD evidence Ensure the target governance model can produce certification, segregation-of-duties analysis, and audit-ready reporting across all connected applications.
Key takeaways
- SAP IDM retirement is a governance and architecture change, not a simple software refresh.
- The article points to fixed maintenance deadlines, with mainstream support ending in 2027 and extended maintenance available to 2030.
- Teams need a phased migration plan that preserves lifecycle control, SoD analysis, and audit evidence across hybrid SAP estates.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article covers leaver workflows and access revocation during IDM migration. |
| NHI-05 — Overprivileged NHI | The article highlights role bloat and excessive permissions in SAP and connected systems. | |
| Recommendation — Review offboarding flows so retiring IDM does not leave stale access behind. Use access certification and SoD analysis to reduce overprivileged accounts during migration. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about reassigning and governing entitlements across a new identity model. |
| Recommendation — Rebaseline entitlement governance before moving lifecycle control to cloud services. | ||
| CIS Controls v8 | CIS-5 — Account Management | The migration depends on accurate account provisioning, revocation, and lifecycle control. |
| Recommendation — Tighten account management procedures before decommissioning legacy IDM workflows. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Standing access and stale permissions can expand attacker reach across hybrid systems. |
| Recommendation — Map stale entitlements to credential access and lateral movement exposure in hybrid SAP estates. | ||
Key terms
- Identity Governance and Administration (IGA): A framework of policies, processes, and technology to manage and govern digital identities and their access rights. Increasingly extended to cover non-human identities alongside human users.
- Joiner, Mover, Leaver Workflow: A joiner, mover, leaver workflow is the process that grants, updates, and removes access as a user or identity changes state. In modern programs, the same logic should extend beyond employees to service accounts and AI agents so access does not persist after need ends.
- 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.
- Cloud Identity: A cloud identity is any account, role, token, or credential used to access cloud services and resources. In practice, it includes both human and non-human identities that can authorize actions in infrastructure, applications, or automation pipelines. Governance depends on knowing which identity type is active and what it can do.
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 or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org