Module 3: Defender XDR Portal Navigation

The Microsoft Defender portal at security.microsoft.com is the single interface where you will spend most of your operational time as a SOC analyst working in a Microsoft 365 environment. It consolidates incident management, alert triage, advanced hunting, threat intelligence, and response actions across every Microsoft security service — Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, and Microsoft Sentinel.

As of 2025, Microsoft began migrating all Sentinel workspaces into this portal. The Azure portal for Sentinel is scheduled for retirement on 31 March 2027. If you are starting your security career now, this is the portal you will learn. There is no reason to learn the old Azure-based Sentinel interface.

(Source: What’s new for unified security operations — Microsoft Learn)

This module walks through the portal layout, the incident-alert-evidence data model, and the operational workflows you will use daily. No KQL is required — that was Module 2. This is about knowing where everything lives so that when an alert fires at 02:00, you are not hunting for the right button.

The Portal Layout

When you sign in to security.microsoft.com, the left navigation pane organises the portal into functional areas. The sections you will use most as an analyst:

Investigation & response — This is your primary workspace.

• Incidents & alerts → Incidents: The unified incident queue. Every security event that warrants investigation appears here. This is where you start your shift.
• Incidents & alerts → Alerts: The raw alert queue. Individual detection signals before they are correlated into incidents.
• Hunting → Advanced hunting: The KQL query editor. This is where you run the queries from Module 2 against live data from both Defender XDR tables and Sentinel tables.
• Actions & submissions → Action center: Pending and completed response actions — device isolations, file quarantines, email purges.

Threat intelligence — Threat analytics dashboards showing active campaigns, CVEs, and trending attack techniques relevant to your environment.

Assets — Inventories of devices, identities, and applications. When an alert references a specific device or user, you pivot here for full entity context.

Microsoft Sentinel — If your workspace is onboarded to the Defender portal, Sentinel features appear here: workbooks, analytics rules, automation rules, data connectors, and the content hub. These were previously only accessible in the Azure portal.

Settings — Portal-wide configuration including notification rules, RBAC, alert tuning rules, and service-specific settings.

(Source: Microsoft Defender XDR in the Defender portal — Microsoft Learn)

The Incident-Alert-Evidence Hierarchy

Understanding how the portal structures security data is more important than memorising menu locations. The data model has three layers, and confusing them is the most common mistake new analysts make.

Alerts

An alert is a single detection signal. It represents one suspicious or malicious event identified by one detection engine. Examples: “A user clicked a malicious URL in an email”, “A process executed a known malware binary”, “An impossible travel sign-in was detected.”

Alerts are produced by multiple sources — Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, Sentinel analytics rules, and third-party integrations. Each alert has a severity (Informational, Low, Medium, High), a detection source, a MITRE ATT&CK classification, and one or more associated entities (users, devices, mailboxes, IPs, files).

(Source: Investigate alerts — Microsoft Learn)

Incidents

An incident is a container of related alerts that together tell the story of an attack. The Defender correlation engine automatically groups alerts that share entities, timelines, or attack patterns. A single incident might contain an email delivery alert from Defender for Office 365, a sign-in anomaly from Entra ID Protection, a suspicious process execution from Defender for Endpoint, and a data exfiltration alert from Defender for Cloud Apps — all connected because they involve the same user account within a short time window.

Incidents are the unit of work for SOC analysts. You triage incidents, not individual alerts. The incident page shows the full attack story: a timeline of alerts, all affected entities, automated investigation results, and recommended response actions.

(Source: Incidents and alerts in the Defender portal — Microsoft Learn)

Evidence

Evidence is the raw data that supports alerts within an incident. Evidence items include user accounts, devices, IP addresses, email messages, files, processes, registry keys, and mailbox rules. The Evidence and Response tab on each incident page lists all collected evidence and any response actions — pending, approved, or completed.

The hierarchy in practice: An attacker sends a phishing email (Alert 1: malicious email detected). The recipient clicks the link (Alert 2: URL click event). The attacker captures credentials and signs in from an anomalous location (Alert 3: risky sign-in). The attacker creates an inbox forwarding rule (Alert 4: suspicious inbox rule). Defender correlates all four alerts into a single incident because they share the same user entity and occur within a narrow time window. The evidence tab lists the email message, the URL, the sign-in record, and the inbox rule — each with available response actions.

Working the Incident Queue

The incident queue at Incidents & alerts → Incidents is where every shift starts. It displays all active incidents sorted by priority score.

Priority Scoring

Defender assigns each incident a priority score from 0 to 100. The scoring algorithm considers alert severity, the number and type of affected assets, whether critical assets are involved, the presence of high-profile threat types such as ransomware or nation-state activity, and behavioural signals. Scores are colour-coded: red for high priority, orange for medium, yellow for low.

(Source: Prioritize incidents — Microsoft Learn)

Filtering the Queue

The default queue shows all active incidents. For effective triage, filter immediately. The most useful filters:

