Trend

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.

All

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.

Short version

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

SignalWhat happensWhy EDR/SIEM alone often miss it
Refresh-token replayAn 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 abuseA 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 geolocationSign-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 escalationNew 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 bombingAn 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 attacksAn 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

  1. Telemetry onboarding: sign-in logs, audit logs, risk detections, directory changes from Entra ID, Okta or AD; plus Graph activity in M365.
  2. Use-case catalogue: token replay, consent grants to unknown apps, MFA bombing, role changes outside change windows, session use outside device context.
  3. 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.
  4. Correlation with EDR and SIEM in the SOC case process; no siloed alerts.
  5. Metrics: MTTD and MTTR for both identity and endpoint cases.
Prerequisite: phishing-resistant MFA

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.

Continue reading in this cluster
Detecting and stopping token theft and session hijacking
Token theft means attackers steal the session or refresh token of an already authenticated user and use it to bypass MFA. The classic path is reverse-proxy phishing (adversary-in-the-middle), increasingly also endpoint info-stealers. A SOC detects this from token usage outside the user context, not from the login itself. Defence means phishing-resistant MFA, Continuous Access Evaluation, token binding and detection on refresh-token replay.
Detecting and stopping Business Email Compromise in Microsoft 365
Business Email Compromise (BEC) in Microsoft 365 rarely involves malware. The attack chain involves phishing, session or token theft, inbox rules and OAuth consent abuse. A SOC detects BEC by correlating signals from Entra ID, Exchange Online and Defender for Cloud Apps. The email body alone is insufficient for detection. Responders revoke sessions, remove inbox rules, withdraw OAuth consents and enforce MFA again. They document these actions in line with ISG and insurance requirements.
SOC as a Service in Switzerland: The Complete Guide
SOC as a Service is an externally operated Security Operations Center that monitors your environment around the clock, detects attacks and triggers the response. According to Mandiant M-Trends 2026, attackers went undetected for a median of 14 days in 2025. With a SOC that detects and assesses around the clock, typical detection time becomes much shorter.
What is MDR? Managed Detection and Response explained
Managed Detection and Response (MDR) is the common name for a service that detects attacks, investigates them and responds, including isolating compromised systems. MDR is neither a tool nor a platform, but a contract with defined response duties. At ANOMAL, this service is part of SOC as a Service.
MTTD and MTTR: the two SOC KPIs that count
Mean Time to Detect (MTTD) measures how fast a SOC spots an attack. Mean Time to Respond or Contain (MTTR, MTTC) measures how fast it is stopped. Together they are the only credible evidence that a SOC is working, not just running.