# What Is ITDR? Detecting Identity Attacks With Identity Threat Detection and Response

**URL:** https://securesys.com.tr/en/learning/identity-and-access-management/what-is-itdr-identity-threat-detection

![What Is ITDR? Detecting Identity Attacks With Identity Threat Detection and Response](/images/bilgi-merkezi/covers/cover-pamiam-07.webp)

In modern cyber attacks attackers do not always have to run malware, use an exploit or target security devices directly. Sometimes obtaining a valid user account, passing a legitimate MFA verification or stealing an existing session token can be much more effective for the attacker.

This situation brings out an important problem of cyber security:

**The system may be seeing a valid user, but that user may not really be the owner of the account.**

**This is exactly the modern security approach that focuses on solving this problem: ITDR – Identity Threat Detection and Response.**

ITDR aims to detect identity-based attacks, to analyze the anomalies in identity behavior, to correlate risky authentication and authorization activities and where necessary to apply a fast response.

For this reason ITDR is not only a technology that monitors failed login attempts.

Modern ITDR tries to answer these questions:

Could an identity have been compromised?

Is the user behaving differently from normal?

Was the MFA really approved by the user?

Could the session token have been stolen?

Did privilege escalation take place?

Is the user going to systems they have never accessed before?

Has lateral movement started over the identity?

The answers to these questions are becoming increasingly critical for modern SOC operations.

### What Is ITDR?

**ITDR, that is, Identity Threat Detection and Response, is the security approach that enables threats aimed at human and machine identities to be detected, analyzed and acted upon.**

ITDR creates visibility over identity-based attacks by bringing together identity signals coming from systems such as IAM, PAM, Active Directory, Entra ID, cloud IAM, MFA, SSO, endpoint and SIEM.

Traditional authentication monitoring looks more at events such as:

Successful Login

Failed Login

Password Reset

these events.

ITDR, on the other hand, goes beyond this.

For example a login can be successful but the user:

connected from a device they do not normally use,

appeared in different geographies within minutes,

changed their MFA method,

received a new privileged role,

then accessed a critical server

they may have done these.

None of these events on its own may be a definite attack indicator.

However, when evaluated together they can create a strong compromise signal.

For this reason the fundamental value of ITDR is:

#### Identity Event Correlation

and

#### Behavioral Context

being able to create these.

### Why Has Identity Threat Detection Now Become Critical?

The large part of modern organizations uses cloud, SaaS and hybrid identity.

A user's access is no longer limited only to the local network.

The same identity:

Microsoft 365,

a cloud console,

CRM,

ERP,

VPN,

file sharing,

a development platform

can access many systems such as these.

For this reason when an identity is compromised the attacker's room for movement can grow significantly.

Moreover if the attacker is using legitimate credentials the firewall or traditional network security controls can see this activity as normal traffic.

For this reason the modern attack model:

#### Exploit the System

from this approach is increasingly shifting to:

#### Exploit the Identity

this approach.

ITDR answers this change.

### What Is Account Takeover?

Account Takeover is the attacker obtaining a real user account and behaving like that user.

The attacker can access the account with methods such as:

phishing,

credential stuffing,

password spraying,

malware,

session theft,

social engineering

these.

After an account takeover, because the attacker uses a legitimate identity detection can become harder.

For example the user appears to have really carried out authentication.

The MFA may have been passed.

The IP address may belong to a cloud provider.

For this reason only login success/failure data is not sufficient.

ITDR tries to determine the account takeover risk by analyzing the user behavior and context.

### How Is Credential Theft Detected?

Credential Theft can be the password being stolen directly.

However, in a modern environment the attacker:

NTLM hashes,

Kerberos tickets,

browser credentials,

OAuth tokens,

API keys,

session cookies

can also target many authentication artifacts such as these.

For this reason credential theft should not be thought of only as "password compromise".

When ITDR and endpoint telemetry work together stronger visibility can be provided.

For example EDR detects credential dumping-like behavior on the endpoint.

A short time later the same user starts to log in to different servers.

ITDR by correlating these two signals can create a high-risk identity incident.

This model:

#### Endpoint Signal + Identity Signal

is the combination.

### How Does Password Spraying Look on the ITDR Side?

In a Password Spraying attack the attacker tries a small number of common passwords on a large number of accounts.

The aim is to find the correct credential without exceeding the account lockout thresholds.

For example:

