ERP Access Controls: An IT Leader's Guide

Someone in accounting can approve their own purchase orders. A sales rep can see every customer’s payment history. A project manager left six months ago, and their account still has full admin access. If any of these sound familiar, your ERP access controls have drifted from whatever was set up at go-live, and the gap keeps widening.

Most mid-market businesses set up ERP permissions during implementation, check a box, and never revisit them. Over time, roles accumulate privileges they don’t need, new hires inherit permissions copied from whoever was hired before them, and temporary access grants become permanent. Nobody is quite sure who can do what anymore, and nobody wants to touch it for fear of breaking something.

Why ERP Permissions Drift After Go-Live

Permission drift isn’t a failure of discipline. It’s a predictable consequence of how mid-market businesses operate.

During implementation, your ERP vendor or partner sets up a clean role structure. Finance gets finance permissions. Operations gets operations permissions. It makes sense on paper. Then reality kicks in.

People change roles without changing permissions. When someone moves from accounts payable to accounts receivable, they get new access added. The old access rarely gets removed. After two or three role changes, that person has permissions spanning half the system.

Managers request access for their teams in a hurry. A deadline hits, and a manager needs someone to run a report they can’t access. IT grants it. The deadline passes. The access stays. Multiply this by dozens of requests per quarter, and you get permission accumulation that no one tracks.

Copied user profiles compound the problem. When a new employee joins, IT often copies the profile of an existing team member. If that team member had accumulated extra permissions over three years, the new hire inherits all of them on day one. According to a 2024 Ponemon Institute study on access governance, 53% of organizations have more access privileges provisioned than their policies allow, largely due to this kind of copy-and-accumulate pattern.

No one owns ongoing access reviews. Implementation partners leave. Internal IT gets absorbed by support tickets and infrastructure. Access control reviews don’t generate revenue or fix visible problems, so they get deprioritized until an audit forces the issue.

The Real Cost of Loose ERP Permissions

Poorly managed ERP access isn’t just an IT hygiene issue. The business risk shows up in three concrete ways.

Financial exposure from separation of duties failures. Separation of duties (SoD) means no single person should be able to both initiate and approve a financial transaction. When ERP permissions drift, SoD violations multiply. Someone who can create a vendor and approve payments to that vendor can commit fraud without anyone else involved. According to the Association of Certified Fraud Examiners’ 2024 Report to the Nations, the median loss from occupational fraud is $145,000 per case, and inadequate internal controls are a contributing factor in 32% of cases.

Audit failures and compliance risk. External auditors test ERP access controls during financial audits. SoD violations, orphaned accounts (belonging to former employees), and excessive admin privileges are common findings. Each finding requires remediation, delays the audit, and can result in qualified opinions that affect investor and lender confidence.

Operational disruption from accidental changes. When too many people have write access to master data (customer records, pricing tables, chart of accounts), accidental changes happen. A well-intentioned user edits a pricing rule they don’t fully understand, and invoices go out wrong for a week before anyone notices. We’ve seen this pattern play out repeatedly. Our post on dirty ERP data covers the downstream operational cost when master data quality breaks down.

What Does Good ERP Access Control Look Like?

Good access control follows a principle that’s easy to state and hard to implement: every user should have the minimum permissions needed to do their job, and nothing more. This is the principle of least privilege, and it applies just as much to ERP systems as it does to network security.

In practice, that means a role-based access control (RBAC) structure with these characteristics:

• Roles map to job functions, not to individuals. You don’t create “Maria’s permissions.” You create “Accounts Payable Clerk” with a defined set of capabilities, and Maria gets that role. When Maria moves to a different function, you swap the role instead of layering new permissions on top.

• Sensitive transactions require separation. Any process that involves creating records and approving them (purchase orders, vendor creation, journal entries, payment runs) should require two different roles. No single user should hold both.

• Admin access is restricted and audited. Full system administrator access should belong to a small number of named individuals, not a shared “admin” account. Every admin action should be logged and periodically reviewed.

• Access reviews happen on a schedule. Quarterly or semi-annual reviews where department managers verify that their team members’ access is still appropriate. This catches orphaned accounts, accumulated privileges, and SoD conflicts before auditors do.

• Temporary access has an expiration. When someone needs elevated access for a project or deadline, it should come with an end date. If the system doesn’t enforce automatic expiration, the process should include a calendar reminder for IT to revoke it.

How Do You Audit ERP Permissions?

If you’ve never done a comprehensive access review, the first one takes real effort. The process itself, though, is straightforward.

Step 1: Export your current user-role matrix. Most ERP systems let you generate a report showing every user and their assigned roles or permissions. Export this into a format you can analyze.

Step 2: Flag orphaned accounts. Cross-reference your user list against HR’s active employee roster. Any ERP account that doesn’t match an active employee gets disabled immediately. This alone often eliminates 10-15% of active accounts in mid-market organizations.

Step 3: Identify SoD conflicts. Map which permissions are incompatible (create vendor + approve payment, create purchase order + receive goods, create journal entry + post journal entry). Then check which users hold conflicting pairs. This is where most organizations discover the biggest surprises.

