A security alert is a starting point, not a complete account of an attack. A suspicious email, an unusual sign-in and an endpoint detection might represent separate problems—or different stages of the same incident. Microsoft Defender XDR correlates related alerts and evidence from supported security services into incidents, giving analysts a shared place to investigate and coordinate response.

In Part 1 of the Microsoft Defender Deep Dive series, we establish the operating model: understand what the Microsoft Defender portal contains, prepare appropriate access, prioritise the incident queue and investigate before taking disruptive action. Later instalments examine the individual workloads and hunting capabilities. The immediate goal is a repeatable workflow that analysts can follow and explain.

By Muhammad Ahsan, Solution Savy — Microsoft 365 and security architect working towards Microsoft MVP.

1. Understand the unified portal—and its boundaries

The Microsoft Defender portal, available at https://security.microsoft.com, is the central interface for Microsoft Defender XDR. It brings together investigation and response experiences across supported services, including Microsoft Defender for Endpoint, Microsoft Defender for Office 365, Microsoft Defender for Identity and Microsoft Defender for Cloud Apps. The experiences and data available to your organisation depend on its subscriptions, deployments, permissions and configuration.

The distinction between portal and protection is important. Accessing a unified interface does not onboard devices, deploy identity sensors or configure email protection. A quiet incident queue is not proof that the environment is secure: first establish which services are supplying data and which assets they cover. Treat missing coverage as an operational finding, not as an absence of threats.

Before building a triage procedure, document the services enabled in your tenant, the teams responsible for them and the accounts used for investigation. Include dependencies on identity, messaging and endpoint administrators. This prevents an analyst from discovering during an incident that nobody on shift can perform the required response action.

Confirm that the intended analysts can open the Microsoft Defender portal and view the relevant incidents and supporting evidence.

Review Microsoft Defender XDR unified role-based access control where supported. Check workload activation, assigned permissions and data scope rather than assuming one role grants access everywhere.

Separate investigation access from permissions for disruptive response actions. Use least privilege and document how analysts obtain additional authority when required.

Unified role-based access control has workload-specific support and activation requirements. Do not assume that enabling it replaces every permission model across Microsoft security services. Test representative analyst accounts against the actual workloads they need to investigate.

2. Make the incident queue an operational workspace

Open the Incidents area in the Microsoft Defender portal. An alert describes a detection; an incident groups related alerts, entities and evidence into a broader investigation. Working primarily from incidents helps analysts assess the combined activity instead of repeatedly handling connected alerts in isolation.

Start with a documented queue view. Use the available filters to focus on unresolved work, then review severity, assignment, affected entities and contributing services. Where useful, create separate working views for urgent unassigned incidents and incidents already under investigation. Filters should help organise work, not make lower-severity activity permanently invisible.

Severity is a triage input, not a complete business-risk assessment. Consider the affected account or device, the apparent attack progression and whether activity is continuing. An incident affecting an administrator or a critical server can require different handling from a similar detection on a less sensitive asset. Record this business context explicitly rather than expecting the detection severity to represent it.

Assign an owner when triage begins. Ownership should identify who is coordinating the investigation, even when several specialists contribute.

Move the incident from Active to In progress when investigation is underway. Keep status aligned with actual work rather than using it merely to tidy the queue.

Use tags and comments consistently. Define a small set of useful organisational tags, such as an escalation team or business service, rather than allowing uncontrolled variations.

Recheck incidents as evidence develops. Microsoft Defender XDR can add related alerts to an incident, so the scope observed at initial triage may change. At shift handover, pass on the incident identifier, current assessment, completed actions, unresolved questions and next owner. A queue entry without this context is not a reliable handover.

3. Investigate the incident, not just its title

Open an incident and establish a working hypothesis from its summary, alerts and affected assets. Treat the title as an orientation aid rather than a final finding. Review the attack story and supporting evidence to understand how the detections relate to one another and which parts of the apparent sequence remain unconfirmed.

A useful initial investigation answers four questions: what happened, which entities are involved, whether the activity is still occurring and what evidence supports the assessment. Separate observed facts from assumptions. For example, a malicious email detection does not by itself establish that the recipient executed a payload or that their endpoint was compromised.

Review the alerts and their timestamps. Identify the earliest relevant activity visible in the incident, then look for subsequent activity rather than assuming alert arrival order equals attack order.

Inspect affected users, devices, mailboxes and other entities. Use their investigation pages to establish relevant context and look for related detections.

Review evidence such as files, URLs, IP addresses and processes where available. Assess each item in context; its presence in an incident is not automatically a verdict that it is malicious.