a single password on 1000 users

or:

a few passwords on 100 users

can be tried.

Traditional monitoring can see this as separate login failures.

ITDR, on the other hand, analyzes it as a pattern.

The same source IP,

the same password pattern,

a large number of different users,

a short time interval

can be evaluated together.

In this way a distributed password attack can be detected.

### The Difference Between Credential Stuffing and Password Spraying

Credential Stuffing is username-password combinations obtained earlier from other breaches being tried on different services.

Password Spraying, on the other hand, is the same or a few common passwords being tried on a large number of users.

Both attacks are in the identity attacks category.

MFA, passwordless authentication and risk-based authentication can reduce these risks.

However, attack attempts are still important in terms of detection.

Because continuous password spraying being seen can show that the organization is being targeted.

### How Is MFA Fatigue Detected with ITDR?

In an MFA Fatigue or MFA Bombing attack a large number of MFA push requests are sent to the user within a short time.

The attacker may already know the password.

The target is to force the user to give approval by mistake or as a result of social engineering.

ITDR can analyze these patterns:

Repeated MFA Requests

Multiple Denials

Sudden Approval

New Device Registration

Unusual IP

events such as these.

For example if 20 MFA denials and then one approval are seen within 5 minutes this may not be a normal authentication pattern.

A high-priority alert can be created for the SOC.

### If the MFA Is Successful Is There No Attack?

No.

This is one of the most critical points of modern identity attacks.

MFA success does not mean a legitimate user.

The attacker:

MFA fatigue,

social engineering,

AiTM phishing,

SIM swap,

a stolen session

can get past MFA with methods such as these.

For this reason:

#### MFA Passed

on its own:

#### Identity Trusted

should not mean this.

ITDR must also monitor the behaviour after authentication.

### Adversary-in-the-Middle and ITDR

In an AiTM phishing attack the attacker can put a proxy between the user and the legitimate application.

The user completes the username-password and MFA flow.

The attacker obtains an authenticated session token.

In this case the attacker may not have "skipped" the MFA during login.

The MFA has really been completed.

However, the session has passed into the attacker's hands.

ITDR here can try to detect the risk over signals such as:

new session properties,

device mismatch,

token usage pattern,

geographic anomaly,

unexpected application access

these.

### Why Is Token Theft One of the Fundamental Areas of ITDR?

In modern cloud identity systems tokens are at the centre of authentication.

The Access Token and Refresh Token enable the user to use services without entering the password again.

If the attacker obtains a token they can provide access without logging in again to the identity provider.

In this case:

No Failed Login

No Password Attack

No MFA Prompt

can be seen.

Traditional authentication monitoring may not notice anything.

For this reason token security is among the critical subjects of modern ITDR.

Suspicious token reuse or unusual session behavior can be an identity threat indicator.

### How Can Session Hijacking Be Detected?

After Session Hijacking the attacker uses the legitimate user session.

For detection not only the login event but:

the session source,

device,

browser,

location,

behavior,

access pattern

must be analyzed.

For example the user session may have started in Istanbul.

Minutes later the same session can start to be used from another geography or unusual infrastructure.

A geographic signal on its own is not definite proof.

VPNs and cloud proxies can create a false positive.

For this reason ITDR must evaluate multiple signals together.

### What Is Impossible Travel?

Impossible Travel is the user appearing to have carried out authentication from locations far from each other within a time that would not be physically possible.

For example if the user appears to have logged in in Singapore 10 minutes after logging in in Ankara a risk signal can arise.

However, because of modern network architecture this signal is not reliable on its own.

A VPN,

a corporate proxy,

a cloud access service

can show the IP location differently.

For this reason mature ITDR does not use geography alone.

Device identity,

browser fingerprint,

session behavior,

user history

it creates context with additional data such as this.

### Identity Analytics and UEBA

Identity Analytics tries to detect deviations by analyzing the normal behavior patterns of users and identities.

**UEBA, that is, User and Entity Behavior Analytics, is the broader form of this approach.**

For example the user normally:

between 09:00–18:00,

from Türkiye,

to 5 standard SaaS applications

may be accessing these.

One night the user:

logs in at 03:30,

uses a new device,

goes to the cloud admin portal,

downloads a large number of files,

activates a privileged role.

Every event can be possible separately.

However, together they form an unusual behavior pattern.

UEBA can raise the risk score.

