I have seen this scenario many times in D365 Finance and Supply Chain projects.
A business user says:
“I only need this person to view a few screens.”
Then someone assigns a broad security role because it is faster.
A few months later, the license report shows that the user now needs a full Finance or Supply Chain license, even though they barely use the system.
That is exactly where D365 license validation becomes important.
The Security and Licensing Connection
In D365 Finance and Supply Chain, security is role based and pessimistic. This means users have no access until access is explicitly granted.
From a licensing point of view, the important thing is this:
D365 licenses are not based on actual usage. They are based on potential access.
So even if a user never opens a specific form or never performs a transaction, the license requirement is still calculated from the security roles assigned to them.
This is why over assigning security roles directly increases license cost.
How This Worked Before
In the older model, licensing was mostly driven by menu item access.
Each menu item had a view and maintain license parameter. The system looked across all assigned menu items and calculated the highest license required.
- Then in 2019, Microsoft introduced more granular licenses such as Finance, Supply Chain, Commerce, Project Operations, and Human Resources. The calculation shifted toward privileges.
- Now, from March 2025 onward, licensing is calculated at the object level outside D365 through a Microsoft hosted microservice.
This microservice becomes the single source of truth across PPAC, LCS, Microsoft 365, and D365.
That is important because previously, different platforms could show different numbers, which created confusion during license reviews.
What Objects Now Matter
The license calculation now considers more than just forms and menu items.
It includes:
• Menu items, including displays, outputs, and actions
• Service operations, such as API endpoints
• Data entities used for external integrations
• Data entity methods used for business processes on entities
The key rule is simple:
Read access defaults to Team Member.
Write access, such as create, update, or delete, is determined by the licensing entitlement table for that object.
Real World Example
Let’s say you create a custom role for a warehouse supervisor.
The supervisor only needs to view a few operational screens and update limited warehouse related information.
If you assign a large standard warehouse role, the user may require a higher Supply Chain license.
But if you duplicate the role, remove unnecessary duties, and keep only what is needed, the required license may reduce to Operations Activity or another lower tier.
This is why role design matters.
Security is no longer just a technical configuration. It directly impacts licensing cost.
Base and Attach License Model
For users who need enterprise level access, one license becomes the base license. This is usually the highest cost applicable license.
Additional licenses for other functional areas can be attached at a lower price.
For example, if a user needs both Finance and Supply Chain access, one may act as the base license and the other as an attach license, depending on the supported combination.
Microsoft has also added flexibility for licenses in the same pricing group, such as Finance and Supply Chain, to be swapped as base or attach.
If the combination is not supported, then two full base licenses may be required.
Enforcement Timeline
Microsoft began its enforcement journey on January 15, 2026.
This applies to organizations whose renewal or anniversary date falls on or after that date.
The timeline works like this:
• 90 days before renewal, license analysis begins
• 30 days before renewal, users start seeing in app notifications if they are underlicensed
• 15 days after renewal, hard enforcement begins
• Underlicensed users are blocked from logging into production
This enforcement applies only to Microsoft managed production environments.
Sandbox, development, and customer hosted environments are reporting only or excluded.
Important Clarifications
There are a few points every D365 customer should understand.
- B2B guest users need to be licensed like normal users.
- Custom objects, whether built internally or delivered through an ISV, require a Team Member license.
- The SysAdmin role does not require a license, and neither do around 50 plus Microsoft defined roles, as long as they are not modified.
- Service accounts do not need a license if they only use those non licensed roles and are not performing interactive business functions.
- Licenses are managed at tenant level, not environment level. So multiple production environments under the same tenant share the same license pool.
- Multiplexing rules still apply. If users access D365 data through an automated external system, they may still need to be licensed.
- Device licenses are not yet part of enforcement, but Microsoft has indicated they will be included in the future.
Where I Usually Check License Impact
In a practical project, I would not rely on only one report.
The current license reporting is based on the same Microsoft hosted microservice, so the results should be consistent across the main reporting areas.
Power Platform Admin Center
PPAC is useful for a high level view.
It shows licensed, underlicensed, and overlicensed users. You can export the data to CSV or Excel.
There is also a Summarize option that generates a text output, which can be reviewed further for recommendations
Lifecycle Services
LCS provides the User License Consumption Report.
This is useful for project teams and administrators who are already working from LCS during implementation, support, or environment management.
D365 User Security Governance
This is the most detailed place to analyze why a user needs a specific license.
It allows you to drill into the objects, roles, duties, and privileges driving the license requirement.
This must be enabled through Feature Management.
The older license reports inside D365, such as view permission reports and user license count reports, are being deprecated in favor of these new reporting areas.
Role Duplication for License Optimization
This is one of the most practical features for license optimization.
D365 now allows you to duplicate a security role and target a lower license tier.
For example, if a role currently requires a Finance license, but you want to bring it down to Operations Activity, the system can show which duties need to be removed.
The removed duties can be exported to Excel for review.
This gives functional consultants, security admins, and business owners a structured way to optimize roles without guessing.
Dataverse Capacity Changes
Another important update is the Dataverse capacity change from December 2025.
Operations and Dataverse storage capacities have been merged into a single pool.
This gives customers more storage capacity at no additional cost.
This is a welcome change because the earlier separation of storage capacity did not always fit the scale of Finance and Supply Chain deployments.
Handling Custom Objects
Microsoft has clarified an important point in its FAQ white paper:
All custom objects require a Team Member license.
This includes:
• Custom objects built by internal development teams
• Objects introduced by third party ISV solutions
This is simpler than many people expected.
You do not need to analyze custom objects the same way you analyze Microsoft standard objects. The license requirement for custom objects is flat.
They require Team Member.
What This Means Practically
If a user only accesses custom functionality, such as custom forms, custom processes, or custom integrations, then a Team Member license may be enough.
But the moment that same user also gets access to standard Microsoft objects that require Finance or Supply Chain, the higher license wins.
The license requirement is always determined by the highest license requirement across all assigned access.
The Risk With ISV Solutions
This is where organizations need to be careful.
When you install an ISV solution, it introduces new objects into the environment.
The custom ISV objects may only require Team Member.
But many ISV solutions also bundle or connect with standard Microsoft objects and roles.
Those standard objects may carry Finance, Supply Chain, Commerce, or other license requirements.
So even if the ISV objects themselves are low impact, the security roles delivered with the ISV may increase user license requirements.
Best practice is simple:
Run a license analysis before and after installing an ISV solution.
That gives you a clear view of what changed and whether new roles, privileges, or objects increased the license requirement.
Critical Warning on Microsoft Unlicensed Roles
Microsoft provides around 50 plus system roles that do not require a license.
But there is one major caution.
If you add even one custom object, duty, or privilege to one of those roles, the no license exemption is lost.
You can remove objects from those roles without penalty.
But adding anything breaks the exemption.
The same logic applies when building custom roles. If you want a role to remain at Team Member level, make sure it does not accidentally include standard Microsoft objects that require Finance, Supply Chain, or another higher license.
How I Would Handle This in a Real Project
In a real D365 project, I would usually follow this approach.
First, export the current license position from PPAC or LCS.
Then review the highest cost users and identify why they need those licenses.
Next, open User Security Governance in D365 and drill down into the roles, duties, privileges, and objects driving the license requirement.
After that, check whether the user really needs all assigned roles.
If a role is too broad, duplicate it and target a lower license tier.
Then remove unnecessary duties and validate what access is actually required.
For ISV solutions, I would run the same analysis before and after installation.
For custom roles, I would make sure standard Microsoft objects are not accidentally pushing users into a higher license.
For Microsoft unlicensed roles, I would avoid modifying them completely.
Finally, I would include license impact checks as part of every security change request.
Key Takeaways
- Start the license review now, regardless of renewal date. Most organizations have more cleanup work than expected.
- Build license checks into the change management process. One security role change can affect hundreds of users.
- Do not modify Microsoft unlicensed system roles. Adding anything to those roles can trigger a license requirement.
- Test security and role changes in non production before pushing them to production.
- Monitor PPAC regularly because Microsoft microservice updates can change your compliance status even if you did not make changes inside D365.
Final Thought
D365 licensing is no longer something to review only during renewal.
It is now directly connected to security design, integrations, ISV installation, custom development, and day to day role management.
The practical rule is simple:
Do not give users more access than they need. Because in D365 Finance and Supply Chain, access is not just security.
Access is licensing.
Disclaimer: This post is based on my practical understanding of D365 Finance and Supply Chain licensing and Microsoft’s published guidance at the time of writing.
Please validate final licensing decisions with your Microsoft partner, account team, or official Microsoft Learn documentation:Stay compliant with user licensing requirements - Finance & Operations | Dynamics 365 | Microsoft Learn
