Microsoft's Evolving Approach to Dynamics 365 Enforcement

Dynamics 365 licencing has historically operated on a trust-based model: Microsoft's licence agreement set out the requirements, and customers were largely left to self-certify compliance. That model has changed materially. From November 2025, Microsoft introduced in-product licence validation for Dynamics 365 Finance and Operations, meaning the platform itself checks whether each user has an appropriately assigned licence before granting access.

The change is significant not because it introduces entirely new licensing rules — those rules have always existed in the product use rights and licence guide — but because it removes the practical obscurity that previously allowed many organisations to carry unlicenced users without immediate consequence. When a compliance gap is discovered at an EA renewal or through a Microsoft-initiated Software Asset Management engagement, the liability calculation typically includes backdated charges covering the full period of non-compliance, which in large organisations can represent multi-million pound exposure.

Microsoft has adopted a staged rollout for enforcement. Customers with contract renewals or anniversaries for Dynamics 365 Finance and Operations occurring after January 15, 2026 received additional preparation time, with in-product notifications arriving first, followed by full per-user licence validation. Regardless of your specific rollout date, the directional message is clear: Microsoft is moving to enforce D365 licencing, and preparation is not optional.

What Microsoft Checks in a Dynamics 365 Audit

Understanding what Microsoft's audit process examines is the foundation of effective preparation. Dynamics 365 audits — whether self-service or Microsoft-initiated — typically focus on four dimensions:

User Count and Licence Assignment

The most fundamental check is a comparison between the number of active users in the system and the number of appropriately licensed users in the tenant. Microsoft's new licence management capabilities in the Power Platform Admin Centre and Dynamics 365 admin centre provide a License Usage Summary Report that maps active users to their assigned licences, highlighting anyone accessing the system without a matching licence assignment.

Critical accounts to check include: service accounts (often created for integrations without individual licence assignment), inactive users who still have active D365 security roles, contractor accounts that may have been set up informally, and named accounts created during implementation that were never cleaned up post go-live.

Security Role and Licence Type Alignment

This is a more nuanced compliance risk that many organisations overlook. Microsoft Dynamics 365 licence types (Full User, Team Member, Device, Activity) carry different access entitlements. If a user is assigned a security role that grants access to capabilities beyond what their licence type permits, Microsoft treats this as a compliance gap — even if the user has not actively used the elevated capabilities.

From November 2025, Microsoft introduced explicit enforcement: if a user's security role does not match their assigned licence, the system will block their access until the mismatch is resolved. This means the gap will be visible and operationally disruptive, not just a compliance risk at renewal time.

Power Platform and Embedded Dynamics Usage

A growing source of Dynamics 365 compliance complexity is the intersection of the Power Platform (Power Apps, Power Automate, Power BI) and Dynamics 365. Many organisations have users who access Dynamics data through Power Apps or automated flows built on Power Automate — and the licensing requirements for these access patterns are different from direct D365 application access. Microsoft's Product Terms and Product Use Rights specify which access patterns require which licence type, and the ambiguity in this area has generated significant audit exposure for organisations that implemented Power Platform solutions without a licensing review.

Third-Party Application Access to Dynamics Data

External applications that integrate with Dynamics 365 via API — ERP add-ons, data warehousing tools, reporting platforms, bespoke integration middleware — can trigger licensing requirements depending on the nature of the access. Read-only access by non-interactive users may be covered under specific licence terms; write access or transactional processing typically requires licensed users associated with those transactions. This area is frequently under-reviewed in organisations that have grown their D365 integration landscape organically.

"The single most common cause of Dynamics 365 licence exposure is not deliberate under-licensing — it is organic growth in user counts and access patterns that was never mapped back to the licence entitlement."

Running Your Internal Dynamics 365 Licence Audit

A proactive internal audit, conducted before Microsoft's enforcement mechanisms identify gaps for you, is the most cost-effective form of D365 compliance management. The following process covers the essential steps.

Step 1: Export the Active Users List

From the Power Platform Admin Centre, export the full list of enabled user accounts across all D365 environments (production, sandbox, UAT, development). Include both licensed and unlicensed users. The goal is a complete picture of who has any form of D365 access, regardless of how they were provisioned.

Step 2: Map Users to Assigned Licences

