DEV Community: cuong do

Defender for Endpoint: licensing and permissions

cuong do — Tue, 13 Oct 2026 05:19:40 +0000

My own Day 1 study notes on Defender for Endpoint, cleaned up and checked against current Microsoft Learn docs (October 2026).
Read this before you onboard the first device: most "why can't I see X" problems later come from the wrong plan or the wrong role.

All screenshots come from my own lab tenant. Names and IDs are cropped or blacked out.

1. What MDE is
2. Plans
3. Requirements to check first
4. Mixed licensing (Plan 1 and Plan 2 in one tenant)
5. Permissions
6. Summary
References (Microsoft Learn)

1. What MDE is

Microsoft Defender for Endpoint (MDE) protects, detects, investigates and responds to threats on endpoints: Windows, macOS, Linux, Android and iOS.

Capability	What it does
Behavioral sensors	Built into Windows, collect and send behavior data
Cloud security analytics	Machine learning on that data to find threats
Threat intelligence	Attacker techniques seen by Microsoft and partners
Vulnerability management	Find and fix weak software and settings
Attack surface reduction	ASR rules, network and web protection, device control
Next-generation protection	Microsoft Defender Antivirus
EDR	Investigate and respond to threats that got past prevention
Automated investigation and remediation	Fewer alerts to handle by hand
Defender Experts	Managed hunting service (paid add-on)
APIs	Automation and integration

It integrates with Defender XDR, Microsoft Sentinel, Intune and the other Defender products (Cloud, Identity, Office 365, Cloud Apps).

Source: Microsoft Defender for Endpoint overview

2. Plans

	Plan 1	Plan 2
Where you get it	Standalone, or in Microsoft 365 E3/A3	Standalone, or in Microsoft 365 E5/A5
Next-gen AV, ASR, manual response	✓	✓
EDR, advanced hunting, automated investigation		✓

Defender Vulnerability Management add-on gives extra risk-assessment features.
Microsoft Defender for Business is the version for small and medium businesses.
Servers are licensed separately: Defender for Servers Plan 1 or 2 (through Defender for Cloud), or Defender for Endpoint for Servers.

This is what the plans look like when you search the product catalog in the Microsoft 365 admin center (Marketplace). Prices are what my lab showed at the time and differ by region and agreement.

My lab used trial licenses:

MDE comes as a service plan inside bundles such as Microsoft 365 E5. You can see it, and switch it on or off per user, under Billing > Licenses > (product) > Assign licenses:

Sources: Defender for Endpoint Plan 1 overview · Defender for Business overview

3. Requirements to check first

OS: Windows 10/11, Windows Server 2012 R2 and later, Windows 365 Cloud PC, Azure Local, macOS, Linux, Android, iOS.
Hardware: the same as the OS needs. My lab rule of thumb: 2 cores and 1 GB RAM minimum, 4 of each is more comfortable.
Browser for the portal: Microsoft Edge or any modern browser.
Network: IPv4, or IPv6 with DNS64/NAT64. Devices need internet access, direct or through a proxy.
Data location: you pick the geography when the tenant is first set up. You cannot change it later, so decide it on purpose.

Source: Minimum requirements for Microsoft Defender for Endpoint

Microsoft Defender Antivirus must still be there

Defender Antivirus must be installed, even if another antivirus is the main one.
With a third-party antivirus on an onboarded device, Defender Antivirus runs in passive mode. Real-time scanning and updates keep working, but features such as cloud-delivered protection and ASR rules do not.
The ELAM driver must be enabled, or onboarding fails.
Do not disable the Defender services (WinDefend, Sense and so on) to "make room" for the other product.

Quick check on a Windows device:

Get-MpComputerStatus | Select-Object AMRunningMode, AMServiceEnabled, AntivirusEnabled, RealTimeProtectionEnabled

AMRunningMode shows Normal, Passive or EDR Block Mode.

Source: Defender Antivirus compatibility with other security products

4. Mixed licensing (Plan 1 and Plan 2 in one tenant)

Common cases:

different plans for different user groups
a Plan 2 trial for some users while the rest stay on Plan 1
a slow move from Plan 1 to Plan 2

How it works:

Mixed mode: tag devices to decide which ones get Plan 1 or Plan 2 features.
Single plan mode: one plan for every device.
Check the result in the license usage report in the Defender portal.

Limits:

Mixed mode is for client devices only, not servers.
Defender for Business does not support mixed licensing.

Source: Manage subscription settings (mixed licensing)

Three ways to tag a device

1. Manually in the portal. Open the device page, then Manage tags:

2. With the registry on the device. Set the Group value (REG_SZ) under HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging. In my lab the tag was Kiosk:

# Run as administrator. Replace Kiosk with your tag.
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging" -Name Group -Value "Kiosk"

Registry tags sync about once a day. A restart makes the device send it sooner. To remove the tag, clear the value instead of deleting the key.

