Why custom detections still fall outside MDR coverage

At a glance

What this is: This analysis argues that custom detections often sit outside MDR scope because shared detection services are built to cover vendor content, not customer-authored SIEM logic.

Why it matters: It matters because teams that rely on custom detections for environment-specific threats still need a plan for alert ownership, tuning and round-the-clock investigation.

Context

Custom detections are environment-specific alert rules that encode local business logic, unusual identity patterns, or application behaviour that generic content will not catch. The governance gap is that the rule may exist inside the SIEM, but the operational ownership for investigating its alerts often remains with the team that wrote it.

MDR is designed around a standard detection library and tier-1 triage for alerts that generalise across customers. Once an alert depends on local context, internal knowledge, or identity-specific behaviour, the service model becomes less effective because the context required to judge the alert sits outside the provider's shared workflow.

Key questions

Q: What breaks when custom detections are handed to MDR without local context?

A: The rule may still be visible, but the provider often lacks the environment-specific context needed to judge it correctly. That leads to shallow triage, false confidence, or excessive escalation back to the internal team. Custom detections are built around local business logic, so they need ownership, evidence, and response criteria that travel with the alert.

Q: Why do custom detections create a governance problem for SOC teams?

A: Because the rule often depends on business logic, identity patterns or application behaviour that only internal teams understand. If governance does not assign clear ownership for interpretation and tuning, the organisation ends up with alerts that are visible but not operationally accountable.

Q: How should teams decide which detections belong inside MDR coverage?

A: Use the level of context required to judge the alert. If a rule can be triaged from generic indicators, it may fit standard MDR handling. If it depends on local application logic, identity nuance or environment-specific baselines, it needs explicit internal ownership and continuous investigation coverage.

Q: What should security teams do when custom detections are business-critical?

A: Treat them like a 24/7 control, not a best-effort alert source. Name an owner, document the rule’s intent, preserve the evidence needed to assess it and make sure the investigation path continues outside business hours.

Technical breakdown

Why custom detections need local context to be judged

Custom detections are not just alert filters. They encode assumptions about what is normal in a specific environment, such as an access pattern in a home-grown application or an identity event that only matters in one business context. To decide whether the alert is real, an analyst needs the rule’s intent, the baseline behaviour it expects, and the surrounding data from SIEM, EDR, identity and cloud sources. Without that context, the alert can be technically visible but operationally opaque.

Practical implication: keep rule ownership close to the teams that understand the business logic behind each custom detection.

How shared MDR coverage breaks at the custom rule boundary

MDR economics depend on standardised content that works across many customers. Providers therefore prioritise their own detection library and the triage model tied to it. Customer-written rules may be ingested as another alert source, but that does not mean they receive the same depth of investigation. In practice, the service boundary is not the alert transport mechanism, but the investigative context and liability for the alert’s meaning.

Practical implication: treat custom detections as an operational exception that needs explicit investigation ownership, not as automatic MDR coverage.

Why round-the-clock investigation becomes the real control

When a custom detection fires, delay is expensive because the alert often represents a nuanced, high-context signal rather than a commodity indicator. That makes a 24/7 response capability part of detection governance, not an optional service enhancement. The control problem is therefore not just alert generation, but whether the organisation can interpret and act on the alert continuously without relying on ad hoc escalation after hours.

Practical implication: design a continuous investigation path for custom detections before you rely on them for critical coverage.

Threat narrative

Attacker objective: Exploit the gap between environment-specific detection logic and standardised MDR coverage so the most context-rich alerts receive slower or weaker investigation.

1. Entry occurs when a custom detection fires on a local environment pattern that vendor content would not recognise as suspicious.
2. Escalation happens when the alert requires contextual analysis from the engineer who wrote the rule, but the MDR service only provides standard tier-1 handling.
3. Impact is delayed response or missed triage for the highest-value alerts in the organisation's own detection estate.

Breaches seen in the wild

