Why We Went Right of Boom

Summary

In inforcer's first Ask an Expert interview, Graham Morrison, Microsoft 365 Team Lead, explains why inforcer moved beyond prevention into threat detection and response. He covers why prevention alone left MSPs exposed, why enterprise-built, identity-only and acquired detection tools don't fit the way MSPs work, and how inforcer TDR builds on inforcer's multi-tenant management expertise to cut alert noise, close the gap between prevention and detection, and help MSPs prove their value to customers.

Versioned Specifics:

• Original publication date: 24th September 2026
• Key problems addressed: gaps left open by prevention alone; detection tools built for enterprises rather than MSPs; identity-only detection that misses the full attack timeline; alert noise; the divide between prevention and detection tools
• Relevant inforcer solutions: inforcer TDR for detection, containment and customer reporting; 365 Manager for pushing fixes and configuration updates to every managed tenant

Why We Went Right of Boom: A Conversation with inforcer’s Graham Morrison

In the world of managed security, the moment a breach occurs is commonly referred to as the “boom”. Everything before it, from hardening configurations to setting security policies, is commonly called “left of boom”. Everything that comes afterwards, from spotting the attack to containing it and cleaning up, is known as a “right of boom” solution.

For most of its history, inforcer has worked left of boom, helping MSPs configure and secure their customers' Microsoft 365 tenants at scale. In 2026, it launched inforcer TDR, a threat detection and response product built specifically for MSPs.

In this first Ask an Expert conversation, interviewer Graham K. Miles sat down with Microsoft 365 Team Lead at inforcer Graham Morrison to find out why. They talked about what prevention couldn't do on its own, why the detection tools already on the market weren't built for MSPs, and what the team did differently when building TDR from scratch.

The move to a right of boom solution: why and why now?

inforcer spent years offering a left of boom solution for MSPs. What does that work actually involve?

Everything we built before TDR was about helping MSPs properly configure tenant environments before threats occurred. Our flagship multi-tenant management platform, which is now known as 365 Manager, gives MSPs a single-pane view of the Microsoft 365 environments for every tenant they manage. This makes it extremely efficient to check tenants against recognized security frameworks or your own standardized security baselines, then push policy and configuration updates across an entire tenant base without manually logging in to each individual environment.

That's the left of boom job—to close gaps before an attacker can find them. Our service team has spent years working alongside MSPs on exactly that, so we have a very detailed picture of how MSPs actually run tenants for their business customers.

So what was missing? Why move right of boom at all?

Well, MSPs need more than prevention alone, because some security gaps are always going to exist. You can't lock a Microsoft 365 tenant down completely and still have it work for the business.

An MSP’s customers are always going to need certain exceptions—like for a director who travels constantly and can't be blocked by location rules, or a finance team that needs to share files with outside accountants. Each MSP has to make judgment calls on which doors to leave open, because the alternative is a tenant environment their customer can’t use.

So yes, left of boom tooling is incredibly important, but gaps are still going to exist and that means incidents can still take place. When that happens, you also need a right of boom solution to deal with them—and you need one that lets you address the issue quickly so you can give your customers the best possible protection. That’s what threat detection and response products are for.

Where existing detection tools fall short for MSPs

Don't MSPs have other threat detection and response options?

Yes, but most of those options aren't actually designed for MSPs to use.

What does that mean? Are you saying no one built a threat detection and response product specifically for MSPs before now?

Not really, and it’s actually pretty easy to explain why: there's more money in enterprise products, or at least that's the perception. A single enterprise sale can be worth far more each month than an MSP contract, so the MSP market has been left largely untapped. But it's still a huge market.

Since our product is brand new, we've built it from the ground up to match modern requirements. Other platforms that have been around for 15 years have technical debt: legacy backends that stop them from doing better AI detection, among other things. It would take months or years for them to update those, and they don't, because people are still paying for them.

That's what lots of other companies have done. They buy something else and try to bring it into their ecosystem, whereas we built ours from the ground up.

“It would take months or years for them to update those, and they don't, because people are still paying for them.”

So what is the risk when an MSP tries to use a detection tool built for enterprise?

An enterprise tool is meant to protect one large organization, and it’s usually an organization that can afford its own dedicated security team or SOC. The way an MSP works is essentially the opposite of that. If you run an MSP, you’re responsible for looking after dozens or hundreds of tenants, and you probably have a relatively small team of engineers.

Most enterprise tools aren't built to work that way. They're designed to help an in-house security team investigate, and a lot of them also stop at identity, which doesn’t always tell the whole story of a breach or where it came from.

Why isn’t identity enough? Can you explain why you went beyond that?

Okay, this is actually really important because most security products are built around identity—primarily Entra. But if you only concentrate on that, you don't get a proper attack timeline because threats can come in from all kinds of other places, like email for example.

What inforcer TDR does is different: it collects data from every Microsoft 365 product the customer uses across their entire tenant environment and correlates those signals to compile a full picture of where each attack came from, what gaps it exploited, and what it affected. That means an MSP using our solution can follow an attack from the phishing email that started it, through the sign-in, to exactly what the attacker did once they were inside. An MSP needs to be able to see that entire timeline to understand what happened and make sure it can't happen again, but they also need to see it so that they can show the customer what they caught and how they’re going to prevent it from happening again in the future.

