MDR Alert Fatigue: 5 Diagnostic Tests to Determine if Your Provider is All Alert, No Action

Your MDR provider just escalated an alert for suspicious authentication activity. The ticket contains a timestamp, an IP address, and a generic MITRE ATT&CK reference. What it doesn't contain: the affected user account, the asset criticality, whether the source IP is known infrastructure, or any actual containment action taken. Your senior analyst now spends 45 minutes gathering context that should have been included, determining scope, and deciding if a password reset is actually warranted.

This scenario plays out daily in organizations paying premium rates for Managed Detection and Response services that have quietly shifted the response burden back to internal teams. When evaluating MDR effectiveness in 2026, the distinction between monitoring-as-a-service and true managed response has never been more critical. The following five diagnostic indicators—derived from observed failures in current MDR delivery models—will help you determine whether your provider functions as a force multiplier or an expensive alert forwarding service.

Technical Analysis: The Alert-vs-Action Gap

Modern MDR services typically operate on a telemetry ingestion model: they collect logs from your EDR, firewall, identity providers, and cloud infrastructure, apply detection logic (often proprietary or open-source rulesets like Sigma), and generate alerts. The failure mode occurs in the handoff.

The Architecture of Failure

When an MDR provider exhibits the "all alert, no action" pattern, specific technical gaps emerge in their operational workflow:

1. Context Stripping: Alerts arrive without enrichment (asset inventory lookups, user risk scores, historical behavior baselines)
2. Investigation Asymmetry: The provider performs initial triage but stops before containment, requiring your team to execute response actions via their own consoles
3. Feedback Loop Absence: Recurring false positives are not tuned out; the same low-fidelity alerts fire repeatedly without rule modification
4. Capability Misalignment: Marketing materials promise "full response" but contract language limits provider actions to "notification and recommendation"

The risk isn't merely inefficiency—it's dwell time extension. When your analysts must reconstruct investigative steps the MDR should have completed, attackers gain additional persistence windows. In ransomware intrusions, the delta between detection and containment often determines whether you face a nuisance event or a business-ending encryption incident.

Detection & Response: Identifying MDR Performance Failures

Since this represents an operational failure rather than a specific software vulnerability, detection focuses on identifying the patterns of inadequate service delivery through your existing ticketing and communication channels.

Sigma Rules: Identifying Recurring Low-Fidelity Alerts

These rules help identify when your MDR is generating noise rather than signal, indicating tuning failures.

---
title: MDR Recurring False Positive Pattern - Identical Source and Signature
id: 8f7e6d5c-4b3a-29c8-1d0e-9f8e7d6c5b4a
status: experimental
description: Detects when the same source IP triggers identical alert signatures repeatedly without resolution, indicating MDR tuning failure
references:
  - https://www.rapid7.com/blog/post/five-signs-your-mdr-is-all-alert-no-action
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.exfiltration
  - attack.t1071
logsource:
  category: firewall
  product: generic
detection:
  selection:
    action: 'alert'
    signature_id|contains: 'mdr_generated'
  condition: selection | count() by source_ip, signature_id > 5
falsepositives:
  - Persistent scanning from legitimate vulnerability scanners
level: medium
---
title: MDR Alert Without Context Enrichment
id: 7e6d5c4b-3a2b-19c8-2d1e-0f9e8d7c6b5a
status: experimental
description: Identifies MDR-generated alerts lacking basic asset or user context, indicating investigation homework being passed to internal teams
references:
  - https://www.rapid7.com/blog/post/five-signs-your-mdr-is-all-alert-no-action
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.discovery
  - attack.t1087
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine|contains:
      - 'whoami'
      - 'hostname'
      - 'ipconfig'
    ParentImage|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
  condition: selection
falsepositives:
  - Legitimate administrative troubleshooting
level: low

KQL (Microsoft Sentinel): MDR Ticket Context Quality Analysis

Use this query to audit the actual context provided in MDR escalations versus the work required by your internal team.

// Hunt for MDR alerts that lack basic enrichment - indicating "homework" being passed back
SecurityAlert
| where TimeGenerated > ago(30d)
| where ProviderName contains "MDR" or AlertName contains "MDR"
| extend HasUserContext = isnotempty(CompromisedEntity), HasAssetContext = isnotempty(RemediationSteps)
| where HasUserContext == false or HasAssetContext == false
| summarize MissingContextCount = count() by AlertName, ProviderName
| where MissingContextCount > 10
| sort by MissingContextCount desc

Velociraptor VQL: Endpoint Validation of MDR Claims

When your MDR claims to have "investigated" an endpoint but you suspect they haven't actually collected forensic artifacts, use this VQL to verify their investigation depth.

-- Verify if MDR actually collected triage data or merely forwarded EDR telemetry
SELECT 
    Fqdn,
    ProcessName,
    CommandLine,
    Hash,
    Timestamp
FROM glob(globs='C:\ProgramData\MDR*\**\*.json')
WHERE Timestamp > ago(24h)

PowerShell: MDR SLA Compliance Auditor

This script audits your MDR's response time against contractual SLAs and checks for actual containment actions versus mere notifications.

# MDR Service Quality Assessment Script
# Analyzes ticket history to determine if provider is delivering response or just alerts

param(
    [Parameter(Mandatory=$true)]
    [string]$TicketingSystemAPI,
    
    [Parameter(Mandatory=$true)]
    [string]$APIKey,
    
    [int]$DaysToAnalyze = 30
)

$headers = @{
    'Authorization' = "Bearer $APIKey"
    'Content-Type' = 'application/json'
}