• Status: Active, In Progress, Resolved. Start with Active.
• Severity: High, Medium, Low, Informational. During a shift, work High first, then Medium.
• Service/detection source: Filter to specific products — Defender for Office 365, Defender for Endpoint, Sentinel, etc. Useful when you are responsible for a specific workload.
• Assigned to: Filter to your own assignments, or to unassigned incidents that need an owner.
• Tags: Custom tags applied during triage. Use these to mark incidents for escalation, track campaigns, or flag false positives.

Once you have configured a useful filter combination, bookmark the browser URL. Cloudflare or your browser’s bookmark bar becomes your collection of saved queue views — one for “my active incidents”, another for “unassigned high severity”, another for “Office 365 phishing this week.”

Incident Triage Workflow

When you open an incident from the queue:

1. Read the Summary tab first. It shows the priority score, a Copilot-generated summary (if licensed), affected entities, the MITRE ATT&CK tactics involved, and similar incidents. This gives you the attack narrative in 30 seconds.

2. Review the Attack Story tab. This is the visual timeline of how alerts relate to each other and to entities. It shows the sequence of events and the connections between them — which user was involved, which device, which email, which IP. If the incident is genuine, this tab tells you the scope.

3. Check the Alerts tab. Each alert within the incident has its own detail view. Open alerts you do not recognise to understand what detection logic produced them and what evidence they reference.

4. Examine Evidence and Response. This tab lists every piece of evidence and any response actions that have been taken or are pending. Automated investigation may have already quarantined a file or blocked a URL. Review pending actions and approve or reject them.

5. Take action. Based on your assessment, either resolve the incident (with a classification of True Positive, False Positive, or Informational), escalate it, or begin manual investigation using Advanced Hunting.

(Source: Investigate incidents — Microsoft Learn)

Managing Incidents

Every incident supports the following management actions:

• Assign: Assign to yourself or another analyst. Ownership drives accountability.
• Classify: True Positive (specify threat type), False Positive, or Informational. Classification feeds the machine learning models that tune future detection accuracy.
• Tag: Apply custom tags. Tags are free-text and searchable — use them consistently. Examples: “AiTM-Campaign”, “Escalated-to-Tier2”, “Awaiting-User-Response”.
• Comment: Add investigation notes. Comments are timestamped and attributed to the analyst. Use them to document your reasoning — what you checked, what you ruled out, what you escalated and why. This is your audit trail.
• Resolve: Mark the incident as resolved. Resolving an incident also resolves all linked active alerts.

(Source: Manage incidents — Microsoft Learn)

Alert Tuning

Alert noise is the number one complaint of SOC analysts. The Defender portal provides alert tuning (previously called alert suppression) to automatically hide or resolve alerts that match known benign patterns in your environment.

Navigate to Settings → Microsoft Defender XDR → Alert tuning. Create a rule by specifying conditions based on evidence types — file names, process names, IP addresses, email senders, and other indicators. When an alert matches the conditions, it is automatically resolved or hidden, and does not generate an incident.

Use alert tuning for:

• Scheduled tasks or monitoring tools that trigger process execution alerts
• Vulnerability scanners that generate network connection alerts
• Known internal IP ranges that trigger impossible travel detections
• Test accounts used for security assessments

Do not suppress alerts you have not investigated. Every tuning rule should be created after you have confirmed the pattern is genuinely benign — never proactively.

Advanced Hunting

The Advanced Hunting blade (Hunting → Advanced hunting) is where the KQL queries from Module 2 run against live data. The portal provides two modes:

KQL Mode

The full query editor. You write KQL directly against the available tables. In the unified portal, this includes both Defender XDR tables (DeviceProcessEvents, EmailEvents, IdentityLogonEvents, etc.) and Sentinel tables (SigninLogs, SecurityAlert, SecurityEvent, etc.) — all queryable from the same editor.

The schema browser on the left lists every available table, its columns, and data types. Use it as a reference while building queries.

30-day limit on Defender XDR tables: Queries against Defender XDR-native tables (those starting with Device*, Email*, Identity*, Cloud*, Alert*) are limited to a 30-day lookback. Sentinel tables connected via the unified workspace may have longer retention depending on your Log Analytics configuration.

Guided Mode

For analysts who are not yet comfortable writing KQL from scratch, guided mode provides a visual query builder. You select a table, add filters, choose columns, and the portal generates the KQL. It is useful for learning — you can see the KQL that the visual builder produces and modify it.

Custom Detection Rules

Any KQL query in Advanced Hunting can be promoted to a custom detection rule. This means the query runs on a schedule (every 1, 12, or 24 hours), and when it returns results, it generates alerts that flow into the incident queue.

This is how you operationalise your hunting. You write a query that finds suspicious behaviour, validate it returns true positives, then promote it to a detection rule. From that point forward, the portal alerts you automatically when the pattern recurs.

To create a custom detection rule from a query: run the query, verify results, then select Create detection rule from the results toolbar. Configure the alert title, severity, MITRE tactic, entity mapping, and schedule frequency.

Response Actions

The portal provides direct response actions without leaving the investigation context:

Device actions (Defender for Endpoint):

• Isolate device — cuts network access except to the Defender service
• Run antivirus scan
• Restrict app execution
• Collect investigation package
• Initiate live response session

