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

9 min read
Aug 28, 2026, 9:00:01 AM

Summary

Detection and prevention usually live in separate tools, so catching an attack does not always produce a permanent fix. For multi-tenant MSPs, that means one misconfiguration can stay open and exploitable across the estate. inforcer TDR closes the loop by mapping each detected attack to the policy that would have stopped it, then allowing MSPs to deploy the required changes across every tenant in their estate using 365 Manager. This turns each incident into lasting prevention.

Time to Read

  • ~8 min

What You’ll Learn

  • Why detection and prevention usually live in separate tools
  • Why catching an attack does not always produce a permanent fix
  • How the same misconfiguration can impact other tenants you manage
  • Which tooling can map a detected attack to the policy that would have stopped it
  • How closing this loop turns invisible security work into provable value

Next Steps

  • Review how long it currently takes you to roll a single policy change across every tenant
  • Identify which misconfigurations recur most often across your managed tenants
  • Book a demo of inforcer TDR and learn how to efficiently close these gaps

Scope and Limitations

This article is written for MSPs managing Microsoft 365 tenants at scale. It focuses on the principle of closing the loop between threat detection and prevention, why that loop matters both operationally and commercially, and how inforcer TDR helps MSPs implement it for multiple tenants. It is not a step-by-step configuration guide or an incident-response runbook.

Versioned Specifics:

  • Original publication date: 28th August 2026
  • Relevant inforcer solutions: inforcer TDR, 365 Manager
  • Relevant Microsoft 365 products: Microsoft Entra ID, Exchange Online, SharePoint Online, OneDrive for Business, and Microsoft Purview

How every breach can make your defences stronger

MSPs spend an enormous amount of effort preventing breaches from occurring in the first place.

Security baselines, conditional access, policy enforcement, and drift remediation are all designed to shrink the number of ways an attacker can get in. This is essential work, and MSPs provide a great deal of value to their customers by doing it.

But here are two inconvenient truths about incident prevention:

  1. It is never perfect. A usable environment needs a degree of openness to function, and every allowance is a potential gap.
  2. When it works properly, nobody notices. A tenant that is never breached looks exactly like a tenant that was never going to be breached in the first place.

That’s why threat detection exists: to catch what prevention misses, and to show customers that your MSP has the capability to do so.

The trouble is that, in most security stacks, detection and prevention are handled by different tools that never speak to each other. In these cases, when an attack is caught, it typically gets contained and closed. However, the underlying weakness that allowed it to happen is often left exactly where it was, ready to be exploited again.

This piece is about how to close that gap. Below, you’ll learn how to make every attack you detect feed directly back into stronger incident prevention for your MSP, even when you manage dozens or hundreds of tenant environments.

Catching an attack is not the same as preventing recurrence

Here’s what usually happens when a typical threat detection tool does its job:

  • An alert fires.
  • An analyst investigates, confirms the attack is real, and responds (by revoking sessions, disabling the compromised account, removing a malicious inbox rule or a rogue app grant, etc.)
  • The immediate threat is neutralised, the incident is documented, and the ticket is closed.

On paper, this is a success.

But what has actually changed in the environment? The attacker is out, but the door they came through is still unlocked. If the incident began because Conditional Access was not enforced, Conditional Access is still not enforced. If a user was able to consent to a malicious application, users can still consent to malicious applications.

The specific attack was stopped. But the conditions that made it possible still exist.

This is the fundamental limitation of treating detection and prevention as separate disciplines.

“Left of Boom” vs. “Right of Boom”

When detection and prevention are separated, industry professionals refer to them in the following ways:

  • Prevention tools are called “left of boom”. They are built to determine whether an environment is configured correctly and adequately secure. However, breaches can still occur in the gaps that keep a tenant environment functional for its intended users.
  • Detection tools are called “right of boom”. These are built to help MSPs notice an attack or breach after it has occurred so that they can take appropriate steps to respond. However, most of these tools do not provide detailed information on how to close the gaps that caused an incident in the first place.