“If you only concentrate on [identity], you don't get a proper attack timeline.”

Learn More: The six layers of TDR for Microsoft 365, and why ITDR alone isn't enough

Comparing threat detection and response tools at a glance

How inforcer TDR fills the gap

inforcer already knew Microsoft 365 inside out from the prevention side. How did that shape the way you built detection?

Well, it basically meant we didn't start from a blank page. We've spent years inside the Microsoft 365 stack with MSPs, so we already knew where the useful data lives, how MSPs actually set up their customers' tenants, and which signals tend to come from real threats in progress instead of producing false positive alerts from regular business activities. All of that information made it easier for us to create a threat detection solution designed for MSPs and the challenges they face.

At launch, inforcer's CPO Matthé Smit said TDR was “surfacing threats in customer estates that partners did not know were there.” Can you tell me more about that?

Sure. This is the kind of thing we often refer to as an “invisible breach”. It means a threat actor has accessed a tenant environment, but there’s no obvious sign that a user would recognize—at least, not yet. That means there's no ransomware note, no locked files, et cetera. Instead, an attacker might sign in with a stolen session token, set up an inbox rule so replies go somewhere the user won't see them, and start reading email or sending invoices from a trusted account. Every individual step in that chain looks like normal business activity, so even if they do produce alerts, those alerts are hard to verify as signs of a genuine threat. The MSP might only find out weeks later, when a massive breach has already occurred.

inforcer TDR’s ability to correlate alert signals from different Microsoft 365 products helps MSPs catch exactly that kind of attack. Since it's looking across email, identity and file activity together, it can see that a suspicious sign-in, a new inbox rule and an unusual burst of outbound mail all happening in the same sequence probably spell trouble for the tenant. That's how it surfaces threats nobody knew were there.

Learn More: Anatomy of an invisible Microsoft 365 breach

You mentioned “false positive alerts” earlier. What does that mean?

A false positive is what happens when an alert is produced by regular business activities. That happens because, as I said before, pretty much every tenant environment needs to have some gaps intentionally left in to keep it usable. So when employees at a business use those gaps to perform certain tasks, an alert goes out—even though there’s no attack happening.

That creates a lot of noise, which can be overwhelming for the engineer responsible for reviewing all those signals. We call this “alert fatigue”, and it can actually be a big problem because it potentially distracts an MSP from being able to identify the signals that represent real attacks.

So noise was one of the first things we designed against. inforcer TDR doesn’t just send alerts based on specific activities; it puts those activities in context to determine whether they represent a real threat or not. For example, an odd sign-in with normal email, mailbox and file activity around it is very different from an odd sign-in followed by a new inbox rule and a spike in outbound mail. What that means is fewer overall alerts, but the ones that do come through are the ones that are really worth an engineer's time.

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

Do threat prevention and detection capabilities usually live in separate tools?

Yes, but what we’ve done is actually a bit different. In most MSPs, prevention and detection are two different purchases, often from two different vendors, with two different consoles. In these cases, the detection tool might find something and someone might deal with it, but the lesson might never make it back into how the tenants are configured. The same gap stays open unless someone goes and closes it for every tenant where it exists, which means the same attack can work again somewhere else.

With inforcer TDR, once a breach is identified, the MSP can see the fix that would have prevented it and push it through 365 Manager. They can also push the same fix to every other tenant that needs it, and they can do it from the same place—without logging into each tenant environment. That lets them leave their whole tenant base better protected than it was before, every time an incident occurs.

Learn More: How MSPs can turn every breach into stronger long-term prevention

So at the end of the day, why should an MSP choose inforcer TDR?

Because we're 100% MSP focused. Other tools on the market don't cater to the needs of MSPs, who need to continuously sell their services and prove value to their customers. The typical end user isn’t necessarily an expert about security, but they understand that they need it. For an MSP to keep renewing its managed services contract, it needs to show how it’s meeting that need.

inforcer has always been aware of that. Our service team has always been very customer focused, helping MSPs prove their value from a left of boom perspective, and inforcer TDR does the same. It has built-in reporting capabilities designed to help MSPs highlight their value. They can show your customers where threats came in, how you patched them, and how this helped the business. It's amazing for sales conversations.

It's less noisy as well, and more effective from a threat detection and response perspective because of our deep Microsoft telemetry.

“The typical end user isn’t necessarily an expert about security, but they understand that they need it. For an MSP to keep renewing its managed services contract, it needs to show how it’s meeting that need.”

And what would you say to an MSP that's still on the fence?

Look at what you're already doing left of boom. If you're configuring your customers' tenants properly, you've done the hard part, and you've also accepted a few gaps to keep those tenants usable. inforcer TDR is all you need to watch those gaps and tighten them if they’re creating too much exposure.

And the response to our product launch tells us that lots of MSPs were waiting for this. More than 700 MSPs used TDR during early access, 500,000 users were onboarded in its first four weeks, and by the time we reached general availability in September, it had processed 20 billion Microsoft 365 logs, with high-risk threats contained in under 60 seconds on average. And every time it stops something, you've got a report to put in front of your customer showing exactly what you did for them.

FAQs