Defender XDR

Microsoft Defender XDR ties together Defender for Endpoint, Defender for Office, Defender for Identity, and Defender for Cloud Apps into a single incidents + alerts pipeline. Manage365 pulls that pipeline for every customer tenant that's got the right GDAP roles, rolls it up into a portfolio view, and gives you a single surface for triage and response.

What you get

1. Cross-tenant portfolio rollup — every Defender incident across every tenant, in one list, with severity + status filters
2. Per-tenant detail — incidents, the alerts that rolled up into each incident, and recommendation data (secure score improvements)
3. Incident updates — update status, classification, determination, and assigned-to from the Manage365 UI. Changes flow back to Defender.
4. Skipped-tenant visibility — tenants missing the Security roles show up with a clear “skipped” badge rather than quietly dropping out

Cross-tenant portfolio rollup

On the Defender XDR → Portfolio page:

• Every Incident from every tenant, newest first
• Filter by severity (low / medium / high / informational), status (active / resolved / redirected), assigned-to, classification, and tenant
• Click an incident to open its per-tenant detail page with full alert list

The rollup refreshes every 15 minutes. Manual refresh button on the page — handy right after you close an incident in the Defender portal directly.

Per-tenant detail

The per-tenant Defender view splits into three panels:

Incidents

Matches the Defender portal's Incidents queue — severity, status, assigned-to, classification, determination, alert count, affected entities, first + last activity timestamps.

Alerts (alerts_v2)

Manage365 uses the alerts_v2 API (the newer schema). You see category, MITRE technique, evidence list, description — everything Defender knows about a given detection.

Alerts are listed standalone (for alerts not yet correlated into an incident) and nested under their parent incident.

Recommendations

Secure score improvement actions specific to the tenant — e.g. Enable multi-factor authentication for all usersor Turn on audit log retention. Click-through to Defender portal for each.

Incident updates

You can update four fields on an incident:

• Status — active → resolved (or back to active if it re-opens)
• Classification — true_positive, false_positive, informational_expected_activity
• Determination — the nature of the event (apt, malware, security_personnel, phishing, etc.) — only meaningful when classification is true_positive
• Assigned-to — a user principal name in the customer tenant

Changes are written via the Graph Security API (POST /security/incidents/{id}). The update takes 10–30 seconds to propagate back into the Defender portal. Manage365 refreshes the local cache immediately so the UI reflects the change.

Example update

PATCH /defender/tenants/:tenantId/incidents/:incidentId
{
  "status": "resolved",
  "classification": "true_positive",
  "determination": "phishing",
  "assignedTo": "sec-lead@acmehealth.com.au"
}

Skipped tenants

The cross-tenant pull needs the SecurityIncident.Read.All and SecurityAlert.Read.All Graph application permissions, delegated via GDAP. Tenants where these aren't granted are skipped rather than errored out — the portfolio view shows them with a “skipped: missing Security roles” badge.

To fix, add Security Administrator (read is enough) to the tenant's GDAP relationship. The next scheduler tick picks up the new permissions and unskips the tenant — no restart needed.

The skip list is visible on Defender XDR → Health so you know which tenants are missing data. Don't take an empty portfolio as “nothing's happening” without checking the skip list first.

Endpoints

End-to-end example: morning triage

1. Open Defender XDR → Portfolio. Filter to severity high + critical, status active.
2. Three incidents from the last 12 hours across two tenants.
3. Open the first — a credential access alert. Alert detail shows the source IP, the MITRE technique, the affected user. Looks like a real attempt.
4. Classify as true positive / credential access, assign to the senior tech, change status to in progress via status → active with a comment.
5. Kick off a compromise remediation playbook on the affected user — disable + revoke + reset + clear forwarding.
6. Close the incident in Defender with status: resolved, classification: true_positive.

Common pitfalls

• Portfolio showing zero incidents — check Defender XDR → Health. Most common cause is every tenant being in the skip list because the Security roles weren't added to your default GDAP invite.
• Classification dropdown disabled — classification is only meaningful on resolved incidents. Close the incident first, then classify.
• Updates not appearing in Defender portal — normal lag is 10–30 seconds. Over 2 minutes suggests a Defender API hiccup. Check the audit entry — Manage365 logs both the outbound call and Microsoft's response.
• Assigned-to rejected — must be a user in the customer tenant, not an MSP user. Defender doesn't know about your techs; only customer UPNs are valid.

FAQ

Does Manage365 run hunting queries? Not directly. Advanced hunting KQL lives in the Defender portal. Manage365 surfaces the incident-level picture and flows corrective actions back — the KQL engine stays where Microsoft runs it.

Can I filter by MITRE technique? On the per-tenant alerts panel, yes. On the cross-tenant portfolio, not yet — filters there are severity / status / classification.

What counts as an incident re-open? If you resolve an incident and Defender later raises a new alert that correlates into the same incident, status flips back to active. Manage365's alert system raises a medium alert on re-open with dedupe key defender.incident.reopen.<incidentId>.