The new Defender server security experience

Applies to: Microsoft Defender for Endpoint Plan 2

The new Defender server security experience brings Defender for Endpoint and Defender for Servers together in the Microsoft Defender portal. Use it to manage server protection and investigate threats with cloud and endpoint information in one place.

This public preview covers Azure environments and on-premises servers. See What's new for the release summary.

On this page: Server asset page | Investigate an incident | Go hunt | RBAC and device groups.

Servers already running Defender for Endpoint

Servers already running Defender for Endpoint continue operating with their existing configuration. You don't need to onboard, reinstall, or migrate them to maintain their existing protection. Review the requirements for each unified capability before changing your configuration.

Review the server asset page

The server asset page brings together available cloud-resource and endpoint-device information for the same server, instead of requiring separate investigation pages.

In Microsoft Defender, open an alert involving the server and select Open asset page from the server's menu. From an incident graph, open the server node's menu and select Asset details.
Check the endpoint device ID and, where available, the Azure resource ID. Don't identify a server by name alone.
Review the server's identity, onboarding status, and available resource and operating-system details.
Select Open device timeline to inspect endpoint activity, or Go hunt to investigate related events.

If records appear duplicated or incorrectly matched, check both identifiers before taking action. Available context depends on connected data sources; manual onboarding doesn't create an Azure resource.

Response actions depend on your permissions, the platform, and the server's state. Use the supported device-response guidance before taking an action that could affect the workload.

Investigate alerts and incidents

To investigate a server, you need access to its investigation data, and the server must have a related alert or incident.

Open an incident involving the server and review its attack graph.
Select the server node. For a server with correlated cloud and endpoint records, the graph provides one server identity and investigation menu.
Right-click the node or open its ellipsis menu. Choose Asset details for context, Pin related alerts to inspect related detections, or Go hunt to investigate activity.
Open a related alert and follow its server link. Confirm that it leads to the same server identity before considering a response action.

Cloud and endpoint alerts can refer to the same server without becoming a single alert. A shared asset identity doesn't guarantee that every alert is grouped into one incident.

Use Go hunt

You need advanced hunting access to the data being queried. Being able to open an asset page doesn't grant access to all hunting tables.

From the incident graph, open the server node's menu and select Go hunt. You can also use the action from the server's alert or asset context where available.
Choose All activity, Related alerts, or See all available queries, then select the query you need.
Inspect the generated query and its results in advanced hunting. Go hunt can execute the generated query automatically rather than only displaying it for review.
Check that the query targets the intended server. Where both identities are available, review its endpoint device and cloud-resource identifiers, selected tables, and time range.
To investigate another time window, adjust the query's timestamp filter and run it again. Use UTC in query expressions.
Open relevant results, compare their timestamps with the alert, and return to the incident to continue the investigation.

For a specific endpoint event, open Device timeline, select the event, and use Hunt for related events where available. This searches around that event rather than starting from the whole server.

All activity doesn't guarantee every data source is included. If results are empty or incomplete, check the query filters, available tables, retention, endpoint reporting, and your data permissions. An empty query result doesn't establish that the server is unaffected. See Go hunt query behavior for query-adjustment guidance.

Verify RBAC and server access

Roles define what a person can do; scopes define which data they can access.

Control	Purpose
Microsoft Entra user group	Identifies the people receiving access, such as a server operations team.
Defender RBAC role	Grants selected read, investigation, response, or administration permissions.
Device group	Groups endpoints and controls access to their data through assigned Entra user groups. It can also set automated-remediation behavior.
Cloud scope	Groups selected cloud environments, such as Azure subscriptions, for cloud-data access. It is separate from Azure RBAC.

For a server represented in both cloud and endpoint data, configure the relevant cloud scope and device group. Linking a device group to a cloud scope aligns server membership; it doesn't replace role assignments or grant users access by itself. Existing endpoint-only deployments don't need a cloud connection just to continue operating.

Assign the team's permissions

Use the permissions model active in your tenant. Don't activate a different model merely to follow this guide.

For tenants using Microsoft Defender unified RBAC, a Security Administrator or an administrator with the required delegated Authorization permissions can:

Open Permissions > Microsoft Defender XDR > Roles and create or edit the appropriate role.
Select the permissions the team needs. Keep investigation access separate from response and administration permissions.
Add an assignment for the team's Microsoft Entra security group and the required data sources. Access to Defender for Endpoint data alone doesn't grant access to Defender for Cloud data.
For cloud data, select the intended cloud scopes. Review and submit the assignment.

Follow Create custom roles for the full wizard. Tenants still using the previous endpoint model should use Defender for Endpoint RBAC; existing roles aren't replaced by this experience.

Define a server device group

Create a device group to manage access to servers using device conditions or existing cloud scopes. Before you begin, ensure that the Microsoft Entra user groups you want to assign have the appropriate role-based access control (RBAC) roles.

In the Microsoft Defender portal, go to Settings > Endpoints > Permissions > Device groups.
Select Add device group, or edit an existing group. Enter a descriptive name and review the automated-remediation level.

On the Devices page, choose how to populate the group:

Option	Description
Define using conditions	Match servers using supported device attributes, such as device name, domain, tags, or OS platform.
Select cloud scopes to populate this group	Select one or more existing cloud scopes. Devices from all selected scopes are included. (preview)

Select Next and review the matching devices on the Preview devices page before continuing.
On the User access page, select the Microsoft Entra user groups that should have access, and then select Submit.
Review the group's membership and access assignments. For condition-based groups, review the group ranking: a device that matches multiple condition-based groups belongs to the highest-ranked group.

Note

Cloud-scope membership includes all devices from the selected scopes. Review the selected scopes to ensure that the group includes only the intended devices.

Align a cloud scope and device group

If needed, create the Azure scope under System > Permissions > Microsoft Defender XDR > Scopes > Add cloud scope. Select the intended connected Azure subscriptions.
Assign the team's cloud-data permissions to that scope, then select it in the device group's Devices step.
Keep the team's endpoint role and device-group User access assignment in place. Verify access to both data sources.

Follow Manage cloud scopes if scope activation is required. Activation is an irreversible configuration change: review existing assignments and the activation wizard before proceeding.

The cloud-scope link updates device membership as the selected scope's contents change. Newly connected environments aren't automatically added to the cloud scope. Review scope membership when adding an Azure environment.

Check the effective access

Test with ordinary analyst accounts, not only a Security Administrator account; broad administrator access can hide scoping mistakes. A display filter narrows a view but isn't a substitute for permissions.

Check	Required outcome
Open a server within the user's assigned access	The intended server and permitted data are available.
Navigate from an alert or incident to the asset and hunting	The server identity remains correct and access remains appropriate.
Attempt to open an out-of-scope server	Restricted data and actions remain inaccessible.
Check a response or configuration action	The action is available only to an authorized user; don't execute disruptive actions just to test access.

If expected access is missing, check role permissions, data-source assignments, Entra group membership, the device's effective group, and its cloud scope. If an analyst sees unintended server data, review other role assignments and broad access before expanding the rollout.

Remove server protection

See Offboard devices for automatic Azure offboarding and other supported offboarding methods.

Feedback

Was this page helpful?

Last updated on 2026-10-07