The Six Layers of TDR for Microsoft 365 (& Why IDTR Alone Isn’t Enough)

Summary

Most MSPs now run some form of Identity Threat Detection and Response (ITDR), and for good reason: identity is the primary attack surface in Microsoft 365. But identity is where an attack begins, not where it ends. A single attack can move through six distinct signal layers, and ITDR only has clear visibility into one of them. Correlation across every layer, rather than more alerts from a single one, is what actually lets an MSP see and stop a breach.

This 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.

Versioned Specifics:

• Original publication date: 1st September 2026
• Relevant inforcer solutions: inforcer TDR
• Relevant Microsoft 365 products: Microsoft Entra ID, Exchange Online, Microsoft Teams, SharePoint Online, OneDrive for Business, and Microsoft Purview

The Six Layers of TDR for Microsoft 365

Ask most MSPs where they focus their Microsoft 365 detection efforts and the answer is identity. This is easy to understand: identity is the number one attack surface in Microsoft 365, so Identity Threat Detection and Response (ITDR) has become a staple of the modern security stack. Watching sign-ins for anomalies is an important responsibility of any MSP to its customers.

But identity-first tooling often leaves other potential security gaps. And some MSPs who believe they are well covered aren’t adequately addressing them.

That’s because identity is where an attack starts, but it is almost never where it ends. A real Microsoft 365 breach unfolds across six distinct layers of activity, and a tool built to watch one of them can, by definition, only tell you part of the story.

This piece maps out all six layers, so you can see exactly where an identity-only view stops, and why correlating signals across every layer is what separates a genuine incident from a pile of unconnected alerts.

Here’s what else your MSP’s threat detection and response solution needs to watch.

Identity is the front door, not the whole house

It helps to picture how an attack actually progresses.

A user is phished and the attacker obtains a valid session. So far, this is an identity event—the part ITDR is built to catch. If the sign-in looks unusual, from an unfamiliar device, an odd location, or with the tell-tale pattern of session token theft, a good ITDR tool raises a flag.

But the attacker is not there to admire the login page. They are there to do something. And what they do next spills straight out of the identity layer and into the rest of the tenant. They might:

• Set up a mail rule to hide their tracks.
• Open the shared drives and start pulling data.
• Register or consent an application so they can keep access even if the password is reset.
• Create a spare account nobody is watching.

Each of these actions leaves a signal, and each signal sits in a different layer of Microsoft 365.

An identity-only tool watches the first of those actions closely and the rest barely at all. That is not a criticism of ITDR; it is simply a description of what it is (and isn’t) designed to do.

The problem arises when ITDR is treated as the whole of an MSP's detection strategy, because then other important parts of the attack play out in the dark. And that means the MSP doesn’t always understand the extent of the damage or what steps are required to fix it.

What ITDR alone cannot identify

ITDR is very good at what it is designed to do: surface sign-in anomalies. Impossible travel, unfamiliar fingerprints, risky IP ranges, authentication that does not fit the user's history.

What it typically cannot see is everything downstream of the sign-in:

• Data exfiltration. Mass downloads, unusual sharing, bulk deletion, files being moved or manipulated. This is the actual impact of a breach, and it lives in the file and data layer, not the identity layer.
• Malicious inbox rules. Rules that auto-forward, delete, or hide messages are a classic post-compromise move, and they are invisible to a tool that stops at the sign-in.
• OAuth and consent abuse. A malicious application granted access to a mailbox or drive is a durable foothold that never triggers another sign-in prompt. Ironically, this is an identity problem, but one most ITDR tools miss.
• Purview and audit signals. The DLP events, sensitivity-label activity, and audit-log detail that explain what actually happened rarely feature in an identity feed at all.

An MSP might even receive alerts from these other activities through third party tools—but without a way to correlate them, these signals can be difficult to differentiate from the noise produced during regular business activities. And this creates a risk that damage from a breach will go undetected.

To close that gap, MSPs need visibility across every layer of the Microsoft environments they manage. They also need a way to put alerts from one or more layers into context so that they can form a complete picture of any breach that occurs.

The six layers of Microsoft 365 threat detection

Here are the six layers a Microsoft 365 attack moves through, what each one tells you, and why it matters.

1. Identity