$startDate = (Get-Date).AddDays(-$DaysToAnalyze).ToString('yyyy-MM-dd')
$uri = "$TicketingSystemAPI/tickets?created_after=$startDate&tag=mdr_escalation"

$tickets = Invoke-RestMethod -Uri $uri -Headers $headers -Method Get

$analysis = foreach ($ticket in $tickets) {
    $actions = $ticket.actions_taken
    $containsContainment = $actions -match 'isolate|block|disable|reset'
    $containsInvestigation = $actions -match 'reviewed|analyzed|correlated'
    
    [PSCustomObject]@{
        TicketID = $ticket.id
        AlertType = $ticket.category
        TimeToAck = ($ticket.acknowledged_at - $ticket.created_at).TotalMinutes
        TimeToAction = if ($containsContainment) { ($ticket.actioned_at - $ticket.created_at).TotalMinutes } else { $null }
        HasContainment = $containsContainment
        RequiresInternalFollowup = $ticket.status -eq 'pending_client_action'
        ContextComplete = ($ticket.custom_fields.user_context -and $ticket.custom_fields.asset_criticality)
    }
}

$metrics = @{
    TotalAlerts = $analysis.Count
    AlertsWithContainment = ($analysis | Where-Object {$_.HasContainment}).Count
    AlertsRequiringHomework = ($analysis | Where-Object {$_.RequiresInternalFollowup}).Count
    AverageTimeToAction = ($analysis | Where-Object {$_.TimeToAction} | Measure-Object -Property TimeToAction -Average).Average
    ContextCompleteRate = (($analysis | Where-Object {$_.ContextComplete}).Count / $analysis.Count) * 100
}

Write-Host "=== MDR Effectiveness Report ===" -ForegroundColor Cyan
Write-Host "Analysis Period: Last $DaysToAnalyze days"
Write-Host "Total Alerts Received: $($metrics.TotalAlerts)"
Write-Host "Alerts with Autonomous Containment: $($metrics.AlertsWithContainment) ($([math]::Round(($metrics.AlertsWithContainment/$metrics.TotalAlerts)*100,2))%)"
Write-Host "Alerts Requiring Internal Follow-up: $($metrics.AlertsRequiringHomework) ($([math]::Round(($metrics.AlertsRequiringHomework/$metrics.TotalAlerts)*100,2))%)"
Write-Host "Average Time to Containment Action: $([math]::Round($metrics.AverageTimeToAction,2)) minutes"
Write-Host "Context Completion Rate: $([math]::Round($metrics.ContextCompleteRate,2))%"

if ($metrics.AlertsRequiringHomework / $metrics.TotalAlerts -gt 0.4) {
    Write-Host "`nWARNING: High homework-to-action ratio indicates MDR may be 'all alert, no action'" -ForegroundColor Red
    Write-Host "Recommendation: Review contract SLA for 'response' definitions and consider provider escalation."
}

Remediation: Contractual and Operational Corrections

If your assessment reveals your MDR operates primarily as an alert forwarding service, take these specific actions:

1. Contract Renegotiation (Immediate)

• Define "response" explicitly in your MSA: Specify whether provider can isolate hosts, disable accounts, or block IPs without pre-approval
• Establish Context Requirements: Mandate that escalations include affected user, asset criticality score, and initial triage notes
• Set Tuning SLAs: Require false positive reduction within 72 hours of reporting, with credits for recurring identical false positives

2. Technical Integration Hardening

• Deploy bidirectional API integration: Ensure your MDR can execute containment actions via your EDR (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) rather than merely recommending them
• Implement automated context enrichment: Use SOAR playbooks to append asset inventory and user risk scores to MDR tickets before they reach your analysts
• Create escalation thresholds: If MDR alerts require internal action more than 30% of the time, trigger automatic service review

3. Alternative Service Models If remediation fails, consider shifting to:

• Co-managed SOC: Retain control of response while outsourcing monitoring
• Incident Response Retainers: For organizations with mature internal teams who only need surge capacity
• Outcome-based MDR: Providers who accept liability for dwell time and containment success rates

4. Validation Testing Conduct quarterly purple team exercises specifically designed to test MDR response capabilities:

• Execute controlled attacks mimicking ransomware precursors (lateral movement, shadow copy deletion)
• Measure time from detection to actual containment (not notification)
• Verify the provider performs memory forensics or merely forwards EDR alerts

The Five Signs Checklist for 2026

As referenced in the Rapid7 analysis, evaluate your current provider against these criteria:

1. Every alert arrives with homework: If >40% of escalations require your team to gather basic context (IP reputation, asset owner, user department), the service is shifting operational burden
2. Recurring false positives persist: The same signature firing on the same benign activity weekly indicates absent feedback loops
3. Response stops at notification: If your MDR cannot execute containment actions (isolate host, disable account) but only recommends them, you're paying for monitoring, not response
4. Alert volume exceeds actionable intelligence: High-fidelity alerts should be rare; daily "critical" alerts often indicate poor tuning
5. No proactive threat hunting: Modern MDR should identify threats you didn't know to look for, not just validate alerts your EDR already generated

Conclusion

The MDR market has bifurcated into true managed response services and rebranded alert monitoring. In 2026, with attacker dwell times averaging under 24 hours for ransomware deployment, the difference between "alert" and "action" determines whether an intrusion becomes an incident or a breach.

Use the detection queries and audit scripts provided here to hold your provider accountable. If the data shows you're paying premium rates for homework assignments, it's time to renegotiate or transition to a provider that brings capacity and expertise—not just more tickets.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub