What is MDR (Managed Detection and Response)?

Marketing pages for MDR read alike, so it helps to read one provider's documentation instead. Microsoft Learn describes Defender Experts MDR as a managed detection and response service in which Microsoft analysts manage the customer's incident queue around the clock, triage and investigate incidents, and either take action or guide the customer's team through the response. Microsoft says the service augments a SOC rather than replacing it.

• Plan 1 covers Microsoft Defender workloads and is the service previously sold as Defender Experts for XDR.
• Plan 2 extends the same work to selected non-Microsoft sources collected in Microsoft Sentinel, such as Okta, Proofpoint TAP, AWS CloudTrail and Palo Alto PAN-OS.

The service boundaries list what is excluded. Plan 2 is not a managed SIEM, so the customer still owns connectors, ingestion, retention and its own analytics rules, and neither plan is an incident response engagement for an active compromise. The FAQ narrows the scope again: High and Medium severity incidents on Windows, Linux and macOS devices are in; DLP, compliance and custom detection incidents, and IoT, iOS and Android devices, are out.

MDR contracts differ most on who is allowed to act

NIST SP 800-61 Rev. 3 calls outsourced incident handling a shared responsibility model: the organization transfers some of its responsibilities to a provider, the contract should define them, and the incident response team should know the division of responsibilities, including information flows, coordination and authority to act on behalf of the organization. NIST's example of a restriction is whether the provider may make operational decisions such as deactivating a service to contain an incident. Joint advisory AA22-131A, from CISA, NSA, FBI and the UK, Australian, Canadian and New Zealand agencies, says the same from the contract side: the contract should state whether the provider or the customer owns responsibilities such as hardening, detection and incident response.

In Defender Experts MDR that authority is a permission chosen at onboarding.

• The default option, Investigate incidents and guide my responses, gives the experts Security Reader access: they investigate and post the actions for your team to perform.
• The recommended option, Respond directly to active threats, gives them Security Operator access, and they can run the actions themselves.

The one-click actions are isolate device, quarantine file, restrict app execution, disable user, and the two undo actions for isolation and app restriction. Customers can also exclude device groups and Entra ID user groups from remediation; for those, the experts send guidance instead of acting.

Expert access runs through granular delegated admin privileges and just-in-time role requests, and it is audited in the customer's Entra ID sign-in logs. NIST gives the reason to review them: service providers often hold privileged access to customer systems, so the risk of a malicious insider at the provider, or of the provider itself being compromised, has to be planned for.

The incident record shows who holds the case at each step

• When the experts pick up an incident they set Assigned to to Defender Experts and Status to In progress.
• They resolve false positives and expected activity themselves and set Assigned to back to Unassigned.
• For a true positive with Security Operator access, they take the actions, resolve the incident and assign it to Customer for review.
• With Security Reader access they set Status to Awaiting Customer Action and Assigned to to Customer, and the incident notification contacts get an email, plus a Teams message if that channel is set up.

Microsoft Sentinel has no matching status, so the same handoff shows there as an Awaiting Customer Action tag with Customer as owner.

One incident through that workflow

(Simulated example generated by SOCSimulator Research; hosts and accounts are invented.) A 900-seat insurance broker kept the default guide-only access and excluded its finance servers from remediation. On a Saturday at 01:31 UTC, workstation ws-mkt-019 opens an RDP session to file server fs-fin-02 as svc-backup, a service account with no reason to log on interactively. At 01:52 Defender for Endpoint records this on the server:

DeviceProcessEvents | Timestamp 2026-10-10T01:52:07Z | DeviceName fs-fin-02 | AccountName svc-backup | InitiatingProcessFileName cmd.exe | FileName vssadmin.exe | ProcessCommandLine vssadmin.exe delete shadows /all /quiet

ATT&CK lists that exact command under Inhibit System Recovery (T1490), and its procedure examples include the Akira ransomware deleting volume shadow copies. The rest of the night, in incident fields:

• 01:52, a High severity incident groups the RDP logon and the shadow copy deletion.
• 01:58, a provider analyst takes it (Assigned to Defender Experts, In progress).
• 02:16, true positive; three pending actions: isolate ws-mkt-019, isolate fs-fin-02, disable svc-backup; Status becomes Awaiting Customer Action and the on-call IT manager's phone lights up.
• 02:49, the IT manager signs in.
• 02:53, all three actions show Completed.

Read that as two clocks

Alert to recommendation took 24 minutes and belongs to the provider. Recommendation to containment took 37 minutes and belongs to the customer. If the provider's response metric stops at the recommendation, those 37 minutes appear in nobody's report. With Security Operator access the analyst could have isolated ws-mkt-019 and disabled svc-backup at 02:16. The file server would still have waited for a person, because the finance servers are excluded. Excluding them can be the right call, but write down who made it and why.

You can measure your half from the incident audit trail. The SecurityIncident table in Microsoft Sentinel writes a new record every time an incident is created or changed, so the latest state of each incident needs arg_max. This lists open incidents waiting on your team:

SecurityIncident
| where TimeGenerated > ago(30d)
| summarize arg_max(TimeGenerated, *) by IncidentNumber
| where Status != "Closed" and tostring(Labels) has "Awaiting Customer Action"
| extend WaitingHours = datetime_diff('hour', now(), LastModifiedTime)
| project IncidentNumber, Title, Severity, LastModifiedTime, WaitingHours
| sort by WaitingHours desc

LastModifiedTime moves with any later edit, a comment included, so WaitingHours is a lower bound; the incident history has the exact handoff time.

MDR vs EDR, XDR and MSSP

EDR and XDR are technologies; MDR is a service that runs on them. EDR records processes, files and connections on each endpoint and offers actions such as isolation. XDR correlates endpoint, identity, email and cloud signals into incidents. MDR adds the analysts who read those incidents at 2 a.m. and the agreement on what they may do about them. MSSP is the wider label: NIST's example of on-contract incident handlers is a SOC outsourced to a managed security services provider, and CISA counts cybersecurity services among what an MSP may deliver. The names overlap in practice, so compare contracts on four points:

1. whose analysts investigate,
2. which response actions the provider may take,
3. which telemetry is in scope,
4. and who owns the SIEM.

Three more points from the primary sources belong in any evaluation

NIST notes that a provider may detect malicious activity sooner than a single organization, because it correlates events across customers and can use what it learned at one customer to protect the others.

The other side is context. The provider's analysts start without knowing which admin accounts touch production, which vendor connects over VPN at night, or which backup job legitimately deletes shadow copies, and that has to be written down at onboarding and kept current.

Last, retention. AA22-131A recommends keeping the most important logs for at least six months because incidents can take months to detect, so check whose storage covers that window.