Week 40 · 28 Sep – 4 Oct 2026

View the device details

From the devices list, select a device.

Select the Device details tab.

Select Devices > All devices > select one of your listed devices to open its details:

Tip

Overview shows the device name, and lists some key properties of the device, like whether it's a personal or corporate device, serial number, primary user, and more. Depending on the device platform, you can perform different actions. For more information, see Use remote actions to manage devices using Intune.

To change editable settings—such as the device name, ownership, primary user, notes, or scope tags—use the Properties tab. See Edit device properties. To find installed apps, app configuration, BitLocker recovery keys, and other information, use the navigation pane on the device page—for example, Discovered apps under Reports, or BitLocker recovery keys under Tools.

Use Properties to assign a device category you create, and change ownership of the device to a personal device, or a corporate device.

Hardware includes many details about the device, like the device ID, operating system and version, storage space, and more details.

Hardware and ~~Software~~ software inventory ~~is refreshed~~ refreshes in the Intune service every 7 seven days, starting from the date of enrollment.

Discovered apps lists all the apps that Intune found installed on the device, and the app versions. For more information, see Intune discovered apps.

§ Hardware details

Hardware details

Device compliance lists all assigned compliance policies, and if the device is compliant or not compliant.

§ Hardware details

This section lists the hardware details exposed by the device, divided into the following categories:

Device configuration shows all device configuration policies assigned to the device, and if the policy succeeded or failed.

§ System

System

Create and assign device categories in Microsoft Intune

App configuration

… 123 more changes: see the page or its history

Device Management · updated 2026-09-28 · +96 −88 words

A device category is a label you assign to a device—such as sales or accounting—to help organize the devices you manage.

What changed

# Create and assign device categories in Microsoft Intune - Microsoft Intune | Microsoft Learn

# Categorize devices into groups in Intune - Microsoft Intune | Microsoft Learn

A device category is a label you assign to a device—such as *sales* or *accounting*—to help organize the devices you manage. Device categories are separate from Microsoft Entra security groups, but you can use them together: when you create a dynamic security group based on a category, Intune automatically adds any device assigned that category to the group.

Device categories allow you to easily manage and group devices in Microsoft Intune. Create a category, such as *sales* or *accounting*, and Intune will automatically add all devices that fall within that category to the corresponding device group in Intune. To enable categories in your tenant, you must create a category in the Microsoft Intune admin center and set up dynamic Microsoft Entra security groups.

This article explains how to create device categories, build dynamic Microsoft Entra security groups from them, and assign a category to a device.

This article describes how to configure and edit device categories.

Device Actions - Wipe, Lock, Locate, and More

Device Management · updated 2026-09-28 · +1 −54 words

Rename · Changes the device name in Intune.

Changed in: Available device actions · Bulk device actions

What changed

§ Available device actions

| !rename-device-icon | Rename device | Changes the device name in Intune. |

§ Bulk device actions

| Rename device | Changes the device name in Intune. |

| ~~| [Rename device]~~ [Rename] | Changes the device name in Intune. |

Change a device's primary user in Microsoft Intune

Device Management · updated 2026-09-28 · +35 −15 words

The primary user also shows as a device property that you can view and update.

Changed in: Change the primary user

What changed

# ~~Find the~~ Change a device's primary user ~~of a~~ in Microsoft Intune ~~device.~~ - Microsoft Intune | Microsoft Learn

A primary user is the user who is primarily associated with a specific Intune device. When a device enrolls in Intune, the signed-in user typically becomes the primary user. ~~When the primary user is assigned, the~~ The primary user also shows as a device property that you can view and ~~possibly~~ update.

You change or remove a device's primary user from the device's Properties tab. This article explains how, and describes how Intune assigns the primary user and where it's used.

§ Change the primary user

## Change ~~a device's~~ the primary user

Device Action: Remove Apps and Configurations

Device Management · updated 2026-09-28 · +11 −8 words

Use the remove apps and configurations action in Intune to uninstall apps and remove configuration profiles from a device.

Changed in: Admin permissions and scope tags for Remove apps and configurations · How to remove apps and configuration from the Intune admin center · Monitoring the device action remove apps and configuration

What changed

# Device Action: Remove Apps and ~~Configuration~~ Configurations - Microsoft Intune | Microsoft Learn

Use the *remove apps and configuration* configurations* action in Intune to uninstall apps and remove configuration profiles from a device. This action is useful for troubleshooting or temporarily removing settings that might be causing issues.

§ Admin permissions and scope tags for Remove apps and configurations

#### Admin permissions and scope tags for Remove apps and ~~configuration~~ configurations

Admins can use the **Remove apps and configuration** configurations** action to:

§ How to remove apps and configuration from the Intune admin center

At the top of the device overview pane, find the row of action icons. Select **Remove data** > **Remove apps and ~~configuration**.~~ configurations**.

Removal of items such as Wi-Fi, VPN, and Certificates could impact device connectivity, if the items are ultimately used for connectivity to the Intune service. **Remove apps and configuration** configurations** is intended to be used interactively by Intune admins working with impacted users. If connectivity is lost, users might need to take actions on devices to restore connectivity; connect the device to a guest or alternate Wi-Fi or cellular network.

§ Monitoring the device action remove apps and configuration

After you initiate the **Remove *Remove apps and configuration** configurations* action on a device, the **Status** column of the **Overview** page displays the status of the action. The status is updated as the action progresses.

Intune (general) 1

Device management

Intune (general) · updated 2026-09-28 · +18 −30 words

Create and assign device categories

Changed in: Overview · Concept · How-To Guide

What changed

§ Overview

Overview

Device management overview

§ Concept

Manage devices with endpoint security

Centrally manage admin tasks

§ How-To Guide

Create and assign device categories

Categorize devices into groups

View encryption status report details

Change a device's primary user

Find the primary user of a device

Moved or renamed 3

Device Configuration 1

View report details for encryption status of devices managed with Microsoft Intune

Device Configuration · updated 2026-09-28

Use the Microsoft Intune admin center to view reports for device encryption status across macOS FileVault and Windows BitLocker encrypted devices that you manage with Microsoft Intune.

Moved from intune/device-management/monitor-encryption. The old URL now redirects here.

Device Management 1

Rename a device in Microsoft IntuneRewritten

Device Management · updated 2026-09-28 · +323 −525 words

Learn how to rename a single managed device or rename devices in bulk from the Microsoft Intune admin center, including platform-specific naming rules.

Renaming a device changes the Device name displayed in the Microsoft Intune admin center.

Most of this page changed, so the overview below lists its sections instead of every edit.

New sections: Supported platforms · Rename a single device · Bulk rename devices
Removed sections: Prerequisites · How to rename a device from the Intune admin center · How to bulk rename devices from the Intune admin center
Changed sections: Reference links

Moved from intune/device-management/actions/rename. The old URL now redirects here.

Show full diff

# ~~Device Action:~~ Rename ~~Device~~ a device in Microsoft Intune - Microsoft Intune | Microsoft Learn

Renaming a device changes the Device name displayed in the Microsoft Intune admin center. It doesn't affect the *Management name* in Intune or the *Device name* shown in the Company Portal. Renaming helps you keep names consistent across your inventory—for example, aligning names with asset tags, user roles, or location-based identifiers.

The *rename device* action in Microsoft Intune allows IT administrators to change the *Device name* displayed in the Intune admin center for a managed device. This action does not affect the *Management name* in Intune or the *Device name* shown in the Company Portal.

You rename a single device from its Properties tab, or rename multiple devices at once by using Bulk Device Actions.

Renaming a device can help improve clarity and consistency across your device inventory—especially in environments with shared devices, standardized naming conventions, or large-scale deployments. It's useful for aligning device names with asset tags, user roles, or location-based identifiers, making it easier to manage and troubleshoot devices at scale.

Supported platforms

Rename is supported on:

Renaming Android Enterprise devices only changes the Device name in the Intune admin center and not on the device itself. The Device name in Intune is a friendly name that users can change.

Android Enterprise corporate-owned Fully Managed (COBO), Dedicated (COSU), and Corporate-Owned Work Profile (COPE)

Note

iOS/iPadOS in Supervised mode

macOS (corporate-owned)

Prerequisites

Windows (corporate-owned)

![](../../media/icons/16/devices.svg)Device platform requirements

> > This action supports the following platforms: > > - Android Enterprise corporate-owned Fully Managed (COBO) > - Android Enterprise corporate-owned Dedicated (COSU) > - Android Enterprise corporate-owned Work Profile (COPE) > - iOS/iPadOS in Supervised Mode > - macOS (corporate-owned) > - Windows (corporate-owned) >

Android Enterprise: Renaming changes only the Device name in the admin center, not the name on the device. This friendly name is one that users can change. It can take 10 minutes or more for a renamed device to update in the Devices list.

![](../../media/icons/16/rbac.svg)Roles requirements

- **Windows**: Renaming Microsoft Entra hybrid joined devices from Intune ~~is not~~ isn't supported. To rename hybrid joined devices, use domain-based methods outside of Intune.

> > To run this action, use an account with at least one of the following roles: > > - Help Desk Operator > - School Administrator > - Custom rolethat includes: > - The permission Remote tasks/Set device name > - Permissions that provide visibility into and access to managed devices in Intune (for example, Organization/Read, Managed devices/Read) >

§ How to rename a device from the Intune admin center

- **iOS/iPadOS**: If you ~~have~~ use an ~~iOS~~ enrollment profile with a Device Name Template, the device ~~will be~~ is renamed but ~~will revert~~ reverts to the template after the next sync with Intune.

How to rename a device from the Intune admin center

§ Rename a single device

Rename a single device