User actions (Entra ID / Defender for Identity):

• Disable user account
• Revoke sign-in sessions (force reauthentication)
• Confirm user compromised (raises risk level)
• Reset password

Email actions (Defender for Office 365):

• Soft delete email from mailboxes
• Hard delete email
• Move to junk
• Block sender

File actions:

• Quarantine file
• Block file (add hash to indicator list)
• Download file for analysis

All response actions are logged in the Action Center (Actions & submissions → Action center), which provides a full history of what was done, by whom, and when.

Automatic Attack Disruption

Defender XDR includes automatic attack disruption — a capability that takes response actions without analyst intervention when high-confidence attack patterns are detected. When the correlation engine identifies an in-progress attack with sufficient confidence (such as active ransomware encryption or business email compromise with credential theft), it can automatically:

• Contain a compromised user account
• Disable a compromised device
• Suspend a malicious OAuth application

Disrupted incidents are clearly marked in the queue with a disruption tag. Review these incidents promptly — automatic disruption buys you time, but the investigation and full remediation still require an analyst.

(Source: Microsoft Defender XDR — Microsoft Learn)

Notification Rules

Configure how you receive alerts outside the portal. Navigate to Settings → Microsoft Defender XDR → Email notifications.

You can create notification rules that send email to specified recipients when incidents meet specific criteria — severity, detection source, or device group. Set up at least:

• A rule that emails your SOC distribution list for all High severity incidents
• A rule that emails the on-call analyst for incidents involving critical assets

Notification rules reduce the risk of an analyst missing a critical incident because they were not actively watching the queue.

RBAC in the Defender Portal

Role-Based Access Control determines what each analyst can see and do. The unified portal supports two RBAC models:

Microsoft Defender XDR Unified RBAC — The recommended model for organisations using the unified portal. Permissions are managed centrally and apply across all Defender services and Sentinel. Key built-in roles:

• Security Reader: View incidents, alerts, hunting data, and settings. Cannot take response actions.
• Security Operator: Everything a Reader can do, plus take response actions (isolate devices, quarantine emails, etc.).
• Security Administrator: Full access including configuration changes, alert tuning rules, custom detections, and RBAC management.

(Source: Planning guidance for unified security operations — Microsoft Learn)

Sentinel-specific RBAC — If your Sentinel workspace predates the unified portal migration, you may still have Azure RBAC roles (Sentinel Reader, Sentinel Responder, Sentinel Contributor) assigned at the resource group level. These continue to work in the Defender portal, but Microsoft recommends migrating to Unified RBAC for simplicity.

For the SC-200 exam, know that a minimum of Sentinel Reader at the resource group level is required for an analyst to see Sentinel data in the Defender portal.

SC-200 Exam Relevance

Two SC-200 objectives map directly to this module:

• Configure the Microsoft Defender portal: Expect questions about notification rules, alert tuning, RBAC roles, and which settings control what behaviour. The exam assumes you know where to find configuration options and what permissions are required.

• Manage incidents and alerts in Microsoft Defender XDR: Questions will test whether you can distinguish between incidents and alerts, select the correct triage action for a given scenario, and identify what automatic attack disruption does. Drag-and-drop sequencing questions on incident response workflows are common.

(Source: SC-200 study guide — Microsoft Learn)

Key Takeaways

• Triage incidents, not alerts. The incident is your unit of work. Alerts are the evidence that compose it.
• Filter the queue immediately. An unfiltered incident queue is noise. Bookmark your useful filter views.
• Read the Summary and Attack Story first. These tabs give you the narrative before you dive into individual alerts.
• Classify every incident you resolve. True Positive, False Positive, or Informational. This data trains the detection models.
• Use comments as your investigation journal. Every action you take and every hypothesis you rule out should be recorded. Your future self (or the analyst who inherits the incident) will thank you.
• Advanced Hunting is unified. Defender XDR and Sentinel tables are queryable from the same editor. There is no longer a reason to switch between portals.
• Automatic disruption buys time, not resolution. Always investigate disrupted incidents — the automation contained the threat, but did not eradicate it.

References

1. What’s new for unified security operations — learn.microsoft.com/en-us/unified-secops/whats-new
2. Microsoft Defender XDR in the Defender portal — learn.microsoft.com/en-us/unified-secops/defender-xdr-portal
3. Incidents and alerts overview — learn.microsoft.com/en-us/defender-xdr/incidents-overview
4. Investigate alerts — learn.microsoft.com/en-us/defender-xdr/investigate-alerts
5. Investigate incidents — learn.microsoft.com/en-us/defender-xdr/investigate-incidents
6. Manage incidents — learn.microsoft.com/en-us/defender-xdr/manage-incidents
7. Prioritize incidents (incident queue) — learn.microsoft.com/en-us/defender-xdr/incident-queue
8. Planning guidance for unified security operations — learn.microsoft.com/en-us/unified-secops/overview-plan
9. Incident response workflow — learn.microsoft.com/en-us/unified-secops/plan-incident-response
10. SC-200 study guide (January 2026 update) — learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/sc-200

Next module: Module 4: Entra ID Sign-In Log Analysis →