What do security teams get wrong about detecting attacker movement through SaaS environments?

Why This Matters for Security Teams

SaaS environments are often treated as low-friction productivity layers, but they now hold the same identity risk surface as traditional infrastructure. Attackers do not need malware if they can reuse a valid session, pivot through an OAuth grant, or abuse an over-permissioned app integration. That is why SaaS movement is frequently missed by controls built for endpoint compromise, not identity-led intrusion. Guidance from the NIST Cybersecurity Framework 2.0 reinforces the need to detect and respond across identity, application, and data flows rather than only on host telemetry.

NHIMG research shows the scale of the visibility problem: in The State of Non-Human Identity Security, 85% of organisations reported incomplete visibility into third-party vendors connected via OAuth apps. That gap matters because attacker movement in SaaS often looks like ordinary integration activity until permissions change, unusual consent appears, or a trusted account starts accessing a new data set. Practitioners also miss how quickly exposed credentials are abused; Entro Security reported that when AWS credentials are public, attackers attempt access in an average of 17 minutes, which is a strong proxy for how little time defenders have once identity material leaks. In practice, many security teams encounter saas lateral movement only after a trusted integration has already been used to reach data that should never have been in scope.

How It Works in Practice

Detecting attacker movement through SaaS requires thinking in identity sequences, not single alerts. A session token refresh, an admin consent event, a new app installation, and a sudden spike in cross-tenant sharing may each look benign on their own. Together, they can form a clear intrusion path. Current guidance suggests building detections around user, service account, and non-human identity behaviour, then correlating that activity with app permissions, API calls, and data access patterns. The operational model in The 52 NHI Breaches Report and Top 10 NHI Issues is useful here because many SaaS abuse cases begin with credential or token misuse, not endpoint execution.

• Baseline normal sign-in geographies, device posture, app consent patterns, and API call frequency for each identity.
• Alert on privilege elevation, new OAuth grants, and unusual app-to-app access by accounts that rarely perform those actions.
• Correlate SaaS audit logs with identity provider logs so token reuse and session hijacking are not treated as separate problems.
• Prioritise detection on high-value workflows such as mailbox access, file exports, billing changes, and admin console activity.

For control design, the MITRE ATT&CK Enterprise Matrix helps map SaaS abuse to technique chains, while CISA cyber threat advisories remain useful for recurring token theft and cloud account takeover patterns. This approach works best when SaaS audit data is complete and identity events are retained long enough to reconstruct the path. These controls tend to break down when logs are fragmented across tenants and integrations, because the attacker’s movement no longer appears as a single incident.

Common Variations and Edge Cases

Tighter detection often increases alert volume and investigation overhead, requiring organisations to balance signal quality against analyst capacity. That tradeoff becomes sharper in SaaS because many legitimate actions resemble attacker behaviour: bulk exports, delegated admin tasks, automated workflows, and service-to-service API calls can all produce noisy telemetry. Best practice is evolving, but there is no universal standard for distinguishing normal automation from malicious chaining across SaaS applications.

Edge cases matter. Shared admin accounts hide attribution. Shadow IT apps create blind spots. Long-lived refresh tokens can keep an attacker active even after a password reset. A strong detection model therefore needs both identity context and lifecycle controls, as described in the NHI Lifecycle Management Guide. Where SaaS platforms expose limited audit depth, teams should compensate by watching for impossible travel, new consent grants, and changes in data-access shape across critical accounts. The broader warning in Ultimate Guide to NHIs — Why NHI Security Matters Now applies directly here: identity abuse often survives because defenders expect a machine to behave like malware instead of like a trusted user with a stolen token.

Related resources from NHI Mgmt Group

• What do security teams get wrong about least privilege in SaaS and cloud environments?
• What do security teams get wrong about detecting abuse in AI-enabled environments?
• What do security teams get wrong about SaaS governance in hybrid work environments?
• What do security teams get wrong about catching synthetic identity document fraud?