In Microsoft 365 Admin Centre, export the licence assignment report for all users in the tenant. Cross-reference against the D365 active users list to identify: users with D365 access but no licence assigned; users assigned a licence type that does not match their security role profile; and users assigned licences they have not logged in to use in the past 90 days (potential licence optimisation).

Step 3: Review Security Role Assignments

Within each Dynamics 365 environment, review the security roles assigned to each user and compare against the Microsoft licence guide's entitlement table for each licence type. Particular attention should be paid to: users with Full User security roles who are assigned Team Member licences; Finance and Operations users with finance module access but only a Business Central licence; and users with customised security roles that blend entitlements from multiple application modules.

Step 4: Audit Integration and Service Accounts

List all service accounts, integration users, and application users in each environment. Confirm each has either: (a) an appropriate named-user licence if they are associated with human transactions; (b) an Application User configuration (licensed separately as part of the Power Platform) if they are exclusively machine-to-machine integrations; or (c) explicit coverage under the relevant product use rights for non-interactive access.

Step 5: Quantify and Remediate Gaps

For each identified gap, quantify the licence exposure: the number of under-licensed users multiplied by the correct licence type price, covering the period the gap has existed. This provides an internal view of the financial exposure before Microsoft identifies it. Remediation options include: purchasing additional licences to close gaps, reassigning security roles to match existing licences, deactivating users who no longer require access, and converting named user accounts to Application User configurations where the usage pattern qualifies.

Concerned about D365 compliance exposure ahead of your Microsoft EA renewal?

Redress Compliance provides independent Dynamics 365 licence audits and Microsoft EA negotiation support.
Request a D365 Audit →

How to Respond if You Receive a Microsoft Audit Notification

If Microsoft or its authorised representative (typically through a Software Asset Management or True-Up review process) notifies your organisation of a compliance review, the following response principles apply.

Do not respond immediately or in isolation. Microsoft's initial audit communication is a starting point, not a final determination. Organisations that respond with immediate admission of gaps and acceptance of Microsoft's initial liability calculation consistently pay more than those who conduct an independent analysis first. Engage your Microsoft licensing partner or an independent advisory firm before submitting any formal response.

Conduct your own count before accepting Microsoft's figures. Microsoft's audit methodology may include inactive users, test accounts, or integration users that your organisation has legitimate grounds to exclude from the licence count. Run your own authoritative count using the methodology described above, document your methodology clearly, and use this as the basis for any settlement discussion.

Understand your contractual position. Review your Enterprise Agreement terms for the audit rights Microsoft holds, the cure period available for identified gaps, and any limitation of liability provisions. In most EA structures, there is a defined period (typically 30–60 days) in which you can resolve identified gaps without automatic penalty escalation.

Negotiate the settlement, not just the licence purchase. If a genuine licence gap is confirmed, the final settlement should be negotiated — not simply accepted. Elements open to negotiation typically include: the effective date from which backdated charges are calculated, the unit price for retrospective licence purchases, whether to resolve the gap through additional licence purchases or through restructuring the EA at the next renewal, and any penalty clauses versus clean-up periods.

Preventing Future Audit Exposure: Ongoing Compliance Management

The most expensive compliance event is the one that surprises you. The following ongoing practices eliminate surprise and reduce audit exposure to a manageable level:

  • Quarterly licence reconciliation: Run the user-to-licence cross-reference process described above on a quarterly schedule, not just at EA renewal. Set calendar reminders linked to your HR offboarding process so that user deactivation in Dynamics 365 happens within a defined window of employment termination.
  • Licence gate on D365 provisioning: Require a licence assignment confirmation before any new user account is created in Dynamics 365, rather than provisioning access and backfilling licences retrospectively.
  • Power Platform licencing review for every new solution: Before deploying any new Power App or Power Automate flow that accesses Dynamics 365 data, conduct a brief licencing review to confirm the access pattern is covered by the existing licence structure.
  • EA renewal preparation starting 12 months out: Use the EA renewal as an opportunity to right-size your D365 licence mix — not just to renew existing allocations. Identify unused or over-provisioned licence types and negotiate adjustments before the renewal, rather than discovering the discrepancy during a true-up.

Dynamics 365 licence management is rarely glamorous, but the financial consequences of systematic non-compliance — particularly as Microsoft's enforcement capabilities become more automated and real-time — make it a governance function worth investing in properly.