An investigation approach that treats identity activity as a primary source of compromise evidence rather than a supporting signal. It correlates IdP, SaaS, cloud, and endpoint data to determine whether access was expected, abused, or delegated in a risky way.
Expanded Definition
Identity-led investigation is a security investigation method that starts with identity evidence, such as authentications, conditional access decisions, privileged role changes, session activity, and delegated access, then builds the incident narrative outward into SaaS, cloud, and endpoint telemetry. It is distinct from a generic alert review because it treats identity state as an evidentiary source, not just a directory record. That matters when access is issued through an IdP, federated login, or non-human workflow, where the question is not only whether an alert fired, but whether the access path itself was legitimate. In practice, teams use identity-led investigation to decide whether a session was expected, whether a token was replayed, whether delegation was approved, or whether a privilege escalation occurred without proper control. This approach aligns well with NIST Cybersecurity Framework 2.0, especially where governance, detection, and response depend on understanding who or what initiated access. The most common misapplication is treating identity-led investigation as simple log search, which occurs when teams query sign-in records without correlating privilege changes, token use, and downstream resource activity.
Examples and Use Cases
Implementing identity-led investigation rigorously often introduces correlation overhead, requiring organisations to weigh faster root-cause analysis against the cost of normalising identity data across platforms.
- A security team traces a suspicious SaaS export back to a federated login that succeeded from an unfamiliar location, then confirms whether MFA, device posture, and session duration were consistent with policy.
- During suspected account takeover, investigators compare IdP authentication logs with cloud API calls to determine whether the attacker used an interactive session, a stolen token, or delegated access.
- An administrator reviews a privileged role assignment after a configuration change, using evidence from IAM, PAM, and audit logs to verify whether the elevation was approved or silently granted.
- A cloud incident response team follows identity signals from the first authentication to the last resource action to establish whether a service account behaved within its intended automation scope.
- After an unusual mailbox rule appears, analysts correlate mailbox access, endpoint telemetry, and identity assurance events to determine whether the action came from the user or an impersonating session.
Where identity evidence is strong, this approach can shorten the time needed to separate benign anomalies from true compromise, particularly in environments with heavy federation and third-party integrations. It also helps distinguish human misuse from non-human execution, which is increasingly important when agentic AI, service principals, and API-driven workflows all use identity material to act. Guidance is still evolving on how much weight should be given to each identity signal, so mature teams document their own investigation thresholds rather than assuming a universal standard. Useful reference points include access governance expectations in the NIST Cybersecurity Framework 2.0 and identity assurance concepts from NIST SP 800-63 Digital Identity Guidelines.
Why It Matters for Security Teams
Identity-led investigation matters because many modern attacks do not begin with malware detection, they begin with valid access obtained through phishing, token theft, session hijacking, delegated permissions, or abused automation. If investigators start from endpoint alerts alone, they can miss the access path that made the incident possible. Starting from identity activity helps teams answer the core questions faster: who authenticated, what assurance was present, what privilege changed, and what the identity did next. That is especially valuable in environments with SSO, cloud console access, and non-human identities, where a single compromised credential can pivot across multiple services. It also strengthens governance because identity evidence can show when policy failed, when a role was overbroad, or when a service account was used outside its intended scope. For incident response, this shifts the focus from isolated detections to chain-of-custody around access. Organisations typically encounter the full cost of identity-led investigation only after an intrusion persists across multiple systems, at which point reconstructing the access trail becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | CSF emphasizes monitoring to detect anomalous activity across identity and system sources. |
| NIST SP 800-63 | IAL/AAL/FAL | Digital identity assurance levels shape how much confidence investigators can place in access events. |
| NIST Zero Trust (SP 800-207) | SC-4 | Zero Trust requires continuous verification of access, which supports identity-led investigation. |
| OWASP Non-Human Identity Top 10 | NHI guidance highlights how machine identities and tokens create investigation blind spots. | |
| NIST AI RMF | AI governance requires traceability for agent actions, which overlaps with identity-led investigations. |
Correlate identity events into monitoring workflows so unusual access is identified early and investigated consistently.