3. With rules. Rule-based tags are added automatically from conditions such as device name, domain or OS.

Source: Create and manage device tags

5. Permissions

Admin roles

Whoever buys the subscription becomes Global Administrator by default.
Keep Global Administrators to a minimum. Give each person the least privileged role that does the job.
Assign roles from the user's profile, from Roles > Role assignments, or with PowerShell for many users. Export the admin list to CSV and review it regularly.

Source: Assign admin roles in Microsoft 365

Unified RBAC (URBAC)

One place in the Defender portal to manage permissions for Endpoint, Identity, Office 365 Plan 2, Cloud, Vulnerability Management, Cloud Apps and more.
New Endpoint tenants use URBAC by default since February 2025.
You need Global Administrator or Security Administrator in Entra ID to set it up.
Existing roles can be imported. You activate URBAC per workload. After that, you manage those permissions only in the Defender portal.

Source: Microsoft Defender XDR Unified RBAC

Custom roles for Endpoint

In my lab I built a "view only" role for local IT. The permission groups are: View data, Active remediation actions, Alerts investigation, Manage security settings and Live response (Basic or Advanced). Tier 1 only gets View data:

This screenshot is from the older Endpoint roles page (Settings > Endpoints > Roles). In a URBAC tenant you create the same thing under Permissions > Microsoft Defender XDR > Roles, and the permission names are grouped a little differently.

Sources: Create and manage roles for RBAC · Use RBAC in Defender for Endpoint

Device groups and a simple tier model

Use Entra ID groups plus custom roles, and limit what each role sees with device groups.

A device group is built from matching rules on name, domain, tag and OS. Here the rule uses the tag from section 4:

Each group gets its own remediation level and the Entra ID user groups that can see it. A device that matches several groups lands only in the highest-ranked one. Devices that match nothing go to Ungrouped devices (default).

Tier	Who	Example permissions
Tier 1	Local IT / security ops	View data
Tier 2	Regional security ops	View data + remediation
Tier 3	Global security experts	Full access

Source: Create and manage device groups

6. Summary

Pick the right plan first: Plan 1, Plan 2, Business, and separate server licenses.
Defender Antivirus must exist even when it is not the main antivirus.
Mixed licensing works for clients, not servers. Tags decide which plan a device gets.
Use least privilege. Plan for URBAC, custom roles and device groups early.

Next: Day 2: onboard a device, then decide who can see it

References (Microsoft Learn)

Defender for Endpoint Day 2: onboard a device, then decide who can see it

cuong do — Tue, 13 Oct 2026 04:59:22 +0000

My own Day 2 study notes on Defender for Endpoint, rewritten as a hands-on guide and checked against Microsoft Learn (October 2026).
Day 1 was about plans and licenses (MDE Day 1: licensing and permissions). Day 2 is where it gets real: a device shows up in the portal, and suddenly everyone wants to know who is allowed to touch it.

The classic Day 2 surprise: you create a nice device group for the server team, forget to assign any user group to it, and the helpdesk can still see every server. Nobody hacked anything. That is just how the default works. Let's avoid that.

All screenshots come from my own lab tenant. URLs with tenant IDs are cropped out.

TL;DR

The local script is for testing on up to 10 devices. Production gets Intune, Configuration Manager or Group Policy.
Access in MDE is two questions: what can you do (a role) and on which devices (a device group). You need both.
A device group with no user groups assigned is open to everyone who has portal access.

1. Pick how you will onboard
2. Onboard one Windows device with the local script
3. Put people in Microsoft Entra groups first
4. Create a custom role (what people can do)
5. Create device groups (on which devices)
6. Let rules tag devices for you
Day 2 checklist

1. Pick how you will onboard

Before clicking anything, decide the architecture. Microsoft groups it into four:

Architecture	Fits
Cloud-native	No on-premises management, or moving away from it. Uses Intune
Co-management	Mix of on-premises and cloud. Configuration Manager + Intune
On-premises	You want to keep using Configuration Manager or Active Directory (Group Policy)
Evaluation and local onboarding	A pilot, or a small corner with no management tools, such as a DMZ

And the tools per platform:

Platform	Tools
Windows client	Intune, Configuration Manager, Group Policy, Defender deployment tool, local script (up to 10 devices), VDI options
Windows Server	Local script, Defender for Cloud integration (needs a server plan)
macOS	Intune, JAMF and the other macOS methods
Linux server	Installer script, Ansible, Chef, Puppet, Defender for Cloud, and more (needs a server plan)
Android / iOS	Intune (iOS also has an option for unmanaged devices)

Source: Identify your architecture and select a deployment method · Get started with your deployment

2. Onboard one Windows device with the local script

The local script is the instant noodles of onboarding: perfect for one hungry lab VM at 2 a.m., not how you feed 5,000 laptops. Microsoft says it plainly: 10 devices or fewer.

