ITDR, XDR, SIEM, MDR: A Plain-English Guide to the Microsoft 365 Security Alphabet for MSPs

Summary

Security categories describe three different things at once: which surface a tool watches, who operates it, and whether it hardens configuration or detects live attacks. Separating those axes makes the overlaps obvious. EDR watches endpoints, ITDR watches identity, XDR correlates several surfaces, SIEM stores and queries everything you feed it, SOC and MDR describe who does the watching, and ISPM and ESPM harden identity and mail configuration before anything happens. Most of these categories assume a single enterprise estate, which is where multi-tenant Microsoft 365 MSPs run into trouble.

ITDR, XDR, SIEM, MDR: A Plain-English Guide to the Microsoft 365 Security Alphabet for MSPs

Versioned specifics

• Original publication date: 7 September 2026
• Microsoft 365 products mentioned: Microsoft Sentinel, Microsoft Defender XDR (Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps), Microsoft Defender for Business, Microsoft Entra ID P1 and P2, Microsoft Entra ID Protection, Microsoft Intune Plan 1, Microsoft Purview Audit (Standard), Microsoft Secure Score, Microsoft 365 Business Premium, Azure Lighthouse, GDAP
• Relevant inforcer solutions: inforcer TDR, 365 Manager article is written for MSPs managing Microsoft 365 tenants at scale. It deliberately stays at the level of what to detect and why, rather than providing step-by-step configuration instructions. It maps the six signal layers a Microsoft 365 attack moves through and explains where an identity-only detection strategy leaves gaps; it is not a hardening guide, an incident-response runbook, or a substitute for one.

Introduction: Microsoft 365 acronyms shouldn’t be confusing

Sit through four vendor calls in a week and you will hear four acronyms used to describe what sounds like the same job. One vendor sells ITDR. The next sells XDR that "includes identity". A third sells MDR built on the second vendor's XDR. A fourth sells posture management that promises to stop the incident before any of them are needed.

None of them are lying. There are meaningful differences between these categories. The difficulty is that a category name can answer any of three unrelated questions, and it’s not always clear which one:

• What surface does the tool watch? Endpoints, identity, mail, cloud apps, network traffic, or several at once?
• Who operates it? Your engineers, an outsourced team, or nobody in particular?
• When does it act? Left of boom, by hardening configuration, or right of boom, by detecting behaviour?

EDR and ITDR answer the first question. SOC and MDR answer the second. ISPM and ESPM answer the third. SIEM and XDR sit across all three, which is why they are the hardest two to pin down.

And then there’s TDR: threat detection and response. This refers to any product that helps you spot an attack in progress and act on it.

Why it gets confusing: TDR can fall under numerous different categories

EDR is TDR pointed at the endpoint. ITDR is TDR pointed at identity. NDR is TDR pointed at the network. XDR is TDR pointed at several of those at once, and MDR is TDR with somebody else's analysts attached.

If reading all of that confuses you, don’t worry—you’re not alone.

With that in mind, we created the following guide to help you make sense of these terms. Here are the acronyms for each of the eight scopes vendors sell against each other, explained in simple English and followed by what each one assumes about your customers.

Eight important security categories for Microsoft 365 environments at a glance

The eight categories in detail

SOC (security operations centre)

What it watches: nothing on its own. A SOC is the people, shift patterns, escalation paths and processes that act on what your tools report.

Who operates it: your own analysts, or analysts associated with your TDR tool.

Microsoft-native example: none. Microsoft sells the tooling a SOC uses, not the function.

What it assumes: enough alert volume, and enough revenue attached to it, to justify salaried analysts around the clock.

Where it stops: at the edge of the tooling underneath it. A SOC cannot see a surface that nothing is instrumented to report on.

SIEM (security information and event management)

What it watches: any log source you point at it. It normalises what arrives into a common format, runs your detection rules over the result and retains the history for investigation and compliance.

Who operates it: your engineers, including whoever writes and tunes the rules.

Microsoft-native example: Microsoft Sentinel.

What it assumes: a budget that scales with ingestion volume, and an engineer with time to maintain detection logic. Multi-tenant use adds a second assumption. Cross-tenant Sentinel queries run through Azure Lighthouse, Microsoft's service for managing customer subscriptions from your own tenant, because GDAP (granular delegated admin privileges, the permission model partners use to reach customer tenants) does not cover Sentinel data.

Where it stops: at the boundary of what you chose to ingest, and at the point where nobody has time to write another rule.

EDR (endpoint detection and response)

What it watches: what happens on a device. Process execution, file changes, memory activity, persistence mechanisms, lateral movement attempts. When it sees malicious behaviour it can alert, kill the process or isolate the machine.

Who operates it: your engineers, or your MDR partner if you have one.

Microsoft-native example: Defender for Endpoint, or Defender for Business in the Business Premium bundle.

