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

Why This Matters for Security Teams

Access reviews for ERP platforms like Dynamics 365 BC are not just an audit exercise. They are a control over who can post journal entries, approve payments, change master data, and bypass segregation of duties. If reviewers rely on broad role names, they miss the effective access hidden inside composite permissions, delegated administration, and temporary exceptions. That is how low-risk recertification becomes a privilege retention problem.

The practical issue is that ERP access often reflects business process history rather than current need. A user may still carry entitlements from a prior project, a merger, or a support incident long after the reason has expired. Current guidance from the OWASP Non-Human Identity Top 10 and NHI Management Group’s Ultimate Guide to NHIs both reinforce a wider pattern: standing access and poor visibility are what turn routine entitlement review into a security gap. In practice, many security teams encounter the real risk only after an exception has already been used in production, rather than through intentional review.

How It Works in Practice

Effective ERP access reviews start with entitlement risk, not with a flat list of users. Reviewers should first isolate the highest-impact access paths, such as vendor payment approval, posting rights, GL adjustments, security administration, and any permissions that can override workflow controls. Then the review should validate what the account can actually do, not just the name of the role assigned to it.

A workable process usually combines three checks:

• Transaction risk: confirm whether the entitlement can move money, alter records, or weaken controls.

• Business ownership: route certification to a manager or process owner who understands the workflow, not only the system owner.

• Effective access: inspect inherited access, nested roles, and temporary exceptions so hidden privilege does not survive the review.

For ERP environments, this is also where segregation of duties matters. If a single user can create vendors and approve payments, the review should flag that combination even if each role appears legitimate in isolation. Automation helps if it preserves context: approvers need to see last-used date, ticket reference, business justification, and whether the access is tied to a role or a one-off exception. That is consistent with the governance direction in the NHI Lifecycle Management Guide, where entitlement lifecycle and revocation discipline are treated as operational controls, not periodic paperwork.

Teams should also align the review cadence to risk. High-impact financial and administrative rights deserve shorter review cycles than low-risk self-service access. Best practice is evolving here, but current guidance suggests that a risk-tiered approach reduces reviewer fatigue while improving catch rates. These controls tend to break down when ERP customisations, emergency access, and decentralized approval chains make it difficult to reconstruct effective privilege at review time.

Common Variations and Edge Cases

Tighter certification often increases operational overhead, requiring organisations to balance control strength against reviewer fatigue and business disruption. That tradeoff is real in Dynamics 365 BC environments where role mapping is inherited from legacy ERP design, department-specific add-ons, or partner-managed extensions. The answer is not to review everything equally. It is to focus effort where the blast radius is highest.

One common edge case is shared or service-style access used by finance bots, integrations, or third-party connectors. Those accounts should not be reviewed like human user access because their approval logic, ownership, and renewal cadence are different. Another is emergency access: if temporary elevation is allowed, the review should verify automatic expiry and evidence of post-use cleanup rather than accept a standing exception. NHI Management Group’s The State of Non-Human Identity Security highlights how often organisations underestimate entitlement sprawl and over-privilege, which is exactly what ERP recertification can miss when it stays name-based instead of risk-based.

There is also no universal standard for how much process context an approver must see, but current guidance suggests that reviewers need enough detail to decide whether access is still justified without forcing them to interpret raw technical permissions. The best reviews are the ones that reflect how the ERP is actually used, not how the role catalog was originally designed.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams run SOX access reviews across multiple in-scope systems?
• How should security teams govern SaaS applications that access Microsoft 365 on behalf of users?
• How should security teams implement policy-based access reviews alongside RBAC?