TL;DR: The evaluation now extends beyond traditional segregation of duties to SAP threat detection, system hardening, privileged access management, and audit support, reflecting broader governance expectations for SAP and non-SAP estates, according to Pathlock's 2026 Leadership Compass for SAP Access Control and Security. The security question is shifting from role design alone to continuous control across access, privilege, and assurance.
Editorial analysis by NHI Mgmt Group, based on content published by Pathlock: “Pathlock Named Overall Leader in the KuppingerCole Report Highlighting Excellence in Access Control and Security for SAP”.
Key questions
Q: How should security teams govern access across SAP and business applications?
A: Security teams should govern access by linking identity, entitlement, and activity data across systems instead of certifying each application separately.
Q: Why do traditional SoD controls fall short in modern SAP environments?
A: Because SoD only checks for conflicting permissions at design time, while modern SAP risk also comes from how access is used, elevated, and monitored in production.
Q: What breaks when SAP access governance ignores privileged access management?
A: Access control becomes easier to certify on paper than to defend in practice.
Practitioner guidance
- Expand SAP governance scope Reassess whether your SAP programme still treats SoD as the primary control outcome, or whether it now needs explicit coverage for threat detection, hardening, privileged access, and audit support.
- Map privileged access paths Inventory where SAP administrators, support users, and technical operators hold standing elevation paths that bypass normal business role controls and then assign clear ownership for each path.
- Add transaction-level risk review Use fine-grained transaction analysis to identify access that is formally authorised but operationally out of step with the business context or separation-of-duties intent.
Bottom line: The article shows SAP access control moving past a narrow SoD model into continuous governance that also covers detection, hardening, PAM, and audit support.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
SAP access control is being redefined as a continuous governance problem, not a periodic compliance check. The article shows the market moving from SoD-only thinking to a wider model that includes threat detection, hardening, PAM, and audit support. That matters because static role reviews do not address how access is actually used in production. Practitioners should interpret this as a signal that SAP control design is converging with broader identity governance disciplines.
A question worth separating out:
Q: What is the difference between SAP audit checks and runtime access control?
A: Audit checks verify whether policies, roles, and approvals look correct, while runtime access control determines whether access is actually constrained, monitored, and appropriate as it is used. In SAP, both are needed because compliance evidence alone does not stop misuse.
👉 Read our full editorial: SAP access control is expanding beyond SoD and audit checks