Microsoft Defender for Endpoint (MDE) — Custom Role Design for Troubleshooting Mode–Only Access

1) Introduction

In many organisations, Security Operations (SOC) teams and Windows infrastructure crews often find themselves under pressure to investigate endpoint issues within the Microsoft Defender for Endpoint portal. However, they must also maintain a solid governance structure regarding who can alter security settings.

The Troubleshooting Mode allows for temporary changes to Defender Antivirus settings, even on devices governed by strict organisational policies, like those using Tamper Protection. Broad access to this feature can lead to configuration drift, higher operational risks, and unclear lines of accountability.

To tackle this issue, organisations typically prefer a least-privilege, scoped access model that upholds the principle of Segregation of Duties (SoD):

• Investigators (Security Reader) have visibility to investigate but cannot create or modify MDE security policies.
• Only a select group is given the minimal permissions needed to activate Troubleshooting Mode, with this access restricted to specified device groups—a strategy that helps mitigate risk and clarifies governance.

This approach allows teams to carry out necessary investigations and controlled troubleshooting while enforcing least privilege, SoD, and predictable operational impacts throughout the customer’s environment.

This document outlines a method for providing secure access to Troubleshooting Mode on a defined set of devices.

– An Entra ID user group for eligible users

– A custom Defender XDR role with strictly the necessary permissions

– Microsoft Defender for Endpoint device groups to limit where these permissions apply

The aim is to facilitate safe troubleshooting without compromising the principles of least privilege or introducing unforeseen policy changes.

2) Prerequisites & Coverage

– A group in Entra ID for eligible users

– A custom Defender XDR role with the absolute minimum permissions

– Microsoft Defender for Endpoint device groups for scoping these permissions

The purpose of this setup includes:

– Enforcing the least privilege model (only the required permissions for Troubleshooting Mode and limited operational tasks)

– Restricting powerful actions to certain device groups instead of applying them universally

– Supporting a divided model where one Security Reader group has access to Troubleshooting Mode while another operates without it

– Upholding governance: users can investigate and perform limited actions without the ability to create or modify MDE policies

– Enhancing audit capabilities by making key actions trackable through device telemetry and the Action Centre (noting that some telemetry may lack the initiating username).

3) Steps to Implement Troubleshooting Mode (TO BE PERFORMED IN MICROSOFT DEFENDER PORTAL / ENTRA ID)

3.1 Setting Up Entra ID User Group

Identify an existing Entra ID user group containing users (IT Infra Team) with the Security Reader role, or create a new dedicated group for this purpose.

– This group will consistently be used for:

– Assigning the custom Defender XDR role

– Scoping access to Defender for Endpoint device groups

3.2 Creating and Assigning Custom Defender XDR Role

Create a custom Defender XDR role that includes Microsoft Defender for Endpoint (MDE) Security Settings Management permissions.

– While creating this custom role, only select the minimal permissions required to maintain a least-privilege model.

– Assign this custom Defender XDR role to the identified Entra ID user group in Step 1.

Reference: Check out the screenshots below for guidance on role creation, permission selection, and group assignment.

3.3: Assign the Entra ID User Group to a Device Group

Now, assign the same Entra ID user group (identified in Steps 1 and 2) to a Microsoft Defender for Endpoint device group.

– Devices within this group should be dynamically organised based on criteria like:

– Device tags

– Patterns in device names

– Other supported attributes

– This ensures that custom role permissions are applicable only to the specific set of devices intended.

Reference: Check out the screenshot below for guidance on creating a device group and assigning the Entra ID group.

3.4 Resulting User Experience and Permissions

After completing Steps 3.1 to 3.3, users who log in with:

– The Security Reader role, and

– The Custom Defender XDR role

will experience the following in the Microsoft Defender portal:

– Access to Troubleshooting Mode on the specified devices

– Users cannot create or modify MDE policies

– Access only to a controlled set of operational and investigative actions, including:

– Exclude

– Go hunt

– Download the force release from isolation script

