You have a segregation of duties (SoD) matrix, documented ERP roles and an annual access review. Yet every audit surfaces the same findings: role combinations that crept in between two reviews, emergency accounts that were never deactivated, exceptions with no paper trail. At some point the problem is no longer the method. It is the tooling.
Other articles on this blog cover the method (ERP access governance from onboarding to offboarding, 12 SoD controls to put in place before the annual audit). This one settles the tooling question: SAP GRC Access Control and SAP Cloud Identity Access Governance, Pathlock, Saviynt, or the native controls of your ERP.
The features below are based on vendors’ public pages and on secondary sources cited inline, all consulted on 28 October 2026. Vendors change their offerings: check every point with them before deciding. No prices are published here; these tools are sold by quote.
When the Excel matrix is no longer enough
A spreadsheet works as long as three conditions hold: few privileged users, a single ERP, and an annual review without surprises. It breaks as soon as one of them fails. These are the warning signs, in order of increasing severity:
- Conflict analysis has become manual. Cross-checking composite roles against actual transactions or privileges by hand takes days, and the result is out of date by the next job change.
- Your auditors expect continuous evidence. If your external auditor or internal audit asks who approved which combination, when, and with which compensating control, a shared file is not reliable proof.
- Emergency access is handled by email. A “super user” account lent out without a reviewed activity log is one of the first things auditors flag.
- You run several systems. ERP, payroll, procurement, CRM: SoD that stops at the boundary of one system lets cross-system conflicts through.
- You are subject to SOX or an equivalent requirement. See also our article on SOX compliance in the ERP if your group is US-listed or a subsidiary of such a group.
There is no universal user count beyond which a tool becomes mandatory. The right indicator is the time your team spends producing evidence, compared with the risk of failing to produce it.
Selection criteria
Seven criteria have actually separated the tools in the projects we observe:
- ERP coverage: native connectors for your systems, depth of analysis (transactions, authorization objects, fine-grained privileges) rather than mere role reading.
- Risk analysis: bundled SoD rule library, ability to tailor it, simulation before a role is assigned.
- Remediation: suggested fixes, documented compensating controls, exception management with an expiry date.
- Emergency access (firefighter): temporary elevation, logging, log review by a third party.
- IGA integration: link with your directory and identity governance tool (joiners, movers, leavers).
- Licensing model: per user, per system, per module, cloud-hosted or on premises.
- Implementation effort: quality of your starting roles, internal resources, use of an integrator.
The 4 candidates
SAP GRC Access Control and SAP Cloud Identity Access Governance
What the vendor says. SAP presents SAP Access Control around five functions: access risk analysis, access request management, business role management, emergency access management and periodic user access review. Scope covers SAP ECC, SAP S/4HANA and integrated non-SAP applications. SAP Cloud Identity Access Governance is its cloud counterpart, positioned as a fast entry point (SAPinsider).
Strengths.
- Depth of analysis on SAP authorizations, where third-party tools depend on the quality of their connectors.
- Built-in emergency (“firefighter”) access, well known to auditors used to SAP.
- Consistency with the SAP roadmap and the rest of the product range.
Limitations.
- Less relevant outside the SAP ecosystem: integrating non-SAP applications takes work.
- The on-premises version requires specific infrastructure and expertise; the path between the on-premises and cloud editions should be clarified with SAP in light of your S/4HANA migration timeline.
- A serious implementation, with a role design workstream you cannot skip.
Best fit. A mid-market or large company that is overwhelmingly SAP, already in an S/4HANA programme, with an in-house SAP authorizations team or one at its integrator. The choice is less obvious if your SAP trajectory is uncertain or if most of your risk sits in non-SAP applications.
Pathlock
What the vendor says. Pathlock positions its access orchestration platform on cross-application SoD, with a single rule set applied across several applications. Its documentation cites SAP (including Ariba and SuccessFactors), Oracle (E-Business Suite, Fusion Cloud), Microsoft Dynamics 365, PeopleSoft, Workday and JD Edwards (Pathlock). Announced capabilities include pre-assignment risk analysis, access certification, emergency access with workflow and role management (Pathlock, access orchestration). Pathlock also offers a dedicated solution for Oracle E-Business Suite and Fusion Cloud ERP (Pathlock).
Strengths.
- GRC and SoD specialization: the product is built around this need, not around identity in general.
- Broad coverage of ERPs and business SaaS, useful for a heterogeneous landscape.
- A common rule baseline, which avoids maintaining one matrix per system.
Limitations.
- It is not a full IGA: identity lifecycle management remains your job or that of another tool.
- Real depth varies by application; ask for a proof of concept on your own roles.
Best fit. A multi-ERP company (for example SAP plus Oracle or Dynamics) that wants unified SoD without overhauling its IGA. It also suits internal audit teams that want to maintain one rule baseline, validated by the business, rather than a matrix per system. It is a weaker fit if you want a single tool for the whole identity lifecycle.
Saviynt
What the vendor says. The Application Access Governance module of the Saviynt Enterprise Identity Cloud platform handles SoD risk, access certification and compliance across SAP, Oracle, Workday, Salesforce and other applications. The vendor places it within a broader platform: identity governance and administration, privileged access management and third-party access governance (KuppingerCole, Executive View; ERP Research). Cross-application SoD is presented as a dedicated capability, closely tied to IGA initiatives.
Strengths.
- One platform for identity and application access governance: joiners, movers and leavers feed SoD controls directly.
- Consistent with a cloud strategy and with governing many applications beyond the ERP.
- Emergency access handled within the platform scope.
Limitations.
- The broad scope is also a project risk: scope the ERP subset first.
- If your need is limited to ERP SoD, you may be paying for IGA functions you will not use right away.
Best fit. A group launching or rebuilding its IGA programme that wants to include ERP SoD from the start, with access governance beyond the ERP (SaaS, infrastructure, third parties). It is a weaker fit for a company whose only need is SoD control on a single ERP, where a specialist tool or native controls will be simpler to scope.
Native option: Oracle, Dynamics 365, Odoo
Before you buy, look at what your ERP can already do.
Dynamics 365 Finance. Microsoft documents segregation of duties rules: for each rule, the administrator defines the two conflicting duties, a severity, a risk description and mitigation guidance. Assigning a conflicting role triggers an error message that forces you to explicitly deny or allow it (Microsoft Learn). Validating roles and assignments is a separate step that you have to run yourself.
Odoo. The model relies on user groups, per-model access rights and record rules that restrict which records are visible (Odoo documentation). We found no native SoD engine equivalent to Dynamics’ in the documentation we consulted: SoD there comes down to group design and a review control.
Oracle. Oracle applications provide built-in roles and controls, but cross-system conflict analysis is generally handled by complementary tools, for which Pathlock offers a dedicated version (see above). Check the exact scope of your licence with Oracle.
Strengths. No extra licence cost, fast deployment, consistency with the ERP’s own roles. Limitations. No cross-system view, audit evidence to assemble yourself, emergency access often needing procedural workarounds. Best fit. Single-ERP SMEs with few privileged users.
Summary comparison table
| Criterion | SAP Access Control / Cloud IAG | Pathlock | Saviynt | Native (Dynamics, Odoo, Oracle) |
|---|---|---|---|---|
| ERP coverage | SAP in depth, non-SAP through integration | SAP, Oracle, Dynamics, Workday, JD Edwards, PeopleSoft | SAP, Oracle, Workday, Salesforce and others | A single ERP |
| Cross-application SoD | Limited outside SAP | Yes (core argument) | Yes | No |
| Emergency access | Yes | Yes | Yes (platform) | Varies, often needs supplementing |
| IGA integration | Through the SAP ecosystem | Partial, to be confirmed | Native (same platform) | No |
| Licensing model | By quote | By quote | By quote | Included in the ERP |
| Implementation effort | High | Medium to high | Medium to high | Low |
How to read the table: effort ratings are our own assessments based on vendor documents, not measurements. None of them is a commitment.
Recommendation by profile
100% SAP mid-market or large company. Start with SAP Access Control or Cloud IAG. Pick the edition based on your S/4HANA timeline and hosting, and have SAP confirm the roadmap for the on-premises edition. A third-party tool is only justified if you plan to add other systems.
Multi-ERP landscape. Pathlock if your need is SoD, Saviynt if you are also rebuilding identity management. In both cases, require a proof of concept on your most complex roles before signing.
SME on Dynamics 365 or Odoo. Start with native controls. On Dynamics 365, enable and validate the SoD rules provided. On Odoo, structure your groups and document a quarterly review. Only buy a tool if the audit or the number of systems requires it.
SOX-regulated group. Continuous evidence and logged emergency access are non-negotiable. Favour the tool that goes deepest on your main ERP, then assess coverage of peripheral systems. Involve internal audit and your external auditor in the choice: they are the ones who will or will not accept the evidence.
Cost and deployment
None of the three vendors publishes a usable price list, and we do not put figures on their offers. The cost items are nonetheless identifiable:
- Licences or subscription, where the metric (users, systems, modules) changes the bill substantially depending on your size.
- Integration and connectors, including test environments.
- Role design or clean-up, often the most underestimated item.
- Change management: training role owners and approvers.
- Operations: one person or a fraction of a team to handle alerts and exceptions.
Timelines depend almost entirely on the state of your roles, not on the tool. A range of several months for a first scope is realistic, to be validated against quotes and integrator planning. Ask for at least two detailed quotes, with volume assumptions.
A 3-phase rollout plan
Phase 1: clean up before you tool up. Inventory roles, remove dormant accounts, strip out “catch-all” roles, and validate the SoD matrix with the business. A tool applied to badly designed roles only produces thousands of false conflicts.
Phase 2: pilot scope. Choose one high-risk process (procure-to-pay, for example) and one ERP. Load the rules, measure conflicts, resolve them, and set up emergency access with log review.
Phase 3: extension and automation. Extend to other processes and systems, connect access requests to the approval workflow, and automate periodic reviews and audit reports.
5 classic mistakes to avoid
1. Buying the tool before cleaning up roles. Consequence: thousands of false conflicts, and a team that stops reading alerts. Countermeasure: complete phase 1 (inventory, dormant accounts, catch-all roles) before signing.
2. Not naming business risk owners. Consequence: conflicts go unarbitrated and IT alone decides what is acceptable. Countermeasure: one business owner per process, with the authority to accept or refuse a combination.
3. Accepting too many exceptions without an expiry date. Consequence: the temporary waiver becomes permanent and the auditor finds it again year after year. Countermeasure: every exception carries a compensating control, an approver and an end date.
4. Underestimating operations after go-live. Consequence: unhandled alerts, late periodic reviews. Countermeasure: budget operating capacity (in-house or managed) in the quote from the start.
5. Choosing on a demo rather than a proof of concept. Consequence: coverage gaps only appear during the project. Countermeasure: require each vendor to run a test on your most complex roles, with written success criteria.
Going further
To frame your choice, contact DigitsLane: we help write the requirements, organize the proof of concept and challenge the quotes. You can also download our ERP evaluation grid to structure your comparison.
To dig deeper: ERP access governance from onboarding to offboarding, 12 SoD controls before the annual audit and ERP and GRC: governance, risk and compliance.
