Who should own the SAP IDM replacement decision?

Why This Matters for Security Teams

SAP IDM replacement is rarely a tooling refresh. It is a governance decision that determines who can approve access, how quickly access is removed, and whether the organisation can prove control to auditors after the fact. If the replacement cannot handle service accounts, batch jobs, integrations, and privileged access with the same discipline as human users, the result is usually a split control plane and weak evidence. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which is exactly why replacement ownership cannot sit with one team alone; the blast radius spans identity, SAP, operations, and compliance.

The security team may be tempted to frame this as an IAM migration, but SAP estates are operational systems first and identity platforms second. A poor ownership model leaves gaps between policy, implementation, and plant reality, especially when access changes must happen without interrupting production. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is clear that accountability must be explicit, but it does not remove the need for business ownership of critical workflows. In practice, many security teams encounter ownership disputes only after a failed audit, a delayed deprovisioning event, or a privileged SAP account is reused in a way nobody had intended.

How It Works in Practice

The replacement decision should be owned as a joint governance programme, not a single-platform procurement. IAM typically leads the identity architecture, SAP architecture defines integration boundaries, compliance defines evidence and control requirements, and plant or business operations define uptime and change windows. That shared ownership needs one accountable executive sponsor, because the technical decision will cascade into provisioning models, SoD enforcement, emergency access, and offboarding for both people and NHIs.

Current best practice is evolving toward central policy with distributed operational input. In practical terms, the team should decide whether the new capability can enforce role-based access, just-in-time elevation, approval workflows, and machine identity governance across SAP and adjacent systems. The most useful test is not whether the tool has broad features, but whether it can prove who approved what, when access expired, and how service credentials were rotated or revoked. NHIMG’s research on SAP SQL Anywhere Monitor Hardcoded Credentials and SAP Breach shows why hidden credentials and weak lifecycle controls create real operational risk, not just audit findings.

A workable decision process usually includes:

• an inventory of SAP users, technical users, service accounts, and external connectors
• control requirements for joiner, mover, leaver, and emergency access scenarios
• evidence requirements for auditors, regulators, and internal control owners
• clear integration ownership for SAP, IAM, PAM, and downstream systems
• sign-off from the business process owners who will live with the change

That model tends to break down when plant operations are excluded from design decisions, because access controls that look correct on paper can delay maintenance, break batch processing, or encourage shadow accounts to reappear.

Common Variations and Edge Cases

Tighter governance often increases implementation overhead, so organisations must balance auditability against operational speed. There is no universal standard for this yet, especially where SAP landscapes include custom code, legacy connectors, or outsourced support teams.

One common edge case is when security wants the replacement owned by IAM alone because the problem looks like provisioning. That usually fails when SAP-specific authorisation concepts, segregation-of-duties rules, or emergency access workflows are not understood well enough outside the SAP team. Another variation is when compliance tries to own the decision end to end. That can improve control mapping, but it often produces a system that satisfies evidence collection without fitting day-to-day operations.

The strongest pattern is shared ownership with clear accountability boundaries: IAM owns identity mechanics, SAP architecture owns platform fit, compliance owns control assurance, and business operations owns service impact. NHI governance should be part of the evaluation because service accounts and API keys are often more persistent than human access, and their lifecycle is frequently where replacement projects fail. The practical question is not who signs the purchase order, but who can enforce the control model after go-live.

Related resources from NHI Mgmt Group

• Who should own the decision between replacement and compensating controls for legacy HSMs?
• When should organisations prioritise SAP IDM replacement over other IAM work?
• Who should own the decision when identity governance is central to GRC?
• Who should own the decision when both PAM and IGA are needed?