In the Defender portal go to Settings > Endpoints > Onboarding.
Pick the operating system, then Deployment method: Local script (for up to 10 devices).
Select Download onboarding package.

Endpoints > Onboarding with the download button and the detection test section" width="800" height="430">

Copy the zip to the device and extract it. You get WindowsDefenderATPLocalOnboardingScript.cmd.
Open Command Prompt as administrator and run the script. Press a key when it asks.
Give it a few minutes, then find the device in Assets > Devices. Sensor health should be Active.

Run the detection test

The onboarding page gives you a one-line PowerShell command (step 2 in the screenshot above, also on the Microsoft Learn page below). Copy it from there and run it in an elevated Command Prompt on the onboarded device.

The window closes by itself. That is normal, not a crash. An alert for the device should show up in the portal in about 10 minutes, and the onboarding page shows First device detection test: Completed, like in my screenshot. The command writes into C:\test-MDATP-test, so in my lab I create that folder first.

Sources: Onboard Windows devices using a local script · Run a detection test on a newly onboarded device

Gotcha: there are two "local onboarding scripts"

My original notes linked the Microsoft Purview local script page. It looks almost the same, but it is a different package (DeviceComplianceOnboardingPackage.zip, downloaded from the Purview portal) and it onboards devices for Endpoint DLP and Insider Risk Management, not for MDE. Same 10-device advice, different product. If your device never appears in the Defender portal, check which zip you ran.

Source: Onboard Windows devices to Microsoft Purview using a local script

3. Put people in Microsoft Entra groups first

Every access decision in MDE points at Entra groups, so sort the groups out before the roles.

	What it is for
Security group	Access to resources. Members can be users, devices or service principals. Use this one for MDE
Microsoft 365 group	Collaboration (mailbox, shared files). Users only

Membership can be Assigned (you add people by hand) or Dynamic (rules add and remove users or devices from their attributes). Dynamic membership needs Microsoft Entra ID P1.

Role-assignable groups

If you want to give an Entra role (for example Security Administrator) to a group instead of to people one by one, the group must be role-assignable. The rules are strict, and they bite people who try to "just tick the box later":

You can only set it when you create the group. You can't convert an existing group, and you can't undo it.
Membership must be Assigned. No dynamic rules, and no nested groups.
Maximum 500 role-assignable groups per tenant.
Needs Entra ID P1, and at least Privileged Role Administrator to create one.
With Entra ID P2 you can put the group in PIM, so members activate the role only when they need it. Require approval for that, or a less-privileged admin could reset someone's password and activate it for them.

Sources: Learn about groups and membership · Use Microsoft Entra groups to manage role assignments · Create a role-assignable group

4. Create a custom role (what people can do)

With Microsoft Defender unified RBAC, roles live in Permissions > Microsoft Defender XDR > Roles > Create custom role. You need at least Security Administrator in Entra ID, or all Authorization permissions in unified RBAC.

The wizard asks for three things:

Permissions, in groups:
- Security operations: alerts, response, live response, file collection, email and collaboration actions
- Security posture: vulnerability management, exception and remediation handling, security baselines, Exposure Management
- Authorization and settings: roles, core security settings, detection tuning, system settings
- Data operations (preview)
Assignments: Entra security groups (or single users) and the data sources the role applies to, such as Defender for Endpoint.
Review and submit.

Two things that catch people:

A new unified RBAC role is not enforced until you activate unified RBAC for that workload. Until then the portal happily shows your role and ignores it.
The role says what, not where. For MDE, device groups still decide which devices a user can see and act on. Configure them separately.

My lab still had the older Endpoints roles page (Settings > Endpoints > Roles). The idea is the same: a role gets one or more Entra groups.

Sources: Create custom roles with Microsoft Defender unified RBAC · Permissions in unified RBAC

5. Create device groups (on which devices)

Settings > Endpoints > Permissions > Device groups > Add device group. The wizard has four steps.

General: name, description and the remediation level for automated investigation: No automated response, three "Semi" levels (approval required for all folders, non-temporary folders, or system folders), or Full remediation.

Devices: the matching rule. Conditions are device name, domain, tag and OS.

A device must match all the conditions you fill in.
Several values for the same condition work as OR. Up to 10 values per property.

Preview devices: shows up to 10 devices that match. Use it. It is much cheaper than finding out next week.

User access: the Entra groups that may see this device group. Only groups that already have an RBAC role show up here, so do step 4 first.

How ranking works

A device that matches several groups joins only the highest-ranked one (rank 1 wins). Think of it as a VIP list with one door. Devices that match nothing land in Ungrouped devices (default), which you can't delete or re-rank, but you can still set its remediation level and user access.

The default that surprises everyone

If you assign no user groups to a device group, it is visible to everyone with portal access. It is the opposite of a nightclub: no list means everybody gets in. Always assign at least one group.

Other limits: up to 2,000 device groups per tenant, and changes can take from minutes to a few hours to show everywhere.