What it assumes: that the device is managed and enrolled, and that the attack touches it at some point.

Where it stops: at the device. It is the right answer to ransomware and to anything an attacker does with hands on a keyboard. But an attacker who signs into a mailbox from their own laptop never needs to touch a managed endpoint directly.

ITDR (identity threat detection and response)

What it watches: identity systems and identity behaviour. Sign-ins, token use, privilege changes, directory modifications, consent grants. Gartner named the category in March 2022 to cover the gap between preventative identity controls and general security operations.

Who operates it: your engineers, or your MDR partner.

Microsoft-native example: Entra ID Protection and Defender for Identity.

What it assumes: licences your small tenants often do not hold. Risk-based conditional access policies and full risk detail need Entra ID P2, and P1 gets read-only reporting with the detail stripped out. Defender for Identity requires EMS E5, Microsoft 365 E5 or a standalone licence, and its centre of gravity is on-premises Active Directory that many cloud-first customers do not have.

Where it stops: at identity. ITDR tells you the sign-in was not your user. The forwarding rule created twenty minutes later and the SharePoint download that followed both sit outside its remit.

XDR (extended detection and response)

What it watches: several detection surfaces at once, correlated so that a device alert and an identity alert stop being two tickets and become one incident with a timeline.

Who operates it: your engineers, or your MDR partner.

Microsoft-native example: Microsoft Defender XDR, which unifies Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, Entra ID Protection and Defender Vulnerability Management in a single portal.

What it assumes: one organisation looking at its own estate, with licences for every component underneath. Defender multitenant management supports up to 100 target tenants in a multitenant view, a ceiling MSPs above that size hit quickly. Access works through GDAP or Entra B2B, the guest access model that invites an account from one tenant into another, and roles still have to be correct tenant by tenant.

Where it stops: at whatever the products underneath are licensed to produce. XDR inherits every blind spot in the stack below it.

MDR (managed detection and response)

What it watches: whatever the provider's stack covers, which is the question to ask before you sign anything.

Who operates it: the provider. Analysts monitor your customers and respond on your behalf, with response authority set by contract.

Microsoft-native example: Microsoft Defender Experts for XDR. However, this product is aimed at enterprises rather than MSPs.

What it assumes: pricing per endpoint or per user that your customer will carry, and that you are comfortable with somebody else's judgement on containment at 3am.

Where it stops: at the same surface boundaries as every other category. Buying attention solves the staffing problem. The question of which surfaces are covered moves into the provider's technology stack, where it is harder to see.

ISPM (identity security posture management)

What it watches: identity configuration. MFA coverage, legacy authentication still enabled, Conditional Access gaps, dormant privileged accounts, over-permissioned app consents.

Who operates it: your engineers, or a managed posture provider who acts on the findings for you.

Microsoft-native example: Microsoft Secure Score, which scores tenant configuration against Microsoft's recommendations and covers some of this ground.

What it assumes: that somebody acts on the findings in every tenant, and keeps acting as configuration drifts. Doing this manually across multiple tenants is often impractical for MSPs, which is why many rely on multi-tenant management platforms to streamline these tasks. 

Where it stops: baseline coverage doesn’t account for dormant privileged accounts, risky app consents, or drift that keeps happening after the first pass. And posture is not detection. A well-configured tenant can still be breached by a user who approves the wrong prompt.

ESPM (email security posture management)

What it watches: mail platform configuration. Forwarding and inbox rules, mailbox delegate permissions, legacy protocols such as IMAP and POP, sharing and retention settings, and sensitive data sitting in mailboxes where it should not be.

Who operates it: your engineers, or a managed posture provider.

Microsoft-native example: parts of Secure Score and Exchange Online reporting.

What it assumes: the same as ISPM, applied to mail. Somebody has to review the findings and fix them per tenant.

What it is not: a secure email gateway. A gateway filters what arrives. ESPM looks at the configuration weaknesses an attacker exploits once they are already inside.

Where it stops: at the state of the platform. A live attack in progress belongs to a different tool.

Where these categories overlap (and where the gaps normally exist)

Because these categories overlap to some extent by design, MSPs regularly end up paying two vendors to watch the same thing.

The most common example is a SIEM sitting alongside an XDR. Both take security data from several sources and work out which combinations of events add up to an attack, so if you are paying Sentinel to ingest the same Microsoft 365 audit logs that Defender XDR is already correlating, you are paying by the gigabyte for detections you already own. A SIEM earns its cost when you need something Defender cannot do, such as logs from firewalls and on-premises servers, custom detection rules, or retention beyond what Microsoft keeps.

The second most common example is buying an EDR when you already have one. Defender for Endpoint is a component of Defender XDR, and Business Premium includes the Defender for Business version of it, so a third-party agent means two products watching the same process activity and two consoles to reconcile by hand.

