How should security teams evaluate access risk when multiple roles are assigned in Dynamics 365 Finance and Operations?

Teams should review role, duty, and privilege reports together, then test the user’s effective access against actual business tasks. D365FO can show what each security layer grants, but it does not automatically resolve combined access across multiple roles. That means access risk must be assessed by tracing the full hierarchy and validating whether the resulting permissions match the user’s job function.

How multiple role assignments change the access review

In Dynamics 365 Finance and Operations, the key question is not what each role allows in isolation, but what the user can do when role assignments are combined. A single role report can understate access risk because it misses privilege stacking, duplicated duties, and paths that only appear once multiple roles are effective at the same time.

This is why reviewers should trace the full hierarchy from role to duty to privilege, then compare the resulting effective permissions with the user’s actual job tasks. If the combined access enables actions outside the role holder’s function, the risk is not theoretical, it is an access design problem that needs remediation.

For teams building a repeatable review process, the most useful baseline is an access governance model that treats roles, entitlements, and recertification as one control surface. NHIMG’s IAM and IGA Basics is a practical starting point because it frames role assignment, access review, and entitlement governance as linked decisions rather than separate checks.

Why combined role evaluation matters in D365FO

D365FO security is layered, so the effective permission set can be broader than any one report suggests. A user may receive a harmless-looking role for one business function and another for operational support, but together those roles can create write access, approval authority, or administrative visibility that no single reviewer would flag on its own.

The practical failure mode is role explosion combined with privilege creep. Over time, users accumulate access for projects, backfills, exceptions, and local fixes, and those assignments are left in place after the original need has passed. That creates an authorization picture that is technically valid in the system but no longer defensible from a business perspective.

Access model design also matters because RBAC alone may not capture every business constraint cleanly. NHIMG’s Authorisation Models Guide is useful here because it helps reviewers distinguish role-based assignment from finer-grained authorization decisions, which is essential when the security question is whether the combined roles still match the person’s duties.

How to test effective access against real work

The most reliable review method is task-based validation. Start with the business activities the user actually performs, then test whether the combined permissions allow only those tasks and nothing materially beyond them. In practice, this means checking not just whether access exists, but whether the user could create, approve, post, reverse, or export records in ways that would exceed their job scope.

Where the user has several roles, look for overlap that changes the risk profile. Two narrow roles can become one broad capability set, especially when one role supplies read access, another supplies transaction rights, and a third supplies approval or administrative functions. The combined effect is what determines whether the account is acceptable.

Teams should also confirm whether any elevated access is temporary, exception-based, or tied to a compensating control. NHIMG’s IAM and IGA Basics supports that review because it connects access certification, least privilege, and separation of duties to the practical question of whether the assigned permissions still fit the user’s function.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Combined role assignments must still limit users to necessary access.
	AC-5 — Separation of Duties	Stacked roles can collapse duties that should stay separated.
	AC-2 — Account Management	Role assignment and review are account-management decisions over time.
Recommendation — Review combined D365FO access against least-privilege needs and remove excess permissions. Check assigned roles for conflicting duties before approving effective access. Reassess role assignments whenever job function, exceptions, or responsibilities change.
ISO/IEC 27001:2022	A.5.15 — Access control	The question is about evaluating whether access remains appropriate under combined roles.
	A.5.18 — Access rights	Access rights must be granted, reviewed, and adjusted based on actual need.
Recommendation — Apply access-control rules to verify that effective permissions match business need. Review and recertify access rights after combining all assigned roles.

Practitioner Guidance

What to prioritise: Review combined permissions first for roles that can create separation-of-duties conflicts, approval bypass, payment impact, or master-data change capability. Those are the assignments most likely to create business harm if they stack unexpectedly.

What to verify: Test the effective access path with a real task list, not a role title list. If the user can complete an end-to-end sensitive workflow without another person’s involvement, the assignment set deserves escalation even if each role looked reasonable on its own.

Common mistake: Treating the role catalog as proof of safety. Role definitions show intended design; they do not prove that the combined assignment set is still aligned to the user’s actual responsibilities.

Practitioner takeaway: In D365FO, access risk is decided by the aggregate permission outcome, not by individual role intent, so the review must end with a business-task test, not a report comparison.