How should organisations approach SAP IDM replacement without losing governance coverage?

Why This Matters for Security Teams

SAP IDM replacement is not just an application project. It is a governance transition that can silently remove certification evidence, segregation of duties checks, and privileged access review if the new platform only covers human joiner-mover-leaver flows. That risk is especially high when SAP has grown into a broader identity control plane for SAP, non-SAP, contractors, service accounts, and automation. NIST’s NIST Cybersecurity Framework 2.0 expects identity governance to support the full access lifecycle, not just provisioning.

The practical problem is that many organisations discover missing controls only after the old SAP IDM workflows have already been retired. NHIMG research shows how often identity blind spots become real incidents, not theoretical risk: the 2024 ESG Report: Managing Non-Human Identities found that 72% of organisations have experienced or suspect a breach of non-human identities. That matters here because SAP IDM replacements often expose the same control gap across service accounts, integrations, and machine identities if those are not modelled from the start. In practice, many security teams encounter missing governance only after the first audit or access incident reveals that the “replacement” preserved workflows but not control evidence.

How It Works in Practice

The safest approach is to treat SAP IDM replacement as a control mapping exercise before any migration work begins. Start with every entitlement source, approval path, certification campaign, SoD rule, privileged role, and downstream integration currently enforced by SAP IDM. Then classify what must remain intact across SAP, non-SAP, external identities, and non-human identities. The replacement platform should be tested against those control outcomes, not just against provisioning speed or connector count.

For governance coverage, current guidance suggests four things must be demonstrable:

• Access requests, approvals, and certifications can be applied consistently across SAP and non-SAP systems.
• SoD rules are preserved or translated without weakening the original risk model.
• Privileged access review still works for both human admins and service or automation identities.
• Identity lifecycle events are auditable end to end, including deprovisioning and exception handling.

That is where the control model matters. NIST SP 800-53 Rev. 5 supports the underlying access governance expectations, especially around least privilege, account management, and auditability through NIST SP 800-53 Rev 5 Security and Privacy Controls. For identity-specific depth, NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs helps frame how lifecycle governance must extend beyond employees to secrets, integrations, and automation. If the replacement cannot show policy parity for those flows, it is not a governance-preserving migration.

Security and audit teams should also validate reporting. The new system must preserve historical evidence, current state visibility, and exceptions in a way that auditors can trace without stitching together multiple tools. These controls tend to break down when SAP IDM was also serving as the only authoritative workflow engine for custom SAP roles and legacy integrations, because those dependencies are often undocumented until cutover.

Common Variations and Edge Cases

Tighter governance coverage often increases migration complexity, requiring organisations to balance control continuity against the speed of decommissioning SAP IDM. That tradeoff is most visible in hybrid estates where SAP authorisation models, non-SAP provisioning, and machine identities are handled by different teams with different approval standards.

One common variation is partial replacement, where a new IGA platform handles human identities but SAP-specific workflows remain in custom code or side processes. That can work temporarily, but current guidance suggests it should be treated as a bounded exception with explicit ownership, review cadence, and a retirement date. Another edge case is external identity governance, where contractors, partners, and third-party access live outside the old SAP IDM scope. If the replacement cannot unify those identities with the same certification and SoD logic, it creates a split governance model that is hard to defend in audit.

This is also where non-human identity coverage matters. NHIMG’s Top 10 NHI Issues highlights how often secrets, ownership, and lifecycle gaps weaken control coverage, and the SAP Breach material shows why SAP environments cannot be treated as isolated from broader identity risk. The safe rule is simple: if the replacement cannot prove equivalent governance for every identity class that SAP IDM touched, the old control gap has only been renamed, not removed.

Related resources from NHI Mgmt Group

• How should security teams replace SAP GRC without losing access governance coverage?
• How should federal teams automate ICAM without losing governance?
• How should organizations approach the governance of AI agents?
• Should organisations prioritise external exposure or internal credential governance first?