In Sign in to the [Microsoft Intune admin ~~center],~~ center] and select [**Devices**] > [**All devices**].

§ How to rename a device from the Intune admin center

At the top of the device overview pane, find the row of action icons. Select Rename device.

… 30 more changes: see the page or its history

Governance 1

Centrally manage Admin Tasks

Governance · updated 2026-09-28

Centrally manage admin tasks in Microsoft Intune. Use the unified Admin tasks view to organize and act on administrative tasks from Device Offboarding, Endpoint Privilege Management, and more.

Moved from intune/device-management/admin-tasks. The old URL now redirects here.

Bulk edits (1) · the same change on many pages

Same kind of change on 18 pages

3 variants of one edit · Device Management

Adds Secure > · 8 pages
§ How to remove a passcode from the Intune admin center
At the top of the device overview pane, find the row of action icons. Select **Secure** > **Remove passcode**.
- Device Action: BitLocker Key Rotation Device Management
- Device Action: Disable Activation Lock Device Management
- Device Action: Remote Lock Device Management
- Device Action: Remove Passcode Device Management
- Device Action: Reset Passcode Device Management
- Device Action: Rotate FileVault Recovery Key Device Management
- Device Action: Rotate local admin password Device Management
- Device Action: Rotate Recovery Lock Passcode Device Management
Adds Remote actions > · 6 pages
§ How to suspend the managed home screen from the Intune admin center
At the top of the device overview pane, find the row of action icons. Select **Remote actions** > **Suspend Managed Home Screen**.
- Device Action: Logout Current User Device Management
- Device Action: Pause Config Refresh Device Management
- Device Action: Restart Device Management
- Device Action: Restore Managed Home Screen Device Management
- Device Action: Shutdown Device Management
- Device Action: Suspend Managed Home Screen Device Management
Adds Remove data > · 4 pages
§ How to use Autopilot reset from the Intune admin center
At the top of the device overview pane, find the row of action icons. Select **Remove data** > **Autopilot reset**.
- Device Action: Autopilot Reset Device Management
- Device Action: Fresh Start Device Management
- Device Action: Retire Device Management
- Wipe devices with Microsoft Intune Device Management

Minor changes (11) · fewer than 15 words

App Management 2

Add an Unmanaged macOS PKG App to Microsoft IntunemacOS

App Management · updated 2026-09-30 · +7 −1 words

If the app remains assigned, failed installations are retried at the next agent check-in with up to three time retries.

Changed in: Troubleshooting

What changed

§ Troubleshooting

macOS app installation may not be successful due to any of the following reasons provided in the table below. To resolve these errors, follow the remediation steps. If the app remains assigned, failed installations are retried at the next agent ~~check-in.~~ check-in with up to three time retries.

Add and Assign Managed Google Play Apps to Android Enterprise DevicesAndroid

App Management · updated 2026-09-30 · +2 −1 words

The Microsoft Intune app, Microsoft Authenticator app, and the Company Portal app are installed as required apps on all fully managed, dedicated and…

Changed in: Assign a Managed Google Play app to Android Enterprise fully managed devices

What changed

§ Assign a Managed Google Play app to Android Enterprise fully managed devices

The Microsoft Intune app, Microsoft Authenticator app, and the Company Portal app are installed as required apps on all fully ~~managed~~ managed, dedicated and corporate-owned work profile devices during onboarding. Having these apps automatically installed provides Conditional Access support, and Microsoft Intune app users can see and resolve compliance issues.

Device Management 8

Use the latest TeamViewer integration in Microsoft Intune

Device Management · updated 2026-09-28 · +8 −4 words

Select the device that needs remote assistance, and then choose Remote actions > Begin a remote assistance session.

Changed in: Remotely administer a device with TeamViewer

What changed

§ Remotely administer a device with TeamViewer

Select the device that needs remote assistance, and then choose **New Remote Assistance Session**. **Remote actions** > **Begin a remote assistance session**.

Device Action: Full Scan

Device Management · updated 2026-09-28 · +6 −1 words

Select Microsoft Defender > Run full malware scan.

Changed in: How to initiate a full scan from the Intune admin center

What changed

§ How to initiate a full scan from the Intune admin center

At the top of the device overview pane, find the row of action icons. Select **Full **Microsoft Defender** > **Run full malware scan**.

Device Action: Quick Scan

Device Management · updated 2026-09-28 · +6 −1 words

Select Microsoft Defender > Run quick malware scan.

Changed in: How to initiate a quick scan from the Intune admin center

What changed

§ How to initiate a quick scan from the Intune admin center

At the top of the device overview pane, find the row of action icons. Select **Quick **Microsoft Defender** > **Run quick malware scan**.

Device Action: Run Remediation

Device Management · updated 2026-09-28 · +2 −4 words

In the Run remediation pane, select the Script package you want to run from the list.

Changed in: How to run a remediation from the Intune admin center

What changed

§ How to run a remediation from the Intune admin center

At the top of the device overview pane, find the row of action icons. Select **Run ~~remediation (preview)**.~~ remediation**.

In the **Run remediation (preview)** remediation** pane, select the Script package you want to run from the list.

Device Action: Play Lost Mode Sound

Device Management · updated 2026-09-28 · +4 −0 words

Select Locate > Play Lost Mode sound (supervised only).

Changed in: How to play lost mode sound from the Intune admin center

What changed

§ How to play lost mode sound from the Intune admin center

At the top of the device overview pane, locate the row of action icons. Select **Locate** > **Play Lost Mode sound (supervised only)**.

At the top of the device overview pane, locate the row of action icons. Select **Locate** > **Play lost device sound**.

Device Action: Collect Diagnostics

Device Management · updated 2026-09-28 · +2 −1 words

To confirm, select Collect data.

Changed in: How to collect diagnostics from the Intune admin center

What changed

§ How to collect diagnostics from the Intune admin center

To confirm, select **Yes**. **Collect data**. A pending notification appears on the device's **Overview** page.

Device Action: Locate Device

Device Management · updated 2026-09-28 · +2 −0 words

Select Locate > Locate device.

Changed in: Locate a device

What changed

§ Locate a device

At the top of the device overview pane, find the row of action icons. Select **Locate** > **Locate device**.

Device Action: Lost Mode

Device Management · updated 2026-09-28 · +2 −0 words

Select Locate > Lost mode (supervised only).

Changed in: How to enable Lost Mode from the Intune admin center

What changed

§ How to enable Lost Mode from the Intune admin center

At the top of the device overview pane, find the row of action icons. Select **Locate** > **Lost mode (supervised only)**.

Device Security 1

Protect data and devices with Microsoft Intune

Device Security · updated 2026-09-28 · +0 −1 words

Run device actions to respond to security incidents or maintain device security.

Changed in: Use device actions to protect devices and data

What changed

§ Use device actions to protect devices and data

Run ~~immediate~~ [device actions] to respond to security incidents or maintain device security. Unlike policies that maintain ongoing configurations, device actions execute once when invoked. Actions take effect immediately for online devices, or at next check-in for offline devices. [Bulk device actions] can target multiple devices simultaneously.

12 pages were republished without text changes and are not shown.

Microsoft Defender XDR

4 what's new 2 new 14 important 3 minor

What's new, release notes and known issues 4

Troubleshooting known issuesKnown issues

Defender for Identity · updated 2026-09-29 · +62 −0 words

Compared with the previous version: 1 added

Added Sensor migration isn't supported between different Microsoft tenants
Migration from sensor v2.x to sensor v3.x isn't supported when the Defender for Identity workspace and Defender for Endpoint onboarding for the same server are associated with different Microsoft tenants. The server might appear Ready for migration, but sensor v3.x activation fails. Sensor v2.x continues reporting, and the unsuccessful migration eventually rolls back.
Open on Learn ·

Show full page diff

§ Sensor migration isn't supported between different Microsoft tenants

Sensor migration isn't supported between different Microsoft tenants

Migration from sensor v2.x to sensor v3.x isn't supported when the Defender for Identity workspace and Defender for Endpoint onboarding for the same server are associated with different Microsoft tenants. The server might appear Ready for migration, but sensor v3.x activation fails. Sensor v2.x continues reporting, and the unsuccessful migration eventually rolls back.

Microsoft Defender for Endpoint release notesRelease notes

Defender for Endpoint · updated 2026-09-28 · +19 −9 words

Compared with the previous version: 1 changed

Linux releases
Changed Linux | September 2026 | 101.26081.0010 › Enhancements and featuresLinux
What changed in this entry (~~removed~~ / added):
| Feature area | Update summary | | --- | --- | | Device identity | Fixed an issue where cloned Linux virtual machines could retain the source image's machine identifier, causing multiple endpoints to appear with the same Microsoft Defender for Endpoint device ~~identity.~~ identity.Each cloned endpoint is now correctly identified as a unique device. | | Bug fix | Fixed `SIGILL` crashes on systems with processors that don't support SSE4.1. ~~The crashes were caused by bundled open-source libraries.~~ | | General | Reliability and quality improvements. |
Full text as it is now
| Feature area | Update summary | | --- | --- | | Device identity | Fixed an issue where cloned Linux virtual machines could retain the source image's machine identifier, causing multiple endpoints to appear with the same Microsoft Defender for Endpoint device identity.Each cloned endpoint is now correctly identified as a unique device. | | Bug fix | Fixed SIGILL crashes on systems with processors that don't support SSE4.1. | | General | Reliability and quality improvements. |
Open on Learn ·

Show full page diff

§ Enhancements and features

