Notifications
Clear all
Topic starter
25/06/2026 3:18 pm
TL;DR: JD Edwards access governance is complicated by layered menu, action, and row controls, up to 30 roles per user, and 40,000 to 70,000 lines of security that make manual segregation-of-duties checks and access reviews error-prone, according to SafePaaS. The practical lesson is that ERP access governance fails when controls are fragmented, undocumented, and too large for spreadsheets to hold together.
NHIMG editorial — based on content published by SafePaaS: JD Edwards access governance challenges and access governance solutions
By the numbers:
- The system allows up to 30 roles per user, which can create role sequencing issues and unexpected access results.
Questions worth separating out
Q: How should security teams govern access in a complex JD Edwards environment?
A: They should govern it as an effective-access problem, not a role-count problem.
Q: Why do ERP environments like JD Edwards make segregation of duties hard to enforce?
A: Because SoD depends on knowing the real combination of entitlements, not just the presence of individual permissions.
Q: What breaks when access reviews rely on spreadsheets in JD Edwards?
A: Spreadsheets cannot reliably model role ordering, cross-module entitlements, or the volume of security lines in a mature JD Edwards estate.
Practitioner guidance
- Build a unified entitlement inventory across all JD Edwards modules Consolidate menu-level, action-level, and row-level permissions into one reviewable model so reviewers can see effective access across Financials, Manufacturing, and Human Capital Management.
- Test role sequencing after every role change Validate effective access whenever a user receives multiple roles, because higher-priority roles can override lower-priority settings and create unexpected access outcomes.
- Replace spreadsheet SoD checks with continuous conflict detection Tie SoD rules to live entitlements and automate checks so conflicts are detected as access changes, not only during audit preparation.
What's in the full article
SafePaaS's full article covers the operational detail this post intentionally leaves for the source:
- JD Edwards-specific examples of menu, action, and row-level control interactions across modules
- Operational guidance for building access certification workflows that fit ERP review cycles
- Implementation detail for automated SoD monitoring and role analysis in complex JD Edwards estates
- Practical change-management considerations for production, test, and development environments
👉 Read SafePaaS's analysis of JD Edwards access governance challenges →
JD Edwards security complexity: what IAM teams need to fix?
Explore further
25/06/2026 4:45 pm
JD Edwards access governance is really an entitlement interaction problem, not a simple provisioning problem. The article shows that menu, action, row, PUBLIC, role-based, and user-specific controls all interact inside the same ERP estate. That means the security question is whether the combined permission state still matches intent after layering, inheritance, and sequencing. Practitioners should treat entitlement evaluation as a system-level control, not a role-by-role checklist.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage, according to NHI Mgmt Group research.
A question worth separating out:
Q: Who should own JD Edwards access risk when access structures keep changing?
A: Ownership should sit with identity, ERP security, and business process teams together, because no single group can see all the implications. Security teams need the entitlement data, ERP teams understand the configuration model, and process owners validate whether access still matches operational need. That shared ownership is what makes governance defensible.
👉 Read our full editorial: JD Edwards access governance exposes the limits of manual SoD