That leaves MSPs with incomplete information, because what they need is tooling that tells them: “This attack succeeded because of this specific gap - and here is how to close it.”

MSPs without this capability can end up responding to the same class of attack again and again, closing incident after incident without ever removing the conditions that produce them.

Most right of boom tools are too limited for MSPs managing multiple tenants

There is no shortage of existing threat detection tools for MSPs. But they are not all created equal. Most fall into one of the following categories, both of which stop short of providing meaningful information on how to prevent the same threat from recurring.

Alert-only tools

These tell you something happened and leave the rest to you. They are effective at surfacing activity, but they hand the MSP a signal and no more. They also provide no context for these signals.

Since many regular business activities produce signals that can resemble part of an attack when taken out of context, this can result in a flood of alerts that fatigue help desks or engineers and run the risk of obscuring genuine threats.

Even in cases where these tools help to catch real threats, working out which policy changes would have prevented the incident and then actually deploying them is left entirely to the analyst. In practice, under time pressure, that follow-through is often the first thing to be dropped once the immediate fire is out, and the gaps tend to remain open.

User- or incident-level remediation tools

These go a step further and help you resolve the specific incident (reset the account, kill the session, quarantine the message, etc.). This is genuinely useful, but it is remediation, not prevention. It restores the affected user to a safe state without changing the configuration that let the attack through, which means the environment is no more resilient than it was beforehand.

The risks of these limitations scale alongside your tenant base

The more tenants your MSP manages, the more these limitations can cost you. A misconfiguration that allowed an attack in one tenant almost certainly exists in many others. Fixing it one incident at a time, in one tenant at a time, is a slow and painstaking process that leaves your customers vulnerable for days or weeks, while doing nothing to prevent the same incidents from happening again.

For an MSP, the question is not really "how do we close this incident?" It is "how do we make sure this class of attack cannot succeed anywhere in our estate again?"

The majority of threat detection and response tools are simply not designed to answer that question. The exceptions are the threat detection and response tools designed to work alongside the prevention-level tools you already use to manage your tenants.

Related: The Six Layers of TDR for Microsoft 365 (& Why ITDR Alone Isn't Enough)

Closing the loop: from detected attack to updated policy

inforcer’s multi-tenant management platform (now known as 365 Manager) is designed to help MSPs efficiently manage multiple Microsoft 365 tenant environments. For years, Microsoft MSPs have used it to:

  • Monitor every managed tenant at once
  • Assess all tenants against a wide variety of recognized security standards
  • Push policy updates and remediate configuration drift as needed

All of this can be done within a single dashboard instead of requiring individual logins. This effectively solves the scaling problem for MSPs by allowing them to manage far more tenants than they would be able to handle manually.

Now, our team has added a threat detection and response solution that works hand-in-glove with 365 Manager to identify attacks or breaches across an MSPs tenant base. inforcer TDR uses deep Microsoft telemetry to correlate potential threat signals from each layer of Microsoft 365 and put them into context, surfacing genuine signs of an incident and screening out ordinary noise.

But when inforcer TDR flags an incident, it does not simply hand you an alert and stop. It also identifies the specific gap in the tenant that allowed the attack to progress, and enables you to fix it for every affected tenant in your estate via 365 Manager in a matter of moments.

That is the piece most tools never supply: a direct line from what happened to the policy that would have stopped it, and a way to quickly change that policy everywhere that matters.

Here is what that looks like in practice:

  • inforcer TDR detects a stolen session token being replayed, or a user consenting to a malicious application, in one customer's tenant.
  • It maps the incident to the control that would have blocked it: for example, a Conditional Access policy restricting token use to managed devices, or a policy preventing unrestricted user consent.
  • Rather than fixing only the tenant that was attacked, the MSP uses 365 Manager to deploy that control as a baseline across the entire managed estate.
  • The gap is now closed everywhere. An attack that succeeded in one environment has just hardened every other environment against the same technique.

Learn More: Scalable Entra ID policy management for MSPs serving multiple tenants

Making invisible security visible

Even if you could configure a customer's environment flawlessly (and you can't, because an environment has to stay open enough to be usable) you would struggle to demonstrate the value of having done so. Customers don’t notice the incidents you prevent, which can make the value of a strategy that focuses on prevention only difficult to justify.

