Most MSPs I talk to are still triaging Defender alerts one console at a time. Open Defender for Endpoint, jump to Defender for Office 365, check Entra sign-in logs, back to the device timeline. Five tabs, five clocks, no story.
That’s not response. That’s archaeology.
Defender XDR fixed this. The unified incident queue sits in the Microsoft Defender portal and stitches signals from Endpoint, Office 365, Identity, Cloud Apps and Entra into a single container called an incident. One incident, one timeline, one place to act.
If you’re still working from individual alert lists, you’re doing the correlation work the platform already did for you.
What is the unified incident queue, really?
An alert is one signal — a flagged email, a process anomaly, a risky sign-in. An incident is what Defender builds when it stitches several of those alerts into one attack story across products. Same user, same device, same attacker IP, same hour, one incident.
You stop looking at noise and start looking at attacks. Microsoft frames it exactly that way in Incidents and alerts in the Microsoft Defender portal.
Notice what’s missing? Sentinel. You don’t need it to get value from this queue.
Step-by-Step: Working an incident properly
Open the queue
In security.microsoft.com, expand Investigation & response > Incidents & alerts > Incidents. That’s your home page now. Pin it.
Triage the top of the list
Sort by Severity. For each new incident, assign an owner, set status to In progress, and add a tag like ransomware-suspect or bec-suspect so the rest of your team can filter on it. Microsoft walks through this on Manage incidents in Microsoft Defender.
Open the attack story
Inside the incident, click Attack story. You get a graph — users, devices, files, mailboxes — with events in order. This is where the correlation pays off. You’re not joining tabs in your head anymore.
Hunt for the rest of it
If the incident feels like one footprint of a bigger campaign, open Hunting > Advanced hunting and run a KQL query against the relevant table. Bookmark the Advanced hunting overview(opens in new window) — it lists every table the queue can see across all the Defender workloads.
A starter:
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("Invoke-WebRequest","DownloadString","certutil")
| project Timestamp, DeviceName, AccountName, ProcessCommandLineNotice what’s missing? PowerShell. You’re not running this from a remote shell. It runs in the portal, against the same data the incident was built from. That’s the point.
Save the good queries as detections
Any hunting query you’d happily wake up to at 3am can become a custom detection rule. From Advanced hunting, hit Create detection rule. Defender runs your query on a schedule and the matches feed straight back into the incident queue. The flow is documented in the Custom detections overview.
That’s the loop. Hunt once, detect forever.
Why this actually changes behaviour
“Where do I start?” becomes “What story is Defender telling me?”
When the queue is your home page, your team stops chasing alerts and starts closing incidents. The numbers you report to clients become incidents closed, median time to triage, active attack stories — not raw alert counts nobody can interpret.
The custom detection layer is where MSPs separate themselves. The product gives you the correlations Microsoft thought of. The rules you write are the correlations your clients need. Stack a few by vertical — finance, legal, construction — and you have a productised security service the next MSP down the road doesn’t.
The unified queue isn’t there to give you fewer alerts. It’s there to make alerts something you can actually work.
CIAOPS 