• Sumo Logic breach 2023: A compromised credential opened a Sumo Logic AWS account; customers were told to rotate API keys and stored credentials. No data impact was found.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Custom detections expose a coverage boundary, not a tooling gap. The important issue is not whether the alert exists in the SIEM, but whether anyone owns the interpretation of that alert when it depends on local business logic. Shared MDR models optimise for content that generalises, while custom detections often encode the exact conditions that matter most to the organisation. Practitioners should treat that boundary as a governance decision about ownership and escalation.

The custom-detection queue is an identity and access problem as much as a SOC problem. Several of the examples in the article depend on unusual identity patterns, internal application behaviour, or access paths that only make sense in one environment. That means detection quality is tied to IAM context, entitlement knowledge, and application-specific normality, not just log volume. Security teams should align custom rule governance with identity and application owners, not leave it solely inside the SOC.

24/7 investigation capacity becomes part of the detection control plane. If a custom rule is the control that best protects the environment, then the ability to investigate its alerts at any hour is part of the control itself. The article makes clear that the cost is structural, because one team cannot safely absorb nights, weekends and specialised context on demand. Practitioners should plan for continuous coverage as a prerequisite, not a downstream service add-on.

Detection engineering and alert operations have to stay coupled. A rule that cannot be tuned, tested and explained by the people who wrote it will drift into noise or be ignored at the exact point where it matters most. The lesson for mature programmes is to keep design authority, runtime handling and tuning feedback in a single governance loop. That is the difference between a custom detection programme and a pile of bespoke alerts.

What this signals

Custom detection programmes only work when alert interpretation stays close to the people who understand the rule’s intent. A SIEM can surface the signal, but the investigation still depends on local knowledge of applications, identity patterns and expected behaviour. For practitioners, the signal is to map ownership before a rule becomes business-critical.

The coverage gap is structural because MDR services are optimised for standard content, not bespoke environment logic. That makes custom detections a governance issue, not just a SOC resourcing issue. Teams should decide now whether they will staff the gap internally, automate the response path or limit the number of bespoke rules they depend on.

Custom detection operations should be managed as a control surface with explicit service levels. If a detection protects crown-jewel systems or unusual identity activity, it needs response targets, escalation paths and after-hours handling that match its importance. Practitioners should review whether their current operating model can actually support the alerts they most value.

For practitioners

• Define ownership for every custom detection Assign a named internal owner for each customer-written rule, including who tunes it, who interprets it and who approves changes to its logic.
• Separate vendor content from custom rules in triage Route MDR vendor detections and custom SIEM detections through different runbooks so the latter receive context-rich investigation rather than generic closure paths.
• Measure the alert share from custom logic Track how much of alert volume comes from custom detections and identify which of those alerts require specialised context to resolve.
• Build continuous coverage for high-value custom alerts Create after-hours and weekend investigation coverage for the custom rules tied to crown-jewel systems, unusual identity behaviour and business-critical applications.

Key takeaways

• Custom detections often fall outside standard MDR coverage because the alerts require local context that a shared service does not own.
• The issue is not whether the alert appears in the SIEM, but whether someone can interpret and investigate it continuously.
• Teams should treat bespoke detections as governed controls with named ownership, tuned response paths and after-hours coverage.

Key terms

• Custom Detection: A custom detection is a rule written to identify a specific behaviour, pattern, or control violation that matters to one organisation. In browser security, it can target DOM activity, headers, or request flows so defenders can detect business-specific abuse instead of relying only on generic signatures.
• Managed Detection And Response: MDR is a service model focused on detecting suspicious activity, investigating alerts, and helping contain attacks across threat-facing technologies. It is designed to turn telemetry into action, which makes it closer to security operations than simple platform administration.
• Detection Engineering: The discipline of designing, testing, and maintaining detection logic so it remains useful against real attacker behaviour. It covers telemetry selection, rule quality, false-positive management, and the operational workflow needed to keep alerts actionable.
• Triage Ownership: The assignment of responsibility for deciding whether an alert is real, important and actionable. In environments with custom detections, triage ownership must sit with people who understand the rule’s intent and the business context behind the signal.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps security practitioners connect identity control to the operational realities of detection and response.