Feature area	Update summary
Device identity	Fixed an issue where cloned Linux virtual machines could retain the source image's machine identifier, causing multiple endpoints to appear with the same Microsoft Defender for Endpoint device ~~identity.~~ identity.Each cloned endpoint is now correctly identified as a unique device.
Bug fix	Fixed `SIGILL` crashes on systems with processors that don't support SSE4.1. ~~The crashes were caused by bundled open-source libraries.~~
General	Reliability and quality improvements.

What's newWhat's new

Defender for Identity · updated 2026-09-29 · +247 −16 words

Compared with the previous version: 2 added 1 changed

August 2026
Added Defender for Identity sensor updates
| Version number | Updates | | --- | --- | | 2.255.19347.63719 | This sensor update includes security improvements. |
Open on Learn ·
September 2026
Added Automatic sensor v3.x activation and Windows auditing by defaultWindows
The rollout differs for new Microsoft Defender for Endpoint customers and existing Defender for Identity customers: New Microsoft Defender for Endpoint customers: If your organization is licensed for Defender for Identity, its first device was onboarded to Defender for Endpoint on or after September 13, 2026, and it doesn't already have a Defender for Identity workspace, Defender for Identity automatically creates a workspace when it identifies an eligible identity-role server. It also enables automatic sensor v3.x activation and Windows auditing by default. This flow activates the Defender for Identity sensor capability on eligible servers that are already onboarded to Defender for Endpoint. It doesn't add a separate Defender for Identity installation, activate the sensor on other Defender for Endpoint servers, or affect servers that already have a Defender for Identity sensor. Existing Defender for Identity customers: The change becomes available gradually. The Defender portal displays a notice before it enables the settings automatically. After the notice period ends, the portal enables the settings. While the notice appears, select Go to Advanced features to enable the settings or Opt out to prevent automatic enablement. The notice appears on the Sensor management tab of the On-premises settings page. For more information, see Activate the Defender for Identity sensor v3.x and Configure Windows event auditing.
Open on Learn ·
Changed Sensor v3.x support for additional identity server roles: AD CS, AD FS, and Entra Connect (Preview)
What changed in this entry (~~removed~~ / added):
Defender for Identity sensor v3.x now supports eligible AD FS, AD CS, and Microsoft Entra Connect servers that aren't domain ~~controllers. Manual activation and automatic Windows event auditing are supported. Automatic activation~~ controllers and ~~migration aren't currently supported.~~ don't have an existing Defender for Identity sensor. For more information, see [Defender for Identity sensor v3.x prerequisites].
Full text as it is now
Defender for Identity sensor v3.x now supports eligible AD FS, AD CS, and Microsoft Entra Connect servers that aren't domain controllers and don't have an existing Defender for Identity sensor. For more information, see Defender for Identity sensor v3.x prerequisites.
Open on Learn ·

Show full page diff

§ Automatic sensor v3.x activation and Windows auditing by default

Automatic sensor v3.x activation and Windows auditing by default

The rollout differs for new Microsoft Defender for Endpoint customers and existing Defender for Identity customers:

New Microsoft Defender for Endpoint customers: If your organization is licensed for Defender for Identity, its first device was onboarded to Defender for Endpoint on or after September 13, 2026, and it doesn't already have a Defender for Identity workspace, Defender for Identity automatically creates a workspace when it identifies an eligible identity-role server. It also enables automatic sensor v3.x activation and Windows auditing by default.

This flow activates the Defender for Identity sensor capability on eligible servers that are already onboarded to Defender for Endpoint. It doesn't add a separate Defender for Identity installation, activate the sensor on other Defender for Endpoint servers, or affect servers that already have a Defender for Identity sensor.

Existing Defender for Identity customers: The change becomes available gradually. The Defender portal displays a notice before it enables the settings automatically. After the notice period ends, the portal enables the settings.

While the notice appears, select Go to Advanced features to enable the settings or Opt out to prevent automatic enablement.

The notice appears on the Sensor management tab of the On-premises settings page.

For more information, see Activate the Defender for Identity sensor v3.x and Configure Windows event auditing.

§ Sensor v3.x support for additional identity server roles: AD CS, AD FS, and Entra Connect (Preview)

Defender for Identity sensor v3.x now supports eligible AD FS, AD CS, and Microsoft Entra Connect servers that aren't domain ~~controllers. Manual activation and automatic Windows event auditing are supported. Automatic activation~~ controllers and ~~migration aren't currently supported.~~ don't have an existing Defender for Identity sensor. For more information, see [Defender for Identity sensor v3.x prerequisites].

§ Defender for Identity sensor updates

Version number	Updates
2.255.19347.63719	This sensor update includes security improvements.

### Defender for Identity sensor updates

§ Microsoft Defender for Identity sensor version updates

| Version number | Updates |

New features in Microsoft Defender for EndpointWhat's new

Defender for Endpoint · updated 2026-09-29 · +64 −0 words

Compared with the previous version: 1 changed

September 2026
Changed Microsoft Defender for Endpoint plug-in support for WSL containers (WSLc)GAWindowsLinux
What changed in this entry (~~removed~~ / added):
- **Type**: Feature - **Feature**: [Microsoft Defender for Endpoint plug-in support for WSL containers (WSLc)] - **Preview/GA**: ~~Preview~~ GA - **Description**: Extend Microsoft Defender for Endpoint protection to workloads running in WSL containers (WSLc). Gain visibility into WSL container activity through device inventory, alerts, incidents, device timeline, and Advanced Hunting, helping security teams investigate and respond to threats across both Windows and Linux workloads.**Available in Public Preview. To enroll, complete the [registration form].** workloads. MDE plugin version 2.26.921.1.
Full text as it is now
Type: FeatureFeature: Microsoft Defender for Endpoint plug-in support for WSL containers (WSLc)Preview/GA: GADescription: Extend Microsoft Defender for Endpoint protection to workloads running in WSL containers (WSLc). Gain visibility into WSL container activity through device inventory, alerts, incidents, device timeline, and Advanced Hunting, helping security teams investigate and respond to threats across both Windows and Linux workloads. MDE plugin version 2.26.921.1.
Open on Learn ·

Show full page diff

§ September 2026

Type	Feature	Preview/GA	Description
Feature	Microsoft Defender for Endpoint plug-in support for WSL containers (WSLc)	GA	Extend Microsoft Defender for Endpoint protection to workloads running in WSL containers (WSLc). Gain visibility into WSL container activity through device inventory, alerts, incidents, device timeline, and Advanced Hunting, helping security teams investigate and respond to threats across both Windows and Linux workloads. MDE plugin version 2.26.921.1.

New pages 2

Determine your OAuth app security posture with app governance

Defender for Cloud Apps · updated 2026-09-29

Determine your app security posture with app governance in Microsoft Defender XDR with Microsoft Defender for Cloud Apps.

Secure OAuth apps with Microsoft Entra RBAC roles

Defender for Cloud Apps · updated 2026-09-29

Learn how to use app governance to identify and investigate Microsoft Entra roles assigned directly to service principals and assess privilege risk.

Important changes 14

Defender for Cloud Apps 5

Application inventoryRewritten

Defender for Cloud Apps · updated 2026-09-29 · +242 −671 words

At a glance, you can see information such as app name, risk score, privilege level, publisher information, and other details for easy identification of SaaS…

Most of this page changed, so the overview below lists its sections instead of every edit.

New sections: OAuth app details
Removed sections: OAuth Apps
Changed sections: Navigate to the Applications page · SaaS app details · Sort and filter the SaaS apps list · Sort and filter the OAuth apps list

Show full diff

Protecting your SaaS ecosystem requires taking inventory of all SaaS and connected OAuth apps that are in your environment. With the increasing number of applications, having a comprehensive inventory is crucial to ensure security and compliance. The Applications page provides a centralized view of all SaaS and connected OAuth apps in your organization, enabling efficient monitoring and management. ~~At a glance you can see information such as app name, risk score, privilege level, publisher information, and other details for easy identification of SaaS and OAuth apps most at risk.~~

At a glance, you can see information such as app name, risk score, privilege level, publisher information, and other details for easy identification of SaaS and OAuth apps most at risk.

- OAuth apps: A comprehensive view of OAuth apps registered on Microsoft Entra ID, Google ~~workspace~~ Workspace, and Salesforce. This tab highlights OAuth ~~apps~~ app metadata, publisher ~~info and~~ information, app origin, permissions used, data ~~accessed~~ accessed, and other insights.

§ Navigate to the Applications page

- Apply ~~filters~~ filters.

§ SaaS app details

At the top of ~~Saas app~~ the SaaS apps tab, you can find actionable insights that allow you to quickly identify apps that need your ~~attention and focus.~~ attention. The following details are displayed:

- **Untagged ~~high risk~~ high-risk apps** – - Shows apps that aren't tagged and have a ~~high-risk.~~ high risk score.

- **Untagged ~~high traffic~~ high-traffic apps** – - Shows apps that aren't tagged and have a high usage traffic (greater than 1 GB of data traffic).

- **Untagged GenAI apps** – - Shows apps that aren't tagged and are ~~Gen-AI based.~~ based on generative AI.

You can use the sort and filter functionality to get a more focused view. These controls also help you assess and manage the SaaS applications in your organization.

Use sorting and filtering to focus the SaaS apps list on the applications you want to assess and manage. For filter descriptions and query options, see Filter and query discovered apps.

| Filter | Description |

OAuth app details

Filter	Description
App tags	Select Sanctioned, Unsanctioned, or create custom tags to use in a customized filter.

The OAuth apps tab provides visibility into OAuth apps from Microsoft ~~365, Google workspace~~ Entra ID, Salesforce, and ~~Salesforce.~~ Google Workspace. Admins can review applications and decide to disable the apps or apply policies to monitor their behavior in their environment.

Filter	Description
App	Filter for specific SaaS apps.