### What Is Peer Group Analysis?

Comparing a user's behavior only with their own history is not always sufficient.

For a new employee there may not be a historical baseline.

In this case a peer group can be used.

For example if Finance Analysts generally use particular applications but one Finance Analyst accesses the DevOps production environment it can be an unusual entitlement or behavior.

Peer Group Analysis:

role,

department,

job function

can make a comparison over attributes such as these.

This also creates an important connection between IGA and ITDR.

### How Does Privilege Escalation Look on the Identity Side?

Privilege Escalation is the attacker moving from normal user access to a higher authority.

This can happen in various ways:

the user is added to a privileged group,

a cloud role is activated,

PAM access is received,

a new administrator account is created,

a service account's privilege is increased.

ITDR can evaluate these changes as high-risk identity events.

Especially the combination:

Rare Privilege Change

High-Risk User

Unusual Session

can be critical.

### Why Is Active Directory Important for ITDR?

Active Directory is at the centre of the identity infrastructure in many enterprise environments.

An AD compromise can give the attacker broad control.

Attackers:

credential theft,

Kerberos abuse,

privileged group changes,

lateral movement,

directory reconnaissance

can use techniques such as these.

For this reason ITDR must provide visibility over Active Directory activities.

Especially:

Domain Admin changes,

unusual authentication,

service account behavior,

sensitive object access

events such as these must be monitored.

### Kerberos and Identity Threat Detection

Kerberos is one of the important components of Active Directory authentication.

The attacker by abusing Kerberos tickets can provide lateral movement or persistence.

Attack concepts such as Golden Ticket, Silver Ticket or Pass-the-Ticket are directly related to identity security.

These attacks can require detailed forensic analysis.

ITDR tools can try to detect suspicious behavior over authentication relationships and ticket anomalies.

The fundamental security principle here:

**A credential is not only a password.**

An authentication ticket can also carry the nature of a credential.

### Lateral Movement and Identity Security

Lateral Movement is the attacker progressing from the initial compromised system to other systems.

This movement most of the time takes place over credentials.

For example the attacker obtains a credential on an employee laptop.

Then:

File Server

↓

Application Server

↓

Database Server

↓

Domain Controller

they can try to progress in this way.

This chain can be seen on the network traffic.

However, identity logs show which account moved between which systems.

For this reason NDR + EDR + ITDR together can provide strong lateral movement visibility.

### ITDR and PAM Integration

PAM controls high-risk privileged access.

ITDR, on the other hand, detects the identity risk.

When these two systems work together an adaptive privileged access model can arise.

For example ITDR:

User Risk = High

detected this.

The user at the same time is requesting Domain Admin access over PAM.

While under normal conditions access would be given after approval, because of the high-risk identity the PAM request can be blocked.

This is the:

#### Risk-Aware PAM

model.

In another case after an ITDR alert PAM can rotate the privileged password.

This is the merging of identity threat detection with privileged response.

### ITDR and IAM Integration

IAM applies the identity controls.

When ITDR detects a risk a response can be carried out over IAM.

For example:

Force Password Reset

Require Stronger MFA

Block Sign-In

Revoke Session

Disable Account

actions such as these can be applied.

For this reason ITDR should not only produce alerts.

In a mature architecture response orchestration is necessary.

### ITDR and IGA Integration

IGA governs which permissions the user should have.

ITDR, on the other hand, evaluates whether the current identity behavior is risky.

When these two systems are combined an event-driven access review can be carried out.

For example after a high-risk identity incident:

Privileged Entitlements Review

Sensitive Data Access Review

External Access Review

can be started.

This model:

**Detect Risk → Re-Evaluate Entitlements**

is this approach.

### The Difference Between ITDR and SIEM

The SIEM collects logs from many different security systems and carries out correlation.

ITDR, on the other hand, specializes in identity threats.

The SIEM:

Firewall

Endpoint

Network

Application

Identity

collects these logs together.

ITDR, on the other hand, can provide deeper analytics on identity relationships and identity behavior.

For this reason ITDR is not an alternative to the SIEM.

The strongest model:

**ITDR → Identity Intelligence**

**SIEM → Enterprise Correlation**

is in this way.

### The Relationship Between ITDR and XDR

XDR can combine endpoint, e-mail, cloud, identity and other security telemetry at the incident level.

ITDR provides identity-specific detection.

For example:

Phishing Email

↓