One dangerous pattern to check for in your own stack is three products all watching endpoints and identity, and nothing watching mailbox rules, file sharing and app consents, since these are the areas where most Microsoft 365 attacks actually play out.

Learn More: MFA Token Theft: New Risks & Responses

Where these categories fall short for multi-tenant Microsoft 365 MSPs

Every category above was designed for a large organisation with its own IT estate and its own security team. That means products within these categories often do not scale efficiently for MSPs managing dozens or hundreds of small-to-mid-size Microsoft 365 tenants. Here’s why:

Important activity doesn’t always happen on devices and servers

EDR came first, and most of the categories that followed were built outwards from it. That heritage is reflected in how the products are often designed: endpoint telemetry is treated as the main signal, and cloud activity is treated as supporting detail attached to it.

In our conversations with partners, something in the region of a quarter of SMB customers now run essentially the entire business inside Microsoft 365: mail, files, identity, chat, meetings and often the line of business applications that sign in through Entra ID.

For those customers, there is no domain controller and no file server, and sometimes the only device is a laptop that was never enrolled in Intune. Everything worth stealing sits in the tenant: the mailbox, the SharePoint libraries, the Teams history, and the identity that opens all three. A product designed to start at the endpoint and work outwards has very little to look at in that environment.

Most of these products assume your customers are on E5

Microsoft's own detection tools are largely gated behind E5-level licensing. Entra ID Protection's risk-based detections need Entra ID P2 to provide risk scoring as well as just raw data, and Defender for Identity and Defender for Cloud Apps need E5 or standalone add-ons. Microsoft 365 Business Premium includes none of those three.

However, Business Premium is where most SMB customers sit, and it is usually the right recommendation for them. So when a reseller or distributor demonstrates Defender XDR spotting an identity attack and correlating it across surfaces, the demo tenant is licensed well above what your customers buy. Reproducing that demo in your book of business means an E5 upgrade, per user, per tenant, which is a conversation most of your customers will resist.

Third-party products in these categories have the same problem for a different reason: they are priced for enterprise organisations with a considerable security budget. Our rough sense from partner pricing conversations is that only around a fifth of small businesses can carry a full XDR plus SIEM plus MDR stack at list price.

Reading every alert manually presents challenges at scale

Every detection product produces alerts, but an alert is only valuable when you are able to verify what it means. Some alerts are false-positives created by regular business activity, and manually reviewing these to identify the ones that represent genuine threats is a time-consuming process, even for a single tenant.

Now imagine manually reviewing alerts across eighty or a hundred tenants. This creates an unsustainable workload, especially when your tooling does not provide a single-pane view for every tenant environment your MSP manages.

Defender's multitenant view tops out at 100 tenants. Cross-tenant Sentinel queries need Azure Lighthouse configured, and permissions have to be right in each tenant individually.

Furthermore, manually reviewing tenant environments one at a time creates the risk that audit logs will expire before your MSP has a chance to examine them. For example, Microsoft Purview Audit on the Standard tier only keeps 180 days of audit logs.

Mailbox compromise is often discovered long after it starts, sometimes only when a customer's supplier phones about an invoice that was never sent. So if an original malicious sign-in happened eight months ago, the logs that would show you how the attacker got in may have already aged out by that point, and the only answer you would be able to give the customer is a guess.

Learn More: Measuring the cost of alert fatigue for multi-tenant MSPs

Cost-effective threat detection and response for MSPs managing multiple tenants

Every category above was built for a single organisation with its own security team, and Microsoft's own detection components assume E5-level licensing on top of that. Neither assumption holds when you are running dozens of Business Premium tenants.

What multi-tenant MSPs need is a two-pronged approach to security:

• Configuration hardened before an attack happens
• Detection that catches what gets through anyway

inforcer provides two products designed to run together across every tenant you manage—from a single view, and at the licensing level your customers already pay for.

365 Manager is inforcer's multi-tenant management platform for Microsoft 365.

What it’s for: tenant configuration across every Microsoft 365 tenant you manage. This allows you to update policies and remediate drift for every tenant you manage in one single place instead of logging into each environment individually.

Left or right of boom: left of boom. 365 Manager hardens configuration before an attack happens.

inforcer TDR is inforcer's multi-tenant threat detection and response solution.

What it’s for: inforcer TDR uses deep Microsoft telemetry to monitor signals across Entra, Defender, Purview, Teams, SharePoint and the rest of the Microsoft 365 environment, and place them into context to distinguish signs of a genuine threat from false-positive alerts created by routine operations.

Left or right of boom: right of boom. inforcer TDR looks for attacks that are already happening rather than hardening configuration in advance.

inforcer TDR also links each incident it raises back to the configuration change that would have prevented it, and because it works hand-in-glove with 365 Manager, your MSP can push that fix across every tenant that needs it without leaving either dashboard.

