Notifications
Clear all
Topic starter
02/08/2026 11:34 am
TL;DR: Identity detection fails when teams monitor isolated events instead of attack sequences, because the highest-value signals are failure-then-success logins, MFA anomalies, dormant account activity, impossible travel, and post-authentication behaviour, according to Panther. The real challenge is building cross-source coverage that catches attacker intent without turning the SOC into a backlog factory.
NHIMG editorial — based on content published by Panther: Identity Threat Detection: Best Practices for Modern SOC Teams
By the numbers:
- A company with remote employees across 15 countries has a different definition of impossible travel than a single-office team.
- Docker saw this directly and cut its false positive alert rate by 85% year over year, without adding additional headcount.
Questions worth separating out
Q: How can organisations reduce false positives without weakening identity controls?
A: Use alert summarization to convert noisy detections into a clear explanation, evidence, and next step.
Q: Why do identity alerts need cross-source correlation?
A: Because authentication data alone rarely shows attacker intent.
Q: What breaks when teams monitor logins without session context?
A: They miss the behaviours that happen after authentication, which is often where compromise becomes visible.
Practitioner guidance
- Tune detections to behavioural sequences Write rules for failure-then-success patterns, repeated MFA pushes, dormant account reactivation, and suspicious post-authentication actions instead of single event thresholds.
- Correlate identity and cloud telemetry in one investigation path Join Okta, CloudTrail, EDR, and session activity on identity, IP, and time so investigators see the full chain from authentication to downstream action.
- Build environment-specific identity baselines Define normal geographies, travel patterns, service-account behaviour, and account activity windows for your own organisation.
What's in the full article
Panther's full blog covers the operational detail this post intentionally leaves for the source:
- Rule logic examples for failure-then-success login patterns, MFA push bursts, and dormant account reactivation
- Detection engineering guidance for joining Okta, CloudTrail, and EDR into one identity investigation path
- Practical tuning examples for impossible travel, VPN exceptions, and service-account baselines
- How Panther's AI SOC agent applies shared context during alert triage
👉 Read Panther's blog on identity threat detection best practices for modern SOC teams →
Identity threat detection coverage: are your controls catching real attacks?
Explore further
02/08/2026 12:48 pm
Identity threat detection fails when teams optimise for event volume instead of attack sequence. A single failed login, a single MFA prompt, or a single impossible-travel hit is usually just noise. The security value appears when those events are linked into a chain that shows credential abuse, session misuse, and downstream intent. For practitioners, the lesson is that alert design must follow attacker behaviour, not logging convenience.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which helps explain why identity detections so often lack the context needed for confident triage.
A question worth separating out:
Q: Who should own identity detection coverage in a mature security programme?
A: SOC and IAM teams should share ownership, because the detections depend on both threat logic and identity lifecycle data. Security operations needs the alerting and correlation layer, while identity teams supply account status, deprovisioning state, and access context. If ownership sits in only one group, coverage usually becomes incomplete.
👉 Read our full editorial: Identity threat detection for modern SOC teams is a coverage problem