Credential Theft

↓

Risky Login

↓

Privilege Escalation

↓

Endpoint Activity

can be seen inside a single incident chain.

XDR provides attack chain visibility.

ITDR, on the other hand, deepens the identity part of the chain.

### Microsoft Defender for Identity, CrowdStrike and Identity Security Platforms

Modern identity threat detection can be offered inside different security platforms.

Microsoft Defender for Identity is one of the solutions associated especially with Active Directory and identity-related threat detection use cases.

Platforms such as CrowdStrike Falcon Identity Protection can offer identity risk and attack detection use cases.

Identity security platforms such as Silverfort can also be positioned in the authentication and identity protection area.

PAM and IAM vendors are also increasingly developing identity threat analytics capabilities.

The important point here is the architecture rather than the product category.

The organization must answer this question:

**On which platform will identity telemetry be collected, how will it be correlated and when a risk is detected which response will be applied?**

### What Should Be Looked at When Choosing an ITDR Product?

During product evaluation looking only at the detection list is not sufficient.

These criteria can be evaluated:

Active Directory Visibility

Entra ID / Cloud Identity Integration

MFA Signals

Session / Token Visibility

PAM Integration

SIEM Integration

XDR Integration

Behavior Analytics

Risk Scoring

Automated Response

Non-Human Identity Support

areas such as these are important.

In addition the false positive rate and SOC workflow integration are critical subjects.

Producing an alert is easy.

Producing a high-quality identity alert the SOC can use is more valuable.

### How Does Risk Scoring Work in ITDR?

Identity risk does not have to be determined over a single event.

Different signals can receive a weight.

For example:

New Device = +10

Unusual Location = +15

MFA Fatigue Pattern = +30

Privileged Role Activation = +40

Sensitive Data Access = +25

risk scores such as these can be thought of.

When the threshold is exceeded:

Step-Up Authentication

Block

Session Revocation

SOC Alert

can be applied.

This model creates adaptive identity security.

### Are Identity Risk Score and User Risk the Same Thing?

They can be similar concepts but the implementation changes according to the platform.

Identity Risk can express the compromise probability of the user.

Session Risk can be the risk for a particular login/session.

Entitlement Risk can express the impact of the permissions the user has.

A modern architecture can evaluate these three risk types together:

#### Identity Risk × Privilege Level × Resource Sensitivity

In this way a more correct incident severity can be determined.

### What Is a High-Risk Identity?

A High-Risk Identity is not only a user thought to have been attacked.

There are also identities that are naturally high-impact because their privilege level is high.

For example:

Domain Admin

Global Administrator

PAM Administrator

Backup Administrator

can be monitored separately as high-risk identities.

For these accounts a lower detection threshold than for a normal user can be used.

### Service Account and Non-Human Identity Threat Detection

Service Accounts and Machine Identities may not show traditional user behavior.

However, when they are compromised they can create a serious risk.

For example a service account normally connects to the database only from one application server.

If it suddenly carries out an interactive login from a different workstation it is suspicious.

For this reason a baseline can be created for NHI behavior.

For example:

Expected Source

Expected Target

Expected Protocol

Expected Time

can be determined.

A deviation creates a high-risk signal.

### Machine Identity and Token Abuse

Inside cloud environments machine identities:

Service Principals

Managed Identities

Workload Identities

API Keys

Certificates

Tokens

can use these.

The attacker can obtain a machine credential instead of a human user.

In this case MFA cannot be applied.

For this reason for NHI security:

Short-Lived Credentials

Credential Rotation

Usage Analytics

Identity Threat Detection

become more critical.

### Are AI Agents a New Difficulty for ITDR?

Yes.

AI Agents because of automation can carry out very fast and high-volume actions.

Normal human behavior analytics may not be meaningful for an AI Agent.

For this reason agent identities require a separate baseline.

For example if the agent normally uses only the ticket system and the EDR API, it suddenly requesting financial database access can be unusual.

For AI Agent threat detection:

Agent Identity

Allowed Tools

Allowed Actions

Expected Data Access

Execution Context

signals such as these can be used.

**This can form the Agent Identity Threat Detection area of the future.**

### How Should ITDR Incident Response Be?

After detection the response must be planned in advance.

For example in a suspicion of a compromised identity these actions can be applied:

Session Revocation

Token Revocation

Password Reset

MFA Re-Registration Review