Together, the two cover both sides of the job: harden the tenant, and catch anything that still gets through.

Learn More: How MSPs Can Turn Every Breach Into Stronger Long-Term Prevention

Which acronyms actually matter for your MSP’s book of business?

It depends on what your customers actually own.

• If your customers run servers, mixed operating systems and network hardware, you need breadth, because an attack can start anywhere in that estate. That is XDR territory, with a SIEM underneath it if you also have long retention or custom detection requirements.
• If your problem is that nobody is free to look at alerts at 10pm, you are shopping for MDR, and the question to put to every provider is which surfaces their own tooling watches, because that is the coverage you are renting.
• If a regulator or an insurer may ask you to prove what happened two years ago, you need a SIEM, because that retention is the thing a SIEM does that nothing else in the list does. Budget for data ingestion rather than per-user licences.
• If your customers keep everything in Microsoft 365, are spread across many small tenants, and sit on Business Premium, the enterprise categories are quoting you for an estate your customers do not have. Threat detection and response designed to run across multiple Microsoft 365 environments will cover the ground that matters at a price point that works for current Business Premium customers.

Most MSPs need some combination of these. The point of separating them is so you can see which parts of your stack are covering the same ground twice, and which parts of your customers' estates nobody is covering at all.

FAQs

What is the difference between ITDR and XDR?

ITDR watches identity only: sign-ins, tokens, privilege changes and directory activity, to catch attacks that use legitimate credentials. XDR ingests several detection surfaces, typically endpoint, identity, email and cloud apps, and correlates between them so related alerts become one incident. Most XDR platforms already include identity signals, so a standalone ITDR product makes most sense when you lack the licences that feed your XDR's identity components, or when its identity detection is materially better.

What does TDR stand for, and how is it different from EDR or XDR?

TDR is threat detection and response, the umbrella term for any product that identifies an attack in progress and acts on it. The more specific acronyms are TDR with a scope attached: EDR at the endpoint, ITDR at identity, NDR on the network, XDR across several surfaces at once. The differences between products in this family come down to what each one has been pointed at, how well it correlates signals within that scope, and whether it was built for one estate or many.

Do MSPs need a SIEM if they already have Microsoft Defender XDR?

Not usually, unless there is a specific reason. Defender XDR already correlates the Microsoft signals a SIEM would ingest, so pointing both at the same logs means paying ingestion charges for detections you own. A SIEM earns its place when you need non-Microsoft sources, custom detection logic, or retention beyond what Microsoft Purview Audit keeps, which is 180 days on the Standard tier.

Is MDR the same as a SOC?

They answer the same question in different ways. A SOC is the function of watching and responding to security events, whether you build it internally or buy it. MDR is that function delivered as a service, with the provider supplying the analysts and usually the tooling. Neither one is a detection technology. Both depend on detection tools underneath, which is what you should actually be comparing.

What does ISPM cover that Microsoft Secure Score does not?

There is real overlap. Secure Score assesses tenant configuration against Microsoft's recommendations and scores it. Dedicated identity security posture management products go further into continuous assessment and enforcement, covering dormant privileged accounts, risky app consents and drift over time, and managed offerings add somebody to act on the findings.

Which of these do I need if my MSP's customers run Microsoft 365 Business Premium?

Business Premium already covers endpoint and mail filtering, but it leaves detection and response across the tenant uncovered. Microsoft's own detection components sit behind E5-level licensing, and the third-party products in these categories are priced for organisations with a dedicated security budget. inforcer TDR is built for exactly this situation: it runs on Business Premium tenants without requiring an additional licence uplift, covers the whole Microsoft 365 environment rather than one surface, and works across every tenant you manage from one view.

Is inforcer TDR an ITDR product?

No. ITDR is threat detection and response scoped to identity alone. inforcer TDR is scoped to the whole Microsoft 365 tenant, reading identity alongside Defender, Purview, Teams, SharePoint and broader tenant activity, then correlating those signals into a single incident. It is also multi-tenant from the ground up, which is what lets it cover the surfaces where cloud-first SMBs are actually attacked without pricing itself out of that market.

Scope & limitation statement

inforcer TDR detects and responds to threats inside Microsoft 365 tenants. It collects telemetry from Entra, Defender, Purview, Teams and SharePoint alongside broader Microsoft 365 activity, correlates those signals to separate likely attacks from isolated events, presents incidents across all managed tenants in one view, and identifies the configuration weakness that allowed each incident so it can be efficiently remediated through 365 Manager. It is not a source of endpoint telemetry beyond what Microsoft exposes, it does not monitor on-premises Active Directory, servers, network hardware or non-Microsoft SaaS, and it does not replace the Microsoft licences that generate the telemetry it reads.