Integration counts are a vanity metric in detection engineering

At a glance

What this is: This is an analysis of why more security integrations do not automatically produce better detections, with the key finding that breadth without engineering creates noise and blind spots.

Why it matters: It matters because IAM, NHI, and broader security programmes depend on trustworthy telemetry, and over-integration can obscure privilege abuse, credential misuse, and other signals that should drive action.

👉 Read Expel's whitepaper on high-fidelity detections and integration quality

Context

Security operations can fail when teams optimise for tool count instead of detection quality. In practice, a large integration estate can create more alerts than analysts can meaningfully investigate, while still leaving coverage gaps in techniques that matter most to attackers, including access misuse and privilege escalation.

The identity angle is real even in a detection-engineering discussion. When alerts are noisy, teams miss the behavioural signals that expose compromised service accounts, abusive API use, or privilege escalation in cloud and SaaS environments, which is why alert design and identity telemetry need to be treated as linked governance problems.

Key questions

Q: How should security teams decide which integrations are worth keeping in the SOC?

A: Keep integrations that improve a specific detection use case, investigative decision, or attacker-technique coverage. Drop feeds that only increase event volume or duplicate existing telemetry. The best test is whether the integration helps analysts confirm, enrich, or prioritise identity abuse, privilege escalation, or exfiltration faster than they could without it.

Q: Why do too many integrations make threat detection worse?

A: Too many integrations can create false confidence while flooding analysts with low-value alerts. When the queue is noisy, real indicators of compromise are easier to dismiss, especially when the activity resembles legitimate account or API behaviour. Quality detection depends on context, not sheer data volume.

Q: What breaks when detections are built around vendor coverage instead of attacker behaviour?

A: You get broad-looking dashboards that miss the actual ways attackers move. Teams may detect commodity malware while missing cloud privilege escalation, token abuse, or service account misuse because those behaviours were never mapped into the detection strategy. That leaves blind spots where modern intrusions usually live.

Q: How do teams know if detection engineering is actually improving?

A: They should measure whether new detections survive variant testing, whether telemetry is complete enough to support triage, and whether alerts feed back into updated logic without long delays. If the programme only changes during quarterly reviews, it is probably drifting faster than it is improving.

Technical breakdown

Why integration volume does not equal detection quality

Detection quality depends on how well telemetry is normalised, enriched, and mapped to attacker behaviour. An integration that only forwards raw events can increase volume without improving fidelity, because analysts still lack context such as identity, privilege, asset criticality, or sequence of actions. High-performing detection programmes engineer for precision first, then scale the data sources that genuinely improve investigative value.

Practical implication: evaluate every new integration against a specific detection use case, not against coverage theatre.

High-fidelity detections require attacker-technique coverage

A mature detection stack is built around techniques, not product categories. The article points to the common failure mode where teams have plenty of malware or perimeter visibility but miss cloud privilege escalation or misuse of legitimate APIs. That gap is especially relevant to NHI governance, where service accounts, tokens, and OAuth-connected systems can behave like trusted identities while still being abused by attackers.

Practical implication: map detections to attacker techniques and identity abuse paths, then close the highest-risk blind spots first.

Why alert fatigue is an operational control problem

Alert fatigue is not just an analyst experience issue, it is a control failure. When low-value detections dominate queues, triage quality drops and meaningful anomalies are more likely to be dismissed. This turns detection engineering into a governance discipline, because the quality of alerting directly affects whether the SOC can distinguish benign noise from account compromise, lateral movement, or exfiltration.

Practical implication: treat signal-to-noise ratio and mean time to triage as governance metrics, not just SOC performance stats.

Threat narrative

Attacker objective: The attacker wants to operate inside trusted systems without triggering a high-fidelity alert, then use that invisibility to escalate access or exfiltrate data.

1. Entry occurs when attackers exploit the organisation's weaker visibility layer, using legitimate access paths or noisy integrations to blend malicious activity into routine telemetry.
2. Escalation happens when over-broad permissions, unmanaged identities, or insufficiently enriched alerts prevent the SOC from seeing privilege abuse until the attacker is already inside trusted workflows.
3. Impact follows when hidden activity such as credential misuse, cloud privilege escalation, or API-based exfiltration remains undetected long enough to damage systems or steal data.

NHI Mgmt Group analysis

Integration theatre is a governance failure, not a tooling preference. The article correctly identifies a common security anti-pattern: teams optimise for the appearance of coverage rather than measurable detection value. In practice, the real problem is not the number of integrations, but whether the telemetry they produce can be trusted, correlated, and acted on at speed. Detection engineering should be evaluated as a control outcome, not a procurement inventory item.

