RMM 2.0: Why MSPs Need XMM to Master Microsoft 365, Cloud & Identity

I did not wake up one morning and decide the world needed another acronym.

XMM was not born from a branding exercise. It came out of a very real sense that the tools we had, the mental models we had, and even the way we defined “managed services” were no longer keeping up with what our customers were actually running and what attackers were actually targeting.

In other words, XMM had to be created because the ground under MSPs had quietly shifted.

The early days: when RMM felt like magic

When I first started working with MSPs, the job was simpler, at least on the surface.

Most of the action lived on physical boxes and local networks. You had:

• A server or three in a closet

• A fleet of Windows desktops and laptops

• A firewall on the edge

• Maybe a tape or image backup solution

RMMs fit that world perfectly. Install an agent, monitor CPU and disk, push patches, script some fixes, remote into machines, and plug into a PSA so tickets did not get lost. It was a clean story: the endpoint was the center of gravity, and if you managed the endpoint well, you were doing your job.

We had problems, of course. Patch failures, bad scripting, noisy alerts. But they were familiar problems, and RMM gave us centralization, visibility, and a sense of control in a world where we were used to driving out to every site.

For a while, that was enough.

Cracks in the model: when “more tools” stopped being the answer

Then the environment started changing faster than our tools.

Servers moved to the data center and then to the cloud. Line-of-business apps that once lived on a file share started showing up as web portals and SaaS products. Email left the Exchange box in the closet and reappeared inside Exchange Online.

We responded the way this industry always responds at first: by adding more tools.

• A portal for Microsoft 365

• A portal for security

• A portal for backup

• A portal for remote access

• A portal for documentation

• A portal for everything else

The RMM agent was still there, and it still mattered, but it was no longer the single pane of glass. It was one tile in a mosaic of consoles, reports, and browser tabs.

I started to see something that looked a lot like what security teams experienced with SIEM, EDR, and then XDR. In the security world, XDR emerged when teams realized that isolated tools, each with their own view of the world, created blind spots and alert fatigue. They needed a way to unify signals across endpoints, networks, cloud, and identity into one story they could act on.

MSPs were living a similar version of that story, but on the management side.

Only instead of “too many security tools,” it was:

• Too many consoles

• Too many disconnected inventories

• Too many overlapping automations

• Too many spreadsheets trying to stitch it all together

There was no system of record for “the truth” about a customer’s environment anymore. The RMM had one truth, Microsoft 365 had another, backup a third, identity a fourth.

That is when things really started to break.

The Microsoft 365 era: identity became the new operating system

The real pivot point, for me, was Microsoft 365.

When email, collaboration, and identity consolidated into Microsoft 365, the center of gravity moved again. Exchange, SharePoint, Teams, and Entra ID (Azure AD at the time) became the backbone of how small and midsize businesses actually did work.

Later, Intune and Defender for Business raised the stakes. They took what used to be “security add-ons” and turned them into native capabilities right where users and devices already lived.

Suddenly:

• The most important security control was not an agent, it was an identity

• The most important “policy” was not a GPO, it was an Intune profile or a conditional access rule

• The most damaging outage was not a dead file server, it was a misconfigured tenant or compromised admin account

Traditional RMMs were never designed for that world. They were built to manage devices, not tenants, identities, or cloud workloads.

This is very similar to how XDR expanded on EDR. EDR focused on endpoints and did that job well, but attackers were going after email, networks, cloud workloads, and identities. XDR had to extend across these domains, correlate them, and respond as one system instead of a pile of tools.

I started to feel that same pressure on the MSP side.

RMM was still necessary, but it was no longer sufficient.

The questions RMM could not answer

There was one conversation that really crystallized things for me.

I was talking with a partner who had dozens of Microsoft 365 tenants under management. He asked a question that seems simple until you try to answer it with the usual toolset:

“Can you show me, across all my customers, which users are actually protected, which devices are compliant, and which data is being backed up? One view, so I can see where I am exposed.”

We could get part of the answer from RMM. Another part from Microsoft portals. Another part from the backup system. Maybe some of it was in a spreadsheet or a documentation tool.

