User access reviews for Dynamics 365 BC need risk-based rigor

At a glance

What this is: This is Delinea’s analysis of why Microsoft Dynamics 365 Business Central access reviews need risk-based rigor to catch overprovisioned access, indirect entitlements, and SoD conflicts.

Why it matters: It matters because ERP access reviews often fail at the point where finance, operations, and IAM governance intersect, so practitioners need reviews that reveal real business capability rather than checkbox certification.

Context

Microsoft Dynamics 365 Business Central is an ERP access governance problem as much as it is an application security problem. When business-critical roles, permissions, and indirect access paths are not reviewed with enough context, certification campaigns can miss who can actually post transactions, approve payments, or alter master data.

Delinea argues that the issue is not simply review volume or cadence. The governance gap appears when access reviews are run with low visibility into effective permissions, role combinations, and segregation of duties conflicts, so reviewers approve access without understanding the operational power behind it.

Key questions

Q: What breaks when SaaS access reviews rely on spreadsheets?

A: Spreadsheets freeze access data in time, so reviewers work from stale exports while roles, teams, and app usage keep changing. That creates entitlement drift and weak evidence for auditors. A better model is recurring review automation with current usage, department, and risk context, plus direct remediation from the review step.

Q: Why do over-permissive ERP roles create business risk even when reviews are done?

A: Because a completed review is only as good as the access model behind it. If native roles already grant more privilege than a user’s job requires, certification can approve excess access instead of removing it. In finance-heavy workflows, that can leave posting rights, vendor control, or master data changes intact after review.

Q: How can security teams tell whether a D365 BC access review is actually working?

A: Look for evidence that reviewers can explain what users can do, not just what roles they hold. If business owners are approving access without understanding effective permissions, review fatigue, or SoD conflicts, the control is weak. A working programme produces defensible removals, cleaner roles, and fewer repeated exceptions.

Q: Who should own access certification for business applications like D365 BC?

A: IT can run the workflow, but business owners should decide whether access still fits the job. That accountability split matters because technical role names rarely describe business authority clearly enough for safe approval. Ownership belongs with the people who understand the process risk, while IT provides the control record.

Technical breakdown

Why indirect access makes D365 BC reviews unreliable

Dynamics 365 Business Central can combine roles, permission sets, security groups, and excluded permissions into effective access that is greater than any single assignment suggests. That means a user may appear to have limited access on paper while still retaining the ability to perform sensitive business actions through layered entitlements. In access governance terms, the review target is not the named role alone but the effective permission state created by inheritance and exception handling. Without that view, certification becomes descriptive rather than evaluative.

Practical implication: review effective permissions, not just direct role names, when certifying D365 BC access.

Why spreadsheet-based certification breaks down

Manual access reviews tend to separate the reviewer from the evidence they need. Spreadsheets do not surface permission dependencies, SoD conflicts, or changes in access scope over time, and they do little to route approvals to the right owners or chase overdue responses. In a business application like D365 BC, that turns certification into a logging exercise instead of a governance control. The more complex the role model, the faster the manual process loses fidelity.

Practical implication: replace spreadsheet-led review tracking with automated workflows that preserve context and accountability.

How risk-based review design changes the control

Risk-based access review design starts with the roles that can cause the most harm if misused, such as financial posting rights, vendor master access, and elevated roles like Super. This is a governance prioritisation problem: review capacity is finite, so certification should focus first on access that can directly create fraud, error, or SoD conflict. D365 BC also supports permission set recording and indirect access analysis, which can expose what users actually did and how hidden entitlements are assembled. Those mechanisms make the review control materially stronger than a calendar-driven campaign.

Practical implication: prioritise high-risk roles first and use D365 BC’s native evidence to target the most consequential access paths.

NHI Mgmt Group analysis

Risk-based certification is the only defensible review model for complex ERP access. Annual or quarterly review cycles are too blunt when a business system aggregates roles, security groups, and excluded permissions into effective access. Delinea’s example shows that the real control question is not whether a user has a named role, but whether that role combination creates financial or operational authority beyond job scope. Practitioners should treat access certification as a risk allocation exercise, not a routine calendar task.

