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

At a glance

What this is: This is Delinea’s guidance on tightening Dynamics 365 Business Central access reviews by focusing on high-risk roles, hidden entitlements, and automated review workflows.

Why it matters: It matters because ERP access is often where financial misuse, privilege creep, and audit failures become operational, and IAM, IGA, and PAM teams need reviews that can surface real access rather than checkbox approvals.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Delinea’s guidance on lightweight user access reviews for Dynamics 365 BC

Context

User access reviews are the governance check that asks who has access, what they can do, and how that access is granted. In Microsoft Dynamics 365 Business Central, that matters because ERP permissions often combine direct roles, indirect access, group-based assignment, and excluded permissions, which can hide the real entitlement picture from reviewers.

The problem is not that organisations never review access. It is that manual, low-context review cycles often produce compliance theatre instead of control, especially when technical role names and indirect permissions obscure business impact. For IAM and IGA teams, this is a familiar pattern: if reviewers cannot understand effective access, the certification process cannot reliably reduce risk.

Key questions

Q: How should security teams run access reviews for ERP systems like Dynamics 365 BC?

A: They should start with the highest-risk entitlements, use reviewers who understand business process, and validate effective access rather than relying on role names. ERP reviews work best when certification is tied to transaction risk, segregation of duties, and automated routing that preserves context for the approver.

Q: Why do manual access certification campaigns fail in business applications?

A: Manual campaigns fail because spreadsheets and email reminders do not give reviewers enough context to judge effective access. When permission names are technical or indirect, approvals become shallow and risky access survives. Automation helps, but only if it improves reviewer understanding rather than just speeding up the same weak process.

Q: What breaks when indirect permissions are ignored in ERP reviews?

A: The review stops reflecting actual privilege. Users can inherit capabilities through groups, aggregate permission sets, or excluded permissions, which means a clean-looking certification can still leave someone able to post transactions or change sensitive records. That gap makes the control look complete while leaving real exposure in place.

Q: Who should own ERP access reviews, IT or business owners?

A: Business owners should make the access decision because they understand what each entitlement means in practice, while IT should provide the workflow, evidence, and reporting. If IT owns the decision without business context, reviewers are likely to approve access they do not fully understand.

Technical breakdown

Why Dynamics 365 BC access reviews miss effective permissions

Dynamics 365 Business Central does not always expose access in a simple one-role-one-right model. Aggregate permission sets, indirect access through groups, and excluded permissions can combine to produce effective entitlements that are invisible in a spreadsheet review. That is why a user may look under-privileged on paper while still being able to post transactions, edit vendors, or bypass intended SoD boundaries. Permission Set Recording and Indirect Access Analysis exist because static role names do not describe actual capability. Practical implication: reviewers need evidence of effective permissions, not just assigned roles.

Practical implication: assess effective permissions and indirect access before certifying any high-risk ERP user.

Why manual certification campaigns create review fatigue

Annual or quarterly access reviews often fail because the process is treated as an administrative task rather than a control. Spreadsheets, email reminders, and IT-owned routing create bottlenecks, while application owners receive little context about the business meaning of each entitlement. Review fatigue follows when reviewers see long permission lists without understanding the risk of each access path. The result is predictable. People approve what looks familiar, question what is unclear, and miss the accounts that matter most. Practical implication: move certification into a workflow that preserves context and accountability.

Practical implication: replace spreadsheet campaigns with workflow controls that preserve reviewer context and accountability.

Why over-permissive ERP defaults become a governance problem

ERP platforms are often configured for business convenience first and security second. Out-of-the-box roles can be broader than the user’s job scope, and once those roles are layered with group membership or indirect entitlements, the final access footprint grows further. In governance terms, the issue is not just excess privilege. It is that the system can look standard while still enabling transactions outside job function, which creates both fraud exposure and audit risk. Practical implication: treat native roles as a starting point for review, not as proof of least privilege.

Practical implication: test native ERP roles against job scope and SoD requirements before considering them approved.

Threat narrative

Attacker objective: The attacker or insider seeks to use legitimate ERP access to move money, alter business records, or conceal unauthorized transactions without immediate detection.

1. Entry occurs through overprovisioned business application access, especially when users retain roles beyond their current duties or gain permissions through indirect assignment.
2. Escalation follows when reviewers cannot see effective access, allowing elevated functions such as financial posting, vendor maintenance, or approval bypass to remain active.
3. Impact is fraud, unauthorized payments, SoD conflict, and audit exposure that persists because the access certification process never clearly removed the risky entitlement.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• Microsoft Azure OpenAI service breach — stolen Azure API keys used to bypass AI safety controls at scale.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Access reviews fail when they certify assignment, not capability. Business Central illustrates a common governance error: teams approve named roles without understanding the effective permissions those roles create. Aggregate permission sets and indirect access mean the reviewer may sign off on something they never actually saw, which turns certification into documentation rather than control. The practitioner takeaway is that identity governance must validate what the user can do, not just what the directory says they have.