Account Disable

PAM Credential Rotation

Privilege Removal

Endpoint Isolation

Access Review

Forensic Investigation

However, every identity alert should not result in an account disable.

The business impact must be taken into account.

For this reason risk-based response playbooks must be created.

### Why Is Token Revocation Different from a Password Reset?

A mistake frequently made in organizations is when a compromised account is seen only changing the password.

However, if the attacker has an authenticated session or refresh token the session can continue after the password reset.

For this reason during incident response:

Password Reset

Active Session Revocation

Token Revocation

must be evaluated together.

For modern cloud incident response this is an extremely critical subject.

### Why Should MFA Reset Events Be Monitored?

An MFA reset can be a valuable persistence mechanism for the attacker.

After gaining access to the account the attacker can try to register their own authenticator.

For this reason:

New MFA Method

MFA Device Change

MFA Reset

events are high-value identity signals.

Especially when seen on a privileged user they can be reviewed by the SOC.

### Why Is a New OAuth Application Consent a Risk Signal?

The user can give OAuth permissions to a malicious application.

This application can provide data access for a long time.

Therefore ITDR must monitor not only the login but also authorization changes.

For example:

a new OAuth consent,

a new application registration,

a new service principal permission

events such as these can be evaluated within the scope of identity threat detection.

### ITDR and Conditional Access

The ITDR risk score can affect Conditional Access decisions.

For example if the user is low-risk normal access is given.

If they are medium-risk phishing-resistant MFA is requested.

If they are high-risk the login is blocked.

This is the:

**Detect → Adapt Access**

model.

Identity security in this way becomes dynamic instead of static policies.

### ITDR and Zero Trust

In the Zero Trust model the identity is not accepted as trusted at the beginning.

Every access request is evaluated according to the context.

ITDR is an important source of this context.

Because the user can be high-risk right now.

For this reason a Zero Trust architecture:

Identity

Device

Network

Entitlement

Behavior

Risk

must use these signals.

ITDR in particular provides the:

#### Behavior + Identity Risk

this layer.

### An Identity-Centric Incident View for the SOC

On a traditional SOC alert screen:

IP Address

Hostname

Malware Hash

technical indicators such as these come to the fore.

In an identity-centric SOC approach, on the other hand, the incident can be created around the user.

For example:

User: ahmet.yilmaz

Role: Finance Manager

Privilege: Payment Approval

Device: Managed Laptop

Risk: High

Events:

MFA Fatigue

New Device Login

OAuth Consent

Large File Download

This view enables the analyst to understand the business impact faster.

Identity Context improves incident prioritization.

### ITDR Use Case: From Phishing to Privileged Access

Let us think of an example attack chain.

The user receives a phishing e-mail.

They give their password on a fake page.

The attacker starts a login attempt.

An MFA push is sent.

The user approves by mistake.

The attacker obtains SaaS access.

They go to the cloud portal.

They try privilege escalation.

They request PAM access.

Inside this chain the controls:

**E-mail Security can detect the phishing.**

**IAM applies the authentication policy.**

**ITDR detects the abnormal identity behavior.**

**PAM can block the privileged request.**

**The SIEM/XDR can correlate the whole chain.**

For this reason a modern security architecture must be built on integrated signals rather than on products.

### ITDR Use Case: Token Theft

The user logs in legitimately.

They use a passkey.

The phishing-resistant authentication is successful.

However, the endpoint has been compromised by malware.

The attacker steals the browser session token.

They access the SaaS application over different infrastructure.

In this attack the password has not been stolen.

The MFA has not been bypassed.

The authentication security is strong.

However, the session has been compromised.

ITDR can detect the risk over unusual token/session behavior.

This example shows why Identity Security needs to go beyond the login event.

### ITDR Use Case: Service Account Compromise

A service account normally:

Application Server A

over this:

Database Server B

connects to this system.

The attacker obtains the credential.

The service account carries out an interactive login over a workstation.

Then it tries to access the file server.

This behavior does not match the normal baseline.

ITDR/NHI analytics can create a high-risk alert.

PAM can automatically rotate the credential.

The SOC can isolate the endpoint.

This is an example of automated identity response.

### How Should an ITDR Programme Be Started?

A successful ITDR project should not start only with a product deployment.

First the identity attack surface must be understood.

In the first stage these sources can be determined:

Active Directory

Entra ID / Cloud IdP

