They often focus on provisioning and certification screens while underestimating the importance of transaction-level access, SoD rules, and custom workflow preservation. A migration that loses those controls can improve administration while weakening operational governance. The replacement has to prove it can carry the old control fidelity into the new environment.
Why This Matters for Security Teams
Moving off SAP IDM is rarely a simple platform swap. Security teams often assume the hardest work is recreating joiner-mover-leaver flows and approval screens, but the real risk sits deeper: transaction-level entitlements, segregation of duties logic, and exception handling that kept access governable in the old stack. When those controls are not mapped precisely, the new IGA tool may look cleaner while silently loosening enforcement.
This matters because identity governance is not just about who gets provisioned, but what they can do inside critical business processes. A mature migration should preserve control fidelity across roles, entitlements, and workflows, not just replicate visible UI steps. NIST CSF 2.0 emphasizes governance and continuous oversight, which is exactly where weak migrations fail if policy intent is lost in translation. NHIMG research on the Ultimate Guide to NHIs — The NHI Market also shows how often organisations underestimate lifecycle and privilege problems until after exposure has already occurred.
In practice, many security teams discover broken SoD enforcement only after audit findings, access anomalies, or production process abuse have already exposed the gap.
How It Works in Practice
The migration should start with control discovery, not tool selection. SAP IDM often contains custom rules that are easy to overlook because they are embedded in workflows, role derivation, connector logic, and compensating controls. Those elements need to be inventoried and translated into the target IGA platform as explicit policy requirements. That usually means documenting:
- transaction-level access dependencies tied to critical SAP business objects
- SoD conflicts and mitigation rules, including exception approvals
- custom provisioning logic, re-certification triggers, and escalation paths
- evidence requirements for audit, not just administrative convenience
Security teams should validate whether the target platform can express these controls natively or whether it requires external policy engines, custom code, or workflow extensions. Where the new platform lacks equivalent granularity, best practice is to preserve enforcement through compensating controls rather than accepting weaker governance for the sake of simplification. That approach aligns with current guidance in the NIST Cybersecurity Framework 2.0, which treats identity governance as part of ongoing risk management rather than a one-time migration task.
NHIMG’s SAP Breach research is a useful reminder that identity control gaps in SAP-adjacent environments are rarely theoretical. The practical test is whether the new IGA platform can reproduce the same access decisions, revocation timing, and exception handling under real operational load. If not, the migration becomes a governance downgrade disguised as modernization. These controls tend to break down when organisations rush cutover before reconciling inherited SoD logic and custom workflows across all connected SAP landscapes.
Common Variations and Edge Cases
Tighter migration controls often increase project cost and timeline, requiring organisations to balance speed against control fidelity. That tradeoff becomes especially sharp when SAP IDM was used as a control hub for more than one business unit, region, or ERP instance. In those environments, a “lift and shift” conversion usually misses local exceptions, inherited roles, and approval paths that were never fully documented.
There is no universal standard for how much custom workflow should be preserved versus redesigned. Current guidance suggests preserving any control that affects auditability, SoD enforcement, or privileged transaction access, while allowing non-control-related administrative simplifications. In contrast, cosmetic workflow changes are usually safe to redesign if they do not alter the decision logic behind access approval or revocation.
Security teams should also watch for edge cases such as emergency access, manual compensating controls, delegated approvers, and interfaces feeding downstream systems that still rely on old SAP IDM events. If those dependencies are not tested end to end, the new platform may pass provisioning tests while failing real governance scenarios. The lesson is simple: modernising the tool is not the same as modernising the control model.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Highlights risk from weak credential lifecycle and access governance during migration. |
| OWASP Agentic AI Top 10 | Useful where migration workflows automate decisions and need safe policy enforcement. | |
| CSA MAESTRO | Covers orchestration, policy, and control assurance for complex identity workflows. | |
| NIST CSF 2.0 | GV.OC-01 | Identity governance migrations must preserve organisational context and control ownership. |
| NIST AI RMF | Supports risk-based validation when automated decisions and exceptions change in new workflows. |
Preserve lifecycle controls and revoke or rotate access paths that lose governance fidelity in the new IGA stack.