– Consult Defender Experts

This setup allows for safe troubleshooting while avoiding any configuration drift or unauthorised security policy changes.

Reference: Look at the screenshot below that illustrates the available actions and highlights the absence of options for creating or modifying policies.

Reference: See the screenshot below demonstrating that policy creation failed as the user lacks access to Intune for this purpose.

4. Alternatively, you might have two distinct Security Reader groups: one that needs access to Troubleshooting Mode and another that does not. Users in the latter can continue using standard features of Microsoft Defender for Endpoint (MDE), such as managing tags, setting device importance, running antivirus scans, collecting investigation packages, reporting inaccuracies, initiating advanced hunting, triggering policy syncs, and running automated investigations. Meanwhile, users in the Troubleshooting Mode group must also be assigned to the appropriate MDE device group to ensure their access and workflows operate smoothly.

Reference: Take a look at the screenshot below, demonstrating additional MDE capabilities available to those with access to the device group.

5: Auditing and Event Visibility

– Events related to changes in Tamper Protection and the enabling of Troubleshooting Mode get recorded in the telemetry of Microsoft Defender for Endpoint.

– These records are logged and made visible for auditing and investigation purposes.

– It’s crucial to note that the username may not appear in these specific event entries, which aligns with the current Defender auditing model. Nonetheless, the activation of Troubleshooting Mode is still logged and can be seen in the device Action Centre, confirming that the mode was activated along with the username.

Reference: See the screenshot under Step 6 showcasing the relevant audit records in the timeline of the Device Page. You can also correlate using KQL across the two Event Tables (DeviceEvents & EntraIdSignInEvents).

Below is a sample KQL query:

let TimeWindow = 10m;

let Lookback = 7d;

// Portal sign-ins (Security & Compliance Center)

let DefenderPortalSignins =

materialize(

EntraIdSignInEvents

| where Timestamp >= ago(Lookback)

| where Application == “Microsoft 365 Security and Compliance Center”

| project

SignInTime = Timestamp,

PortalUserUpn = AccountUpn,

PortalUserObjectId = AccountObjectId,

SignInIP = IPAddress,

CorrelationId

| extend TimeBucket = bin(SignInTime, TimeWindow)

);

// Tamper-related events (modify as needed)

let TamperEvents =

materialize(

DeviceEvents

| where Timestamp >= ago(Lookback)

| where ActionType has “Tamper” or ActionType == “TamperingAttempt”

| project

TamperTime = Timestamp,

DeviceId,

DeviceName,

ActionType,

AdditionalFields

| extend TimeBucket = bin(TamperTime, TimeWindow)

);

// Output rows: (UPN, TamperTime) within +/- window

TamperEvents

| join kind=inner (DefenderPortalSignins) on TimeBucket

| where abs(datetime_diff(“minute”, TamperTime, SignInTime)) <= toint(TimeWindow / 1m)

| project

PortalUserUpn,

TamperTime,

SignInTime,

DeviceName,

DeviceId,

ActionType,

SignInIP,

CorrelationId,

AdditionalFields

| order by TamperTime desc

• This query correlates by time proximity, indicating “a user logged into the portal around when a tamper event occurred.”
• It does not confirm that the portal user caused the tamper event (this requires additional audit telemetry). For attribution, “who enabled troubleshooting mode/changing settings,” one would pivot to the Defender Action Centre message to then identify the user.
• This query can be used to generate alerts via a custom detection rule and can be integrated with the Security Operations Centre through API connections.

Below is an example output from this query.

6) Summary

Option 3 facilitates a controlled experience in Troubleshooting Mode by integrating Entra ID group-based user assignments, a custom Defender XDR role with minimal permissions, and device group scoping in MDE.

With this approach, eligible users can troubleshoot only on the intended devices and perform a limited, operationally safe set of tasks, while policy creation or modification remains restricted.

Audit and investigation are well-supported through MDE telemetry and device Action Centre visibility, albeit with the known limitation that some telemetry entries might not include the initiating username.