Clear breakdowns of Dynamics 365 Finance & Supply Chain license types, security roles, and compliance risk, written from real audits and real true-ups. No vendor spin. No fluff.
Licensing and security are two different disciplines that both show up on the same D365 F&SC audit. We write for both.
Understand what you're actually entitled to use, and where you're paying for seats nobody needs.
Find the access risk hiding in your security role design before an auditor, internal or external, finds it for you.
Different questions, different deliverables. Most clients eventually need both.
| Licensing Review | Security Audit | |
|---|---|---|
| Question | Are we licensed correctly for how people actually use the system? | Can any single person do something they shouldn't be able to do alone? |
| Best for | Finance & procurement, before a true-up or renewal | Compliance & internal audit, before SOX or ISO review |
| What you get | SKU-by-user mapping, overbuy/underbuy report, right-sizing plan | Conflict matrix, role redesign recommendations, monitoring plan |
| Typical outcome | 25 to 44% reduction in license spend, per our published case studies | Closed audit findings, cleaner SOX sign-off |
Deep, practical breakdowns, not marketing copy.
Personalizations and saved views are bound to security roles. Redesign the roles without carrying them across and people lose their screens on day one. How to keep the change invisible.
Never revoke access until the replacement is proven in. Ship de-provisioning as a signed-off list first and an import file last, so a cost optimization never breaks someone's day.
Swap the ruleset and a segregation-of-duties conflict count moves from 870 to 353 without any security changing. Inherited rulesets are routinely contaminated. Fix the instrument first.
Restrictions are a second, inverted permission layer. An analysis that ignores read-only denies miscounts access, and a careless redesign can revoke access users needed, not just trim cost.
A user-role assignment with no organization rows grants access to every legal entity. Ship one unscoped assignment in a package and you widen access across the whole company by accident.
A client deployed a full security-role redesign straight to production without a UAT pass of the shipped build, and the first business day was quiet. Why an additive, evidence-built cutover makes that safe, and what it does and does not prove.
How two Dynamics 365 clients went live on a new security design without a UAT pass of the shipped build, and why the weeks of data collection beforehand are the test that makes a fast, low-risk go-live possible.
The System Administrator role carries zero rows in the privilege model most analyses are built on, so the most powerful accounts score as the cleanest. A blind spot worth naming.
Which D365 security grants you can observe from write-evidence is fixed by the platform: about 89% of screens, 22% of outputs, 7% of actions, 0% of in-form controls. A structural constant.
The belief that nothing can be done about a D365 license bill is the most expensive one in the room. Microsoft sets the price and the rules. How many licenses you actually need is a function of your own security configuration, and that is yours to change.
One service account posted 44.6 million rows. When batch and integration accounts dominate an audit trail, per-user signal disappears, and a naive read of the log misleads.
The October 2026 Dynamics 365 Licensing Guide adds exactly one new product, Dynamics 365 Sustainability, a standalone SaaS with its own tenant and per-user licensing. For a Finance and Supply Chain shop, nothing changes.
Grant/deny conflicts, mixed-tier privileges, sysadmin-plus-business-role overlaps: none of it needs usage evidence to catch. Here's why the lightest check we run is worth running after every security change during remediation, not just once at the end.
The actor behind D365's highest-stakes verbs, posting and approving, is usually not recorded. What that means for audit evidence, and why a license analysis has to account for it.
A redesign can hand tens of thousands of permissions to users who do not need them, and a dollar-based budget sees none of it, because access that costs nothing is invisible to cost.
A modeled saving of $171,552 looked real until you asked how much hits the next invoice. The answer was near zero until revocation ships. The one question to ask of any quote.
A client chose to deliver their security redesign in batches, a completely reasonable call for a business that can't pause. Here's what that decision actually costs on our side, batch after batch, and why it isn't anyone's fault.
Restoring missing usage data raised the modeled cost from $1.83M to $2.21M. The honest number went up, not down. Why more evidence can make a design look worse, and why that is right.
A saving you cannot bank until the package actually ships it. On one estate the designed cost sat 61.5% below the shipped cost, and the shipped saving was zero.
Cost came first, then it came third, out of a legitimate concern about revoking access without proof of use. Remediation exists to cut a real bill, so we adapted our strategy to keep finding savings compatible with the new order.
Modeling a client's per-role license intent and the process change behind it: find the driver, re-route to a cheaper entry point or drop it, then confirm the tier actually fell.
'We don't run Commerce, take it off our bill' is surgery, not a toggle. The pros, the cons, the ties and service operations that trip it up, and governing intent so drift cannot undo it.
Some organizations want the leanest defensible design. Others want to change nothing that isn't costing them money. We built a dial for it, and caught a real mistake in our own modeling before shipping it.
Pricing a bug correctly nearly removed access hundreds of users needed. Why an evidence-based engine must credit service-operation cost without letting it condemn a privilege.
The same project case needs a premium Project Operations license through one door and only Team Members through another. The license is a property of the door, not the destination.
Most tuning decisions turned out not to matter at all. One did, tested across two structurally different clients, and it behaves in opposite directions depending on the client's shape.
D365 charges real licenses for service operations, the endpoints integrations call. Most license tooling prices them as free, so a whole category of paid access is invisible.
Our evidence model leans on telemetry and audit-log evidence together. This environment had almost no usable telemetry at all. Here's what the redesign looked like on one evidence source instead of two.
Pricing the 'before' seat from the union of every license option a user could reach invents savings that were never there. Price one population, both sides, as a minimum-cost cover.
Our cheapest role-mining design still produced 760 roles. The client asked for as few roles as possible, and told us upfront they'd pay more for it.
A vs-compliance baseline and a like-for-like baseline answer different questions and produce very different savings. Mixing them inflates the headline. Name your baseline.
A client rejected a 100-role fix and asked us to mine roles from real usage instead. Our first attempt would have cost more per month than doing nothing.
On one estate, five privileges pinned 110 of 127 top-tier seats. License cost is Pareto-distributed, so targeted remediation beats a boil-the-ocean role project.
Only about a quarter of D365 menu items cost less read-only, and a handful of privileges drive most expensive seats. Why 'just make it read-only' rarely lowers the bill.
On one estate the user list held about 2,180 accounts but barely 955 were real people. Counting service and system accounts as seats inflates both the bill and the savings claim.
Roughly half of all menu-item privileges can't be directly observed by any audit trail. Here's the careful, layered process for closing part of that gap.
D365 bills per user over the union of their roles, resolved as a minimum-cost set cover. Pricing per role double-counts and invents savings. The conceptual spine of license analysis.
A disposition table says what to keep, downgrade, or drop. It doesn't say what roles to build. Here's the separate step, and the trade-off it can't avoid.
The September 2026 guide's only new entry is Headless Commerce reaching GA. Unlike the last two editions, this one is documented to integrate directly with Finance and Supply Chain Management.
Microsoft bills per user, not per role, over everything their roles can do. A plain-English primer on D365 F&SC license tiers and the vocabulary every analysis assumes.
Most reviews start with a user list and a role count, about ten questions. A properly scoped intake runs to 106. Here's what falls in the gap.
A privilege with no recorded activity isn't automatically safe to remove. Why observability has to be verified before silence can be treated as an answer.
Every privilege in a D365 role lands on one of five outcomes. Here's the evidence model behind that decision, and the one rule that keeps it safe to act on.
Every article on this site traces back to the same three-stage method. This piece is the map, linking to the articles that go deep on each stage.
The security model wasn't the biggest driver of this estate's license bill. The way one integration authenticated was.
Instead of two hours of manual UI exports, get just-in-time database access to a Tier 2 sandbox and run one script that pulls all 33 datasets, license, security, personalization, and audit-log evidence, unattended.
Four published engagements with real before-and-after numbers, including the one where our own recommendation got turned down, and why we publish that one too.
Ten datasets, each answering one specific question, joined together into a single defensible license number.
The August 2026 Dynamics 365 Licensing Guide grew from 89 to 90 pages. Two new Change Log entries, both Customer Insights agents, neither touches Finance or Supply Chain Management.
A working list of the device, integration, and background-operation roles that carry no license requirement on their own.
Telemetry is one of the strongest inputs in a license review, and also one of the easiest to misuse.
Microsoft's per-user validation is tied to each tenant's own renewal date. What actually needs to happen before that date, not after the notice arrives.
A role name rarely tells you why it's expensive. The entry points inside it do.
Most licensing reviews start with a user export and a few disabled accounts. That feels productive and rarely gives you a trustworthy number.
Clients assume Microsoft-delivered roles are untouched and safe to trust. Five real patterns show how a quietly customized role drives cost.
License requirements aren't decided at the role level. They're decided at the user level, across every role that user holds.
Negotiating a Microsoft discount lowers price per license. It doesn't touch how many you actually need. Two real engagements show what the second lever is worth.
A privilege tied to five expensive workloads doesn't need the priciest one. It needs whatever license every entry point actually shares.
A mentoring engagement on a greenfield D365 F&SC implementation found over a thousand segregation-of-duties conflicts in thirty roles, a day before user acceptance testing. What doing security right the first time actually looks like.
Our first fully automated D365 F&SC security migration: an XML import replaced weeks of manual role-building. What that automation actually required, and the framework we had to build around it.
The mathematically optimal security model saved $32,000 a month. The client rejected it as unmaintainable, and was right to. Why, and how we rebuilt our methodology because of it.
A European estate with genuinely well-built security still carried $40,000 a month in avoidable license cost. What a clean configuration hides, and how we found it anyway.
A four-export, two-formula method for finding exactly which permissions drive each license on a role that requires three or more, plus a free downloadable workbook.
The exact Azure and F&SC configuration steps, what it costs against the free tier, and the two KQL scripts that turn telemetry into a license and user-activity report.
Identifying inactive users saves the most of any overlicensing strategy, but the built-in report alone misreads integration users. The two-source method and two exceptions that keep it accurate.
Contradictory Deny/Grant on the same entry point, and Correct or Invoke permissions granted without their prerequisites. Both pass an access review clean and still inflate license tiers.
Team Members, Operations, Finance/SCM, and Premium: what each SL actually entitles you to, official pricing, and the five overbuying mistakes we see in almost every tenant.
How roles, duties, and privileges actually stack up, the conflict pairs that show up most often, and a walkthrough of running your own SoD analysis.
Starting on each tenant's contract anniversary or renewal date, unlicensed users lose access. The T-90/T-30/T+15 timeline and the four-step prep checklist.
Where embedded Copilot features are included in existing SLs, and where they quietly require add-on licensing.
We loop back on gaps in the data and on findings that change the picture, before anything ships to production.
Microsoft revises the Dynamics 365 Licensing Guide monthly and logs changes in its own Appendix K. We started tracking it edition to edition from May 2026. Here's the trail so far.
The guide grew from 90 to 95 pages. One new entry: Dynamics 365 Sustainability, a standalone SaaS with its own tenant license and per-user USL. It names no Finance or Supply Chain integration, so nothing about an F&SC estate changes.
The guide's only new entry is Headless Commerce reaching General Availability, and unlike the last two editions, this one is documented to integrate directly with Finance and Supply Chain Management.
The guide grew from 89 to 90 pages. Two new Change Log entries, both Customer Insights agents in Paid Public Preview, neither touching Finance or Supply Chain Management.
Zero new Change Log entries. The one real change: Copilot Credits documentation consolidated into its own standalone guide. Everything else is copyediting.
Shorter, scannable companions to the full articles.
A quick-reference table for mapping job functions to the cheapest correct SL.
The conflict pairs auditors check first, and how to test for them yourself.
Microsoft's own recommended order of operations before your tenant's validation date hits.
If one of these is your job title, this blog is for you.
Own the license spend and need to defend it at renewal.
Need a clean SoD story before the audit committee meets.
Design security roles and get blamed when they're wrong.
Sign the Microsoft contract and want fewer surprises.
Straight answers, no "it depends" unless it genuinely depends.
No. A self-audit is a planning exercise. It doesn't replace Microsoft's own True-Up or Software Asset Management review, but it tells you what that review is likely to find, while you still have time to fix it.
At minimum annually, and after any significant role redesign, acquisition, or org restructuring. Conflicts creep back in quietly as people change teams and roles get copied.
Attach licensing lets you add F&SC at a discounted rate on top of an existing qualifying Dynamics subscription. Standalone subscription licensing has no such prerequisite, but costs more per seat. Which one applies changes your effective cost per user significantly.
Yes, and most tenants should. Mixing is exactly how you avoid overbuying. The mistake is assigning Operations-tier licenses to users who only need Team Member-level access.
Some Copilot capabilities are included in existing F&SC SLs; others are metered add-ons. We cover the current breakdown in an upcoming article. The split has shifted more than once, so treat any answer as a snapshot in time.
Reconcile your assigned licenses against actual usage before Microsoft does, document your reasoning for edge cases, and fix the obvious overassignments early. Walking in with your own numbers changes the conversation.
A short conversation usually tells us whether it's a licensing problem, a security problem, or both. Let's find out before your auditor does.
