What Most D365 F&O Implementations Get Wrong About Security Roles
Three months after go-live, the CFO of a construction company called us in a panic. "We've just discovered that our accounts payable staff can create and approve their own purchase orders. We've potentially had this security hole since we launched. How did we miss this?"
This scenario plays out with alarming frequency across Dynamics 365 Finance and Operations implementations. Despite meticulous attention to data migration, customisations, and performance, security roles often become an afterthought—hastily configured in the final weeks before go-live, creating serious compliance risks that can persist for months or even years.
After reviewing more than 50 D365 F&O security implementations, I've identified a consistent pattern of critical mistakes that organisations make, many of which could expose them to significant financial and compliance risks. Let me share what I've observed and how you can avoid these common pitfalls.
This scenario plays out with alarming frequency across Dynamics 365 Finance and Operations implementations. Despite meticulous attention to data migration, customisations, and performance, security roles often become an afterthought—hastily configured in the final weeks before go-live, creating serious compliance risks that can persist for months or even years.
After reviewing more than 50 D365 F&O security implementations, I've identified a consistent pattern of critical mistakes that organisations make, many of which could expose them to significant financial and compliance risks. Let me share what I've observed and how you can avoid these common pitfalls.
The Security Role Crisis in D365 F&O
D365 F&O security is inherently complex. With over 915 standard security roles, more than 11,500 privileges, and 37,000+ permissions in a typical implementation, designing an effective security model requires significant expertise. Yet many projects allocate inadequate time and resources to this critical task.
The consequences can be severe:
A building materials distributor discovered six months after implementation that warehouse staff could view gross margin data on sales orders—exposing sensitive pricing information to dozens of employees who shouldn't have had access.
A financial services firm failed a compliance audit when it was discovered that staff in the same department could create vendors, post invoices, and issue payments without appropriate segregation of duties.
An industrial equipment company found that their custom security roles broke during a major upgrade, requiring a costly emergency remediation project to restore proper system access.
The consequences can be severe:
A building materials distributor discovered six months after implementation that warehouse staff could view gross margin data on sales orders—exposing sensitive pricing information to dozens of employees who shouldn't have had access.
A financial services firm failed a compliance audit when it was discovered that staff in the same department could create vendors, post invoices, and issue payments without appropriate segregation of duties.
An industrial equipment company found that their custom security roles broke during a major upgrade, requiring a costly emergency remediation project to restore proper system access.
Seven Critical Security Role Mistakes
1/ Cloning Standard Roles Without Understanding Underlying Permissions
The most prevalent error I encounter is teams simply duplicating Microsoft's standard security roles (like "Accounts Payable Manager") and making minor adjustments without truly understanding the underlying permissions.
A media company discovered that their customised "AP Clerk" role—cloned from the standard role—unknowingly retained the ability to approve invoices up to $250,000, creating a significant segregation of duties conflict.
What to do instead: Create a permissions inventory matrix mapping each role to specific duties and tasks before implementing roles. Don't start from Microsoft's roles—start from your business processes.
A media company discovered that their customised "AP Clerk" role—cloned from the standard role—unknowingly retained the ability to approve invoices up to $250,000, creating a significant segregation of duties conflict.
What to do instead: Create a permissions inventory matrix mapping each role to specific duties and tasks before implementing roles. Don't start from Microsoft's roles—start from your business processes.
2/ Ignoring the Critical Duty Separation Framework
D365 F&O includes a sophisticated duty separation framework designed to prevent fraud by ensuring key financial activities remain properly segregated. Yet many implementations never properly configure these controls.
The table below illustrates common duty conflicts that should never exist within a single role:
The table below illustrates common duty conflicts that should never exist within a single role:
Duty 1
Duty 2
Risk if Combined
Create vendors
Pay vendors
Potential to create and pay fictitious vendors
Create customers
Apply cash receipts
Ability to manipulate receivables
Manage bank accounts
Process payments
Control of payment destinations and processing
Post inventory adjustments
Receive purchase orders
Ability to manipulate inventory values
Maintain prices
Process sales orders
Ability to offer unauthorized discounts
A retail organisation discovered that users with their custom "Inventory Manager" role could both adjust inventory quantities and financially post those adjustments—potentially allowing inventory theft to be concealed through system adjustments.
What to do instead: Implement proper duty segregation from day one by using D365's Segregation of Duties (SoD) conflicts framework, and regularly validate that no roles contain conflicting duties.
What to do instead: Implement proper duty segregation from day one by using D365's Segregation of Duties (SoD) conflicts framework, and regularly validate that no roles contain conflicting duties.
3/ Taking the "Minimum Viable Security" Approach
Under pressure to meet go-live deadlines, many projects configure security roles using a "just enough to function" approach—granting broad permissions just to get users working in the system.
A professional services firm went live with "emergency" security roles that granted almost all users financial posting capabilities, planning to "tighten things up later." Six months post-implementation, these overly permissive roles remained unchanged.
What to do instead: Invest in proper security role design before go-live. It's far easier to implement proper security initially than to retroactively restrict users who have become accustomed to elevated privileges.
A professional services firm went live with "emergency" security roles that granted almost all users financial posting capabilities, planning to "tighten things up later." Six months post-implementation, these overly permissive roles remained unchanged.
What to do instead: Invest in proper security role design before go-live. It's far easier to implement proper security initially than to retroactively restrict users who have become accustomed to elevated privileges.
4/ Overlooking Data Security Beyond Role Permissions
D365 F&O security extends beyond role permissions to include data security models controlling which data users can access. Many implementations focus solely on functional permissions while neglecting these critical data controls.
A manufacturing conglomerate with operations in five states configured functional security correctly but failed to implement proper data security, allowing staff in each location to view and modify data from all locations.
What to do instead: Incorporate data security requirements (legal entity restrictions, organisation hierarchies, and dimension values) into your security design from the beginning. Test these restrictions thoroughly before go-live.
A manufacturing conglomerate with operations in five states configured functional security correctly but failed to implement proper data security, allowing staff in each location to view and modify data from all locations.
What to do instead: Incorporate data security requirements (legal entity restrictions, organisation hierarchies, and dimension values) into your security design from the beginning. Test these restrictions thoroughly before go-live.
5/ Failing to Document Role Design and Decisions
Security role implementations frequently lack proper documentation explaining design decisions, permission inclusions, and the business justification for access grants.
A distribution company struggled to troubleshoot security issues after their implementation partner departed, finding no documentation explaining why certain permissions were granted or denied for specific roles. Their eventual security redesign cost over $85,000.
What to do instead: Maintain comprehensive documentation for each security role, including:
A distribution company struggled to troubleshoot security issues after their implementation partner departed, finding no documentation explaining why certain permissions were granted or denied for specific roles. Their eventual security redesign cost over $85,000.
What to do instead: Maintain comprehensive documentation for each security role, including:
- Business purpose and intended users
- Key duties and permissions included
- Explicit justification for sensitive permissions
- Approval history for role changes
6/ Treating Security as an IT Responsibility, Not a Business Function
Perhaps the most fundamental mistake is treating security configuration as a technical task rather than a critical business function requiring process knowledge and risk awareness.
A government agency allowed their technical team to configure security with minimal business input. The resulting roles, while technically functional, failed to align with actual job responsibilities and created numerous control issues identified in a subsequent audit.
What to do instead: Establish a security governance committee with representation from finance, operations, compliance, and IT. This committee should review and approve all security role designs and changes.
A government agency allowed their technical team to configure security with minimal business input. The resulting roles, while technically functional, failed to align with actual job responsibilities and created numerous control issues identified in a subsequent audit.
What to do instead: Establish a security governance committee with representation from finance, operations, compliance, and IT. This committee should review and approve all security role designs and changes.
7/ Neglecting Regular Security Audits and Maintenance
Many organisations implement security once and never revisit it, failing to account for organisational changes, new features, or emerging risks.
A healthcare supply company maintained the same security configuration for three years despite significant organisational restructuring and two major D365 upgrades, resulting in numerous inappropriate access grants that accumulated over time.
What to do instead: Implement a quarterly security review process that examines:
A healthcare supply company maintained the same security configuration for three years despite significant organisational restructuring and two major D365 upgrades, resulting in numerous inappropriate access grants that accumulated over time.
What to do instead: Implement a quarterly security review process that examines:
- User role assignments for appropriate access
- Segregation of duties conflicts
- Unused or redundant security roles
- New permissions introduced by updates
A Better Approach: The Four-Phase Security Implementation Model
Based on successful implementations I've guided, I recommend this structured approach to D365 F&O security:
Phase 1: Security Requirements Gathering (8-10 Weeks Pre-Go-Live)
Start by documenting security requirements based on business processes, not system functions. Create a comprehensive task matrix showing:
- Key business tasks by department and role
- Required permissions for each task
- Segregation of duties requirements
- Data security constraints
Phase 2: Security Design and Construction (6-8 Weeks Pre-Go-Live)
Develop custom security roles from scratch rather than modifying standard roles. Create a proper security architecture with:
- Base privilege roles (containing basic permissions)
- Duty roles (containing related privileges for specific duties)
- End-user roles (combinations of duty roles aligned to job functions)
Phase 3: Testing and Validation (4-6 Weeks Pre-Go-Live)
Conduct comprehensive security testing, including:
- Functional testing (can users perform intended tasks?)
- Negative testing (are users appropriately blocked from unauthorized functions?)
- Segregation of duties validation
- Data security boundary testing
Phase 4: Governance and Maintenance (Ongoing)
Establish a sustainable security governance model:
- Regular security committee meetings (monthly initially, quarterly ongoing)
- Formal role change request and approval process
- Periodic access reviews and certifications
- Security update strategy for system upgrades
Real World Success Story: Getting Security Right
A financial services client adopted this structured approach for their D365 F&O implementation with impressive results:
Their security design phase consumed 220 hours of effort (compared to the 80 hours originally budgeted), a significant investment that initially concerned project leadership. However, over the following year, they experienced:
Their security design phase consumed 220 hours of effort (compared to the 80 hours originally budgeted), a significant investment that initially concerned project leadership. However, over the following year, they experienced:
- Zero security-related audit findings
- 85% reduction in emergency access requests
- No security remediations required during their first major upgrade
- Substantial time savings from reduced security maintenance
Practical Recommendations for Your Implementation
Based on the patterns I've observed across dozens of implementations, here are my key recommendations:
Start early:
Begin security design at least 3 months before go-live, not in the final weeks.
Invest in expertise:
Engage security specialists who understand both D365 F&O's security architecture and financial control principles.
Build from scratch:
Design custom roles based on your specific process requirements rather than modifying standard roles.
Test thoroughly
Validate security through comprehensive testing scenarios that include both positive and negative testing.
Document everything:
Maintain detailed documentation of all security design decisions and role configurations.
Establish governance:
Create a formal security committee with representation from finance, operations, compliance, and IT.
Plan for maintenance:
Develop a strategy for security updates during system changes and D365 F&O upgrades.
Final Thoughts: Security as a Foundation, Not an Afterthought
Effective security role design in D365 F&O isn't just about compliance—it's about creating a foundation for operational efficiency and risk management. By investing adequate time and resources in security design upfront, you can avoid costly remediation projects and compliance failures down the road.
Rather than asking "How quickly can we implement security?" The better question is "How can we implement security right the first time?"
Rather than asking "How quickly can we implement security?" The better question is "How can we implement security right the first time?"