The OAuth app inventory includes the following app types:

Filter	Description
Categories	Filter according to app categories.

Entra ID: Service principals registered in Microsoft Entra ID. These apps access resources through API permissions or Microsoft Entra role assignments.

Filter	Description
Compliance risk factor	Filter for specific standards, certifications, and compliance your app might comply with. For example: HIPAA, ISO 27001, SOC 2, and PCI-DSS.

Salesforce: OAuth apps connected through Salesforce. The inventory includes both Connected Apps and External Client Apps (ECAs).

Filter	Description
Risk score	Filter by a specific risk score, such as to view only risky apps.

Google Workspace: OAuth apps connected through Google Workspace. Users authorize these apps, which have varying levels of access to Google Workspace resources.

Filter	Description
Security risk factor	Filter based on specific security measures, such as encryption at rest, multifactor authentication, and others.

§ OAuth Apps

OAuth Apps

§ Risk management based app policy templates

Insight	Description	Available for
Highly privileged apps	Apps with powerful permissions that allow them to access data or change important settings. For Salesforce, includes Connected Apps and External Client Apps (ECAs) whose granted permissions are classified as High.	Microsoft 365, Google Workspace, Salesforce ~~(Preview)~~

… 30 more changes: see the page or its history

Create and manage OAuth app policies with app governanceNew setting

Defender for Cloud Apps · updated 2026-09-29 · +119 −190 words

App policy templates are grouped into these categories: Usage, Permissions, Risk management, and Certification.

Changed in: App policy templates · Risk management based app policy templates · Certification-based app policy templates +5 more

What changed

§ App policy templates

App policy templates are grouped into these categories: Usage, Permissions, Risk management, and Certification.

Risk management based app policy templates

The following table lists the app governance templates supported to generate alerts ~~for~~ based on app ~~usage.~~ risk.

Template name	Description
New high risk app	Find newly registered apps that have a high risk. This policy checks the following conditions: <br>- Registration age: Seven days or less (customizable)<br>- Risk score: Greater than 70 (customizable)

§ Certification-based app policy templates

| Template name | Description |

§ Create custom OAuth app policies

Condition	Condition values accepted	Description	More information
Risk score	Greater than X	Apps with a risk score greater than the specified value

Audit mode: Policies are evaluated but configured actions won't occur. Audit mode policies appear with the status of Audit in the list of policies. You should use Audit mode for testing a new policy.

§ Monitor your new app policy

If the number of alerts is an unexpectedly low value, edit the settings of the app policy to ensure you've configured it correctly before setting the policy status.

## ~~Test and monitor~~ Monitor your new app policy

§ Monitor your new app policy

Here's an example of a process for creating a new policy, testing it, and then making it active:

~~Now that your app policy is created,~~ After you ~~should~~ create an app policy, monitor it on the **Policies** page to ~~ensure it's registering an~~ confirm that it generates the expected number of active ~~alerts~~ and total ~~alerts during testing.~~ alerts.

§ Monitor your new app policy

Create the new policy with severity, apps, conditions, and actions set to initial values and the status set to Audit mode.

Check for expected behavior, such as alerts generated.

If the number of alerts is unexpectedly low, review and update the app policy settings.

§ Create a new policy for OAuth apps connected to Salesforce and Google Workspace

If the behavior isn't expected, edit the policy apps, conditions, and action settings as needed and go back to step 2.

If the behavior is expected, edit the policy and change its status to Active.

For example, the following flow chart shows the steps involved:

In Microsoft Defender XDR, go to Cloud Apps > App governance > Policies > Other apps. For example:

Go to Microsoft Defender XDR > App governance > Policies > Other apps. For example:

§ Edit an app policy configuration

