A few years ago, a breach almost always started the same way: someone found a hole in your software and climbed through it. A missed patch, an exposed port, a zero-day nobody had named yet.
That still happens. But it is only part of the story.
The other half is quieter, and in some ways more unsettling. An attacker gets hold of a password that already works. They open a browser, type it into your company’s normal login page, and wait for the MFA prompt. Thanks to a phished session token or a fatigued employee tapping “approve” on the fifth push notification of the night, they may get past it too. Then they’re in. Not as an intruder. As a user.
No malware to trip an antivirus signature. No exploit to trip an intrusion detection rule. Just a login that looks, on paper, like the legitimate ones happening at the same time.
Quick answer: Identity Threat Detection and Response (ITDR) exists because traditional security tools such as firewalls, EDR, and network monitoring are built to catch attackers breaking in. They were not designed to catch every attacker who logs in with credentials that pass authentication. ITDR helps close that gap by treating identity as a monitored and defensible layer of security, rather than assuming the login screen is where security ends.
For most of the industry’s history, “defend the perimeter” was a reasonable strategy, because there was a perimeter. Servers sat in a data center you controlled. Employees sat behind a firewall you configured. If something was inside the network, it was, by definition, at least somewhat trusted.
That assumption doesn’t hold anymore, and it hasn’t for a while. Today’s enterprise is stitched together across an on-premises Active Directory forest, one or more cloud identity providers, a multi-cloud footprint spanning AWS, Azure, and Google Cloud, and a long tail of SaaS applications that IT may or may not fully know about. There isn’t a single network boundary to defend, because there isn’t a single network.
What’s left, the one thing that has to touch every part of that sprawl, is identity. Every server, every SaaS login, every API call eventually traces back to someone’s credentials. Which means identity isn’t just a security layer anymore. For many real-world attacks, it is a critical part of the attack path.
Attackers figured this out well before most security budgets caught up. According to Verizon’s 2026 Data Breach Investigations Report, exploitation of vulnerabilities accounted for 31% of known initial access vectors in the report’s dataset. But when Verizon looked at credential abuse across the full breach progression, not only the first step, it appeared in 39% of breaches. These figures describe different stages of the attack, and both matter. An attacker may exploit a vulnerability to gain an initial foothold, then use credentials and legitimate access to move through an environment.
That’s the part traditional tools can miss. And it’s worth being specific about how, because “credential-based attack” covers a lot of different techniques.
Password reuse is still a serious security concern, so attackers may run exposed credential lists against corporate SSO gateways and other services. They are not necessarily guessing passwords. They are checking whether a password that worked somewhere else also works for your VPN or another company system.
Adversary-in-the-Middle phishing kits can help attackers get around some MFA protections. Instead of trying to defeat the second factor directly, an attacker may sit between the user and the real login page, capture the session cookie or token when it is issued, and reuse it. The resulting activity can look like a legitimate authenticated session.
Inside Active Directory, techniques like Kerberoasting and AS-REP roasting target aspects of how authentication works. An attacker may request a service ticket, attempt to crack it offline, and use the result to obtain credentials. The technique abuses identity infrastructure rather than relying on a conventional software exploit.
The contractor whose project ended months ago. The service account someone created for a migration and never decommissioned. These accounts can remain active after their original purpose disappears, and may have no clear owner watching for unusual activity. A dormant account becoming active is not automatically malicious, but it can be an important signal when combined with other context.
An account does not need to be formally named “Administrator” to have powerful permissions. Access can accumulate through inherited permissions, delegation, or nested group membership that no one has reviewed. On paper, an account may look like an ordinary user. In practice, it may have the ability to perform sensitive administrative actions.
None of this happens because security teams are careless. It happens because the tools doing the watching were built to answer a different question.
An EDR agent is designed to spot suspicious endpoint activity, such as a malicious process. It may have little context about whether the user running a normal process should be doing so from that device, at that hour, or from that location. A next-generation firewall can inspect traffic patterns, but an authenticated session over TLS may still appear to be just that: authenticated. A SIEM built around log aggregation can record a successful login, but the login event alone may not explain whether the identity’s activity is unusual.
The attacker isn’t necessarily hiding from these tools. They may be using legitimate access in ways that the tools were not designed to evaluate on their own.
The question ITDR is built to help answer is: Is this identity behaving the way it should right now, across the systems it touches? Not simply “Did someone log in?” but “Does this login and the activity that follows make sense for this identity, at this moment, in this context?”
Many identity security tools are built around different architectural approaches. Each approach can address part of the problem, but can also create limitations when deployed in a real production environment with real operational demands.
In Part 2: 4 Identity Security Approaches That Fail in Production, we examine four approaches and the gaps they can create. These include kernel agents that raise infrastructure concerns, governance platforms that can become a rubber-stamping exercise, and privileged access vaults that engineers may work around.
In Part 3: The Zero-Friction Alternative: How Seceon aiSecurity UIDGuard360 Approaches Identity Threat Detection, we look at an alternative architecture and how it aims to address identity security without introducing unnecessary operational friction.
Identity Threat Detection and Response (ITDR) is a category of security tooling focused on detecting, investigating, and responding to threats that abuse legitimate identities and credentials. It monitors authentication behavior, privilege use, and account activity across on-premises directories, cloud identity providers, and SaaS platforms to help identify attacks that may look like normal logins.
EDR primarily evaluates endpoint activity, while SIEM collects and correlates security events. An attacker using valid, stolen credentials may generate activity that does not look like a malicious process or an obvious network attack. Identity-specific behavioral context can help security teams assess whether the authenticated activity is legitimate.
A dormant account is one that has not been used for a while, such as a former contractor’s login or an old service account. It can be risky if it remains active and unmonitored. A shadow admin account is an account with effective administrative privileges through indirect or inherited permissions, even though it may not belong to a formally managed admin group.
The phrase describes how identity now connects users and services to resources across on-premises infrastructure, cloud platforms, and SaaS applications. Verizon’s 2026 DBIR found that credential abuse appeared in 39% of breaches when counted across the full breach progression, even though vulnerability exploitation led the known initial access vectors at 31%. The figures measure different points in an attack, illustrating why both initial entry and activity after authentication matter.
