TL;DR: Security teams often buy detection technology without the people and process to operate it, leaving much of the investment unrealised, according to SentinelOne. The real decision is whether a programme needs tool administration, 24/7 detection and response, or continuous threat hunting to turn telemetry into outcomes.
At a glance
What this is: SentinelOne frames MSSP, MDR and MTH as different service models for security operations, warning that buying tools without operational capacity leaves most of the investment underused.
Why it matters: This matters because IAM, NHI and broader SOC programmes fail when monitoring, response and governance are treated as the same problem, rather than distinct operating needs.
Context
Security operations value is not created by tooling alone. The gap appears when organisations buy detection or control technology first and only later discover they do not have the people, process or operating model to use it well. In practice, that leaves monitoring shallow, response slow, and the original security objective only partially met.
The article separates three service models that are often blurred together: MSSP for tool management, MDR for detection and response, and MTH for attacker-focused hunting. That distinction matters to IAM and NHI programmes because identity telemetry, privileged access and service-account activity only become useful when someone is tasked to act on them, not merely to administer the platform.
Key questions
Q: What should teams do first when security tools are deployed but not actively operated?
A: First, separate tool administration from operational responsibility. Assign clear ownership for monitoring, investigation, containment and remediation so the environment is not treated as ‘deployed equals protected’. Without that split, alerts are triaged but not converted into outcomes, and the original security investment remains mostly administrative.
Q: Why do MSSP, MDR and MTH produce different security outcomes?
A: They solve different operational problems. MSSP keeps tools maintained and alerts triaged, MDR adds continuous detection and response, and MTH actively searches for attacker behaviour that may not trigger alerts. Choosing the wrong service type usually means buying a capability that is broader or narrower than the organisation’s actual gap.
Q: What are the signs that a security operations model is becoming unsustainable?
A: Common signs include rising alert volume, exhausted analysts, slow incident response, poor coordination across teams, and difficulty proving security value to leadership. A further warning is when legacy tools cannot support current use cases or when performance metrics such as detection speed and response time are not being tracked consistently. These symptoms usually point to structural strain, not just temporary workload pressure.
Q: When should organisations treat incident response as part of the operating model?
A: Before an incident occurs. Response retainers, escalation paths and decision authority should be in place as part of readiness, not assembled during a crisis. That approach reduces time to detect, contain and recover, which is especially important when attackers are already operating inside monitored environments.
Technical breakdown
Security tool management vs security operations
Security tool management is the administration layer: policy changes, access provisioning, de-provisioning, patching, scaling, and basic alert handling. Security operations is the outcomes layer: monitoring for incidents, investigating what happened, containing the event, and responding in a way that changes risk. The article’s core point is that many organisations confuse the two and therefore underinvest in the operating function needed to realise value from EDR, SIEM or adjacent controls. This distinction also applies to identity tooling: a control can be correctly configured yet still fail operationally if no one is using its telemetry to drive action.
Practical implication: Separate platform administration from detection and response ownership in your operating model.
Why MDR and MTH are not interchangeable
MDR focuses on continuous monitoring, investigation and response to active threats, typically with 24/7 coverage. MTH goes further into adversary behaviour, using TTPs, IoAs and hypothesis-driven searches to find attacks that tools may not alert on cleanly. In other words, MDR is oriented around confirmed or suspected activity, while MTH is oriented around proactive pursuit of hidden compromise. For identity-heavy environments, that difference matters because credential misuse, privilege abuse and dormant access patterns are often easier to hunt than to detect through signatures alone.
Practical implication: Choose MDR for response coverage and MTH when you need proactive search for hidden attacker behaviour.
Why service models must match organisational maturity
The article’s three organisation types map to different operating gaps. Smaller organisations often lack 24/7 capability and need outsourced detection and response. Mid-maturity teams may have a SOC but not full-time coverage, so MDR augments existing operations. Highly mature teams may already run a 24/7 SOC but still need hunting support and compromise assessment to scale beyond routine alert handling. This is a governance issue as much as a staffing issue: the service model should reflect the organisation’s actual operating maturity, not the market buzzword that sounds most complete.
Practical implication: Match the service model to maturity, coverage gaps and whether the SOC can actually act on telemetry.
Threat narrative
Attacker objective: Exploit the gap between deployed security tooling and actual security operations so compromise can persist long enough to cause business disruption.
- Entry often begins after an organisation deploys security technology without the staffing or process needed to operate it, so malicious activity lands inside a partially monitored environment.
- Escalation occurs when alerts are only triaged, not investigated, allowing attackers to persist through weak response handoffs and low-fidelity monitoring.
- Impact follows when the organisation discovers that the control existed, but the operational layer needed to contain and remediate the event was missing.
Breaches seen in the wild
- Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.
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
Security operations debt is the hidden failure mode in many control programmes. Buying EDR, SIEM or similar tools does not create outcomes unless there is a function prepared to investigate, contain and respond. The article is correct to separate administration from operations because many teams measure deployment coverage while the attacker measures response capability. Practitioners should treat operational ownership as a control in its own right.
MDR and MSSP solve different governance problems, not just different procurement categories. An MSSP keeps platforms running and alerts triaged, while MDR exists to detect and respond to attacks. Conflating them creates a false sense of coverage, especially where the environment includes identity telemetry, privileged access or service accounts that need active review. Security leaders should design for the outcome they actually need, not the label that sounds broader.
Continuous threat hunting is the distinguishing control for organisations that already have baseline monitoring. Once a SOC exists, the question becomes whether it can find what does not alert cleanly, including attacker behaviour that blends into normal identity and endpoint activity. That makes hunting a maturity control, not a luxury. Teams that already own detection but still lack proactive hunting are accepting blind spots in exchange for a checkbox.
Human-machine teaming is the realistic model for modern security operations. The article’s point that no technology detects 100% of attacks is operationally important because it resets expectations away from tool-first thinking. The security programme should assume technology plus process plus skilled analysts, with each compensating for the others’ limits. Practitioners should use that assumption to redesign their operating model and service mix.
Managed response should be part of resilience planning, not just incident aftercare. Retainers that are only discussed after a breach miss the article’s central point that readiness shortens detection, containment and recovery. In identity-led environments, that matters when privileged accounts, tokens or service identities are involved because delays expand blast radius quickly. Teams should align response access, escalation and decision paths before the incident occurs.
What this signals
Security operations maturity is the real selection criterion. The service model should follow whether the organisation can actually investigate and act, not whether it has purchased a monitoring platform. Teams that already have tooling but still rely on compliance-driven alerting should reassess whether they need MDR coverage or dedicated hunting support.
Operational separation is the governance lesson here. Tool management, detection, response and hunting should not be collapsed into a single procurement label because each one answers a different programme need. That distinction is especially important where identity telemetry, privileged access or service accounts generate signals that only matter if someone is empowered to respond.
Continuous threat hunting changes the control from reactive to adversary-led. Once a team can maintain baseline monitoring, the next gap is usually hidden activity that does not present as a clean alert. In practical terms, that means hunting for suspicious patterns across endpoint and identity activity rather than waiting for a predefined incident to surface.
For practitioners
- Define separate ownership for tool management and security operations Document who handles configuration, policy changes, provisioning and basic monitoring, and who is accountable for investigation, containment and response. Do not let a single service description blur these responsibilities.
- Map service model choice to operating maturity Use your current SOC coverage, staffing levels and alert-handling capability to decide whether you need MSSP support, MDR coverage, or MTH for deeper hunting. The right answer depends on the gap you are actually trying to close.
- Prioritise 24/7 detection and response where coverage is incomplete If the SOC is not always staffed, add MDR before assuming the existing monitoring stack is sufficient. Continuous coverage is the control that turns telemetry into action.
- Retain an incident response retainer before an incident Keep a prepaid or zero-dollar retainer in place so you are not negotiating support while an active incident is unfolding. The objective is to reduce delay in containment and recovery.
- Separate hunting from triage in mature programmes If your team already handles alerts, add a distinct hunting capability that looks for attacker TTPs, IoAs and compromise patterns that routine monitoring misses. Hunting should be a deliberate function, not an afterthought.
Key takeaways
- Many organisations underrealise security investment because they buy tooling before they build the operating model needed to use it.
- MSSP, MDR and MTH are not interchangeable labels. They describe different combinations of administration, detection, response and proactive hunting.
- The right service choice depends on whether the organisation needs platform upkeep, round-the-clock response or deeper adversary search.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Tool management and SOC operations both depend on governing who can administer and respond across systems. |
| DE.CM-01 — Networks and systems are monitored to detect potential cybersecurity events | MDR and MTH are both about continuous monitoring and detection coverage. | |
| Recommendation — Apply PR.AA-05 to separate administrative access from operational response privileges. Use DE.CM-01 to define where monitoring must be continuous rather than periodic. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The article's value gap appears when telemetry exists but is not operationalised into action. |
| Recommendation — Centralise and review telemetry so alerting can support investigation and response. | ||
| MITRE ATT&CK | TA0006; TA0007; TA0040 — Credential Access; Discovery; Impact | The article is about detecting and responding to adversary behaviour before it turns into business impact. |
| Recommendation — Map monitoring and hunting coverage to TA0006, TA0007 and TA0040 to close detection gaps. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Security tool management and response both depend on controlled administrative access. |
| Recommendation — Enforce access control around security tooling and operational consoles. | ||
Key terms
- Managed Security Service Provider (MSSP): An MSSP is a provider that primarily manages and monitors security tools on behalf of an organisation. In practice, the emphasis is on administration, alert triage, and keeping platforms operational rather than leading full detection-and-response operations.
- 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.
- Managed Threat Hunting: Managed Threat Hunting is proactive search for attacker behaviour, indicators of attack, and compromise patterns that may not trigger a direct alert. It relies on telemetry, hypotheses, and analyst judgement to find active threats that basic monitoring can miss.
- Security operations: Security operations is the part of the security programme that turns controls and telemetry into outcomes. It covers monitoring, investigation, containment, response, and recovery, and it depends on people, process, and technology working together rather than on tools alone.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the NHI Foundation Level course, the industry's only accredited NHI security programme, to strengthen governance across human, machine and agent identities.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org