How should security teams monitor risky identity activity across cloud services?

Why This Matters for Security Teams

Risky identity activity rarely appears dangerous when each event is reviewed in isolation. A mailbox rule change may look routine, a database query spike may be explainable, and a storage delete may be approved, yet the sequence can reveal account takeover, lateral movement, or data staging. That is why monitoring has to focus on identity behaviour across cloud services, not just single alerts. NHI Management Group research shows only 5.7% of organisations have full visibility into service accounts, which makes cross-service correlation a practical gap, not a theoretical one, as described in the Ultimate Guide to NHIs.

Security teams need a monitoring model that connects actor, action, and context across email, IAM, databases, and SaaS. That means defining which actions are high-risk for each platform, then ranking them by identity type, privilege, and timing. Guidance from the NIST Cybersecurity Framework 2.0 supports this kind of risk-based detection, but the operational challenge is making those signals visible in one investigation path. In practice, many security teams discover identity abuse only after a benign-looking sequence has already completed and the data has already moved.

How It Works in Practice

Effective monitoring starts by defining the actions that matter in each cloud service. For email, that may include inbox forwarding, rule creation, delegate grants, or OAuth app consent. For infrastructure and data platforms, it may include privilege grants, token creation, bulk export, snapshot access, or anomalous deletes. For NHI-heavy environments, those events should be tied back to the identity that executed them, the workload or application owner, and the expected task path.

The practical pattern is to build correlation rules or detections that combine several low-signal events into one risk story. A single cloud API call may not justify escalation, but a sequence of new credential issuance, suspicious role assumption, and an unusual access spike can signal that an identity has been hijacked. NHIMG’s Top 10 NHI Issues highlights why this matters: excessive privileges and inadequate monitoring are recurring failure points, and both become harder to detect once actions are spread across multiple services.

• Normalize logs from IAM, SaaS, email, database, and cloud control planes into a shared investigation view.
• Map each event to an identity, an asset, a privilege level, and a service owner.
• Flag unusual sequences, such as privilege elevation followed by bulk access or mass deletion.
• Use time windows that capture campaign-like behaviour, not just one-off anomalies.
• Prioritise alerts when the identity has broad access, no recent rotation, or no clear owner.

For investigation design, align detection logic to the response workflow rather than the tool that generated the log. That means one analyst should be able to see the full chain without pivoting through separate consoles. Current guidance suggests that this becomes most effective when teams combine behavioural detections with policy and identity inventory data, rather than relying on alerts alone. These controls tend to break down in highly fragmented SaaS environments because identity context is split across vendors, tenants, and log formats.

Common Variations and Edge Cases

Tighter monitoring often increases alert volume and analyst workload, so organisations have to balance deeper visibility against operational noise. That tradeoff is especially visible in mixed human and non-human estates, where the same action can be normal for one identity type and suspicious for another. The best practice is evolving, but many teams now maintain separate baselines for service accounts, human users, and agentic workloads rather than forcing one detection model onto all three.

Edge cases also matter. Shared service accounts can hide the real actor unless session attribution is preserved. Short-lived tokens can make it difficult to reconstruct what happened after the fact unless logs are retained long enough. Third-party OAuth apps are another blind spot; NHIMG research in the State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes identity correlation incomplete by default. In those environments, monitoring should focus on consent changes, token creation, and unusual API grants as much as on the downstream data action itself.

Where there is no universal standard yet, current guidance suggests teams should document which identity events are deemed high-risk, who owns each identity, and what correlation path an analyst must follow. That combination makes risky activity visible before it turns into a breach, rather than after the account has already been used to move laterally.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• How should security teams make NHI best practices usable across the business?
• How should security teams unify identity across cloud and data center environments?