Effective ERP access control assigns permissions to roles rather than users, derives roles from real job functions, and separates the duties that must never combine. Zero-trust adds continuous verification: access is reviewed on a schedule, privileged actions are logged, and permissions expire rather than accumulating.
Designing roles that survive
Role design fails in two directions. Too many roles and the model becomes unmaintainable, with roles that differ by a single permission and nobody able to explain the difference. Too few roles and everyone receives broad access to compensate.
The practical approach is role mining: extract actual permission usage from logs, cluster it into patterns, then map clusters to job functions and compress them. A workable enterprise target is usually a few dozen roles rather than a few hundred or a handful.
Separate functional roles from data scoping. What a person can do, such as approve a purchase order, is distinct from what they can see, such as only their cost centre. Keeping these orthogonal dramatically reduces role count, because the functional roles are reused across scopes.
- Mine roles from observed usage rather than from the org chart.
- Keep functional permissions separate from data scoping.
- Compress to a maintainable role set and document each role's purpose.
- Allow only exceptions to be granted individually, with an expiry.
Least privilege and separation of duties
Least privilege means a user has the permissions required for their current function and no more. In practice that requires a default of deny, explicit grants, and a process for removing access when someone changes role. The common failure is accumulation: people keep the permissions of every previous role.
Separation of duties encodes the combinations that must never coexist in one person, typically creating a vendor and approving payment, or entering a journal and approving it. These must be enforced in the system as conflicting-role rules, checked at assignment time, not left to policy.
Where a conflict is unavoidable due to small teams, the compensating control should be explicit: a second approver, a mandatory review, or documented monitoring. Silent acceptance is what auditors object to.
| Function A | Function B | Why it conflicts |
|---|---|---|
| Create vendor | Approve payment | Fictitious vendor fraud |
| Enter journal | Approve journal | Unreviewed financial adjustment |
| Maintain price master | Release sales order | Uncontrolled discounting |
| Receive goods | Approve invoice | Concealed short delivery |
| Manage users | Audit logs | Privilege escalation without trace |
| Define role | Assign role | Self-granted privilege |
Field-level permissions and privileged access
Some controls require restricting individual fields rather than whole records. Salary data, banking details, cost prices and credit limits frequently need to be visible to some roles and masked to others, even on records those roles can otherwise edit.
Field-level controls belong in the service layer and the data access layer, not only in the interface. Hiding a field in a form is presentation, not authorisation, and any API that bypasses the form will expose it.
Privileged and administrative accounts need separate treatment: individually named rather than shared, just-in-time rather than standing, fully logged, and excluded from routine work. A shared administrator account with standing access is the single most common audit finding.
- Enforce field-level restrictions in the service and data layers.
- Use individually named, just-in-time administrative access.
- Log every privileged action with actor, target and justification.
- Prohibit shared administrative accounts.
Continuous verification and access review
Zero-trust means access is verified continuously rather than trusted because it originated inside the network. Practically, that means every request is authenticated and authorised at the service, sessions expire, and permission changes take effect immediately rather than at the next login.
Access review should be a scheduled process with real consequences. Managers receive a list of their team's current access, must confirm or revoke each item, and unconfirmed access is revoked automatically after a deadline. Reviews without automatic revocation produce no change.
Measure and report on the controls themselves: number of roles, number of individual exceptions, conflicts granted with compensating controls, dormant accounts and time since last review. Those metrics describe whether access control is actually working.
- Authorise every request at the service, not only at the perimeter.
- Expire sessions and apply permission changes immediately.
- Require managers to confirm or revoke access on a schedule.
- Revoke unconfirmed access automatically at the deadline.
Frequently asked questions
How many roles should an ERP have?
Enough to express distinct job functions and no more. Enterprise deployments usually settle in the range of a few dozen roles once functional permissions are separated from data scoping, provided roles are mined from real usage rather than built from an org chart.
What is separation of duties in ERP?
It is the enforcement of rules that prevent one person from holding combinations of duties that enable error or fraud without detection, such as creating a vendor and approving payment to it.
How often should access be reviewed?
At least quarterly for standard access and more often for privileged roles. The review must revoke automatically if not confirmed, otherwise it becomes a formality that produces no change in actual access.
References
Engineer your next strategic platform
Estimate your project investment and delivery timeline instantly, or schedule an architectural discovery call with our engineering leadership.