IAM

PAM

MFA

VPN

Endpoint

Cloud Platforms

SaaS

Identity telemetry must be collected from these data sources.

Afterwards critical identities must be classified.

Domain Admin,

Global Admin,

PAM Admin,

Finance Approver,

Backup Admin

high-impact identities such as these can be monitored separately.

At the following stage priority use cases must be created.

For example:

Password Spraying

MFA Fatigue

Privilege Escalation

New MFA Registration

Suspicious Session

Token Abuse

Service Account Anomaly

detections such as these can be prioritized.

### ITDR KPIs and KRIs

An ITDR programme must be measurable.

Example metrics:

Identity Alert Volume

High-Risk Identity Count

Mean Time to Detect Identity Threat

Mean Time to Revoke Session

Compromised Account Rate

MFA Fatigue Detection Count

Privilege Escalation Detection Count

Token Abuse Detection Count

Service Account Anomaly Count

False Positive Rate

Automated Response Rate

indicators such as these can be used.

However, the number of alerts being high does not mean maturity.

What is important is identity attacks being detected quickly and correctly.

### The Most Frequently Made Mistakes in ITDR

In corporate identity threat detection programmes these mistakes can be seen:

- Seeing ITDR only as failed login monitoring
- Accepting MFA success as a safe identity
- Ignoring the Token Theft risk
- Not monitoring Session Hijacking
- Not analyzing Active Directory logs sufficiently
- Not sending Cloud Identity events to the SIEM
- Not monitoring New MFA Registration events
- Not monitoring OAuth Consent changes
- Accepting Privilege Changes as low-risk
- Leaving PAM telemetry outside ITDR
- Not monitoring Non-Human Identities
- Missing Service Account interactive login events
- Not adding business context to identity alerts
- Not creating a SOC playbook
- Carrying out a Password Reset and not revoking the tokens
- Not integrating identity risk with Conditional Access
- Not carrying out false positive tuning
- Thinking producing an alert is a response

### ITDR Security Checklist

Organizations can evaluate the following controls:

- Is identity telemetry centralized?
- Are Active Directory events being monitored?
- Are Cloud Identity logs being monitored?
- Are MFA logs being transferred to the SOC?
- Are Password Spraying detections present?
- Are Credential Stuffing patterns being monitored?
- Is MFA Fatigue being detected?
- Does New MFA Registration produce an alert?
- Is Impossible Travel evaluated with context instead of being used on its own?
- Are Token Theft use cases present?
- Is Session Hijacking monitoring being carried out?
- Are Privilege Escalation events being monitored?
- Do Domain Admin changes produce an alert?
- Are cloud role changes being monitored?
- Are PAM access events going to the SIEM?
- Are Service Accounts under behavior monitoring?
- Is a Non-Human Identities inventory present?
- Are OAuth Consent events being monitored?
- Are New Application Registrations being monitored?
- Have High-Risk Identities been classified separately?
- Is UEBA being used?
- Is Peer Group Analysis being evaluated?
- Is ITDR and EDR correlation being applied?
- Is ITDR and NDR correlation being applied?
- Is ITDR and PAM integration present?
- Is there a Session Revocation playbook?
- Can Token Revocation be applied?
- Has the Compromised Account playbook been tested?
- Is it clear under which conditions Automated Response will be used?
- Do ITDR alerts contain business context?

### ITDR Maturity Model

**Level 1 – Authentication Log Monitoring: The organization mostly monitors successful and failed login events. Identity attack visibility is limited.**

**Level 2 – Centralized Identity Detection: AD, cloud identity and MFA logs become centralized on the SIEM. Password spraying and suspicious login detections are applied.**

**Level 3 – Behavioral Identity Security: UEBA, privilege changes, MFA anomalies, token/session events and PAM telemetry are evaluated together.**

**Level 4 – Integrated ITDR: ITDR works integrated with IAM, PAM, EDR, XDR and the SIEM. Risk-based response is applied.**

**Level 5 – Adaptive Identity Defense: Human, Machine and AI Agent identities are evaluated continuously with real-time risk scoring. Sessions and privileges can be adjusted or revoked automatically.**

This transformation:

#### Login Monitoring

↓

#### Identity Analytics

↓

#### Identity Threat Detection

↓

#### Automated Identity Response

↓

#### Continuous Adaptive Identity Defense

proceeds in this way.