This is the layer ITDR knows best, and the natural place to start, because it is where most attacks begin. This has to go beyond producing alerts based on unexpected sign-ins and consider their context as well. Examples of sign-in activity that could signal genuinely suspicious activity include:

• Impossible travel (where two sign-ins occur further apart than anyone could physically travel in the time between them).
• Unfamiliar devices, hosting-provider or VPN IP ranges, and authentication patterns that do not match the user's normal behaviour.

Identity is the strongest early-warning layer you have. But an early warning is only useful if something is watching the layers the attacker moves into next.

2. Email and collaboration

Once inside, one of the first things an attacker usually does is manipulate communication. That means malicious inbox rules to hide replies and cover their tracks, business email compromise to impersonate the user, and malicious links sent onward to the victim's own contacts.

This layer is also where the human element is most exposed. Most people have learned to be reasonably wary of emails containing strange links, but a malicious link often attracts far less scrutiny if it arrives over Teams. Fewer people hesitate before clicking a link like this, because they simply do not expect an attack to arrive that way.

This is the limit of a "left of boom" approach. Configuring a tenant well genuinely reduces the number of breaches that happen. But you cannot configure against the human element. No policy stops someone trusting a message from a contact they know, which is exactly why this layer has to be actively monitored and not just hardened.

3. Files and data

If identity is where an attack starts, the file layer is where you see its impact. This is the point at which the attacker’s intent usually becomes visible—but only when you’re looking for the signs.

File activity can tell you whether someone has tried to exfiltrate, delete, or manipulate data. Consider a typical chain:

• A user clicks a link
• The attacker rides the resulting session
• They create an admin account
• They use it to download a shared drive and then delete large volumes of data

The identity layer showed you the compromised sign-in, but the file layer shows you what it was for. Without visibility here, you can know an account was breached and still have no idea whether anything was actually taken.

Learn More: MFA Token Theft: New Risks & Responses

4. App registrations and consent grants

This is the layer that most cleanly exposes why "identity-only" security solutions tend to be insufficient. App registrations and malicious consent grants are, technically, part of identity, because in Microsoft 365 applications are identities. Service principals authenticate, hold permissions, and act inside the tenant just as users do.

And yet consent abuse is one of the most commonly missed attack paths. An attacker persuades a user to approve a malicious OAuth application, or registers one themselves, and that application is granted standing access to mail, files, or directory data.

From then on, the attacker no longer needs the password, and no longer needs to sign in, so no further sign-in alert ever fires. It is a foothold that hides precisely in the blind spot between "identity" as ITDR tools usually implement it and identity as it actually works in Microsoft 365. Treating app and consent activity as a primary signal is what closes that gap.

5. Persistence

Persistence is the attacker's insurance policy. Having breached an environment, they want to guarantee they can get back in even after the original hole is closed.

That takes two main forms:

1. The first is a permanent back door: a new account, often with elevated rights, that the attacker controls and that nobody is monitoring, so a password reset on the compromised user changes nothing.
2. The second is tampering with configuration itself, turning off security features, weakening policies, or altering settings to make future access easier and detection harder.

That second form is also the clearest argument for keeping configurations backed up. If an attacker quietly disables a control, you need to be able to see that it changed and restore it to a known-good state. Detecting configuration drift and being able to roll it back is a core part of both containing an incident and proving what was altered.

6. Purview and the audit trail

The final layer is the one that ties the other five together. Purview audit logs, sensitivity and data labels, and the wider audit trail hold the detailed record of what was accessed, changed, shared, or removed.

On its own, this is forensic data. In the context of an incident, it is the evidence layer. It supplies the context behind an attack pattern and lets you report on exactly what happened, which files were touched, which labels were involved, which actions the attacker took and in what order. It turns "we think this account was compromised" into a precise account of the incident from first sign-in to final action.

Learn how to manage Purview at scale across multiple tenants.

How inforcer TDR turns six layers into one incident

Laid out like this, the problem with an identity-only strategy is obvious. Each layer holds a piece of the story, and no single layer holds enough to act on with confidence.

A suspicious sign-in on its own is ambiguous because users travel and switch devices all the time. A single mail rule, consent grant, or bulk download might be completely innocuous when considered in isolation.

