TL;DR: Detection pipelines built on rules and anomaly baselines miss cloud configuration context, identity chaining, and business context, leaving security teams with noisy alerts instead of complete incidents, according to Exaforce. In modern cloud and SaaS estates, context at detection time is the difference between triage and blind correlation.
NHIMG editorial — based on content published by Exaforce: Detections done right: Threat detections require more than just rules and anomaly detection
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
Questions worth separating out
Q: How should security teams correlate identity activity with cloud configuration data?
A: They should evaluate activity, permissions, and resource policy together at detection time, not during manual triage.
Q: Why do cloud detections need more than anomaly scoring?
A: Anomaly scoring tells you that something changed, but not whether the change matters.
Q: What do SOC teams get wrong about incident context?
A: They often treat context as a post-alert enrichment step instead of part of the detection itself.
Practitioner guidance
- Correlate detections with effective permissions Require alerts to include transitive role assumptions, resource policy overrides, and reachable resources before they are sent to analysts.
- Model shared roles as first-class identities Treat AWS roles, automation tokens, and shared service identities as distinct analytical objects with their own baselines, not as aliases of the last human user seen in the log.
- Push business context into the detection layer Capture environment-specific context such as critical resources, office patterns, known maintenance windows, and active reorganisations inside the detection workflow.
What's in the full article
Exaforce's full blog post covers the operational detail this post intentionally leaves for the source:
- The three-model architecture behind the semantic, behavioral, and knowledge layers.
- How session chaining is used to reconstruct origin identities and role assumptions in cloud events.
- Examples of config enrichment for AWS, GitHub, and SaaS resources that improve alert fidelity.
- How duplicate findings are grouped, classified, and chained before analyst review.
👉 Read Exaforce's analysis of cloud detections, config context, and identity chains →
Cloud detections and identity context: what IAM teams are missing?
Explore further
Configuration-aware detection is now an identity governance requirement, not a SOC luxury. Rules and anomaly scoring are incomplete when access is shaped by transitive roles, resource policies, and ephemeral cloud assets. The identity problem is not only whether an event is unusual, but whether the actor could actually reach the thing that matters. IAM teams should treat detection context as part of the access model, not a downstream enrichment task.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, showing that visibility gaps create real operational risk.
A question worth separating out:
Q: How should security teams reduce false positives in cloud detection workflows?
A: They should attach identity, workload, and asset-criticality context to every alert before analysts see it. That lets teams distinguish routine activity from risk faster, reduces wasted investigation time, and improves escalation quality. The goal is not more alerts, but better decisions about which alerts deserve response. A contextual triage model also reduces burnout.
👉 Read our full editorial: Cloud detections need config, identity and context, not rules alone