ITDR: Identity Threat Detection and Response for Switzerland
ITDR (Identity Threat Detection and Response) detects attacks on the identity itself, not just endpoints or networks. Targets are accounts, tokens, sessions, permissions and identity providers such as Entra ID or Okta. ITDR extends EDR and SIEM with signals only visible in the identity layer. These include impossible travel, consent phishing, refresh-token abuse, role abuse and attacks on federation and directory objects. For Swiss organisations running M365, Entra ID and regulated processes, ITDR today is as important as EDR was five years ago.
Scope: ITDR vs token theft vs glossary
This page covers ITDR as a category, including its detection signals, integration into a SOC and relationship with EDR and SIEM. Token theft and session hijacking covers the specific attack vector: token theft through adversary-in-the-middle attacks, refresh-token replay and session hijacking. For a short definition see Glossary ITDR. For the operational SOC framework, see SOC as a Service Switzerland.
Token theft is an attack. ITDR is the detection-and-response discipline that surfaces such attacks in the identity layer and stops them.
Which signals ITDR detects
| Signal | What happens | Why EDR/SIEM alone often miss it |
|---|---|---|
| Refresh-token replay | An attacker redeems a stolen refresh token from a different device or IP range. | The login itself looks clean; only the identity provider sees the context switch. |
| Consent phishing / OAuth app abuse | A user grants a malicious app broad Graph permissions; the attacker exfiltrates mail and files. | No classic login alert, no malware signal on the endpoint. |
| Impossible travel and unusual geolocation | Sign-in from Bern and three minutes later from Singapore with the same session. | SIEM sees logs but without identity context has no per-user baseline. |
| Directory privilege escalation | New role assignment, addition to Global Admins, changes to Conditional Access policies. | The action looks like normal admin work; ITDR distinguishes expected activity from anomalous activity. |
| MFA fatigue and push bombing | An attacker triggers repeated MFA prompts until the user accepts. | A single failed sign-in looks harmless; only the pattern is the alert. |
| Federation and Golden SAML attacks | An attacker forges SAML tokens with a stolen signing certificate and bypasses login entirely. | Nothing on the endpoint, nothing in the SIEM standard feed; only directory and signing telemetry shows it. |
ITDR versus EDR, SIEM and MDR
ITDR replaces neither EDR nor SIEM nor a managed detection offering (MDR). It closes the gap that opens when attacks shift from endpoints or networks to the identity provider. A modern SOC correlates ITDR signals with EDR and SIEM signals: a suspicious token use gains weight when the associated endpoint had an info-stealer hit. Conversely an EDR alert becomes more severe when a consent grant on a sensitive mailbox happens in parallel.
Why ITDR is becoming mandatory in Switzerland now
- M365 and Entra ID are standard in Swiss SMEs and enterprises. Attackers know this and target the identity layer; see BEC in M365.
- Token theft bypasses classical MFA; without ITDR signals the attack stays unnoticed until the data-exfiltration phase.
- revFADP (revised Federal Act on Data Protection) and FINMA rules demand traceability of who did what and when; without identity telemetry this cannot be reconstructed after the fact. See revFADP and SOC and SOC and FINMA requirements.
- ISG notification duty: compromised identities with access to personal data can trigger the 24h notification, see SOC and ISG reporting.
How ITDR is embedded in a SOC
- Telemetry onboarding: sign-in logs, audit logs, risk detections, directory changes from Entra ID, Okta or AD; plus Graph activity in M365.
- Use-case catalogue: token replay, consent grants to unknown apps, MFA bombing, role changes outside change windows, session use outside device context.
- Response playbooks: session invalidation, refresh-token revocation, password reset, app consent revocation, temporary lockout. Teams document every action and attribute it to a responsible person.
- Correlation with EDR and SIEM in the SOC case process; no siloed alerts.
- Metrics: MTTD and MTTR for both identity and endpoint cases.
ITDR reduces impact but does not replace hard controls. Phishing-resistant MFA (FIDO2, passkeys, certificate-based), Conditional Access with device compliance and Continuous Access Evaluation form the foundation. ITDR detects what still gets through.
Frequently asked questions
What is the difference between ITDR and EDR?
EDR observes the endpoint (processes, files, memory). ITDR observes the identity (sign-ins, tokens, roles, consent grants). Attacks such as token theft or consent phishing leave almost no trace on the endpoint; they are only visible in the identity layer. See also [EDR](/en/glossary/edr).
Is Entra ID Protection enough as ITDR?
It is one building block, not a complete ITDR. Entra ID Protection delivers risk signals (risky sign-in, risky user). A SOC additionally needs detection rules on Graph activity, consent grants, app registrations and response playbooks. Risk-based detection requires at least Entra ID P2.
How does ITDR relate to MDR?
MDR is a delivery model (Managed Detection and Response). ITDR is a detection category. A strong MDR offering for Switzerland includes ITDR use cases; an MDR without identity coverage is incomplete. See [What is MDR](/en/soc/what-is-mdr).
Is ITDR also relevant for SMEs?
Once an SME uses M365 or a SaaS portfolio, the identity layer becomes the primary attack path. SMEs can obtain ITDR as part of a managed SOC; see [SOC for SMEs](/en/soc/soc-for-sme).
Which response actions belong to ITDR?
ITDR response actions include session invalidation, refresh-token revocation, password reset, revocation of malicious OAuth app consents, temporary lockout and role rollback. Teams must document every action and attribute it to a responsible person to satisfy revFADP (revised Federal Act on Data Protection) and FINMA traceability.
Related terms
- IAM Identity and Access Management (IAM) controls who can access specific systems and data within an organisation.
- MFA Multi-Factor Authentication requires a second form of verification in addition to a password during login.
- Conditional Access Conditional Access is a form of policy-based access control for user sign-ins and sessions.
- Privilege Escalation Privilege escalation describes the process of gaining higher permissions than an account or process is assigned.
- Lateral Movement Lateral Movement describes how attackers move from system to system and escalate privileges after initial access.