Hidden entitlements are the governance blind spot in Dynamics 365 BC. Indirect access and over-permissive out-of-the-box roles mean the apparent entitlement list can understate what a user can actually do. That is especially dangerous in finance-adjacent workflows, where posting rights, vendor management, and master data changes can move money or alter controls without a visible direct assignment. The practical conclusion is that effective access must be the unit of review, because direct roles alone do not capture business power.

Spreadsheet-driven access reviews create false assurance. When IT owns certification through manual tracking, reviewer fatigue and low context combine to produce check-the-box approvals. This is not merely inefficient, it weakens the control itself because it suppresses questions about SoD conflicts and permission-set semantics. A lightweight review process still has to be evidence-based, owner-led, and capable of showing why access exists. Otherwise the certification result says more about process completion than about governance.

Business ownership is not optional in ERP access governance. Application owners know which permissions are acceptable in a given business process, while IT often only knows how access is provisioned. That split matters in D365 BC because the technical shape of access and the business meaning of access are not the same thing. The governance lesson is straightforward: if the owner cannot explain the permission in business terms, the review is not actually testing business risk.

Permission-set design and certification design have to be treated as one control surface. D365 BC access reviews expose whether role engineering, indirect access handling, and certification logic were aligned from the start. When native roles are over-permissive, access reviews inherit that design flaw and can only detect it after the fact. The better discipline is to keep review evidence and role design tightly linked so recurring certification informs future least-privilege modelling.

From our research library:

• Over 70% of organisations lack automated access risk analysis, user access reviews and provisioning and deprovisioning, according to Pathlock's 2025 Digital Transformation and Access Risk Report.
• Read next: Access Reviews and Certification Guide

What this signals

Effective access, not role labels, is the governance unit that matters. In ERP environments, reviewers need to understand what a user can do through role combinations, indirect access, and excluded permissions. If the certification process cannot surface that effective state, it will keep approving access that still carries financial or operational risk.

Risk-based review design will matter more as ERP role models get harder to interpret. The practical pressure is not to review everything equally, but to concentrate on the access paths that can move money, alter master data, or break segregation of duties. That is where governance teams should spend their limited review attention.

For practitioners

• Prioritise high-risk D365 BC roles Begin certification with financial posting rights, vendor master access, and elevated roles such as Super so reviewers focus on the access most likely to create fraud, error, or SoD conflict.
• Replace spreadsheets with workflow-based reviews Use automated routing, reminders, and escalation so access owners see the full review task rather than a static list that hides dependencies and stale assignments.
• Review effective access, not just direct roles Validate indirect access, security group inheritance, and excluded permissions so certification reflects what users can actually do in the application.
• Involve business owners in every cycle Require application stakeholders to judge whether each permission still aligns with the user’s job, because business context is what distinguishes legitimate access from residual privilege.
• Use review outcomes to refine role design Feed recurring certification findings back into permission-set cleanup so over-permissive roles and repeated exceptions are reduced before the next cycle.

Key takeaways

• Dynamics 365 BC access reviews fail when they certify role names instead of actual business capability.
• The most serious exposure comes from indirect access, over-permissive native roles, and low-context reviewers.
• Risk-based prioritisation and business-owner review are the controls that make certification meaningful.

Key terms

• User Access Review: A user access review is a periodic check that confirms each account still needs the access it has. In identity programs, the control is used to reduce excess privilege, support compliance, and catch access that has outlived its business need.
• Effective Access: The actual permissions an identity can exercise after inheritance, nested groups, delegation, and object-level controls are evaluated. In Active Directory, effective access is more useful than direct membership because it reveals the true operational reach of a service account.
• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Permission Set: A permission set is an additive access package in Salesforce that grants extra privileges without changing the base profile. It is the preferred way to extend access because it keeps the underlying role definition small and makes review and reuse easier across different users and functions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.