### Frequently Asked Questions

#### What is ITDR?

ITDR, Identity Threat Detection and Response, is the modern security approach that enables identity-based attacks to be detected, analyzed and responded to.

#### What is ITDR useful for?

It provides visibility over identity threats such as account takeover, credential theft, password spraying, MFA fatigue, token abuse, session hijacking and privilege escalation.

#### What is the difference between IAM and ITDR?

IAM applies access and authentication policies. ITDR, on the other hand, focuses on detecting whether these identities are under attack or compromised.

#### What is the difference between ITDR and PAM?

PAM controls privileged access. ITDR detects the identity risk. When the two systems work together the privileged access of risky identities can be blocked.

#### Are ITDR and SIEM the same thing?

No. While the SIEM carries out correlation over enterprise-wide logs and events, ITDR specializes in identity-specific analytics and detection.

#### Are ITDR and XDR the same thing?

No. XDR can combine endpoint, e-mail, cloud and identity telemetry on an incident basis. ITDR focuses more deeply on the identity attack surface.

#### If the MFA is successful is the account safe?

No. Because of MFA fatigue, AiTM phishing, session hijacking or token theft the attacker can obtain access even after a valid MFA.

#### What is Token Theft?

It is authentication artifacts such as an access token, refresh token or session token being obtained by the attacker.

#### What is Session Hijacking?

It is the authenticated session being obtained by the attacker and them trying to use it like the legitimate user.

#### What is Password Spraying?

It is the attack in which a small number of common passwords are tried on a large number of accounts to try to find a valid credential.

#### What is Impossible Travel?

It is the user appearing to have logged in within a short time from distant locations that would not be physically possible. It is not a definite compromise indicator on its own.

#### What is UEBA?

User and Entity Behavior Analytics tries to detect anomalies by analyzing the normal behavior patterns of users and entities.

#### Is ITDR necessary for Active Directory?

Because Active Directory is high-value identity infrastructure AD-focused identity threat detection can be especially important in enterprise environments.

#### Are Service Accounts within the scope of ITDR?

Yes. When service accounts and other Non-Human Identities are compromised unusual behavior must be detected.

#### Will AI Agents be within the scope of ITDR?

AI Agents that carry out privileged or sensitive actions must be taken into the scope of identity and behavior monitoring. This area is becoming an important part of Agent Identity Security.

#### Is a password reset sufficient for a compromised account?

Not always. Active sessions, refresh tokens, MFA methods and OAuth access must also be checked and where necessary revoked.

### Conclusion: To Catch the Modern Attacker It Is Necessary to Monitor Not Only the System but the Identity's Behaviour

Traditional security for many years looked for the attack over:

malware,

an exploit,

a malicious IP,

network traffic

these.

This approach is still important.

However, when the modern attacker uses a legitimate identity they can become invisible to the security controls.

The attacker:

a valid username,

a valid password,

a valid MFA,

a valid token

may be moving with these.

In this case the question:

**"Was the authentication successful?"**

should not be this.

The essential question:

**"Is this identity really behaving normally right now?"**

should be this.

ITDR is therefore the detection layer of modern Identity Security.

IAM gives the access.

IGA governs whether the access is correct.

PAM limits privileged access.

Passwordless authentication reduces the credential phishing risk.

ITDR, on the other hand, tries to detect the attack when despite all these an identity is compromised.

The modern identity defense formula:

**IAM + PAM + IGA + Phishing-Resistant Authentication + ITDR**

can be thought of in this way.

However, in a more advanced model these systems should not work as separate silos.

When the identity risk rises:

IAM must change the access,

PAM must block the privilege,

IGA must start an entitlement review,

the SIEM/XDR must create an incident,

the SOC must apply a response.

This:

**Identity Detection → Identity Decision → Identity Response**

forms this cycle.

The ITDR architecture of the future will monitor not only human users but also Non-Human Identities such as:

Service Accounts,

Workload Identities,

Machine Identities,

API Identities,

AI Agents

these.

Because from the attacker's point of view what is important is not whether the identity is human.

What is important is that identity's:

**what it can access.**

For this reason the fundamental principle of the modern Identity Threat Detection approach can be summarized as follows:

**Trust authentication less, verify behavior more.**

And the most important sentence of this chapter:

**In modern identity security a successful login is not a trust indicator; real security is provided by the continuous evaluation of how the identity behaves after authentication.**