Identity data improves intelligence because access events are often the earliest sign of malicious activity in cloud and SaaS-heavy environments. When logins, token use, and privilege changes are correlated with threat context, teams can distinguish routine behaviour from risky activity faster and with less manual investigation.
Why This Matters for Security Teams
Identity data gives defenders a time-ordered view of who or what touched a system, which is often more actionable than a raw alert stream. In cloud, SaaS, and hybrid estates, access logs, token issuance, MFA outcomes, and privilege changes can expose attacker movement before payloads or malware are visible. That makes identity telemetry a practical threat intelligence signal, not just an audit record.
This matters because threat actors increasingly operate through valid accounts, stolen tokens, and automated workflows rather than noisy exploitation alone. When identity events are enriched with known bad IPs, impossible travel, geolocation anomalies, device posture, and threat advisories from sources such as CISA cyber threat advisories, teams can prioritise what is likely malicious and suppress benign noise. That is especially important when attackers abuse legitimate access paths that would otherwise blend into routine administration.
The key point is that identity data improves intelligence only when it is curated, normalized, and tied to risk context. Raw authentication logs alone do not create insight; correlation does. In practice, many security teams encounter the compromise only after a valid session, token theft, or privilege escalation has already been used, rather than through intentional identity-led detection.
How It Works in Practice
Identity-led threat intelligence starts by collecting the events that reveal access behaviour: successful and failed logins, session start and end, MFA challenges, token creation, role assignment, API key use, and admin actions. Those events are then enriched with asset, user, device, and location context so that a login is interpreted in relation to normal behaviour, not in isolation. Current guidance suggests that this correlation is most useful when it is embedded in SIEM, SOAR, and identity governance workflows rather than treated as a separate analyst task.
A practical workflow usually includes four steps:
- Normalize identity sources across IAM, PAM, SaaS, and cloud control planes so the same user or workload can be traced consistently.
- Map events to known attack patterns, such as credential stuffing, session hijacking, privilege abuse, or suspicious consent grants.
- Enrich with external intelligence, including indicators from ENISA Threat Landscape and analyst reporting.
- Promote high-confidence cases into response playbooks for token revocation, step-up authentication, account suspension, or session containment.
Identity data also becomes more useful when teams distinguish human users, service accounts, and autonomous software identities. That distinction is increasingly important in environments with agents and machine-to-machine access because a login that looks normal for a service account may be anomalous for a person, and vice versa. Where AI systems are involved, threat context should also consider prompt injection, tool abuse, and supply-chain compromise, using references such as the MITRE ATLAS adversarial AI threat matrix and incident reporting like the Anthropic AI-orchestrated cyber espionage campaign report. These controls tend to break down when identity records are fragmented across tenants and the team cannot reconstruct a single session path across the attack chain.
Common Variations and Edge Cases
Tighter identity correlation often increases tuning overhead, requiring organisations to balance faster detection against false positives and privacy constraints. That tradeoff is especially visible in global enterprises, regulated sectors, and environments with high numbers of contractors, service principals, and delegated admin roles.
Best practice is evolving for several edge cases. In shared-device or kiosk environments, a login anomaly may reflect operational reality rather than compromise, so device and session context matter more than geolocation alone. In CI/CD and cloud automation, identity signals from workload identities, secrets rotation, and API calls may be more valuable than end-user login data. For AI-enabled operations, identity data should also capture which agent, model, or orchestration layer executed a tool action, because the user-facing account may not be the actual source of risk.
Another common gap appears in incident response. Teams sometimes build excellent dashboards but fail to connect identity intelligence to containment steps, such as disabling refresh tokens, revoking OAuth consent, or forcing reauthentication. There is no universal standard for how much weight each identity signal should carry, so organisations should define trust thresholds based on environment risk, business criticality, and attacker exposure. Where personal data is part of the identity record, governance must also account for data minimization and retention limits while preserving enough evidence for investigation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Identity telemetry improves continuous monitoring and anomaly detection. |
| MITRE ATT&CK | T1078 | Threat actors often use valid accounts and stolen sessions to evade detection. |
| NIST AI RMF | AI-assisted threat analysis needs governance, measurement, and human oversight. | |
| OWASP Agentic AI Top 10 | Agentic systems create new identity and tool-use risks that affect threat signals. | |
| NIST SP 800-63 | CSP 2.2 | Identity assurance matters when access events drive trust decisions. |
Collect identity events continuously and alert on deviations from normal access behaviour.
Related resources from NHI Mgmt Group
- How should security teams unify identity across cloud and data center environments?
- How should security teams reduce cloud identity risk in customer data environments?
- Why do passwords still create so much identity risk in modern environments?
- What do security teams get wrong about identity visibility in modern environments?