Check investigation and response activity already associated with the incident. Determine what automation or another analyst has completed before repeating an action.

Use the connected evidence to test the hypothesis. For a suspected phishing-led compromise, distinguish email delivery from user interaction, endpoint execution and subsequent identity activity. These are separate investigative questions, and the evidence available depends on the deployed services and telemetry. If a stage cannot be confirmed, record the gap rather than filling it with inference.

Before escalating, write a short evidence-based summary: suspected entry point, affected assets, observed behaviour, actions taken and remaining uncertainty. This gives the next responder something more useful than a screenshot or a copied incident title.

4. Coordinate response and close with a defensible record

Response should follow the evidence and your organisation’s authority model. Microsoft Defender XDR connects incident investigation with response capabilities, but the available actions depend on the relevant service, asset support, permissions and configuration. Do not assume every entity in an incident has the same response options.

For example, isolating a supported device through Microsoft Defender for Endpoint can limit its communication while retaining connectivity to the Defender service. That can be appropriate containment, but it can also interrupt business activity. Before acting, confirm the target, the justification and any required approval. Where immediate action is authorised, record the decision and notify the responsible service owner.

Review the Action center for pending and completed actions. Automated investigation and remediation behaviour varies with supported workloads and configuration; some actions can require approval. Distinguish an investigation finding from a proposed action, and distinguish a proposed action from one that completed successfully. A pending remediation must not be reported as completed containment.

Record the reason for each material response action, including the affected entity and the expected security outcome.

Check action status and investigate failures. Selecting an action is not sufficient evidence that it succeeded.

Coordinate endpoint, identity and email work under the incident owner so that one team’s actions do not leave another team with an outdated assessment.

Resolve the incident when the investigation and required response work meet your closure criteria. Apply the appropriate classification, such as True positive, Informational, expected activity, or False positive, and add the supporting explanation. Expected legitimate activity is not the same analytical conclusion as an incorrect detection. A resolved incident should show what happened and why the team considers the work complete; it does not independently prove that every underlying weakness has been remediated.

5. Use a small hunting query to understand alert activity

Advanced hunting provides a query-based way to explore available security data. Start with a narrow question rather than a complicated detection query. The following Kusto Query Language query counts alert records from the last seven days by service source and severity using the AlertInfo table:

AlertInfo
| where Timestamp >= ago(7d)
| summarize AlertCount = count() by ServiceSource, Severity
| order by AlertCount desc

Run it in Advanced hunting in the Microsoft Defender portal with an account authorised to query the relevant data. The result provides a simple view of which services and severity levels are represented in the accessible alert records. It can help orient an analyst before they examine specific incidents.

Interpret the result carefully. This query counts alerts, not incidents, and it does not measure attack success or security effectiveness. Multiple alerts can contribute to one incident. A service with no returned rows might have no alerts in the selected period, but licensing, deployment, permissions and data availability must also be checked. Do not use this query alone to validate telemetry health.

Use hunting to answer specific questions raised during triage, then bring the findings back into the incident record. Later in this series, we will build on this approach with queries for endpoint, email and identity investigations.

6. Short readiness checklist

Coverage: the team knows which security services are deployed and which assets remain outside their coverage.

Access: analyst accounts have been tested for incident visibility, supporting evidence and permitted response actions.

Queue management: ownership, status updates, escalation criteria and shift handovers follow a documented process.

Investigation: notes distinguish confirmed evidence, working hypotheses and missing information.

Response: pending approvals, completed actions and failures are checked rather than assumed.

Closure: resolved incidents include a supported classification, a concise outcome and any outstanding remediation work.

7. Conclusion: build the workflow before adding complexity

The value of Microsoft Defender XDR is not simply having security information in one portal. It is the ability to connect related evidence and manage an investigation through a shared incident. That requires deployment coverage, appropriate access and consistent analyst decisions.

Begin with a manageable operating routine: review the queue, assign ownership, validate the evidence, coordinate proportionate response and document closure. Use hunting to answer focused questions, not to replace incident management. In Part 2, we examine Microsoft Defender for Office 365 Safe Links and Safe Attachments, and how those protections contribute to the wider investigation workflow.

Microsoft Defender XDR overview

Microsoft Defender XDR unified role-based access control

Incidents and alerts in Microsoft Defender XDR

Investigate incidents in Microsoft Defender XDR

Manage incidents in Microsoft Defender XDR

AlertInfo table reference for advanced hunting

Originally published on Solution Savy. Need help with this? Book a consultation.