But if those things are happening within a specific interval or forming a suspicious pattern, it could very well signal that an attack is taking place. The signal is not in any one layer. It is in the combination.

MSPs need tools that can interpret these signals in context to identify likely breaches in progress. This is why inforcer TDR continuously monitors all six layers across every managed tenant and correlates the signals between them using deep Microsoft telemetry. A sign-in anomaly, followed by a new inbox rule, followed by a consent grant to an unfamiliar application, followed by a spike in file downloads, stops being four separate low-confidence alerts and becomes one high-confidence incident with a clear narrative.

That correlation does two things for an MSP:

1. It cuts the noise, because ordinary user behaviour that happens to trip a single signal no longer generates a false alarm when the surrounding layers are quiet.
2. It shrinks the detection window, because the pattern that reveals a real attack emerges far faster from correlated telemetry than it ever could from an analyst reviewing sign-in logs by hand across dozens of tenants.

It also does not stop at detection. When inforcer TDR flags an incident, it identifies the gap in the tenant that allowed the attack to progress. From there, an MSP can use inforcer’s 365 Manager to push the required policy or configuration updates that close the gap, hardening the environment against similar incidents in the future. In this way, every resolved incident makes the tenant more secure and resilient.

Related: Scalable Entra ID policy management for MSPs serving multiple tenants

Offer your customers more than identity-only security

Identity deserves its place at the centre of the conversation. It is the primary attack surface in Microsoft 365, and ITDR is a genuinely valuable tool. The point is not that identity monitoring is wrong; it’s that it is incomplete. An attack that begins at the front door does not stay there, and a detection strategy that does will always be reading one page of a six-page story.

The practical answer is coverage across all six layers, with correlation tying them together, so that scattered partial signals resolve into a single, clear incident an MSP can actually act on.

Pairing 365 Manager for configuration and hardening with inforcer TDR for cross-layer detection gives you exactly that: the front door watched, and the other five rooms of the house watched with it.

FAQs

What is ITDR?

Identity Threat Detection and Response (ITDR) is a category of security tooling focused on detecting and responding to attacks against identities, primarily by monitoring sign-in and authentication activity for anomalies such as impossible travel, unfamiliar devices, and risky IP ranges. It is valuable because identity is the number one attack surface in Microsoft 365, but it focuses on the identity layer specifically rather than the full breadth of an attack.

Why isn't ITDR enough on its own?

Because a Microsoft 365 attack does not stay in the identity layer. After the initial compromise, an attacker manipulates email, exfiltrates or deletes files, grants access to malicious applications, and establishes persistence, and most of this activity is invisible to a tool that watches sign-ins alone. ITDR shows you the compromised login but not what the attacker did with it, so relying on it exclusively leaves the majority of the attack undetected.

What are the six layers of Microsoft 365 threat detection?

The six layers are identity (sign-in and authentication activity), email and collaboration (inbox rules, business email compromise, malicious links including over Teams), files and data (exfiltration, deletion, and manipulation), app registrations and consent grants (OAuth and service-principal abuse), persistence (back-door accounts and configuration tampering), and Purview and the audit trail (the forensic record of what actually happened). A complete incident usually leaves signals across several of these at once.

Aren't app registrations part of identity?

Yes, and that is exactly why they are so easily missed. In Microsoft 365, applications are identities: service principals authenticate and hold permissions just as users do. A malicious consent grant gives an application standing access to mail or files without any further sign-in, so it never triggers another identity alert. It is an identity attack that hides in the space between how ITDR tools usually implement identity monitoring and how identity actually works in the platform.

Why does configuration backup matter for threat detection?

Because one common persistence tactic is to tamper with configuration, turning off security features or weakening policies to make future access easier and detection harder. If your configurations are backed up, you can detect when a control has been changed and restore it to a known-good state. Without a baseline to compare against, a quietly disabled control can go unnoticed indefinitely.

How does inforcer TDR detect attacks that ITDR misses?

inforcer TDR monitors all six signal layers across every managed tenant and correlates the signals between them, rather than watching identity in isolation. A sign-in anomaly followed by a new inbox rule, a consent grant, and a spike in file activity is treated as one connected incident rather than four separate low-confidence alerts. This reduces false positives, shortens the detection window, and identifies the specific gap that allowed the attack, so every incident can be used to harden the tenant against the next.