Ask a security team who can isolate a device and you get a name. Ask them to prove it and you get a pause, then a list of places to go and look. In a brownfield tenant the honest answer is that the permission lives in one of two models, that which one depends on the workload, and that nobody has written down which is which. This is the least glamorous decision in the platform and the one I force earliest, because it is the only decision here that gets harder the longer it waits.
Three tiers, and each one answers a different question
Permissions in the Defender portal resolve through three layers that people habitually collapse into one. Entra ID directory roles grant standing: they say that a principal belongs in this conversation at all, and Microsoft is explicit that the portal continues to respect them after the unified model is activated. Unified role based access control grants function: what this principal may read and what it may do. Scoping grants blast radius: over which data and which slice of the estate. Standing, function, radius. A design that only reasons about the first tier produces the estate everyone has, in which a directory role is handed out because somebody needs one specific capability, and arrives carrying everything else that role has ever meant.
The function tier organises into permission groups, and the groups are a better description of a security team’s actual job titles than any role list Microsoft has shipped before. Security operations covers day to day work on incidents and advisories, with a separate category for raw mail and collaboration data because reading somebody’s mail is a different kind of act from resolving an alert. Security posture covers the posture and vulnerability management work, and now carries its own subgroup for scanning artificial intelligence code. Authorization and settings covers the people who change how the portal itself behaves. A fourth group, data operations, governs security data and advanced analytics permissions for the Sentinel data lake and is still in preview.
Scoping is where the model earns its keep, and it is two dimensions rather than one. An assignment names the data sources it covers, meaning the workloads, and the data collections, meaning Sentinel workspaces. Within endpoint, device groups narrow it further. So a regional analyst can hold real investigative function over the endpoint estate in one country and hold nothing at all over mail, and that is one assignment rather than a negotiation. There is a checkbox on the assignment to include future data sources automatically, which is the kind of small decision that quietly determines whether your permissions model still describes reality in two years or has to be rebuilt when the next workload arrives.
The Global Administrator sentence
The single most interesting thing in this model is what it does to the most powerful role in the tenant. Microsoft’s wording is worth reading twice: being a Global Administrator does not grant automatic permissions over workspaces, and it does grant the right to assign permissions, including to yourself. Authority and access have been pulled apart in the one place the industry has always fused them. The holder of the most privileged directory role can still reach anything, but not by standing there. They have to make an assignment, and the assignment is an event that appears in an audit log with an actor and a timestamp.
Global Administrator no longer means you can see it. It means you can grant yourself the ability to see it, and that grant is a visible act rather than an ambient condition.
Do not oversell it, because the same page carries the qualifier. Sentinel experiences in the Defender portal continue to respect Azure Resource Manager roles alongside the unified model, so a principal holding more in Azure than in the Defender model sees more than the Defender assignment describes. That is not a contradiction, it is the seam between two governance systems that are being stitched together, and it means an access review that reads only one of them is incomplete. If somebody has subscription level rights on the workspace, the Defender side of the model is not what is deciding their access.
What the model does not govern
The exclusions are precise and they are all the same shape: this model governs the Defender portal and stops at the edge of anything with its own administrative plane. Microsoft Purview keeps its own role based access control for data loss prevention and insider risk, which an analyst investigates inside a Defender incident and administers somewhere else entirely. Exchange Online PowerShell and Security and Compliance PowerShell continue to run on Exchange roles and mail and collaboration role groups; activating the unified model does not touch them, so a script that has been working for years keeps working and keeps being governed by a model your new design does not describe. Three Sentinel roles stay Azure managed: Playbook Operator, Automation Contributor and Workbook Contributor. Assigning permissions to a service principal, or to a delegated administration group used by a partner, is not supported in the unified model at all.
That last pair is the one that catches managed service arrangements. A partner operating your tenant through delegated administration, and any automation running as a service principal, sit outside this model by design. If your access review scope is defined as everything in the unified model, you have written a review that cannot see the two categories of principal most likely to hold standing access nobody remembers granting.
Coverage on the other side has been arriving product by product and is nearly complete: endpoint, vulnerability management, identity, Office 365 Plan 2, Defender for Cloud data in the portal, exposure management including Secure Score, cloud apps, and Sentinel per workspace including the data lake. Two of those need care. Defender for Cloud and exposure management are active by default, so they are not workloads you switch on; create a role holding an exposure management permission and it takes effect immediately. And cloud apps is in an awkward documentary state, where a release note declares worldwide availability while the newer supported workloads table still labels the row as preview. I would deploy it and I would not write it into a design document as generally available.
The asymmetry, and why it is a decision rather than a migration
New tenants have been defaulting into this model one product at a time, and the dates are the clearest evidence available of how Microsoft lands a platform change. New endpoint tenants since 16 February 2025. New identity tenants since 2 March 2025. New Office 365 Plan 2 organisations since this month, and for those organisations the legacy mail and collaboration roles page is not merely deprecated, it is absent. Anyone who tells you the unified model has been mandatory since early 2025 is generalising an endpoint specific fact, which is exactly the mistake the dates are there to prevent.
So a greenfield tenant has one model and no decision. Everything else has two, and the split runs along workload lines rather than along anything a person would design. The reason this does not get dealt with is that nothing fails while you postpone it. The legacy model keeps working. The portal keeps letting people in. What degrades is your ability to answer a question, and the question always arrives from outside the security team: an auditor asking what a named analyst can do, or an incident review asking who could have taken the action that was not taken. Answering it across two models, one of which is per product, is not a five minute exercise, and I have watched teams discover that with a deadline attached.
This is the same argument I made about endpoint security settings in the security settings management article, where two consoles render the same underlying store and the question of which one owns a setting is a governance decision rather than a preference. The shape recurs across this whole product family. Two systems that both work, no forcing function, and a slow accumulation of estate that nobody can describe in one sentence.
Reversible, for now
The usual objection to a permissions migration is that it is a one way door, and here it genuinely is not. Legacy roles can be imported before activation, arriving as copies with their permissions and user assignments carried over, tagged as imported, editable without touching the originals. Activation is per workload, so the blast radius of the change is one product at a time and you choose the order. And deactivation is the same toggle in reverse: the workload returns to Not Active, the roles you built in the unified model stop being in effect, and the previous permissions model resumes. Import, activate one workload, watch, and roll back if you were wrong.
That is the strongest argument for doing this deliberately, and it comes with a date-free warning that I would not ignore. Microsoft’s own step by step guidance for the Office 365 workload states that the ability to deactivate unified role based access control will be removed in a future update. No date, and the main activation page says nothing about it, so this is one page’s forward notice rather than a product announcement. Take it seriously anyway. The rollback that makes this safe to attempt is the thing Microsoft has told you it intends to withdraw, which means the window for treating activation as a reversible experiment is open now and is not guaranteed to be open when you get round to it.
Read alongside the new tenant defaults, the direction is not ambiguous. Every new organisation arrives in this model, product by product. The legacy model is being emptied from the front. An estate that has not activated is not holding a position, it is accumulating a debt whose interest is paid in access reviews, and the argument for scheduling it is simply that you would rather do it while the undo still exists.
The decision to make before touching anything
Import is not a plan. Importing every legacy role reproduces, inside a better model, whatever your old model had drifted into, and legacy role sets in this product family are almost always wider than anyone would design today because they were assembled one urgent request at a time. The genuine opportunity in this migration is the one nobody budgets for: deciding what the roles should be, using the import as a record of what they currently are rather than as the target state. That is a conversation with the people who hold the roles, and it takes longer than the activation does.
The other decision is order. Activation is per workload and the workloads are not equal in consequence, so sequence them by how much you can afford to be wrong. There is also one hard dependency in the ordering that is not obvious and that the build sheet treats as a gate: Exchange Online permissions cannot be activated in this model until Office 365 permissions are active. Get that the wrong way round in a plan and you discover it mid-change.
Directory role hygiene is the prerequisite underneath all of this and it belongs to identity governance rather than to this series; if standing privilege in the directory has never been addressed, the third tier of this model is decorating a problem in the first. What comes next here is the reproducible part: importing, editing, activating in a defensible order, and wiring the tenant level settings that belong to no pillar and that most tenants have never configured. That is the activation build sheet.
Defender XDR
‹ Previous: [D 7] The XDR Fabric: The Platform You Actually Own
Next: [D 7.1.1] Build Sheet: Activating Unified RBAC and Wiring the Fabric Settings ›
