How should security teams build detection around identity activity instead of relying on traditional threat intelligence?

Why Identity-Centric Detection Beats Static Threat Feeds

Identity activity gives security teams a live view of how access is actually being used, which is far more useful for detection than waiting for a threat feed to describe a known adversary pattern. When a session token is abused, a service account is misused, or an unusual privilege path appears, the signal is in the runtime behaviour itself. That matters because compromise often looks like legitimate use until the sequence of actions is correlated across systems, not because an indicator was pre-labelled by a vendor. The NIST Cybersecurity Framework 2.0 is useful here because it emphasises detection and response outcomes rather than relying on static artefacts alone. In practice, many security teams discover the value of identity-led detection only after an intrusion has already blended into normal administrative activity.

How to Build Detections from Identity Telemetry

Effective identity detection starts with high-fidelity event capture from the systems that issue, use, and observe identity-driven actions. That means cloud control planes, SaaS audit logs, directory activity, privileged access workflows, workload authentication, and CI/CD events should all be normalised into a common timeline. The goal is not simply to log more data, but to connect authentication, authorisation, privilege change, token use, and sensitive action into a sequence that shows intent and progression.

Teams should define detections around behavioural pivots rather than single events. For example, a new geolocation, a sudden jump in privilege, a token used from a new workload, or a service principal touching resources it has never accessed before becomes much more meaningful when paired with adjacent events. That correlation is what distinguishes routine automation from suspicious activity. The same approach also helps reduce false positives caused by approved tools that look unusual in isolation but are normal within their execution chain.

• Normalise identity events across cloud, SaaS, endpoints, and build systems into one detection pipeline.
• Correlate authentication with privilege elevation, resource access, and session context before escalating.
• Track high-risk identities and automation paths separately so their behaviour can be baselined realistically.
• Use detections that look for sequence, scope change, and access drift instead of only known bad indicators.

The approach breaks down when logs are incomplete, identity ownership is unclear, or automation shares the same access patterns as human users without any way to distinguish them.

Where Identity Detection Needs More Nuance

Tighter identity monitoring often improves visibility but also increases tuning overhead, because legitimate administrative work, deployment automation, and incident response can resemble compromise if the environment has poor context. The practical challenge is to avoid treating every rare identity event as malicious while still catching the small number of events that change the risk posture. For broader cybersecurity guidance, the CISA cyber threat advisories can help teams understand current attacker behaviour, while the ENISA Threat Landscape is useful for validating which identity abuse patterns are recurring across sectors. Those sources are supporting context, not a substitute for runtime identity telemetry.

There is also a genuine consensus gap on how much identity signal should be treated as primary evidence versus correlation material. Some teams prioritise direct privilege and authentication anomalies, while others build broader sequences that include downstream cloud actions. Both approaches can work, but the weaker model is the one that relies on static threat intelligence to explain what is already happening in production rather than detecting the behaviour first.

Practitioner Guidance

What to prioritise: Start with the identity events that most directly change exposure, such as privilege elevation, token issuance, new trust relationships, and high-value resource access. Those are the events most likely to separate routine use from active compromise.

What to verify: Confirm that your detections can reconstruct a sequence across systems, not just alert on isolated anomalies. If you cannot connect authentication to action, you will struggle to tell benign automation from attacker tradecraft.

Common mistake: Teams often overfit detections to known adversary indicators and underinvest in identity context, which leaves them blind to novel abuse that still follows familiar access patterns.

Practitioner takeaway: Identity-led detection works best when the team treats access behaviour as the source of truth and threat intelligence as enrichment, not as the starting point for understanding compromise.

Related resources from NHI Mgmt Group

• How should security teams implement identity threat detection without relying on logs alone?
• How should security teams use identity data for threat detection instead of just compliance reporting?
• How should security teams build intrusion detection for CI/CD environments instead of relying on logs alone?
• How should security teams use MFA denials in identity threat detection?