Notifications
Clear all
Topic starter
10/07/2026 9:18 pm
TL;DR: Legitimate credentials, trusted sessions, and overloaded identity surfaces are making intrusion harder to detect even as enterprises collect more authentication telemetry, according to SentinelOne. The real blind spot is post-authentication behavior, where IAM and security teams must govern what identities do after access is granted, not just who gets in.
NHIMG editorial — based on content published by SentinelOne: The identity paradox is widening across human and non-human access
By the numbers:
- In 2025 alone, SentinelLABS tracked over 1,000 job applications and roughly 360 fake personas linked to these operations.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams detect abuse when attackers use legitimate identities?
A: Security teams should correlate successful authentication with downstream behaviour such as unusual file access, privilege escalation, bulk export, and lateral movement.
Q: Why do legitimate accounts create more risk than failed login attempts?
A: Because a valid account inherits trust from the organisation, many controls stop scrutinising it once authentication succeeds.
Q: What do security teams get wrong about identity monitoring?
A: They often monitor identity events as if login success were the main control boundary.
Practitioner guidance
- Expand identity detections beyond login success Correlate authentication with repository access, privilege changes, bulk exports, and lateral movement so valid accounts cannot hide malicious activity inside normal access patterns.
- Flag high-risk identity events as security-relevant changes Treat new MFA device enrolments, OAuth permission grants, and service account privilege changes as review-worthy events because they often precede trusted-session abuse.
- Separate account validity from behavioural trust Maintain a distinct control for post-authentication activity so approved credentials do not automatically inherit unrestricted confidence across SaaS, cloud, and developer platforms.
What's in the full article
SentinelOne's full analysis covers the operational detail this post intentionally leaves for the source:
- Breakdown of the specific identity abuse patterns observed in the wild, including fake insiders and supply chain compromise.
- Examples of post-authentication behaviour signals that teams can tune into their own detection stack.
- Context on how identity telemetry, browser activity, and endpoint behaviour can be correlated in practice.
- Discussion of how the vendor positions its visibility and response architecture across human and non-human activity.
👉 Read SentinelOne's analysis of the identity paradox and post-login abuse →
Identity paradox and post-login behavior: what should teams change?
Explore further
10/07/2026 9:40 pm
Identity telemetry without behavioural interpretation creates an illusion of control: The article describes a world where security teams see more logs, more authentication events, and more access records, yet still struggle to distinguish abuse from normal work. That is a governance problem, not just a detection problem. When an attacker acts through a legitimate account, the programme’s trust model becomes the attacker’s camouflage. Practitioners should treat identity data as evidence that requires context, not as proof of safety.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who is responsible when a trusted account is abused for malicious activity?
A: Responsibility usually sits across identity governance, the application owner, and the security team that monitors runtime behaviour. A trusted account can be technically valid and still misused, so accountability must cover issuance, permission scope, and post-authentication monitoring. That is especially true for service accounts, delegated SaaS access, and AI-driven workflows.
👉 Read our full editorial: The identity paradox is widening across human and non-human access
