Security roles, segregation of duties and cloud licensing in a same-lineage upgrade
AX 2012 introduced the same role/duty/privilege model D365 uses today — which makes this chapter about the differences beneath the shared labels: changed securables, Extensible Data Security policy status, cloud licensing consequences, the disappearance of client-side security surfaces, and what a security team can carry forward versus what it must re-derive.
What you will be able to do
Articulate precisely what is identity-mapped in the security model and what changes beneath the shared names
Explain Extensible Data Security policy behaviour in D365 and its constraints
Evaluate how cloud licensing is derived from entry-point access levels and how role design directly affects cost
Configure segregation-of-duties rules and compare the capability honestly with AX 2012's native SoD
Plan the replacement of Enterprise Portal-era external-user access patterns
Decide which security artifacts to carry forward from the upgrade and which to rebuild from business process
Introduction
Part 1 of this domain mapped the organisational skeleton — companies, hierarchies, sites, warehouses, and the mandatory remediation of virtual companies and partitions. This chapter is about who is allowed to touch that skeleton, how you prove it, and what happens to the licence bill when you get role design wrong.
What is genuinely identity-mapped
The following security artifacts carry forward structurally without requiring redesign:
What changes beneath the shared names
A privilege does not grant access in the abstract — it grants access to a specific entry point (a menu item, a web content item, or a service operation) at a specific access level (Read, Update, Create, Correct, Delete, or Invoke).
Extensible Data Security policies after upgrade
AX 2012 R2 introduced Extensible Data Security (XDS) — policy-based row-level restriction that answers "which rows can this user see" independently of the role-based "can this user use this function" question. XDS policies defined in AX 2012 carry forward by name in an in-place upgrade.
Cloud licensing: how role design becomes a cost decision
This is the change that has no AX 2012 precedent. In AX 2012, licensing was measured separately from role design: named-user types, concurrent-user models, and module-based licensing were purchased and audited independently of how security roles were built.
Segregation of duties: what carries forward and what does not
AX 2012 introduced a native segregation-of-duties engine that D365 retains without architectural change. A rule pairs a first duty with a second duty, assigns a severity, and carries free-text risk and mitigation fields. The engine enforces:
Disappeared surfaces and Enterprise Portal external-user access
AX 2012 provided several security-related tools and surfaces that are either deprecated or substantially changed in D365:
A practical security upgrade method
The security workstream on a same-lineage upgrade has a different shape from a greenfield build. The starting point is not a blank slate — it is an existing, functioning security model that has been upgraded in place. The question is what to trust and what to re-derive.
Knowledge check
Summary
AX 2012's security model is identity-mapped to D365 at the framework level — roles, duties, privileges, segregation-of-duties rules, and XDS policies all carry forward by name. This is the chapter's good news, and it is more good news than any foreign-ERP migration enjoys.