1) Introduction
In customer environments, Security Operations (SOC) teams and Windows infrastructure teams frequently need to investigate endpoint issues in the Microsoft Defender for Endpoint portal—often under time pressure—while still preserving strong governance over who can change security controls.
Because Troubleshooting Mode can enable temporary modification of Defender Antivirus settings even when devices are governed by organizational policies (for example, when policy protections are in place using Tamper protection settings), granting this capability broadly can introduce configuration drift, increase operational risk, and blur accountability.
To address this, customers typically require a least‑privilege, scoped access model that enforces Segregation of Duties (SoD):
- Investigators (Security Reader) retain visibility and investigation capability but cannot create or modify MDE security policies.
- Only an explicitly authorized group is granted the minimum permissions required to enable Troubleshooting Mode, and that access is restricted to a defined device scope using device groups—supporting both risk reduction and clear governance.
This approach ensures teams can perform required investigations and controlled troubleshooting while maintaining least privilege, SoD, and predictable operational impact across the customer’s environment.
This document describes an approach to providing controlled access to Troubleshooting Mode on a scoped set of devices.
- An Entra ID user group to collect eligible users
- A custom Defender XDR role with only the minimum required permissions
- Microsoft Defender for Endpoint device groups to scope where those permissions apply
The goal is to enable safe troubleshooting while maintaining least privilege and preventing unintended policy changes.
2) Prerequisite & Coverage
- An Entra ID user group to collect eligible users
- A custom Defender XDR role with only the minimum required permissions
- Microsoft Defender for Endpoint device groups to scope where those permissions apply
The goal is to enable safe troubleshooting while maintaining least privilege and preventing unintended policy changes.
This setup is necessary to:
- Enforce least privilege (only the permissions needed for Troubleshooting Mode and limited operational actions)
- Scope powerful actions to a defined device group instead of all devices
- Support a split model where one Security Reader group gets Troubleshooting Mode access and another Security Reader group remains view/operate without TS Mode
- Preserve governance: users can investigate and perform limited actions but cannot create or modify MDE policies
- Improve auditability by ensuring key actions are observable via device telemetry and the Action Center (while acknowledging that some telemetry may not include the initiating username).
3) Implementation Steps for Troubleshooting Mode (TO BE PERFORMED IN MICROSOFT DEFENDER PORTAL / ENTRA ID)
3.1 Prepare Entra ID User Group
Identify an existing Entra ID user group that contains users (IT Infra Team) with the Security Reader role or create a new dedicated Entra ID user group for this purpose.
- This group will be used consistently for:
- Assigning the custom Defender XDR role
- Scoping access to Defender for Endpoint device groups
3.2 Create and Assign Custom Defender XDR Role
Create a custom Defender XDR role with Microsoft Defender for Endpoint (MDE) Security Settings Management permissions.
- While creating the custom role, select only the minimum required permissions to maintain a least-privilege model.
- Assign this custom Defender XDR role to the Entra ID user group identified in Step 1.
Reference: See screenshots below for role creation, permission selection, and Entra ID group assignment.
3.3: Assign Entra ID User Group to Device Group
Assign the same Entra ID user group (used in Steps 1 and 2) to a Microsoft Defender for Endpoint device group.
- Devices in the device group should be dynamically grouped using supported criteria such as:
- Device tags
- Device name patterns
- Other supported device attributes
- This scoping ensures that the custom role permissions apply only to the intended set of devices.
Reference: See screenshot under below showing device group creation and Entra ID group-to-device group assignment.
3.4 Resulting User Experience and Permissions
After completing Steps 3.1 through 3.3, users who sign in with:
- Security Reader role, and
- Custom Defender XDR role
will observe the following behavior in the Microsoft Defender portal:
- Troubleshooting Mode is available on the scoped devices
- Users cannot create or modify MDE policies
- Users have access only to a controlled set of operational and investigative actions, including:
- Exclude
- Go hunt
- Download force release from isolation script
- Ask Defender Experts
This configuration enables safe troubleshooting while preventing configuration drift or unauthorized security policy changes.
Reference: See screenshot under below illustrating the available actions and the absence of policy creation/modification options.
Reference: See screenshot below where creation of AV policy failed as User will not have access to Intune to create policy.
4. In an alternate scenario, two separate Security Reader groups are maintained: one group requires access to Troubleshooting Mode, while the other should have no Troubleshooting Mode access. Users in the latter group (no TS Mode requirement) can continue to use standard Microsoft Defender for Endpoint (MDE) operational capabilities such as managing tags, setting device criticality, running antivirus scans, collecting an investigation package, reporting device inaccuracy, initiating advanced hunting (Go hunt), triggering policy sync, and running automated investigations. Users in the Troubleshooting Mode-enabled Security Reader group must also be assigned to the appropriate MDE device group to ensure their device-level access and workflows continue to function as expected.
Reference: See the screenshot below, which illustrates the additional MDE capabilities available to users who also have access to the device group
5: Auditing and Event Visibility
- Events related to Tamper Protection changes and Troubleshooting Mode enablement are captured in Microsoft Defender for Endpoint telemetry.
- These events are logged and visible for audit and investigation purposes.
- The username is not recorded in these specific event entries, which is expected behavior in the current Defender auditing model. However, the activation of Troubleshooting Mode is still logged and visible in the device Action Center, which allows confirmation that the mode was enabled on the device and the username.
Reference: See screenshot under Step 6 showing the relevant audit and event records in Timeline of Device Page. Similarly ,correlate using KQL across two Event Tables (DeviceEvents & EntraIdSignInEvents).
Below is the 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-protection related events (broaden 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. It indicates “user signed into the portal around the time a tamper event happened.”
- It does not prove that the portal user caused the tamper event (that requires audit telemetry for the action). If you later want attribution (“who enabled troubleshooting mode / changed settings”), we should pivot to Defender Action Center message and then confirm the user.
- The query can be used for generating alert using custom detection rule and take this alert to Security Operations center using API integration.
Below is reference to the sample output of the query.
6) Summary
Option 3 enables a controlled Troubleshooting Mode experience by combining Entra ID group-based user assignment, a custom Defender XDR role with minimal permissions, and device group scoping in MDE.
With this approach, eligible users can troubleshoot only the intended devices and perform a limited, operationally safe set of actions, while policy creation/modification remains restricted.
Audit and investigation are supported through MDE telemetry and device Action Center visibility, with the known limitation that certain telemetry entries may not include the initiating username.
Microsoft