Step 4: Review admin and superuser accounts. List every account with system administrator or unrestricted access. Challenge each one. Does this person need full admin, or would a more limited role cover their actual work? In our experience, mid-market companies typically have three to five times more admin accounts than they need.

Step 5: Validate with department managers. Send each manager a list of their team members’ ERP roles and ask: “Does this match what each person actually needs to do?” Managers often discover that former team members still have access, or that current members have permissions for tasks they never perform.

Step 6: Document and remediate. For every finding, document what needs to change and set a deadline. Prioritize SoD violations and orphaned accounts first, then work through excessive permissions in order of risk.

Building an Access Control Process That Scales

A one-time cleanup is valuable but temporary. Without a process, permissions will drift back within a year. A sustainable program for mid-market IT teams has five components.

Standardize role templates. Define a role for every job function in your organization. Document exactly what each role can and cannot do. When someone new joins or changes roles, they get the standard template. No copying from existing users.

Integrate with HR processes. When HR processes a termination, IT disables the ERP account the same day. When HR processes a role change, IT swaps the ERP role within a defined SLA. This requires a formal handoff between HR and IT that many mid-market businesses lack.

Automate what you can. If your ERP supports automated access reviews, scheduled deprovisioning, or SoD conflict detection, use these features. If it doesn’t, build a manual process with a recurring calendar event and a checklist. The Ponemon Institute’s 2024 identity governance research found that organizations with automated identity lifecycle management spend 40% less time on access-related compliance than those relying on manual processes.

Make access requests auditable. Every permission change should be requested, approved, and recorded. This doesn’t require a ticketing system. A shared spreadsheet with columns for requester, approver, date, change description, and reason is better than nothing. A ticketing system is better still.

Run quarterly reviews. Once a quarter, export the user-role matrix, check for anomalies, and send validation requests to managers. The first review takes hours. After that, it takes less than an hour per quarter because you’re only reviewing changes since the last review.

Should You Lock Down Permissions Tightly or Keep Them Flexible?

Every IT leader faces this trade-off. Tighten access too far and you become a bottleneck; leave it too loose and you’re accepting risk you may not be aware of. Where you land depends on the type of transaction.

Lock down tightly: Financial transactions, master data changes, system configuration, user management. These are high-impact, low-frequency actions where the cost of a mistake or misuse is high.

Allow more flexibility: Read-only access to reports, dashboards, and operational data. Most users need to see more than they need to change. Giving broad read access while restricting write access covers most day-to-day needs without creating risk.

Use approval workflows instead of restrictions for the gray area. Some tasks (like adjusting a project budget or changing a customer’s credit limit) need to happen quickly but also need oversight. Instead of blocking access entirely, let users initiate the action but require a second person to approve it. This keeps work moving while maintaining control.

The goal is a system where routine work flows without friction, sensitive actions have guardrails, and you can answer “who did what and when” at any point. Not a lockdown that forces people to work around it.

Frequently Asked Questions

What is the principle of least privilege in ERP systems?

The principle of least privilege means each user gets only the permissions they need to perform their specific job function. It reduces the risk of accidental data changes, fraud, and compliance violations by ensuring people can’t access or modify things outside their responsibilities.

How often should you review ERP access controls?

Most organizations benefit from quarterly reviews, with immediate reviews triggered by employee terminations or role changes. The first comprehensive review takes significant effort, but subsequent quarterly reviews are faster because you’re only checking changes since the last cycle.

What is separation of duties in ERP?

Separation of duties (SoD) ensures that no single person can both initiate and complete a sensitive transaction, such as creating a vendor record and approving payments to that vendor. SoD controls prevent fraud and errors by requiring at least two people to complete high-risk processes.

What are orphaned accounts in ERP systems?

Orphaned accounts are ERP user profiles that belong to people who no longer work at the organization or no longer need access. These accounts represent a security risk because they could be used to access the system without detection. Regular cross-referencing of ERP accounts against HR records catches them.

How do you fix ERP permission sprawl?

Start by exporting your current user-permission matrix and cross-referencing it against active employees and defined role templates. Disable orphaned accounts, resolve separation of duties conflicts, and reduce admin access to only those who genuinely need it. Then build a recurring review process so permissions don’t drift back.

How Tier2 Keel Handles Access and Permissions

The access control challenges discussed above often stem from ERP systems where permissions are configured once during implementation and then left to accumulate. Tier2 Keel builds role-based access into its core workflow, with granular control over what each user can see, create, edit, and approve across the full business process, from leads through invoicing and settlement.

Because Keel operates as a connected workflow rather than a collection of separate modules, permission changes propagate consistently. When you adjust a role’s access to project management, the related billing and reporting permissions update in sync. This reduces the gap between intended access and actual access that causes SoD violations in traditional ERP setups.

See how Keel manages access or book a walkthrough.

If your ERP access controls haven’t been reviewed since go-live, the audit clock is already running. Export your user list this week, cross-reference it against HR, and count the orphaned accounts. That number alone will make a stronger case for a structured review process than any policy document could.