By the end of this you have unified role based access control active on the workloads you chose, in an order you can defend, with a role set you designed rather than inherited. You also have the three tenant-level settings that sit outside every pillar configured deliberately: incident email notifications, an alert tuning baseline, and the built-in tuning rules reviewed rather than left at whatever they default to. And you have a test that proves the scoping actually bounds an analyst, rather than a screenshot of a role that looks right.
Prerequisites
You need the Security Administrator role in Microsoft Entra ID. Creating and importing roles can also be done by a principal holding all Authorization permissions in the unified model, which is how the model delegates its own administration once it is running, but activating a workload cannot: activation requires the directory role, every time. You need at least one qualifying product licence for each workload you intend to activate, and for Microsoft Sentinel you additionally need Owner or User Access Administrator on the workspace plus Microsoft Sentinel Contributor. Reading the audit log at the end requires the View-Only Audit Logs or Audit Logs role in Exchange Online, which is a different grant from everything else on this page and is worth arranging before you need it rather than during validation. Have two test principals available who are not you: one to hold the scoped role, one to hold nothing.
Step 1: Inventory what governs the portal today
Before importing anything, write down what currently grants access, per workload, and who holds it. This is the only step with no product surface to walk through and the only one that will change the outcome. You are producing two lists. The first is every legacy role in each workload’s own permissions model, with its members. The second is every Entra directory role that grants standing in the portal, which in most estates means Global Administrator, Security Administrator, Security Operator and Security Reader, again with members.
Then write a third list, which is the one that matters: the principals your inventory cannot see. Service principals and delegated administration groups used by a partner are outside the unified model entirely and will not appear anywhere in the work that follows. Anything reaching your Sentinel workspace through Azure Resource Manager rights is governed by Azure and not by this model. Note them explicitly as out of scope now, in writing, because the failure mode of this whole exercise is finishing it and believing the resulting role list describes everyone who can act in the tenant.
Step 2: Decide the target role set and name it
Decide the roles you want before you look at the ones you have, then use the import as evidence of the gap. Four roles cover most estates and the fifth is the one people forget. A tier one analyst who triages and investigates but takes no response action. A tier two analyst who does take response actions, scoped to the estate they are responsible for. A posture owner who reads and manages vulnerability and exposure data and has nothing to do with the incident queue. A read-only auditor who can see everything and change nothing. And an authorization owner who administers the model itself, which must exist as a role rather than as a directory role somebody happens to hold.
Name them on a convention, because role names in this product family are the thing that decays first. The convention this sheet uses is XDR-<Function>-<Scope> for the role and <RoleName>-<Assignment> for each assignment inside it, with Entra security groups named SG-XDR-<Function>-<Scope>. So XDR-SecOpsT1-EMEA is assigned to SG-XDR-SecOpsT1-EMEA through an assignment named XDR-SecOpsT1-EMEA-Endpoint. The scope token is what makes an access review tractable: a reviewer reading a list of role names can tell which ones are regional without opening any of them. Assign to plain Entra security groups and not to individual users; nested and mail-enabled group behaviour is not documented for this model, so do not build a design that depends on it.
Step 3: Import the legacy roles
Import before activating. In the Defender portal, open Permissions, then under Microsoft Defender XDR open Roles, and select Import role. The control is singular even though it imports a set. Choose the workload, then either all of its roles or individual ones. What arrives is a copy: permissions and user assignments carried over with parity, marked Imported in the description, and editable without any effect on the original. Microsoft is explicit that editing an imported role does not change the role it came from, which is what makes this safe to do before you have decided anything.
Two behaviours to know before you start. Importing the same role twice creates a duplicate rather than updating the first copy, so import once and edit in place. And any role whose membership includes a user or group that no longer exists in Entra ID lands in Roles not eligible for import. That bucket has exactly one documented cause, which is the orphaned principal, and exactly one remedy, which is to clean up the membership in the original model and import again. Do not read anything else into it; it is not a permission parity failure.
The Imported tag is your working record and it disappears the first time you edit a role. If you want to keep the distinction between what you inherited and what you designed, either export the list before you start editing or keep the imported copies untouched and build your target roles new alongside them. I do the latter, then delete the imported set once the target roles are proven, because it leaves a clean before and after rather than a set of roles halfway between two designs.
Step 4: Build the target roles
From the same Roles page, select Create custom role. The wizard runs Basics, then Choose permissions, then Assign users and data sources, then a review before you submit.
On Choose permissions you pick per permission group, and each group offers the same three choices. The choice matters more than it looks.
| Setting | Value | Why |
|---|---|---|
| Permission selection, per group | All read-only permissions | Future permissions added to that category are assigned to this role automatically. Correct for an auditor role, where the intent is genuinely everything readable. |
| Permission selection, per group | All read and manage permissions | Same automatic inheritance, applied to capability rather than visibility. Use only where you mean it, because a capability Microsoft ships next quarter lands on this role without a change request. |
| Permission selection, per group | Select custom permissions | No inheritance. New permissions in the category do not reach this role, and you must reassign deliberately to pick them up. Correct for every operational role, and the reason your review cycle needs a standing item to check for new permissions. |
That inheritance behaviour is the single most consequential setting on this page and it is stated plainly in the documentation rather than hidden. An all-read-and-manage selection is a standing instruction to grant this role whatever Microsoft invents next in that category. For a tier two analyst role that is how you end up, two years later, with a role that can do things nobody approved. For a read-only auditor it is exactly right, because the intent is stable and the risk of a new read permission is close to nothing.
On Assign users and data sources, select Add assignment and complete four fields. The worked example below is the regional tier one analyst, which is the role that proves the whole model because it is the one where a mistake is invisible until somebody uses it.
| Setting | Value | Why |
|---|---|---|
| Assignment name | XDR-SecOpsT1-EMEA-Endpoint | Names the role, the scope and the workload, so the assignment is self-describing in a review that lists assignments rather than roles. |
| Employees | SG-XDR-SecOpsT1-EMEA | A plain Entra security group. Membership is then managed by the identity process that already exists rather than in the security portal. |
| Data sources | Defender for Endpoint only | The analyst holds no function at all over mail, identity or cloud apps. This is the dimension people skip, and skipping it is how a regional endpoint role quietly becomes a tenant-wide one. |
| Include future data sources automatically | Cleared | A new workload arriving in the tenant should not silently extend an existing analyst’s reach. Leave this set only on the auditor role, where inheriting visibility is the point. |
| Data collections | None | Sentinel workspaces are assigned separately and deliberately. An endpoint triage role has no reason to hold workspace data access. |
Device group scoping for endpoint is set on the endpoint side rather than in this wizard, and it is the second half of the same decision. A role scoped to the endpoint data source but to every device group is not a regional role. Pair the two before you call the role finished.
Step 5: Activate, one workload at a time, in this order
Activation is reached from the banner on the Roles page with Activate workloads, or from Workload settings at the top of that page. Each workload has a toggle, and you confirm. Sentinel is different: it activates per workspace, through View Workspaces.
Order by how much you can afford to be wrong, and respect the one hard dependency.
| Setting | Value | Why |
|---|---|---|
| First | Defender Vulnerability Management, or Defender for Identity | Smallest operational blast radius. A wrong permission here delays posture work; it does not stop an analyst containing a device during an incident. |
| Second | Defender for Endpoint | The largest population of roles and the workload where device group scoping has to be proven. Activate it when you have already watched the model behave once. |
| Third | Defender for Office 365 | Gates the next line. Also the workload where legacy mail and collaboration role groups are most likely to be holding permissions somebody granted years ago. |
| Fourth | Exchange Online permissions | Microsoft states the dependency outright: to activate Exchange Online permissions in the unified model, Defender for Office 365 permissions must be active. Sequenced the other way, this step simply cannot be done. |
| Fifth | Microsoft Sentinel, per workspace | Needs its own Azure-side prerequisites, and Azure Resource Manager rights continue to apply alongside the unified model, so this is the one where the resulting access is decided by two systems. |
| Not applicable | Defender for Cloud, Microsoft Security Exposure Management | Active by default with no toggle. Creating a custom role holding an exposure management permission takes effect immediately on the assigned users, with no activation step to gate it. |
The failure mode to watch for after each activation is not an error. It is silence: the workload activates, nobody reports anything, and three days later somebody cannot do something they used to do. Activate at the start of a working day, tell the affected team you have done it, and give it a day before the next one. Rolling back is a toggle, and the point of doing one workload at a time is that you always know which change caused what.
Step 6: Incident email notification rules
This is a tenant-level setting that belongs to no pillar and it is routinely left at nothing, which means the platform’s correlated incidents reach a queue nobody is watching out of hours. Open Settings, then Microsoft Defender XDR, then Email notifications under General, and on the Incidents tab select Add incident notification rule. The wizard runs Basics, Notification settings, Recipients, Review rule, and finishes on Create rule. You need the Manage security settings permission, and if you are scoped to device groups you can only build rules for the groups you manage.
| Setting | Value | Why |
|---|---|---|
| Alert severity | High and Medium | Informational and Low on a correlated incident queue produce a volume that trains people to ignore the sender, which is worse than having no rule. |
| Device group scope | The groups that team owns | Regional teams get their own rule. One tenant-wide rule to a shared mailbox is the arrangement that looks configured and delivers nothing actionable. |
| Send only one notification per incident | Selected | Incidents are living objects and evidence keeps arriving. Without this, one incident generates mail every time the correlation engine adds to it. |
| Include organization name in the email | Selected | Only matters if the recipient covers more than one tenant, which is true of every managed service arrangement and of most people who have ever done incident response. |
| Include tenant-specific portal link | Selected | Removes the step where a responder lands in the wrong tenant’s portal at two in the morning and cannot find the incident. |
On Recipients, add each address individually and use Send test email before you finish, because that is the only proof available that the rule reaches a human. Microsoft documents no maximum number of rules, recipients or device groups, so treat the absence of a cap as undocumented rather than as permission to build fifty rules. Deleting a rule is permanent and there is no undo.
Step 7: The alert tuning baseline
Alert tuning is reached at Settings, Microsoft Defender XDR, Alert tuning, and rules are created with Add new rule or from an alert with Tune alert. A rule selects service sources, then builds conditions on evidence such as files, processes, scheduled tasks, scripts and management instrumentation events, with Equals or Contains, wildcards, and grouping. Then it takes one of three actions, and the actions are not equally available.
| Setting | Value | Why |
|---|---|---|
| Action | Hide alert | Suppresses the alert and prevents incident creation, and the alert still lands in the AlertInfo and AlertEvidence tables so it remains huntable. Defender for Endpoint alerts only. |
| Action | Resolve alert | Auto-resolves the alert and its related incidents, which are triggered with resolved status. The alert and the incident both exist, which is the audit-friendly option. |
| Action | Set as behavior | Converts matching signals into behaviors: no alert queue entry, no incident, data retained in BehaviorInfo and BehaviorEntities for hunting. Not supported for Defender for Cloud or Defender for Office 365 alerts. |
The permission for this is now documented, and it is worth knowing because it is newer than most published guidance. The unified permission is Detection tuning (manage), in the Authorization and settings group, and it covers alert tuning, custom detections and threat indicators of compromise together. It exists specifically so that an analyst can be granted those three without receiving the whole settings permission, which was renamed from Security settings to Core security settings in the same change. Several current Microsoft pages, including the custom detections article, still name the old permission. Grant Detection tuning, not the broader one, and expect the documentation to disagree with itself for a while. What Microsoft still does not publish is a per-workload table of which services are generally available for tuning and which are in preview, so do not plan around one.
The part that needs a decision rather than a setting is the built-in rules, generally available since April 2026, which suppress common benign activity in endpoint and Office 365 without affecting automated investigation and response or email notifications. They are on, they are individually disableable on the same page, and Microsoft names exactly one of them in documentation. Review the live list rather than assuming its contents. If you run the Security Copilot Phishing Triage Agent, or the Security Alert Triage Agent that extends it beyond mail, there is a hard conflict to resolve: the agents do not triage alerts that tuning has suppressed. Microsoft’s instruction is to disable the built-in rule named Auto-Resolve - Email reported by user as malware or phish and any custom tuning rules that suppress the same alert. A tenant that runs the agent and leaves the rule enabled has bought an agent that silently skips the alerts it was bought for.
Step 8: The programmatic equivalent, and its limits
State the boundary before writing any code. Of everything on this page, only role definitions and role assignments have a documented programmatic surface. Workload activation, incident notification rules and alert tuning have none: Microsoft documents no interface for any of them, in Graph or PowerShell, so those three are portal work and there is no infrastructure as code story to tell about them. Treat that as “Microsoft documents no interface” rather than as a positive statement that none exists.
The role surface is Microsoft Graph beta only. The Defender provider is absent from version 1.0, which supports only the directory and entitlement management providers, and the beta endpoints carry the standard warning that they are subject to change and are not supported in production applications. Build your roles in the portal, treat the portal as the system of record, and use the code below to read them back and to reproduce them in a second tenant.
There is one further constraint that shapes the whole approach. Microsoft publishes no catalogue of the action strings this provider uses. The permissions documentation describes them only as display names in read and manage tables, and the strings themselves appear nowhere in the public documentation set. So the only reliable way to obtain them is to create the role once in the portal and read it back.
# Harvest the action strings from a role you built in the portal.
# Prerequisite: Microsoft.Graph module, and admin consent for the scope below.
$ErrorActionPreference = 'Stop'
Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Defender"
# Assert you are in the tenant you think you are in, before anything else.
$ctx = Get-MgContext
if ($ctx.TenantId -ne '') { throw "Wrong tenant: $($ctx.TenantId)" }
$defs = Invoke-MgGraphRequest -Method GET `
-Uri "https://graph.microsoft.com/beta/roleManagement/defender/roleDefinitions"
$defs.value |
Where-Object { $_.displayName -like 'XDR-*' } |
ForEach-Object {
[pscustomobject]@{
Name = $_.displayName
Actions = ($_.rolePermissions.allowedResourceActions -join "`n")
}
} | Format-List Expected result: one block per role, each listing its allowed resource actions as strings. Those strings are what you commit to source control and what a second tenant is built from. Failure mode to watch for: a successful connection that returns an empty collection. That is not an empty tenant, it is almost always a consent problem, because RoleManagement.ReadWrite.Defender requires admin consent and a delegated session that has not been consented returns nothing rather than an authorization error. Check the consent before you conclude there are no roles.
When you create an assignment programmatically, the workload identifiers are the ones the Defender provider defines rather than product names: Mde, Mdo, Mdi, Mda, Mdc and SecureScoreExternal, with / meaning all workloads including future ones. That last value is the programmatic equivalent of the include-future-data-sources checkbox from step 4, and it deserves the same suspicion: it is the right answer for an auditor role and the wrong one everywhere else.
Two documentation defects will confuse you if you read the reference pages closely, and both are Microsoft’s rather than yours. The write scope RoleManagement.ReadWrite.Defender carries the read-only scope’s description in the permissions reference. And the Defender role assignment example is introduced with a sentence about creating Intune role assignments. Neither affects behaviour. Do not reproduce either in your own documentation.
Step 9: Validation
Validate the model, not the configuration. A role that looks correct on screen proves nothing; what you need is evidence that the scoping bounds somebody. Build a small matrix and walk it with a real principal: for each target role, one action it should be able to perform, one action inside its workload it should not, and one action in a workload it holds nothing over. Three cells per role, and the second and third are the ones that fail interestingly.
Then confirm the changes were recorded. Unified role changes are audited, and the searchable operations in the unified audit log are AddRole, EditRole and DeleteRole rather than the prose description that appears in the auditing documentation. Two things are worth knowing before you go looking. The audit search needs the Exchange Online audit role named in the prerequisites, and incident notification rule changes are not documented as audited at all, so do not expect to find them and do not claim in a control document that they are covered.
The end-to-end test
One test, run with a real second principal, that exercises the model and the settings together.
Add your test principal to SG-XDR-SecOpsT1-EMEA and have them sign in to the portal. Confirm three things in order. They can open incidents and alerts for devices in the EMEA device group. They cannot see any device outside it. They have no response actions available anywhere, which is the assertion that proves the permission selection rather than the scoping. Then, from a principal holding no role at all, confirm the portal is not usable, which proves that standing in the directory is not quietly carrying somebody.
Now prove the notification path in the same run. Use Send test email on the recipients page of the rule you built and confirm the message arrives carrying the organisation name and a tenant-specific link. Finally, search the audit log for AddRole and confirm your role creation appears with the correct actor and timestamp.
Expected result: the scoped analyst sees exactly one region and can act on nothing, the unscoped principal sees nothing, the test email arrives, and every role change you made is attributable in the audit log. If the analyst can see devices outside their region, the fault is device group scoping rather than the data source assignment, and those are configured in two different places. If they hold response actions you did not intend, you selected an all-read-and-manage option somewhere in step 4.
Rollback
Deactivating a workload is the same toggle in reverse. The workload returns to Not Active, the roles you created and edited in the unified model stop being in effect, and the previous permissions model resumes governing that workload. Roles are not deleted by deactivation, so a rollback followed by a second attempt does not mean rebuilding them. This is genuinely per workload, which is why step 5 activates one at a time.
Do not treat that as permanently available. Microsoft’s step by step guidance for the Office 365 workload states that the ability to deactivate will be removed in a future update, with no date given, and the main activation page says nothing about it. Plan the work as though the undo exists, because today it does, and do not build an operating model whose safety depends on it still existing next year.
Completion checklist
The inventory from step 1 exists in writing, including the named list of principals this model does not govern. The target role set is designed and named on a convention, and every operational role uses custom permission selection rather than an all-read-and-manage option. Imported roles are either deleted or clearly distinguished from the roles you designed. Workloads are activated in the chosen order, with Office 365 before Exchange Online, and each activation was announced to the team it affects. Defender for Cloud and exposure management are confirmed as already active rather than assumed. At least one incident notification rule exists per responsible team and each has had a test email delivered. The built-in alert tuning list has been reviewed rather than accepted, and if either triage agent is running, the conflicting rule is disabled. The role test matrix has been walked with a real principal and the results written down. Role changes are visible in the audit log.
One item to schedule rather than tick: every role built with custom permission selection is frozen against a catalogue Microsoft keeps extending, so a standing review item is needed to check for new permissions in the categories those roles use. That is the cost of not taking the inheriting option, and it is the right cost to pay.
Authority is now settled and auditable, which means the next question can be asked properly: what is allowed to act in this tenant without asking anyone, and what happens on 1 September 2026 to the half of that machinery that currently asks permission. That is the response fabric.
Defender XDR
‹ Previous: [D 7.1] Authority in One Portal: Unified RBAC and the Three Tiers of Control
Next: [D 7.2] The Response Fabric: Incidents, Attack Disruption, and the End of AIR ›