![Screenshot of the Edit policy pane for a user-defined app policy in App Governance.](media/app-governance-app-policies-manage/edit-user-defined-policy.png#lightbox)

View your OAuth app details with app governancePreview

Defender for Cloud Apps · updated 2026-09-29 · +127 −87 words

By default, the app governance page sorts the grid alphabetically, by Display name.

Changed in: View the apps in your tenant · Review risk details on the Risk score tab · Review app permissions on the Permissions tab +3 more

What changed

§ View the apps in your tenant

By default, the app governance page sorts the grid alphabetically, by **App **Display name**. To sort the list by another attribute, select the column name. You can also select **Search** to search for an app by name.

Column name	Description
App Display name**	The display name of the app as registered on Microsoft Entra ID
~~App status~~ Status	Shows whether the app is enabled or disabled, and if disabled by whom
Risk score	Shows the identity risk score (1-100). Higher values indicate greater risk.
~~App origin~~ Origin	Shows whether the app originated within the tenant or was registered in an external tenant
Used by AI Agents (Preview)	Shows the AI agents that use this identity to authenticate and access Microsoft 365 resources. If the value is N/A, agent details are unavailable, but the identity might still be used by AI agents.
Community use	Shows how popular the app is ~~across~~ among all your users (common, uncommon, rare)

§ Review risk details on the Risk score tab

The Risk score tab is available only for OAuth apps registered in Microsoft Entra ID.

§ Review app permissions on the Permissions tab

Note

§ Manage Google Workspace and Salesforce OAuth apps

~~If you enable~~ Enable the [Google Workspace] or [Salesforce] ~~connector, you can use the **App governance** page~~ connector to view ~~information about~~ connected app permissions ~~in apps connected to Google Workspace~~ on the **App governance** page. For Salesforce, the inventory includes both Connected Apps and ~~Salesforce.~~ External Client Apps (ECAs). You can view the permissions granted to each app and revoke or block apps as needed.

§ View Google Workspace and Salesforce OAuth app details

### View Google ~~Workforce~~ Workspace and Salesforce OAuth app details

Column name	Description
Last used	The most recent date on which this app was used by anyone in your organization. ~~This information is available for Salesforce only.~~

§ View Google Workforce and Salesforce OAuth app details

Column name	Description
Last authorized	The most recent date on which a user granted permissions to this app. This information is available for Salesforce only.

§ View Google Workspace and Salesforce OAuth app details

Column name	Description
Risk score	The app's risk score from 1 through 100. Higher values indicate greater risk.
Permissions	A list of all permissions currently granted to the app. ~~Available for Google Workspace and Salesforce (Preview).~~
Community use	~~Common, Uncommon, Rare.~~ Common, Uncommon, or Rare. Indicates how popular the app is ~~across~~ among all your users.
Last used	The most recent date on which this app was used by anyone in your organization.

App governance in Microsoft Defender for Cloud Apps and Microsoft Defender XDR

Defender for Cloud Apps · updated 2026-09-29 · +11 −14 words

To understand the potential risks and stop these types of attacks, you need clear visibility into your organization's app security posture.

Changed in: Share data between Microsoft services

What changed

To understand the potential risks and stop these types of attacks, you need ~~to gain~~ clear visibility into your organization's app ~~compliance~~ security posture. You need to ~~be able to~~ quickly identify when an app exhibits anomalous behaviors and respond when these behaviors present risks to your environment, data, and users.

§ Share data between Microsoft services

## Share data ~~across~~ between Microsoft services

- On the **App governance** page, view app details and aggregated ~~sign-in activity for each app.~~ data and permission usage. Select an app to view details in a side pane, and select **View in Azure AD** Entra ID** to view more details in the Microsoft Entra admin center.

OAuth app visibility and insights with app governance

Defender for Cloud Apps · updated 2026-09-29 · +14 −1 words

Usage of top resources, such as emails and files throughout the tenant.

Changed in: Visibility and insight scope · What's available on the Overview tab · View app insights

What changed

§ Visibility and insight scope

- Usage of top resources, such as emails and files ~~across~~ throughout the tenant.

§ What's available on the Overview tab

Dashboard element	Description
App categories	The top apps sorted by these categories: - All categories: Sorts by all available categories. - Highly privileged: High privilege is an internally determined category based on platform machine learning and signals. - Risky apps: Apps with a high risk score. - Overprivileged: When app governance receives data that indicates that a permission granted to an application hasn't been used in the last 90 days, that application is overprivileged. App governance must be operating for at least 90 days to determine if any app is overprivileged. - Unused: Apps that have not signed in within the last 90 days - Unverified publisher: Applications that haven't received [publisher certification] are considered unverified. - App only permissions: [Application permissions] are used by apps that can run without a signed-in user present. Apps with permissions to access data in the tenant are potentially a higher risk.- New apps: New apps that have been registered in the last seven days.

Dashboard element

Description

App categories

The top apps sorted by these categories: - **All categories**: Sorts by all available categories. - **Highly privileged**: High privilege is an internally determined category based on platform machine learning and signals. - **Risky apps**: Apps with a high risk score. - **Overprivileged**: When app governance receives data that indicates that a permission granted to an application hasn't been used in the last 90 days, that application is overprivileged. App governance must be operating for at least 90 days to determine if any app is overprivileged. - **Unused**: Apps that have not signed in within the last 90 days - **Unverified publisher**: Applications that haven't received [publisher certification] are considered unverified. - **App only permissions**: [Application permissions] are used by apps that can run without a signed-in user present. Apps with permissions to access data in the tenant are potentially a higher risk.- **New apps**: New apps that have been registered in the last seven days.

§ View app insights

Risk score

Defender for Endpoint 2

Microsoft Defender for Endpoint plug-in for Windows Subsystem for Linux (WSL)WindowsLinux

Defender for Endpoint · updated 2026-09-29 · +153 −227 words

For WSL containers (WSLc), WSL version 2.9.12 or later is required.

Changed in: Prerequisites · Software components and installer file names · Install the Defender for Endpoint WSL plug-in +4 more

What changed

WSL container (WSLc) support is currently in Public Preview. To participate in the Public Preview and obtain the WSLc-compatible preview version of the Microsoft Defender for Endpoint plug-in for WSL, complete the registration form

§ Software components and installer file names

For WSL containers (WSLc), WSL version 2.9.12 or later is required.

For WSL containers (WSLc), WSL version 2.9.12 or later is required. WSLc support is currently in Public Preview and requires a supported preview version of the Microsoft Defender for Endpoint plug-in for WSL.

Installer: ~~`Defenderplugin-x64-1.26.813.1.msi`.~~ `Defenderplugin-x64-2.26.921.1.msi`. You can download the installer from the onboarding page in the [Microsoft Defender portal]. (Go to **Settings** > **Endpoints** > **Onboarding** > **Windows Subsystem for Linux 2 (plug-in)**.)

The installer referenced above is intended for WSL 2 deployments.

Support for WSL containers (WSLc) is currently in Public Preview and requires a preview version of the Microsoft Defender for Endpoint plug-in for WSL. To participate in the WSLc Public Preview and obtain the preview installer, complete the following registration form

§ Install the Defender for Endpoint WSL plug-in

For WSL containers (WSLc), run wsl --update --pre-release to install the latest WSL preview release required for WSLc functionality.

For WSL containers (WSLc), install the WSLc-compatible Public Preview version of the Microsoft Defender for Endpoint plug-in.

§ Verifying functionality and SOC analyst experience

Filter the device inventory using the tag WSL2. The filtered view shows the Windows host and the associated classic WSL and WSL container devices as separate entries.

If it's a WSLc instance, the application name is appended to the Windows host name to form the device name.

In the following example:

LAB-HOST with device type Workstation is the Windows host.

LAB-HOST with device type Server is the classic WSL Linux device.

LAB-HOST-wslc is the WSLc device for the wslc application.

Filter using the tag WSL2.

LAB-HOST-WSLcHelloWorld is the WSLc device for the WSLcHelloWorld application.

When the Windows host and classic WSL device have the same name, use the Device type column to distinguish between them.

For a WSLc instance, the device name consists of the Windows host name followed by the application name. In this example, the application name is wslc, resulting in WinDev2407Eval-wslc. The device is also tagged with WSL2.

§ Test the plug-in

At the Linux prompt, run the command ./mde_linux_edr_diy.sh.

At the Linux prompt, run the command ./mde_linux_edr_diy.sh. An alert should appear in the portal after a few minutes for a detection on the WSL2 instance.

It takes about five minutes for the events to appear on the Microsoft Defender portal. An alert should appear in the portal after a few minutes for a detection on the WSL2 instance.

Note

§ Troubleshooting

Note

§ WSL1 vs WSL2

~~> >~~ Microsoft Intune is the recommended tool for configuring and distributing Defender for Endpoint features to devices. However, Intune is a separate product that isn't part of Defender for Endpoint, and it isn't included in all subscriptions. To use Intune, you need a subscription that includes it, or you can buy it separately as a standalone subscription or add-on. If you don't have Intune, you can use any of the other methods in this article. For more information, see [Microsoft Intune licensing].

Configuration protection in Microsoft Defender for Endpoint

Defender for Endpoint · updated 2026-09-29 · +82 −82 words

Configuration protection is a configuration enforcement model that makes cloud-managed policy the single source of truth for Microsoft Defender Antivirus…

Changed in: Prerequisites · What configuration protection covers · How configuration protection enforcement works +7 more

What changed

# ~~Controlled configuration~~ Configuration protection in Microsoft Defender for Endpoint - Microsoft Defender for Endpoint | Microsoft Learn

~~Controlled configuration~~ Configuration protection is a configuration enforcement model that makes cloud-managed policy the single source of truth for Microsoft Defender Antivirus settings. When ~~controlled~~ configuration protection is enabled, Intune and Microsoft Defender for Endpoint policies take precedence. The device ignores settings from Group Policy, scripts, Microsoft Configuration Manager, and local admin changes.

~~Controlled configuration~~ Configuration protection eliminates configuration drift and policy conflicts by extending tamper-protection-style enforcement to the entire Defender Antivirus configuration surface.

[Tamper protection] and ~~controlled~~ configuration protection are complementary but distinct capabilities:

| Feature | Tamper protection | ~~Controlled configuration~~ Configuration protection |

~~Controlled configuration~~ Configuration protection is a superset of tamper protection that provides policy-driven control over the full Microsoft Defender Antivirus configuration.

Although tamper protection and ~~controlled~~ configuration protection can technically be turned on at the same time, we recommend that your organization selects one or the other.

§ What configuration protection covers

~~Controlled configuration~~ Configuration protection doesn't currently support:

## What ~~controlled~~ configuration protection covers

Currently, ~~controlled~~ configuration protection provides protection and enforcement for Microsoft Defender Antivirus settings, including:

Currently, ~~controlled~~ configuration protection doesn't cover:

§ How configuration protection enforcement works

## How ~~controlled~~ configuration protection enforcement works

~~Controlled configuration~~ Configuration protection enforces cloud-managed policy through three mechanisms:

- **Single-source enforcement**: When ~~controlled~~ configuration protection is enabled, the following enforcement rules apply:

- **Secure defaults**: If a setting isn't explicitly configured in a policy, ~~controlled~~ configuration protection applies Microsoft-defined defaults. This behavior ensures that devices maintain a strong security posture even when administrators haven't configured every available setting.

- **Conflict resolution**: ~~Controlled configuration~~ Configuration protection uses a value-based precedence model rather than a last-write-wins model:

- **On** takes precedence over **Off**. If one policy sets ~~controlled~~ configuration protection to On and another sets it to Off, the feature stays enabled on the device.

**Not configured** doesn't mean **Off**. To disable the feature, explicitly deploy a policy that sets ~~controlled~~ configuration protection to **Off**.

§ Enable configuration protection

## Enable ~~controlled~~ configuration protection

You can enable ~~controlled~~ configuration protection through either Microsoft Intune or [Microsoft Defender for Endpoint security settings management].

~~Controlled configuration~~ Configuration protection is configured through the same policy surface as tamper protection. In the Windows Security Experience profile, Intune renames the tamper protection setting to **Controlled Configuration **Configuration protection (Device)** when ~~controlled~~ configuration protection is available. You can't enable ~~controlled~~ configuration protection through the Settings Catalog or the Device Control v1 (DCv1) template.

Because ~~controlled~~ configuration protection and tamper protection use the same policy setting, setting **Controlled Configuration **Configuration protection (On)** supersedes the tamper protection value on that device. You don't deploy separate tamper protection and ~~controlled~~ configuration protection policies for the same setting. To migrate existing tamper protection (DCv1) policies to ~~controlled configuration,~~ configuration protection, create a Windows Security Experience policy with **Controlled Configuration **Configuration protection (On)**, then remove the tamper protection setting from your DCv1 policies to avoid conflicts.

Locate the **Controlled Configuration **Configuration protection (Device)** setting (formerly **Tamper Protection**).

Set the value to **Controlled Configuration **Configuration protection (On)** to enable ~~controlled configuration.~~ configuration protection.

§ Minimum client version and rollback

Before you assign **Controlled Configuration **Configuration protection (On)**, update devices to Microsoft Defender Antivirus platform version 4.18.26060.3004 or later, and validate the deployment with a pilot group.

… 19 more changes: see the page or its history

Defender for Identity 4

Offensive Security Testing for Microsoft Defender for Identity

Defender for Identity · updated 2026-09-29 · +80 −157 words

Check directory access requirements for your sensor version · For sensor v2.x deployments, configure a Directory Service Account (DSA) for full security…

Changed in: Best practices checklist

What changed

§ Best practices checklist

Recommendation	Description	Links to Documentation for related tasks
Check directory access requirements for your sensor version	For sensor v2.x deployments, configure a Directory Service Account (DSA) for full security coverage. A DSA is required to access the DeletedObjects container and for specific cross-domain and non-domain-controller scenarios.The sensor v3.x uses LocalSystem for Active Directory interactions. On domain controllers, the sensor v3.x collects information about deleted users and computers without a DSA or additional DeletedObjects container permission configuration.	Directory Service Accounts for Microsoft Defender for Identity
Check that you have a Directory Service account (DSA)	While a DSA is optional in some scenarios, we recommend that you configure a DSA for Defender for Identity for full security protection. When you have a DSA configured: - The DSA connects to the domain controller at startup. - The DSA queries the domain controller for data on entities seen in network traffic, monitored events, and monitored Event Tracing for Windows (ETW) activities.A DSA is required for the following features and functionality: - When working with a sensor installed on an AD FS / AD CS server - To access the DeletedObjects container to collect information about deleted users …	Directory Service Accounts for Microsoft Defender for Identity

Activate the Microsoft Defender for Identity sensor v3.x

Defender for Identity · updated 2026-09-29 · +147 −38 words

When Automatic sensor v3.x activation is enabled, Defender for Identity automatically activates sensor v3.x on eligible domain controllers, AD FS, AD CS, or…

Changed in: Turn on automatic sensor activation · Confirm sensor activation

What changed

§ Turn on automatic sensor activation

Automatic activation applies only to eligible domain controllers onboarded to Defender for Endpoint.

When Automatic sensor v3.x activation is enabled, Defender for Identity automatically activates sensor v3.x on eligible domain controllers, AD FS, AD CS, or Microsoft Entra Connect servers that you onboard to Defender for Endpoint. The servers must run Windows Server 2019 or later.

To turn on automatic sensor activation:

Automatic activation doesn't install a separate Defender for Identity sensor package. It activates the sensor capability on eligible servers that are already onboarded to Defender for Endpoint. Servers that already have a Defender for Identity sensor aren't targeted by this flow.

In the Microsoft Defender portal, go to Settings > Identities > Advanced features.

On the Advanced features page in the Microsoft Defender portal at https://security.microsoft.com/securitysettings/identities, use the Automatic sensor v3.x activation toggle to turn on automatic activation for eligible servers. Automatic activation applies only to eligible servers onboarded to Defender for Endpoint.

Turn on Automatic sensor v3.x activation.

Turn on the setting to automatically activate eligible servers when they're discovered.

Turn off the setting to stop future automatic activations.

§ Confirm sensor activation

Note

Deploy the Microsoft Defender for Identity sensor v3.xPreview

Defender for Identity · updated 2026-09-29 · +48 −46 words

Manual activation of Defender for Identity sensor v3.x on eligible AD FS, AD CS, and Microsoft Entra Connect servers is in preview.

Changed in: Supported server types · Configure RPC auditing

What changed

§ Supported server types

~~Activating the~~ Manual activation of Defender for Identity sensor v3.x on eligible AD FS, AD CS, and Microsoft Entra Connect servers is in preview. This preview applies only to servers that aren't domain controllers ~~is in preview. Manual activation~~ and ~~automatic Windows event auditing are supported. Automatic activation and migration aren't currently supported~~ don't have an existing Defender for ~~these servers.~~ Identity sensor.

§ Configure RPC auditing

~~Starting with~~ Install the July 2026 or later Windows Server cumulative update before you install or upgrade to Defender for Identity sensor ~~release (sensor~~ version ~~3.0.8),~~ 3.0.8 or later. Starting with sensor version 3.0.8, RPC auditing is ~~automatically~~ enabled automatically on domain ~~controllers when~~ controllers, so you ~~upgrade the sensor to the latest version. You~~ no longer need to apply ~~a tag manually to enable~~ an RPC ~~auditing, and the~~ configuration tag. The related health alert clears shortly after the upgrade.

Configure Windows event auditingWindows

Defender for Identity · updated 2026-09-29 · +54 −2 words

When Automatic sensor v3.x activation and Automatic Windows auditing configuration are enabled, Defender for Identity automatically activates sensor v3.x and…

Changed in: Control automatic Windows auditing · Configure auditing on an AD CS server

What changed

§ Control automatic Windows auditing

### ~~Turn on~~ Control automatic Windows auditing

When Automatic sensor v3.x activation and Automatic Windows auditing configuration are enabled, Defender for Identity automatically activates sensor v3.x and configures Windows auditing on eligible domain controllers, AD FS, AD CS, or Microsoft Entra Connect servers that you onboard to Defender for Endpoint. The servers must run Windows Server 2019 or later.

§ Configure auditing on an AD CS server

Note

Defender for Office 365 1

Allow or block URLs using the Tenant Allow/Block List

Defender for Office 365 · updated 2026-09-30 · +16 −7 words

Punycode is only allowed in hostname labels before a normal ASCII TLD.

Changed in: URL syntax for the Tenant Allow/Block List

What changed

§ URL syntax for the Tenant Allow/Block List

Unicode isn't supported. Punycode is only allowed in hostname labels before a normal ASCII TLD.

Unicode isn't supported, but Punycode is.

Defender XDR 1

Non-human identities in Microsoft Defender

Defender XDR · updated 2026-09-29 · +221 −18 words

Actionable insights appear at the top of the non-human identities inventory.

Changed in: Actionable insights · Types of non-human identities

What changed

# Non-human identities in Microsoft Defender ~~(Preview)~~ - Microsoft Defender XDR | Microsoft Learn

§ Actionable insights

Actionable insights

Actionable insights appear at the top of the non-human identities inventory. Select an insight to filter the list to identities that need review.

| Insight | Description | Available for |

Insight	Description	Available for
New identities	Identities added in the last 30 days.	Microsoft 365
Highly privileged identities	Identities with powerful permissions that allow them to access data or change important settings. For Salesforce, includes Connected Apps and External Client Apps (ECAs) whose granted permissions are classified as High.	Microsoft 365, Google Workspace, Salesforce
Risky identities	Identities with a high risk score.	Microsoft 365, Google Workspace, Salesforce

§ Types of non-human identities

Salesforce: OAuth apps connected through Salesforce. Users authorize these apps to access Salesforce data and resources.

§ Actionable insights

Insight	Description	Available for
Unused identities	Identities that haven't signed in within the last 90 days. For Salesforce, includes Connected Apps and ECAs that haven't been used for more than 90 days based on the last used date.	Microsoft 365, Google Workspace, Salesforce
Overprivileged identities	Identities with unused permissions.	Microsoft 365
Identities from external unverified publishers	Identities that originated from an external unverified publisher tenant.	Microsoft 365
Used by AI Agents	Identities identified as being used by AI agent platforms.	Microsoft 365

§ Types of non-human identities

Salesforce: OAuth apps connected through Salesforce. The inventory includes both Connected Apps and External Client Apps (ECAs).

Security Exposure Management 1

Set up Microsoft Foundry for Codename MDASH - Agentic code scanner integrationPreview

Security Exposure Management · updated 2026-09-28 · +61 −86 words

Standard: Deploy all three models only once:

Changed in: Deploy the required models · Prerequisites · Allow Codename MDASH to access your Microsoft Foundry resource +1 more

What changed

§ Deploy the required models

- **Standard**: Deploy all three ~~models:~~ models only once:

- **MAI ~~Cyber**\*\* (Preview)\*\*:~~ Cyber** **(Preview)**: To use this configuration, deploy the three models listed previously and:

Deploy each model only once.

§ Allow Codename MDASH to access your Microsoft Foundry resource

- A Microsoft Foundry resource is created, and ~~three~~ the required model deployments are completed.

The same setup applies to the new MAI-Cyber-1-Flash model, which is part of the MAI Cyber (Preview) configuration .

Codename MDASH needs to access your Microsoft Foundry endpoint to validate credentials and run agentic scans. When your Foundry resource networking is set to **Selected networks and private endpoints**, all inbound traffic is blocked by default, including requests from MDASH. Without allowing the required IP addresses, validation of the Foundry resource during MDASH onboarding will fail. If your Foundry resource has public access set to **All networks**, no action is required and you can continue to the next step.

Note

If your Foundry resource has public access set to All networks, no action is required and you can continue to the next step.

§ Disconnect Foundry

To replace a connected Foundry with a different one, or to remove the connection, you can disconnect at any time. Disconnecting the connected Foundry without providing an alternative will disable the use of the agentic code scanning.

Once disconnected, you can leave it as is or reconnect at any time to the same Foundry or to a different one. Disconnecting removes the connection from MDASH but it doesn't delete the Microsoft Foundry resource.

Note

Disconnecting the connected Foundry without providing an alternative will disable the use of the agentic code scanning.

Disconnecting removes the connection from MDASH. It doesn't delete the Microsoft Foundry resource.

Minor changes (3) · fewer than 15 words

Defender for Cloud Apps 1

Get started with app governance in Microsoft Defender for Cloud Apps in Microsoft Defender XDR.

Defender for Cloud Apps · updated 2026-09-29 · +6 −8 words

Use this quickstart to begin using app governance features in Microsoft Defender for Cloud Apps.

Changed in: Step 1: Get visibility and insights

What changed

~~This article describes how~~ Use this quickstart to ~~get started~~ begin using app governance features in Microsoft Defender for Cloud Apps.

§ Step 1: Get visibility and insights

**[Determine ~~compliance~~ security posture]**: Use the data on the **App governance > Overview** tab to assess the ~~compliance~~ security posture of your apps and incidents in your tenant. View details like how many overprivileged apps are in your tenant, the number of active incidents, the total Graph API data access, and more.

Defender for Identity 1

Directory Service Accounts for Microsoft Defender for Identity

Defender for Identity · updated 2026-09-29 · +4 −1 words

For sensor v2.x, a DSA is required for the following features and functionality:

What changed

A For sensor v2.x, a DSA is required for the following features and functionality:

Security Exposure Management 1

Codename MDASH Overview

Security Exposure Management · updated 2026-09-30 · +2 −0 words

aspm-data-externalapi-prd.security.aspm.microsoft.com

Changed in: Allow list

What changed

§ Allow list

aspm-data-externalapi-prd.security.aspm.microsoft.com

2 pages were republished without text changes and are not shown.

Microsoft Entra

1 what's new 18 important 14 minor

What's new, release notes and known issues 1

Microsoft Entra Connect: Version release historyRelease notesRetirement

Hybrid · updated 2026-09-29 · +49 −65 words

Mandatory upgrade required: Upgrade Microsoft Entra Connect Sync to version 2.6.84.0 or later and configure application-based authentication by April 7, 2027.

What changed

Mandatory upgrade required: Upgrade Microsoft Entra Connect Sync to version 2.6.84.0 or later and configure application-based authentication by April 7, 2027. Legacy authentication is being retired, and synchronization services will stop working after this date if these requirements aren't met.

Mandatory Upgrade Required: All synchronization services in Microsoft Entra Connect Sync will stop working on September 30, 2026 if you're not on at least version 2.5.79.0. In May 2025, we released this version with a back-end service change that hardens our services. Upgrade before this deadline to avoid any service disruption.

If ~~you're unable to upgrade before the deadline, all~~ synchronization ~~services will fail until you~~ stops, upgrade to the latest ~~version.~~ version and configure application-based authentication to restore service. The Microsoft Entra Connect Sync .msi installation file is exclusively available on [Microsoft Entra Admin Center]. Make sure you meet the minimum requirements including .NET Framework 4.7.2 and TLS 1.2.

Important changes 18

Agent ID 1

Learn about the agent's user account in Microsoft Entra Agent ID

Agent ID · updated 2026-09-30 · +10 −31 words

The agent's user account can be assigned with custom roles.

Changed in: Security constraints

What changed

§ Security constraints

- Administrative role restrictions: The agent's user account can't be assigned privileged administrator roles. This limitation provides an important security boundary, preventing potential elevation of privileges. The agent's user account can be assigned with custom roles.

- Permission model: The agent's user account typically has permissions similar to guest users, with more capabilities for enumerating users and groups. The agent's user account can't be assigned privileged admin roles. Custom role assignment and role-assignable groups aren't available to the agent's user account. For more information, see [Microsoft Graph permissions reference]

Authentication 2

Introduction to Microsoft Entra KerberosHeads-up

Authentication · updated 2026-09-29 · +648 −0 words

Microsoft Entra Kerberos serves as a foundation for several authentication scenarios that provide access to Active Directory resources by using modern…

Changed in: Scenarios · Windows Hello for Business cloud Kerberos trust · Access Active Directory resources with cloud-managed identities

What changed

§ Scenarios

Microsoft Entra Kerberos serves as a foundation for several authentication scenarios that provide access to Active Directory resources by using modern authentication methods. These scenarios include access for cloud-managed identities, Windows Hello for Business cloud Kerberos trust, FIDO2 security key sign-in, Azure Files authentication, Azure Virtual Desktop profile access, and Platform SSO on macOS.

§ Windows Hello for Business cloud Kerberos trust

Windows Hello for Business cloud Kerberos trust

Windows Hello for Business cloud Kerberos trust uses Microsoft Entra Kerberos to provide passwordless access to Active Directory resources. After a user signs in with Windows Hello for Business, Microsoft Entra ID issues a cloud-based Kerberos ticket that enables the user to obtain Kerberos service tickets for resources protected by Active Directory, such as file shares and line-of-business applications. This deployment model simplifies passwordless adoption by removing the requirement for certificate deployment or public key infrastructure (PKI).

Important

To access resources protected by Active Directory, the user must have a corresponding account in Active Directory. For cloud-managed users, use Microsoft Entra ID to Active Directory provisioning to provision the user account. A cloud-only user who doesn't have an Active Directory account can't obtain an Active Directory TGT or access resources authorized by Active Directory.

Microsoft Entra ID authenticates the user and issues a partial Kerberos TGT. The client exchanges that ticket with an Active Directory domain controller, which uses the provisioned Active Directory account and its group memberships to perform authorization and issue a full TGT and service tickets. Cloud Kerberos trust doesn't require the user's Windows Hello for Business key to be synchronized to Active Directory.

For more information, see the Windows Hello for Business cloud Kerberos trust deployment guide.

§ Access Active Directory resources with cloud-managed identities

Access Active Directory resources with cloud-managed identities

Organizations adopting a cloud-first identity model can manage users and groups in Microsoft Entra ID while continuing to use applications and resources protected by Active Directory.

By using Microsoft Entra Cloud Sync, organizations can provision Microsoft Entra ID users, groups, and memberships to Active Directory. Microsoft Entra Kerberos enables those users to access Kerberos-protected resources by using modern authentication methods such as Windows Hello for Business cloud Kerberos trust and FIDO2 security keys.

This scenario enables organizations to:

Move user and group source of authority to Microsoft Entra ID.

Reduce dependency on on-premises identity management.

Continue accessing Kerberos-protected applications and resources.

Support cloud-managed identities while maintaining compatibility with existing Active Directory environments.

Important

Provisioning users from Microsoft Entra ID to Active Directory creates and manages the corresponding Active Directory accounts. Provisioning alone doesn't enable Kerberos authentication or passwordless access to Active Directory resources. To access Kerberos-protected resources by using modern authentication methods, you must also deploy Microsoft Entra Kerberos and configure a supported authentication method, such as Windows Hello for Business cloud Kerberos trust or FIDO2 security keys.

The following example illustrates how cloud-managed identities that are provisioned to Active Directory can use Microsoft Entra Kerberos:

A user account is managed in Microsoft Entra ID.

Microsoft Entra Cloud Sync provisions the user to Active Directory.

The user signs in by using Windows Hello for Business or a FIDO2 security key.

Microsoft Entra ID issues a Microsoft Entra Kerberos ticket.

Active Directory issues Kerberos service tickets for authorized resources.

The user accesses Kerberos-protected applications and resources without entering a password.

Examples of supported resources include:

… 10 more changes: see the page or its history

Plan a phishing-resistant passwordless authentication deployment in Microsoft Entra ID

Authentication · updated 2026-09-30 · +11 −10 words

Microsoft recommends communicating with users through other channels beyond just email.

Changed in: Plan end user communications · Reporting and monitoring · Step 4: Enforcement of phishing resistance on resources +2 more

What changed

§ Plan end user communications

Microsoft recommends communicating to with users through other channels beyond just email. Other options may include Microsoft Teams messages, break room posters, and champion programs where select employees are trained to advocate for the program to their peers.

§ Reporting and monitoring

Use the previously covered Phishing-Resistant Passwordless Workbook to assist with monitoring and reporting on your rollout. ~~Additionally~~ Additionally, use the reports discussed below, or rely on them if you cannot use the Phishing-Resistant Passwordless Workbook.

- **Registration** shows the number of users capable of phishing-resistant passwordless authentication, and other authentication methods. You can see graphs that show which authentication methods users registered, and recent ~~registration~~ registrations for each method.

- Track user adoption of phishing-resistant passwordless credentials with Authentication Methods ~~sign in~~ sign-in activity reports and ~~sign in~~ sign-in logs.

- Use the [sign-in activity report] to track the authentication methods used to sign in to the various applications. Select the user row; select **Authentication Details** to view the authentication method and its corresponding sign-in activity.

§ Step 4: Enforcement of phishing resistance on resources

Microsoft recommends that you build a report of all your user/device pairs by using sign-in data from your tenant. You can use querying tools like [Azure Monitor and Workbooks]. At a minimum, try to identify all user/device pairs that match these categories.

### Recommended enforcement of Conditional Access policies

§ Respond to risk for passwordless users

- Activity from an anonymous IP address

Configure a Conditional Access policy to block high risk **users** high-risk users

Conditional Access 4

Secure autonomous agents with Conditional AccessPreviewRewritten

Conditional Access · updated 2026-09-30 · +412 −1649 words

Use Conditional Access to control access for autonomous agents that authenticate with their own agent identity and no signed-in user.

Most of this page changed, so the overview below lists its sections instead of every edit.

New sections: Prerequisites · Block high-risk agent identities · Policies for agent user accounts
Removed sections: Block high-risk agents from accessing organizational resources · Policies for autonomous agents' user accounts · Block risky agents' user accounts · Require a compliant device for agents' user accounts · Require a compliant network for agents' user accounts
Changed sections: Allow only specific agents to access resources · Create and assign custom attributes · Create Conditional Access policy

Show full diff

# Secure autonomous agents with Conditional Access - Microsoft Entra ID | Microsoft Learn

# Recommended policies for autonomous agents in Microsoft Entra - Microsoft Entra ID | Microsoft Learn

Use Conditional Access to control access for autonomous agents that authenticate with their own agent identity and no signed-in user. This access pattern includes agents that run in the background, respond to events, run on a schedule, or are published for public use without delegated user context.

Use this guide to configure Conditional Access for agents that authenticate with their own identity, with no signed-in user. The access pattern is known client credentials flow. Instead of acting on behalf of a user, the agent authenticates with its own credentials - a client ID paired with a certificate or managed identity managed by the agent identity blueprint. This access pattern applies in the following scenarios:

In this access pattern, the access token's subject is the agent identity. Conditional Access policies therefore target the agent identity, not a user or an agent's user account.

Autonomous agents that operate independently:

Before you start, review the licensing, role, and agent setup requirements.

These agents run in the background, responding to events, or run on a schedule. A typical example is an agent that generates a daily report and sends the result to a group of employees. In this scenario, there is no user present, and the agent operates on its own.

Prerequisites

Agents that don't always act on a user's behalf:

A Microsoft Entra ID P1 or P2 license.

Sometimes agents operate entirely on their own. For example, a backend SMS service that is not accessible to users. In this scenario, the OBO flow is not applicable and agent accesses the target resource by authenticating directly with its own identity.

Agent 365 license will soon be required

Agents published on the web for public use:

At least the Conditional Access Administrator role.

These agents either don’t authenticate the user or don’t support delegating the user’s context to downstream resources.

At least one agent identity registered in your tenant.

In those scenarios, the agent is the one who requests access, and the issued access token's subject is the agent identity rather than the user. As a result, the Conditional Access policy scope applies to the agent identity, not a user.

The agent uses the autonomous app OAuth flow.

Before configuring a Conditional Access policy, read the Conditional Access for agents article. It covers the authentication flow, service boundaries, and limitations to ensure you cover all scenarios and your corporate data and services are well protected.

§ Allow only specific agents to access resources

Before configuring a Conditional Access policy, read the [Conditional Access for agents] article. It covers the ~~authentication flow,~~ authentication, service boundaries, and limitations to ensure you cover all scenarios and your corporate data and services are well protected.

There are two key business scenarios where Conditional Access policies can help you manage agents effectively. In the first scenario you might want to ensure that only approved agents can access resources. You can do this by tagging agents and resources with custom security attributes targeted in your policy, or by manually selecting them using the enhanced object picker.

Create a block policy that excludes approved agent identities or agent identity blueprints. Start in report-only mode so you can review the policy's effect before you enforce it. You can do this by tagging agents and resources with custom security attributes targeted in your policy, or by manually selecting them using the enhanced object picker.

Alternatively, organizations can create a Conditional Access policy using the enhanced object picker to block all agents except those reviewed and approved by your organization.

~~Alternatively, organizations~~ Organizations can create a Conditional Access policy using the enhanced object picker to block all agents except those reviewed and approved by your organization.

… 123 more changes: see the page or its history

Conditional Access for Agents in Microsoft Entra

Conditional Access · updated 2026-09-30 · +433 −286 words

Conditional Access for agents is an extension of the Conditional Access policy engine that controls how agents access resources protected by Microsoft Entra ID.

Changed in: Requirements and licensing · How Conditional Access evaluates agent access requests · How subjects and audiences are used +7 more

What changed

Conditional Access for agents is an ~~intelligent~~ extension of the Conditional Access policy engine that ~~helps organizations control~~ controls how ~~users and~~ agents access ~~corporate resources.~~ resources protected by Microsoft Entra ID. It brings together real-time signals such as user's and agent's context, device, location, and ~~session~~ risk information to determine when to allow, block, or limit access, or require more verification steps.

Understanding the agent's access pattern helps you target the correct identity. An agent can act on behalf of a signed-in user, use its own agent identity, or use its own agent user account.

Conditional Access for agents requires Microsoft Entra ID P1 or P2 and a Microsoft Agent 365 license for each user. Enforcement of Agent 365 licensing is coming soon. Network controls for agents require Microsoft Entra Internet Access. For more information, see What is Microsoft Entra Agent ID.

Secure autonomous agents with Conditional Access

Configure policies for autonomous agent access

Secure agent users with Microsoft Entra Conditional Access

§ Requirements and licensing

Requirements and licensing

Microsoft Entra ID Conditional Access for agents requires one of the following license plans:

Microsoft 365 E7, which includes Agent 365 and Microsoft Entra Suite.

§ How Conditional Access evaluates agent access requests

The following diagram illustrates this process.

§ Requirements and licensing

Microsoft Agent 365 license paired with at least Microsoft Entra P1 or Microsoft 365 E3.

For more information, see Microsoft Agent 365 plans and pricing.

How subjects and audiences are used

## How Conditional Access evaluates agent access ~~requests~~

Microsoft Entra ID issues an access token to a subject for a specific audience (resource). Each access token has exactly one subject and one audience.

To access a ~~corporate~~ resource such as a SharePoint file, MCP ~~servers,~~ server, or Open API ~~services,~~ service, a user or agent ~~first~~ requests an access token from Microsoft Entra ID.

When a Conditional Access policy applies, Microsoft Entra ID evaluates the ~~configured~~ policy requirements before ~~issuing~~ it issues the token. If the requirements are satisfied, ~~an access token is issued. The token is then presented to~~ Microsoft Entra ID issues the token. The target ~~resource, which~~ resource validates the token and uses its claims to make authorization decisions.

Each access token has one subject and one audience:

- **Subject**: The identity ~~receiving~~ that receives the token.

Audience: The target resource the token is intended for.

- In delegated ~~access scenarios,~~ access, the token represents the user while also identifying the calling application or agent.

The resource must be registered in Microsoft Entra ID.

- In application-only ~~scenarios,~~ access, the ~~application or autonomous~~ agent identity is the subject.

If a subject needs to access multiple resources (for example, multiple MCP servers or APIs), it typically requires a separate access token for each resource, each with its own audience and permissions.

Target agents in Microsoft Entra Conditional Access policies

- In ~~agent's user account scenarios,~~ agent-user access, the agent's user account is the subject.

… 19 more changes: see the page or its history

Conditional Access · updated 2026-09-30 · +97 −136 words

Use this article to select agent identities or agent user accounts in a Conditional Access policy, choose target resources, configure supported conditions…

Changed in: Create a Conditional Access policy for agent identities · Considerations for selecting agent assignments · Controls for agent users

What changed

# Target ~~agent identities~~ agents in Microsoft Entra Conditional Access policies - Microsoft Entra ID | Microsoft Learn

Use this article to select agent identities or agent user accounts in a Conditional Access policy, choose target resources, configure supported conditions, and select access controls.

Conditional Access policies for agent identities let you control how AI agents access corporate resources. As your organization deploys more agents, you need policies that target the right agents, evaluate the right signals, and enforce the right controls. To learn more about how Conditional Access policies for agents work for different scenarios, see Conditional Access policies for agents.

The available conditions and controls depend on the token subject. To choose the right subject before you build the policy, see Conditional Access for agents overview.

This article walks through each section of the Conditional Access policy builder for agents:

Selecting which agents the policy applies to

Choosing target resources

Configuring conditions

Setting access controls.

Each section builds on the previous one to form a complete policy.

§ Create a Conditional Access policy for agent identities

Policies that target agent identities ~~introduce unique~~ or agent user accounts have assignment options, conditions, and ~~control limitations~~ controls that differ from user-targeted policies.

For policies that target agent identities, see Secure autonomous agents with Conditional Access.

For policies that target agent user accounts, see Secure agents that act as users with Conditional Access.

Configure policy for autonomous agent access

Configure policy for on-behalf-of agent access

§ Considerations for selecting agent assignments

- Targeting a blueprint automatically covers all agent identities derived from it, including ones added in the future. For more ~~information about targeting agent identity blueprints,~~ information, see ~~[Conditional Access for agent identities: Agent~~ [Agent identity blueprints].

§ Controls for agent users

- **Require device to be marked as compliant**: Requires agents to run on Intune-managed compliant devices, such as Windows 365 Cloud PCs for Agents. For more information, ~~see[What~~ see [What is Windows 365 for Agents?]. []

How to Use Conditions in Conditional Access PoliciesHeads-up

Conditional Access · updated 2026-09-28 · +30 −0 words

You should use Conditional Access policies using this condition with another policy (like one requiring device compliance or app protection policies) to…

Changed in: Device platforms

What changed

§ Device platforms

Warning

Conditional Access identifies the device platform using information provided by the device, such as user agent strings. Because user agent strings can be modified, this information isn't verified. Use device platform with Microsoft Intune device compliance policies or as part of a block statement. By default, it applies to all device platforms. You should use Conditional Access policies using this condition with another policy (like one requiring device compliance or app protection policies) to mitigate the risk of user agent spoofing.

Enterprise Apps 1

Tutorial: Manage federation certificates

Enterprise Apps · updated 2026-09-29 · +111 −76 words

If notification email addresses are configured programmatically using Microsoft Graph or PowerShell, administrators should navigate to Enterprise applications…

Changed in: Add email notification addresses for certificate expiration

What changed

§ Add email notification addresses for certificate expiration

If notification email addresses are configured programmatically using Microsoft Graph or PowerShell, administrators should navigate to Enterprise applications > [Application] > Single sign-on > SAML and verify that the Notification email address is configured correctly in the SAML Certificates section. For applications that use a custom SAML signing certificate, opening the SAML certificate experience in the Microsoft Entra admin center should initialize certificate notification registration if it does not already exist. Notification registration and certificate information may take time to refresh. Administrators should verify certificate notification settings well in advance of certificate expiration. If the SAML settings aren’t verified in the admin center, certificate expiration notification emails might not be sent.

If notification email address configuration is completed programmatically using Microsoft Graph or PowerShell, administrators should also save the notification email settings in the Microsoft Entra admin center. Go to Enterprise applications > [Application] > Single sign-on > SAML, select Edit in the SAML Certificates and under Notification email section, re-confirm the notification email address, and then select Save. If the SAML settings aren’t re-saved in the admin center, certificate expiration notification emails might not be sent.

Global Secure Access 3

Microsoft Entra Private Network Connectors - Global Secure AccessHeads-up

Global Secure Access · updated 2026-09-28 · +359 −158 words

Private network connectors initiate outbound TCP and UDP connections to configured destinations.

Changed in: Configure dynamic and AutoReuse TCP port ranges · Expanding ephemeral port range · Configure the port ranges +1 more

What changed

Configure dynamic and AutoReuse TCP port ranges

Expanding ephemeral port range

Private network connectors initiate outbound TCP and UDP connections to configured destinations. Each connection requires an available source port on the connector host.

Private network connectors initiate TCP and UDP connections to designated destination endpoints. These connections require available source ports on the connector host machine. Expanding the ephemeral port range can improve the availability of source ports, particularly when you're managing a high volume of concurrent connections.

For high-volume TCP workloads, configure separate, non-overlapping dynamic and AutoReuse port ranges:

To view the current dynamic port range on a system, use the following netsh commands:

Dynamic TCP range: 49152–65535 (16,384 ports)

netsh int ipv4 show dynamicport tcp

AutoReuse TCP range: 10000–49151 (39,152 ports)

netsh int ipv4 show dynamicport udp

The AutoReuse range improves TCP connection scalability by allowing eligible outbound connections to reuse a local source port when the complete connection tuple—source IP, source port, destination IP, and destination port—remains unique.

netsh int ipv6 show dynamicport tcp

Important

netsh int ipv6 show dynamicport udp

The dynamic and AutoReuse TCP ranges must not overlap.

Here are sample netsh commands to increase the ports:

Before you begin:

netsh int ipv4 set dynamicport tcp start=1025 num=64511

Use Windows Server 2016 or later.

netsh int ipv4 set dynamicport udp start=1025 num=64511

Run the commands from an elevated PowerShell session.

netsh int ipv6 set dynamicport tcp start=1025 num=64511

Confirm that ports 10000–49151 aren't required by applications installed on the connector server.

netsh int ipv6 set dynamicport udp start=1025 num=64511