Role-based review design collapses when business context is missing. Technical permission names rarely tell an application owner whether a user can post journals, change vendors, or override segregation of duties. That is why IT-owned, spreadsheet-driven review cycles generate fatigue and shallow approvals. The control gap is not a missing policy statement. It is the absence of decision context at the point of review. Practitioners should treat reviewer comprehension as part of the control itself.

ERP access governance is really SoD governance in disguise. When financial posting rights, vendor master access, and elevated roles remain in place after go-live, the access review programme is dealing with business fraud risk, not just permission hygiene. This is where zero-standing-privilege thinking matters in ERP administration: sensitive access should not persist simply because the role is convenient to keep. The implication is to align access review scope to financial abuse paths, not generic entitlement counts.

Lightweight does not mean weak when the review targets the right risk surface. A focused review model that starts with the highest-risk roles, uses automated routing, and involves business owners can outperform broad but shallow certification campaigns. The governance lesson is that scale without prioritisation produces compliance noise. Practitioners should narrow review effort to the entitlements most likely to create fraud, audit failure, or SoD conflict.

Periodic access certification must be paired with lifecycle awareness. Disabled users, orphaned accounts, and inherited permissions often survive normal review cadence because the process is not connected to identity lifecycle events. That gap matters for ERP controls because access can persist long after role changes. The practical conclusion is that review programmes need lifecycle triggers and not just calendar triggers if they are to reduce exposure.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• NHI Lifecycle Management Guide is the right next step for teams that need a practical framework for provisioning, rotation, and offboarding discipline.

What this signals

Hidden access is the recurring control failure across ERP, NHI, and human identity programmes. When reviewers cannot see effective access, governance turns into approval theatre. Teams that are modernising access certification should treat reviewer context, indirect entitlements, and lifecycle triggers as core control requirements, not optional workflow enhancements.

The named concept here is review fatigue blind spot: a state where reviewers approve access faster than they can understand it. That blind spot is especially dangerous in finance-facing applications because the wrong entitlement can move money, alter records, or mask SoD conflicts. Organisations should expect lower certification quality whenever the access model is more complex than the review interface.

For identity programmes that span human users and machine accounts, the same lesson applies. If the governance process cannot explain effective privilege in plain business terms, it will miss the accounts that matter most. The next step is to align certification, lifecycle offboarding, and privilege review into one operating model.

For practitioners

• Prioritise high-risk ERP roles first Start with financial posting rights, vendor master access, approval roles, and any account with a Super-style entitlement. These are the roles most likely to create fraud exposure or SoD conflict if they remain assigned after job changes.
• Review effective access, not role labels Use permission set recording and indirect access analysis to see what a user can actually do, including permissions inherited through groups or excluded from composite roles. A named role is not enough evidence for certification.
• Replace spreadsheet campaigns with workflow routing Route reviews to the right business owner, send automated reminders, and escalate overdue decisions so certification is accountable instead of purely administrative. Preserve reviewer context in the workflow so approvals are informed.
• Map review scope to SoD and fraud paths Build access review templates around the transactions and approvals that can move money or alter records, rather than reviewing every entitlement with equal weight. That keeps the programme focused on the control failures that matter most.
• Tie certification to lifecycle events Recheck access after role changes, transfers, and offboarding so dormant permissions do not linger until the next quarterly or annual cycle. Review programmes are strongest when they respond to identity changes, not just calendar dates.

Key takeaways

• User access reviews only reduce risk when they validate effective permissions, not just assigned roles.
• Manual, spreadsheet-driven certification cycles create review fatigue that allows overprovisioned ERP access to survive.
• High-risk roles, SoD conflicts, and lifecycle events should define the review scope if the programme is meant to prevent fraud.

Key terms

• User access review: A user access review is a structured check of who has access to a system, what they can do, and whether that access still matches business need. In practice, it is only effective when reviewers can see effective privilege, not just directory role labels or spreadsheet exports.
• Indirect access: Indirect access is permission granted through a group, inherited role, or layered configuration rather than a direct assignment to the user. It matters because the real entitlement can be broader than the visible role, which makes certification and SoD analysis harder unless the underlying access path is exposed.
• Segregation of duties: Segregation of duties is the control principle that separates sensitive actions so one user cannot complete an entire high-risk business process alone. In ERP systems, it is a practical fraud control, not just a compliance term, and it must be evaluated against the user’s effective permissions.
• Effective access: Effective access is the total capability a user actually has after direct assignments, group membership, inherited roles, and exclusions are combined. It is the only access view that matters for governance because role names alone do not show whether someone can post, approve, or modify sensitive records.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Delinea: User access reviews for Microsoft Dynamics 365 BC, lightweight strategies that work. Read the original.