TL;DR: SAP Identity Management 8.0 mainstream maintenance ends on December 31, 2027 with no successor, forcing manufacturing firms to decide whether replacement preserves old gaps or redesigns governance across SAP, contractors, plant systems, and connected applications, according to OpenIAM. The real risk is treating the move as a migration project instead of a lifecycle, SoD, and audit-scope decision.
At a glance
What this is: OpenIAM argues that SAP IDM end of maintenance is a governance redesign problem for manufacturing, not just a platform swap, because the replacement choice must cover lifecycle, SoD, contractor, and audit scope gaps.
Why it matters: For IAM and IGA teams, this matters because a like-for-like replacement can preserve the same control gaps across SAP, non-SAP apps, and non-employee populations that auditors will still test.
Context
SAP Identity Management is an identity lifecycle platform used to provision, deprovision, approve, and certify access across SAP and connected systems. When a platform like this reaches end of maintenance, the issue is not only where records move, but whether the replacement can govern the same identity populations, approval paths, and audit evidence the business actually depends on.
For manufacturing organisations, the governance gap is broader than a single product retirement. Contractor identities, plant transfers, SAP GRC coexistence, service accounts, and plant systems all sit around the SAP core, and the article's central argument is that a replacement must be designed to govern that wider perimeter from the start.
That makes the decision a programme-level architecture choice rather than a software procurement exercise. The article frames the deadline as a forcing function: organisations can either use it to modernise governance or re-create the old operating model on a new platform.
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: When should manufacturing firms prioritise governance redesign over platform migration?
A: They should do it before vendor selection, because the right product depends on the control model it must support. If governance comes second, teams tend to optimise for migration speed and end up rebuilding the same limitations on a different stack.
Q: How do teams know whether an SAP IDM replacement is working?
A: It is working when reviews, approvals, and evidence production cover SAP, connected applications, contractors, and site-specific lifecycle events without relying on manual exceptions. If those populations still need workarounds, the replacement is only partial.
Q: What is the difference between SAP Cloud Identity Services and a full IGA replacement?
A: SAP Cloud Identity Services covers SAP authentication and provisioning, but a full IGA replacement also governs lifecycle policy, access reviews, evidence, and cross-application control scope. Manufacturing environments need both layers if they want the governance model to match the real audit perimeter.
Technical breakdown
Why SAP IDM's scope was never the full governance model
SAP IDM automated joiner, mover, and leaver workflows, plus access requests, approvals, certifications, and evidence collection. But it was still a lifecycle engine, not a complete governance model. It did not natively enforce Segregation of Duties, and it was strongest inside SAP-first estates. In manufacturing environments, that created a split between identity movement and control enforcement: access could be provisioned, but the broader policy context still lived elsewhere. Practical implication: evaluate replacement scope against the full governance model, not just provisioning parity.
Practical implication: define replacement requirements around lifecycle, SoD, reviews, and evidence, not around feature-by-feature parity.
Why SAP Cloud Identity Services and Microsoft Entra ID are partial answers
SAP Cloud Identity Services covers SAP authentication and provisioning, while Microsoft Entra ID covers enterprise federation. Neither product, by itself, restores the full governance scope many manufacturing firms relied on SAP IDM to approximate across SAP, non-SAP applications, and operational environments. The architectural issue is that authentication and federation are not the same as identity governance. Practical implication: separate identity platform selection from governance architecture design, because one will not replace the other.
Practical implication: treat federation and provisioning as components inside a wider governance design, not as the design itself.
Plant transfers and contractor identities expose the replacement gap
Manufacturing identity lifecycle is not a generic office-worker model. Plant transfers can trigger different approvals, different entitlements, and different site-level access patterns, while contractors often sit outside the primary HR source of truth. Those populations break assumptions that workflow templates built for employee-centric environments can handle the whole estate. Practical implication: replacement design must include explicit lifecycle patterns for contractors, site moves, and non-HR-sourced identities before migration work begins.
Practical implication: model contractor and plant-transfer lifecycle separately, then map them into the target governance process.
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.
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
Like-for-like SAP IDM replacement preserves the same governance debt the old platform carried. The article makes clear that SAP IDM handled lifecycle workflow, but not SoD enforcement, broad non-SAP governance, or contractor-scale lifecycle management. That means a straight migration can preserve the audit and control gaps that made the original environment fragile. The practitioner lesson is to treat replacement as debt retirement, not software continuity.
Replacement scope is the real control boundary. SAP Cloud Identity Services and Microsoft Entra ID each cover important pieces of the identity stack, but neither independently restores the end-to-end governance model that manufacturing needs. This is why the decision is architectural: identity federation, provisioning, review evidence, and SoD controls live in different layers. The implication is that teams must design the governance boundary first, then map products to it.
Manufacturing adds a site-based identity problem that generic IAM thinking misses. Plant transfers, contractor governance, and operational systems create lifecycle events that are not cleanly represented in employee-centric workflows. A replacement that assumes HR-driven joiner, mover, leaver logic will underfit the real environment. Practitioners should expect the hardest work to sit in identity population modelling, not in software deployment.
Identity governance for manufacturing now extends beyond the SAP perimeter. The article identifies SAP, Microsoft Entra ID, ServiceNow, cloud applications, contractor populations, service accounts, and plant systems as part of the effective audit surface. That broader surface changes what an auditor will test and what a governance programme must evidence. The practical conclusion is that replacement success will be measured by estate-wide control coverage, not by SAP continuity alone.
Audit pressure turns the migration timetable into a governance decision window. The 2027 end-of-maintenance date and the article's 18 to 36 month planning horizon mean delay narrows design options before technical work even begins. Organisations that wait risk choosing under pressure and reproducing the same control model. The implication is simple: the planning sequence must start with governance design, not product shortlisting.
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
Replacement scope now has to match the real audit perimeter. Manufacturing identity programmes can no longer stop at SAP boundary coverage, because the governance surface now includes contractors, plant systems, service accounts, and connected applications. Teams that plan only for platform continuity will keep inheriting the same control gaps under a different product name.
Identity lifecycle design should be population-specific, not template-first. Plant transfers and contractor onboarding do not behave like standard office joiner-mover-leaver events, so a future-state model needs separate paths for those populations. That is where lifecycle governance becomes a programme design exercise rather than an implementation detail.
For practitioners
- Define the governance target before selecting a platform Map the controls the replacement must deliver across SAP, non-SAP applications, contractors, and audit evidence before any tool shortlist is approved.
- Separate SoD enforcement from lifecycle orchestration Preserve the risk logic that belongs in SAP GRC or equivalent controls, and make sure the replacement adds lifecycle and review coverage instead of duplicating detection logic.
- Model contractor and plant-transfer journeys explicitly Document how non-employee identities and site moves will be approved, provisioned, reviewed, and removed, because HR-driven joiner-mover-leaver logic will not cover them cleanly.
- Inventory service accounts as part of the replacement scope Include non-human identities in the target-state design so the programme does not recreate a human-only governance model around systems that rely on service and integration accounts.
- Build the audit evidence model alongside migration planning Define what proof reviewers need across SAP and connected systems before moving entitlements, so the new platform produces evidence that matches the future control perimeter.
Key takeaways
- The core risk is not the loss of SAP IDM as software, but the temptation to replace it without fixing the governance model it never fully covered.
- Manufacturing estates expose a broader identity perimeter than SAP alone, including contractors, plant systems, service accounts, and connected business applications.
- A successful replacement will be judged by estate-wide lifecycle, SoD, and evidence coverage, not by how closely it mimics the old workflow engine.
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 addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about redesigning entitlement governance across SAP and connected systems. |
| Recommendation — Use PR.AA-05 to align replacement design with enterprise-wide entitlement governance, not SAP-only provisioning. | ||
| CIS Controls v8 | CIS-5 — Account Management | Replacement planning hinges on governing joiners, movers, leavers, contractors, and service accounts. |
| Recommendation — Apply CIS-5 to rebuild account governance for employee and non-employee identities before migration. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article highlights the risk of preserving excessive access and weak lifecycle controls during replacement. |
| Recommendation — Apply AC-6 to ensure the new governance model reduces standing access instead of copying old privilege patterns. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Manufacturing replacements must handle contractors and non-employee identities that SAP IDM did not govern well. |
| NHI-05 — Overprivileged NHI | Service accounts and connected systems in the article need explicit governance scope in the replacement design. | |
| Recommendation — Use NHI-01 to close offboarding gaps for contractors, service accounts, and other non-human identities. Use NHI-05 to review machine and integration access as part of the SAP IDM replacement programme. | ||
Key terms
- Identity Lifecycle Governance: Identity lifecycle governance is the set of processes that create, change, review, rotate, and revoke access across human and non-human identities. It matters because access risk usually increases when lifecycle events are slow, incomplete, or disconnected from the systems that rely on them.
- 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.
- Contractor governance: The set of policies and controls used to manage temporary or third-party access. For physical environments, it includes approval, time limits, scope limits, and automatic revocation when the assignment or relationship ends.
- Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
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 July 28, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org