Start with a scenario that plays out more often than anyone would like to admit.
A midsize manufacturer—let's call them 2,000 employees, JDE environment, been running for 15 years.
Someone in internal audit pulls a report on user access and discovers that 340 active accounts have access to the finance module. The company has 12 people in finance. Three hundred and forty accounts. Nobody can explain how it got this bad. But everyone knows—it just accumulated.
People changed roles, new modules got added, temporary access became permanent access, and nobody ever cleaned it up.
Now, if you're a security professional reading this, you're probably nodding along. Role sprawl in ERP systems is the norm, not the exception.
But here's the problem—most zero-trust conversations happen in the network and infrastructure layer. Firewalls. Endpoints. Cloud access brokers.
By the time anyone thinks about applying zero-trust principles to the ERP layer—where the actual financial transactions, HR records, supply chain data, and manufacturing operations live—the horse has left the barn, crossed the county line, and started a new life in another state.
A compromised identity in your ERP system isn't a security incident. It's a business continuity event.
Why ERP Environments Are a Different Beast
Here's what makes zero-trust in ERP so much harder than in the rest of your infrastructure. Legacy authentication models.
Service accounts with permanent elevated privileges that nobody remembers creating.
Cross-system identity propagation where a single user's credentials flow through integrations to five or six connected systems. And—this is the big one—organic growth over decades.
This shows up all the time. An ERP system gets implemented in 2006.
Over the next 18 years, roles get created, cloned, modified, and stacked on top of each other.
The original role design—if there was one—is buried under hundreds of customizations.
Ask the team to map current roles to actual job functions, and they'll need three months and a bottle of aspirin.
And here's the kicker—most organizations don't even know how many service accounts they have. Service accounts are the quiet time bombs of ERP security. They run integrations, batch jobs, and automated processes. They often have the highest privilege levels in the system. And they almost never get rotated, reviewed, or deprovisioned.
The Four Principles, Applied to ERP
Zero-trust isn't a product you buy. It's a set of principles you operationalize. Here's how they translate to the ERP layer.
Verify explicitly. Every access request, every time.
In an ERP context, this means moving beyond the "log in once and you're trusted" model.
When a user accesses a sensitive transaction—posting a journal entry, modifying a vendor record, changing a pay rate—that access should be verified against their current role, their current context, and the current risk posture. Not just authenticated. Authorized in real time.
Use least-privilege access. This is where role right-sizing comes in.
Most ERP environments have roles that were designed for convenience, not security. "Just give them the same access as Mary"—sound familiar? That's how a marketing coordinator ends up with access to the general ledger.
Least privilege means every role grants exactly what's needed for the job function and nothing more. It means regular recertification. And it means someone actually owns the role design, not just the security team.
Assume breach. This principle makes IT leaders uncomfortable, but it's the right mental model.
Instead of building walls and hoping nobody gets through, you monitor for anomalous patterns continuously.
A user who normally accesses the system during business hours in Chicago suddenly logs in from Eastern Europe at 3 AM? That should trigger an alert.
A service account that normally runs a batch job once a night suddenly executes 400 transactions in an hour? Flag it.
Continuous validation. Not just at login, but during the session.
Session-level validation means checking authorization at key decision points throughout a user's interaction with the system.
This is harder to implement, but it's where the real protection lives—because most breach scenarios don't start with a compromised password.
They start with an authenticated session that gets hijacked or an insider who slowly escalates beyond their legitimate scope.
Platform by Platform — What to Watch For
Here's the practical breakdown, because every ERP platform has its own security architecture.
JD Edwards. Environment-level security is your first line of defense.
Role-based security and row security give you granular control, but they're only as good as the design behind them.
The JDE-specific risk? Companies running older Tools releases with outdated security models.
If you haven't reviewed your security design since your last major Tools upgrade, you're probably exposed.
SAP. Authorization objects and Segregation of Duties analysis are well-understood, but execution is where it falls apart.
The sheer number of authorization objects in a typical SAP implementation makes manual review impractical.
You need tooling—and more importantly, you need someone who understands both the technical objects and the business processes they protect.
Oracle Fusion Cloud. Data security policies and RBAC are built into the architecture, which is an advantage.
But the continuous update model means security configurations need to be validated with every quarterly release. What was properly configured in January may have gaps by April.
PeopleSoft. Permission lists and roles offer flexibility, but that flexibility is a double-edged sword. Row-level security in PeopleSoft is powerful but under-utilized.
Most PeopleSoft shops out there are relying on coarse-grained security that doesn't reflect the actual data sensitivity boundaries.
The Implementation Roadmap — Five Phases
Here's how this actually gets done in practice.
Phase 1: Audit your current identity posture. You can't fix what you can't see.
Pull a complete inventory of all user accounts, service accounts, roles, and privilege assignments.
Identify dormant accounts—users who haven't logged in for 90+ days but still have active access. Across typical ERP environments, 15–25% of accounts are dormant. That's 15–25% of your attack surface that serves zero business purpose.
Phase 2: Eliminate the dead weight. Deactivate dormant accounts.
Revoke orphaned privileges—access grants that no longer correspond to anyone's actual job function.
This is low-hanging fruit, but it's remarkable how many organizations skip it because "someone might need that access later."
Fair enough.
But here's the problem—that logic is exactly how you end up with 340 accounts in a 12-person module.
Phase 3: Implement least-privilege role design. Rebuild roles from the ground up based on current job functions. This is the hard work. It requires collaboration between IT, security, and business process owners. It takes time. But it's the foundation everything else depends on.
Phase 4: Deploy continuous monitoring. Instrument your ERP environment to detect anomalous access patterns in real time.
This isn't just logging—it's active monitoring with alerting and automated response capabilities.
Phase 5: Automate provisioning and deprovisioning. When someone joins, moves to a new role, or leaves, their ERP access should update automatically based on their HR record. Manual provisioning is how role sprawl happens. Automation is how you prevent it.
Where Organizations Fail
The most common failure? Treating zero-trust as a technology project. You buy a tool, configure it, check the box, and move on. That's not zero-trust. That's a new dashboard you'll ignore in six months.
Zero-trust for ERP is an operational discipline.
It requires ongoing role governance, continuous monitoring, regular recertification, and—critically—executive sponsorship.
Without a business leader who understands why this matters and holds people accountable, the entropy will win. It always does.
The second most common failure? Ignoring service accounts. It bears repeating.
Service accounts are the most privileged and least monitored identities in most ERP environments.
If your zero-trust initiative doesn't start there, you're securing the front door while leaving the loading dock wide open.