But catching or responding to an attack is an opportunity to prove your value. If you can show the gap that caused it, the damage you prevented by fixing it, and the security updates you made that will help prevent it from recurring, you can demonstrate exactly why the customer needs you.

This is a far stronger position than an abstract promise of protection, because it is backed by evidence the customer can see. It also makes the harder conversations easier, whether that is justifying a security retainer or making the case for the Microsoft licensing your customers need to support the controls you want to deploy.

Every incident should leave you stronger than before

You cannot configure your way to a perfectly secure environment, and even if you could, no one would see the work. Attacks will get through, because a usable tenant is never a sealed one. The question is what happens next.

If detection and prevention stay in separate tools, the answer is: you close the incident and wait for it to happen again. It leaves the customer vulnerable and keeps your MSP on a treadmill.

When detection and prevention are merged into a single loop, the answer is very different. Each attack helps you improve security and defend your value for every customer you have.

Pairing inforcer TDR with 365 Manager is how you close that loop: detect the attack, trace it to the policy that would have stopped it, and deploy that hardening everywhere in mere moments.

FAQs

Why don't detection tools prevent future attacks?

Detection and prevention are usually handled by separate tools built to answer different questions. Detection tools identify that an attack is happening; prevention tools govern how the environment is configured. Neither is designed to carry an insight across to the other, so a detection tool can tell you an attack succeeded without ever changing the configuration that allowed it. The specific attack is stopped, but the condition that made it possible remains.

What's the difference between remediating an incident and preventing recurrence?

Remediation resolves the immediate incident, like resetting the compromised account, revoking sessions, or removing a malicious rule or app grant. These tasks can restore the affected environment to a safe state, but they do not prevent the possibility of recurrence. That requires changing the underlying configuration so the same class of attack cannot succeed again. Most tools do the first and stop there, which leaves the environment no more resilient than it was before the attack.

Why is a misconfiguration in one tenant a problem for others?

MSPs typically manage many tenants built from shared baselines and templates, so they tend to share the same gaps. A misconfiguration that allowed an attack in one tenant almost certainly exists in others. Fixing it only where the attack occurred leaves the same weakness open everywhere else, which is why remediating one incident at a time does not scale for an MSP.

How does inforcer TDR turn a detected attack into a permanent fix?

When inforcer TDR flags an incident, it identifies the specific gap that allowed the attack to progress and maps it to the policy or configuration that would have stopped it. Because it works alongside 365 Manager, the MSP can then deploy that control across every managed tenant from one place, rather than fixing a single environment by hand. The attack is turned directly into portfolio-wide hardening.

How does closing the detection-to-prevention loop help MSPs prove their value?

Prevention is invisible when it works, which makes it hard to demonstrate. The loop turns each caught attack into concrete evidence: a real incident, the exact gap that caused it, and the control now deployed across the estate to prevent it recurring. This gives the MSP something tangible to show customers, strengthens security conversations, and makes the case for necessary licensing far more compelling than an abstract promise of protection.

Do I need both inforcer TDR and 365 Manager?

They are designed to work together. inforcer TDR provides the detection and maps each incident to the control that would have prevented it; 365 Manager deploys that policy or configuration across every managed tenant. Detection identifies the gap and prevention closes it, so pairing the two is what completes the loop and lets every incident harden your whole estate.

 

 

 

Live demo with Co-founder,
Will Connor

Want to see inforcer in action? Join a live platform demo with inforcer Co-founder and Chief Community Officer, Will Connor to explore how inforcer could benefit you.

Meet Inforcer
true