But there was no place where all of that came together in a way that was:

• Multi-tenant

• Identity-aware

• Cloud-native

• Actionable

That was the moment I realized we had quietly stepped beyond what “RMM” was ever meant to do.

MSPs were being asked to own outcomes like:

• “Ensure every customer tenant has a baseline security posture”

• “Prove we are backing up the right data for the right users”

• “Standardize configuration across dozens or hundreds of tenants”

• “Respond quickly to issues across identity, devices, and data, not just endpoints”

RMM could help, but it was playing on the wrong field. The real game was happening inside Microsoft 365, Intune, Entra, Defender, and the data layer.

We needed something that treated those platforms as first-class citizens, not bolt-ons.

Learning from XDR: from more data to better decisions

When I looked at how XDR evolved, there were some patterns worth stealing.

In security, XDR did not win by simply collecting more logs. It won by:

• Normalizing data across domains

• Correlating that data into stories, not single events

• Prioritizing what mattered, instead of drowning analysts in noise

• Making response workflows simpler and more consistent across tools quzara.com+1

We needed an equivalent shift in how MSPs manage Microsoft-centric environments.

In our world, that meant:

• Normalizing tenants, users, devices, and policies into a single model

• Correlating posture, backup, and configuration into one view of “risk” or “health”

• Prioritizing which customers, tenants, or users needed attention right now

• Making actions repeatable across tenants, instead of one-tenant-at-a-time heroics

That realization is what led, step by step, to XMM.

Why XMM had to exist

XMM, in my mind, is “extended management and monitoring.”

If RMM was built for a world of devices on a LAN, XMM is built for a world of tenants, identities, and workloads in the cloud, with Microsoft 365 sitting in the middle of almost everything.

XMM had to be created because:

1. The primary control plane moved from endpoints to identity and SaaS.
   Managing endpoints is still critical, but it is not enough. The policies, roles, licenses, and relationships inside Microsoft 365 now define what users can do and what attackers can abuse.

2. MSPs needed a true multi-tenant view of Microsoft 365, not just device lists.
   You cannot scale serious security or operations work if you are living inside one tenant at a time.

3. Tool sprawl stopped being a badge of maturity and became a liability.
   Just like XDR consolidated point security tools into something more coherent, XMM has to consolidate how we see and act on tenants, identities, devices, backup, and posture.

4. Customers started buying outcomes, not tools.
   They do not care what mix of RMM, portals, and scripts you string together. They care whether MFA is enforced, critical data is recoverable, devices are compliant, and incidents are handled quickly.

5. AI raised the bar on what “management” can look like.
   Once you have a unified data layer and a consistent way to act on it, you can start layering on assistants, copilots, and automation that reason about the entire environment, not just one console at a time.

XMM, for me, is the platform that takes all of that seriously.

It respects the heritage of RMM in the way it treats devices and agents, but it also admits that the main story has moved higher up the stack: to tenants, identity, configuration, and data protection.

A personal reflection: this is not the end of the journey

When people hear “XMM,” they sometimes assume it is a marketing term that came first and a product that came later.

For me, it is the opposite.

XMM is the label I put on a pattern I kept seeing across MSPs:

• RMM doing its job, but increasingly out of position

• Microsoft 365 becoming the new backbone of the business

• Security expectations rising, while margins and headcount stayed flat

• Tool sprawl and swivel-chair operations turning into real business risk

Just like XDR continues to evolve as attackers change tactics and environments get more complex, XMM will keep evolving as Microsoft adds new capabilities, as identity becomes even more central, and as AI becomes a day-to-day part of how we manage and secure environments.

I do not think of XMM as “the thing we built once.” I think of it as the layer that has to sit between MSPs and the increasingly complex Microsoft-first estates they are responsible for.

RMM was the right idea for its time. XMM is my attempt to honor that foundation while building for the way MSPs actually work, and the way attackers actually operate, today.

And if my experience over the last few years has taught me anything, it is this: when the center of gravity moves, the tools have to move with it. If they do not, someone else will build the platform that does.

This time, I wanted to make sure we were the ones who did.