Coverage blindness is especially dangerous where identity is the attack path. Identity compromise rarely looks dramatic in raw logs. Service accounts, API keys, and OAuth-connected apps often generate legitimate-looking traffic, which means noisy platforms can hide the very signals that indicate NHI abuse or cloud privilege escalation. That makes identity-aware detection design essential, not optional, for modern SOC programmes.

Signal-to-noise ratio is now a security architecture metric. Once teams accept that every additional feed can increase analyst burden, they can start managing telemetry like any other control surface. This aligns with NIST CSF and MITRE ATT&CK thinking: know what you are trying to detect, map it to techniques, and only ingest data that improves confidence. Practitioners should treat excess alert volume as a design flaw, not a badge of maturity.

High-fidelity detection depends on identity context travelling with the event. A log line without privilege, ownership, or lifecycle context is often operationally incomplete. That matters in NHI-heavy environments, where access can be ephemeral, delegated, or service-driven. The practical conclusion is clear: if a control cannot distinguish a human login from an abused machine identity, it is not ready for modern threat hunting.

Detection engineering discipline: the article highlights the shift from collecting more data to proving that each data source improves decisions. That concept will matter more as organisations continue to expand cloud, SaaS, and identity telemetry. Practitioners should build only the detections they can operationalise and measure.

What this signals

Telemetry strategy is becoming an identity governance problem as much as a SOC problem. If teams cannot tell which alerts correspond to privileged human access, service accounts, or token-driven activity, then detection engineering will continue to miss the behaviours that matter most. The practical shift is to treat identity context as part of the event, not an enrichment afterthought.

Detection fidelity debt: the longer organisations accumulate shallow integrations, the more difficult it becomes to separate useful signals from inherited noise. That debt shows up as analyst burnout, longer triage times, and missed coverage around delegated access paths. Programmes that want cleaner detection outcomes should align telemetry decisions with the NIST Cybersecurity Framework and the MITRE ATT&CK matrix, then remove feeds that do not improve decision quality.

As service accounts, API keys, and other non-human identities continue to expand, the control gap is less about visibility in the abstract and more about whether the SOC can interpret identity behaviour correctly. Organisations that tie detection engineering to lifecycle context and access governance will be better positioned to spot abuse before it becomes impact.

For practitioners

• Audit integrations for detection value Rank each data source by the specific attacker technique, identity behaviour, or investigative question it improves. Retire or downgrade integrations that only add volume without improving triage quality or coverage of high-risk paths.
• Map detections to attacker techniques Use a technique-based coverage review so each alert family is tied to a known adversary pattern. This is especially important for cloud privilege escalation, token misuse, and service account abuse where identity signals are subtle.
• Enrich alerts with identity context Ensure privilege level, account type, ownership, and recent access changes travel with every alert. Without that context, SOC analysts cannot reliably distinguish benign machine activity from compromised NHI behaviour.
• Measure signal quality, not volume Track signal-to-noise ratio, mean time to triage, and analyst dismiss rates to identify where alerting is degrading operations. Use those metrics to remove low-value detections before expanding the stack.

Key takeaways

• More integrations do not automatically create better security, because shallow telemetry can overwhelm analysts while leaving real attack paths under-covered.
• Detection engineering works when teams map data sources to attacker techniques and identity behaviour, then measure whether the resulting alerts are actually useful.
• For NHI-heavy environments, the winning control is identity-aware fidelity, because service accounts and tokens often look legitimate until context is added.

Key terms

• 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.
• Signal-to-Noise Ratio: The balance between meaningful security events and routine activity in detection tooling. A weak ratio makes analysts spend more time filtering alerts and less time identifying real attacks, which is why architecture quality strongly affects SOC effectiveness.
• Telemetry Enrichment: Telemetry enrichment is the process of adding context to raw security data so it is more useful for investigation and response. That can include asset, identity, geolocation, or threat intelligence context, but enrichment must be controlled so it does not distort the original evidence record.

What's in the full article

Expel's full whitepaper covers the operational detail this post intentionally leaves for the source:

• Practical guidance on choosing detections that improve signal quality rather than simply expanding integration count
• Examples of how to normalise and enrich telemetry so identity context travels with every alert
• A framework for evaluating whether a data source adds meaningful MITRE ATT&CK coverage or only duplicates existing visibility
• Guidance on balancing analyst workload against detection breadth in real SOC operations

👉 Expel's full whitepaper covers the detection engineering detail, integration trade-offs, and alert-quality guidance.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners who need to connect identity governance to broader security operations.