The tenant is the new server: why Microsoft governance is critical infrastructure for MSPs

Welcome

Thanks so much to everyone for joining, and thank you to those who came in early. We'll give the registrants a minute or two after the hour to join, since we had a good number sign up, and then we'll get started. And yes — for the folks already here, the screen is sharing fine.

Please make sure to use the chat and the Q&A today to ask any questions you have. I'll have both open during the webinar and will try to answer everything I can live; anything I can't, we'll save for the end. There should be plenty of time — hopefully it won't take the full hour, but we have it if we need it.

My name is Dakota. The title of today's webinar is "The tenant is the new server: why Microsoft governance is now critical infrastructure for MSPs." That's a deliberately bold claim, but I want to spend the next hour unpacking what it means — not as a marketing play, but as a structural shift in how MSPs need to think about service delivery, posture, customer conversations, and where recurring revenue will come from over the next three, five, even ten years.

If you take one thing away today, I'd like it to be this: the work you currently do — or used to do — in a customer's server room is now happening, or should be happening, in the Microsoft 365 tenant. Same disciplines, same operational rigour, just a different control plane. A lot of the industry hasn't caught up to that reality yet, and that gap is your opportunity. It's a closing window.

This is the first session in a three-part series. The next is in June and the third is in July, so if you take something positive from this, I hope you'll join us for the second part next month as well.

A bit of housekeeping: we've muted all lines, so you can't unmute yourself, but please put any questions or comments in the chat and we'll discuss them. This is a live interaction for a reason, so please interact — it stops me feeling like I'm talking to myself for an hour.

About me

A quick intro for those who've never joined one of my webinars. I'm Dakota McElliot, an M365 Solutions Architect at inforcer. I help MSPs design and govern secure Microsoft 365 environments across hundreds — sometimes thousands — of tenants. I spend a lot of time with compliance frameworks and the M365 platform itself, which means that day to day I'm translating standards like NIST, CIS, CMMC, and ISO into actual tenant settings: conditional access policies, Defender configuration, the stuff that really moves the needle.

My promise for this session: no theoretical fluff. Every concept we cover today, I'll ground in something Microsoft 365 related.

About inforcer

A little context on inforcer, because it'll help frame some of the examples later. We're UK-headquartered and globally distributed, and we're MSP-only. That matters more than it sounds: we don't sell to end customers and we have no end-customer sales motion, which means our incentives are aligned with yours. When you win, we win. We're never going to show up in your customer's inbox trying to upsell around you.

We have 150-plus people who previously worked at an MSP — actually more now, as we've been hiring a lot. I worked at CIS previously, which is fitting because CIS runs through the foundation of a lot of our compliance work. The point is that a lot of the people at inforcer come from an MSP background, and we're proud of how we've cultivated that internal workforce.

We have over 50,000 tenants under management on the platform today. That's an important number to hold on to, because when I talk about patterns across customer estates, I'm talking from a statistically meaningful data set, not a handful of references. We also have an exclusive partnership with Microsoft on the MSP side, meaning we co-engineer features specifically for the MSP delivery model with Microsoft product groups.

Two credentials are worth calling out because they're relevant to today. First, our MISA membership — the Microsoft Intelligent Security Association, Microsoft's vetted ecosystem of security vendors with deep platform integration. It's not pay-to-play; you have to be invited and demonstrate real integration and a security track record. Second — and I'm particularly proud of this — we're the founding vendor in Microsoft's Intune for MSPs initiative. Intune at MSP scale has historically been fairly brutal, so it's great that Microsoft acknowledged that and that we're part of it.

Three statements: the tenant, identity, and AI

I want to anchor today on three statements. In today's cloud-native world: the tenant is the new server, identity is the new perimeter, and AI is the new opportunity. Each of these used to be a bit of a debate. We'll focus mainly on the first two today — we have other webinars going into our Copilot integration and related work.

The tenant is the new server — this is the main topic today. The workload has moved: files, identities, apps, and devices all live in the tenant now, so the operational discipline that used to be applied to servers has followed that workload.

Identity is the new perimeter. The firewall used to be the boundary; that boundary doesn't exist anymore. Every access decision is now an identity decision.

AI is the new opportunity. I'm flagging it even though I'm not spending much time on it today, because it deserves its own session. Copilot, Copilot Studio, and agents in Microsoft 365 aren't just features — they're a new layer of the platform that needs to be governed, secured, and monetized. The MSPs who figure out how to govern AI deployments are going to print money over the next 24 months.

Why does all of this matter for you specifically as an MSP? It's an enormous opportunity to re-educate customers on what modern IT really looks like. The bulk of MSPs are still selling "IT services" — patch the box, monitor the firewall, back up the file server. Clients who are paying attention have already noticed there's no box anymore. They want a partner who can speak a new language. If you're the partner who can articulate this shift, you're not competing on price — what you're offering is a differentiator. It's a much better game to be in.

Why configuration matters: left of boom and right of boom

Before we go deeper on the tenant side, I want to plant a flag on why configuration matters at all, because I see this constantly given my compliance background. A lot of teams treat M365 like a SaaS product they resell — they turn it on, hand over the credentials, walk away, and bill monthly. That isn't management; that's resale with extra steps.

There's a concept in security circles, borrowed originally from the military: "left of boom" and "right of boom." The boom is the incident — the breach, the ransomware, the data event. Left of boom is everything you do before an attack to prevent it or reduce its blast radius. Right of boom is detection, containment, response, and recovery.

At the bottom of this slide is the NIST Cybersecurity Framework, which is relevant here. Identify is understanding your assets, data, and risks — for a tenant, that's the users you have, the licensing, the apps. Protect is the controls: conditional access, MFA, encryption. Detect is monitoring and alerting, using Defender, XDR, and so on. Respond is incident response. Recover is backup, restore, and business continuity — we have tenant backups there too. Govern is the new function within CSF; if you're involved in NIST today, that was the update from CSF 1.0 to 2.0, and it's really what this session is about — the govern function, and how you'd sell it as a managed service.

One more thing before I move on: Microsoft 365 is not secure by default. That's universally understood — it's built for ease of use over security, so you always have to go above and beyond even the security defaults. Making sure configuration is secure and ready to go is like cleaning a house over time: you don't clean the kitchen once and declare it permanently clean. You clean it Wednesday, and Friday it may need a touch-up. The same applies to a tenant — you can't harden it in Q1 and expect it to still be good in Q4. None of these products are ever "set it and forget it," because technology and configuration change all the time.

I love Nathan's analogy in the chat: "They will sell you the car, but you have to change the oil, put the gas in, close and lock the doors, and turn on the alarm." It's exactly the same. Maintenance with this type of technology needs to be discussed more, and right now we're firmly focused on left of boom.

What the server held — and where it lives now

Let's make this concrete. What did the server actually hold for your customers historically? Four things.

Data — files, databases, and line-of-business systems, probably a Windows file share or a SQL server. Devices — domain-joined workstations managed by group policy, patched from WSUS, with AV pushed from something like System Center. Applications — installed on the server or the desktops, licensed by the customer. Identities — user accounts and security groups, all living in Active Directory.

That was the universe, and servers held all four pillars — which is exactly why server management was such a defensible service line.

Now, where do those four live in the modern client? Data lives in SharePoint, OneDrive, Exchange Online, and Teams — with files attached to chats, in private channels, in shared mailboxes, and scattered across personal OneDrive accounts. Devices are Intune-managed Windows, Mac, and iOS, plus BYOD via app protection policies. Applications are SaaS, federated through Entra — Salesforce, Adobe, hundreds of line-of-business apps the customer signed up for and maybe never told you about. Identities live in Entra ID, which is now the identity provider for that whole sprawl.

Everything that used to live in a box now lives in a tenant. Same four pillars, different control plane — which means every discipline you used to apply to servers (patching, monitoring, hardening, backup) follows the same workload. Otherwise you're a managed service provider that isn't managing anything.

Traditional server management vs. tenant management

Let me put traditional server management and tenant management side by side, because this is the slide that usually flips the light bulb on for a technical audience — and it's a good one to use in your own customer conversations.

On the left, what you used to do for a server: monitor it (uptime, performance, event logs), patch the hardware and firmware, run Windows updates, manage the operating system. Many of you are still doing this today, and that's fine — plenty of folks still have on-prem environments.

On the right, tenant management, line by line. Configuration updates: Microsoft changes things constantly, so you evaluate each change, decide which to apply to which customers, and roll them out — directly parallel to Windows updates plus configuration management. Monitoring, but more for drift detection: settings change without your knowledge when a customer admin makes a tweak, Microsoft flips a default, or an integration partner adds an enterprise app — the same analogue as server monitoring. Then new-feature configuration, identity monitoring, and SSO provisioning: Entra is now the identity provider for hundreds of SaaS apps in a typical customer estate, so provisioning, deprovisioning, attribute mapping, and group-based access is a real workload. And application protection: mobile application management, conditional access for apps, and more.

It's the same operational disciplines in a different service area. If you're charging managed-service rates and you're not doing the right-hand column, you're charging for work you're not delivering. Eventually it's time to make that shift and treat the tenant as the new server.

Why this is an ongoing service, not a one-time project

Why is this an ongoing service rather than a one-time project? The most common mistake I see is adopting it as a hardening project — a fixed-price engagement that moves the customer to flat-rate management without scoping the ongoing work.

Think about three sources of drift. First, your own engineers: someone makes a change, multiplied by your team size and customer count. Second, customer-side admins making their own changes. Third — the biggest one — Microsoft itself, pushing platform changes constantly: new default settings, deprecations, renamed features, capabilities that move between licences. Policies that were best practice last quarter are now superseded. Every one of those changes is drift you didn't introduce, but you own the consequences.

So when an MSP tells a customer, "We hardened your tenant six months ago, you're good to go," that's mathematically false — the day after you say it, something has probably changed. This is the single biggest service-design conversation I have with our customers today: how to price governance as a recurring line item, not as a set-it-and-forget-it project. If you take one thing away, it's that this work can never be set-it-and-forget-it — especially if you come from a technical background.

Why manage M365? Fifty changes a year

Why manage M365? Fifty — that's the number of updates Microsoft made across just four services (Entra ID, Intune, Defender for Office, and Defender for Business) in the last 12 months alone. Just those four — not the whole platform, not Purview, SharePoint, Teams, Exchange, or Copilot. Fifty changes a year on services that directly shape your customer's security posture — roughly one a week, sometimes more. If you're not actively tracking each one, evaluating it, and deciding which customers to apply it to, you're not properly managing M365. But the opportunity is there, which is exciting.

“You wouldn’t leave M365 at default”

Here's a slide I really like — I saw my co-founder Will Connor present it at Cassa Connect a few weeks ago and it was brilliant. It's from those early-2000s anti-piracy ads: "You wouldn't steal a car, you wouldn't steal a handbag, you wouldn't steal a TV — so why would you steal a movie?"

When we talk to MSP owners, one pillar of our conversation is asking: do you believe tenant work is the new server? The answer is almost always yes — they've seen the writing on the wall. (As Alexander said in the chat, you wouldn't leave M365 at default — 100% agree.) Then I ask: how many servers do you have unpatched and unmonitored across your customer base? The answer is almost always zero — it would be a fireable offence. They have tooling that patches, policies in place, and alerting if a server stops checking in.

Then comes the kicker: how many unpatched tenants do you have? If the tenant is the new server, that's the gap. You wouldn't accept it for a server, so you can't accept it for the thing that's replacing the server. That's the whole argument.

Identity is the new perimeter

Identity is the new perimeter. The old perimeter was a firewall — you drew a ring around the network, trusted anything inside it, and treated anything outside as suspect. That's the castle-and-moat model. It isn't necessarily dead if you're still on-premise, but in this context there is no "inside" anymore. Users are on home networks, coffee-shop Wi-Fi, personal phones, and managed laptops at airports. The data they touch lives in tenants they don't own, in countries they may not even be in. The applications they use are SaaS services scattered across the internet. The castle has been demolished and the moat drained.

So what's the perimeter now? Identity. That's why we segmented it out in our platform: we have a tenant section focused on visibility of what's happening in the tenant and the policies that live there, but we also have an overview dashboard and a dedicated Entra ID dashboard, because we believe identity needs its own segmentation. Identity is now the perimeter of literally everything within a tenant.

Every access decision now starts with: who is this person, on what device, from where, doing what, against what data, at what time of day? Identities are the keys to the kingdom — not just to M365 data, but to everything: the CRM, the financial system, the HR platform, the development environments, all federated through Entra in a modern shop. Compromise an identity and you have the whole castle, not just an email account.

That's why account takeover is now the dominant attack vector by a huge margin. It used to be malware on the endpoint; now it's identity compromise leading to data theft, business email compromise, lateral movement into SaaS apps, and eventually ransomware. You've probably heard the Microsoft stat that MFA stops over 99% of unauthorized sign-in attempts. That number is real — it comes from Microsoft's own data across roughly 100 trillion signals a day — but it's dangerously incomplete if you stop there. Modern attackers know MFA and have adapted: we actively see adversary-in-the-middle phishing, token theft from the endpoint, MFA fatigue, and SMS-based MFA that's still unfortunately effective. MFA alone is no longer sufficient — it's table stakes, and the bar has moved. What protects identity in 2026 is layered controls: conditional access, phishing-resistant authentication, Intune device compliance, and token protection.

The modern MSP

If all of that is the new operational model — tenant management, and identity as security — what does the MSP built for it actually look like? I'd say six attributes.

One: customer success instead of maintenance. The old MSP sold uptime — servers running, email flowing, printers working. The modern MSP sells outcomes: productivity and security posture. Changing that in the conversation is important.

Two: selling users productivity, risk reduction, and compliance.

Three: all SaaS, no servers — mostly. There are real exceptions, and we're still processing all of those changes; there are still reasons to have servers. If new-customer onboarding still includes a server, you have a project on your hands, and that's important to prioritise.

Four: zero trust — never trust, always verify. Every request is authenticated, authorized, and encrypted regardless of where it came from. This isn't a product you buy; it's a posture. (Meredith, I 100% agree with your point in the chat.) Keeping up with how fast technology is changing, especially at scale as an MSP, is genuinely difficult — I sympathise, but I love working in this space for exactly that reason.

Five: a configuration-as-code, API, and AI mindset.

Six — last but not least: Microsoft modern workplace as the foundation. This is the platform — M365, Entra, Intune, Defender, Purview, Copilot. Build on top of it; don't recreate it. There's no business case in 2026 for stitching together a non-Microsoft EDR and an email security gateway when the customer is already paying for the Microsoft stack. Use it, and use it conceptually well.

If your MSP already looks like this list, you're modern. If some things are missing, that's fine — it's a road map of things to focus on.

Betting on Microsoft

I keep telling you to bet on Microsoft, so let me back that up with numbers, because the investment scale is genuinely staggering and it tells you where the gravity of the security industry is going.

There are about 34,000 engineers working on security at Microsoft today — more than the total headcount of nearly every security vendor on the market, bigger than CrowdStrike, Palo Alto, or Fortinet. Microsoft's security team alone is one of the largest software organizations in the world. They've committed $20 billion to security between 2021 and 2026 — a five-year commitment larger than the entire market cap of most of Microsoft's security competitors. So when a competitor releases a feature, Microsoft can release the same feature plus deep integration into identity, at effectively little marginal cost to a customer who already has E5.

And they process 100 trillion security signals per day — every sign-in, email, file access, endpoint heartbeat, and DNS lookup feeding the threat intelligence that powers the whole platform. No third-party security vendor on earth has that signal volume; it's not even close.

There are things only Microsoft can do because they own the whole stack — identity, endpoint, productivity suite, cloud, and AI. When you stitch together a best-in-show setup from three vendors, you get gaps in the seams; when the same vendor owns all the seams, that gap disappears. Five capabilities you can't really replicate elsewhere: zero trust — native and signal-driven, evaluated in real time against the user, device, and location, with no third-party identity provider integrating this deeply with the Microsoft data plane; endpoint hardening with opinionated, CIS-aligned defaults that Microsoft publishes, updates, and tunes to real-world needs; streamlined patching with autopatch and hotpatch that removes the operational burden of update rings — a productivity dividend you can quantify; frictionless mobile management; and devices shipping from the OEM directly to the user — white-glove provisioning at zero marginal cost. You can't replicate this with a third-party stack — not at the price, the integration depth, or the signal volume. So the play for the modern MSP is: adopt the platform, master it, govern it, and charge for that governance.

The configuration surface: one tenant, then many

A bit more about inforcer. This is the "wall of doom" slide, so hold your breath. What you're looking at is the configuration surface of Microsoft 365 for one customer tenant, across the major pillars — Entra ID at the bottom, then Intune, Defender XDR, and Exchange in the middle, SharePoint and Teams above that, and Purview and Copilot as well. Every line of text is a real setting, policy, or control that can — and in most places should — be configured: authentication strengths, named locations, conditional access policies, Intune settings, and the list goes on. And that's just hardening one tenant. The hard part isn't knowing what to configure; it's applying it consistently across every tenant.

Now multiply that by the number of customers you have — that's what an MSP is actually staring at. If one tenant was daunting, consider running 30, 50, 200, or a thousand of them. And it's not just a volume issue: every customer comes from a different maturity level, industry, regulatory baseline, compliance posture, licensing SKU, risk appetite, and culture. You can't just clone all settings across the board — you need a baseline of foundational settings and a way to handle the variation.

If you try to do this with documentation, SOPs, and a couple of senior engineers holding granular knowledge, the maths doesn't work. With 10 customers it just about works if your engineers are heroes. With 50 it stops working entirely. With 200 you can't manage it properly until a customer fails, an audit is needed, or there's a breach.

And you have to keep up with Microsoft on top of all that complexity — this slide is just a short list of the headline changes from roughly the last quarter. It's not just the number of tenants to manage; it's all the changes from Microsoft too.

How inforcer helps: the golden baseline and four actions

So how does inforcer help? At the core, we start with a workflow.

It begins with the golden baseline — your standard of what "good" looks like across all these pillars, expressed as a concrete set of foundational settings (conditional access and the rest) that you deem necessary for every customer regardless of industry. It's your opinion, but it's also informed by the different compliance frameworks we provide in the platform. It's yours — it's how your MSP delivers M365. If you're already managing M365 today, this is essentially condensing that work into a formulated baseline; the work's mostly done, it's just being reworked.

Then the multi-tenant magic happens. You point the platform at a customer tenant, and we compare the customer's current configuration against your golden baseline. For every policy that comes back different, you have four actions:

Deploy the policy — if the customer is missing it entirely, push it (the new conditional access policy, the new compliance policy, whatever's missing). This is the most common action when onboarding a new customer.

Accept a deviation — every customer is a little different. Maybe the CFO needs to travel for a few months, or the industry requires a tighter setting than your baseline. You can accept deviations explicitly, document and audit exactly why, and stop it showing as drift — which keeps you and your auditor sane.

Align to the baseline — the policy exists in the customer tenant but has been modified, by an engineer, the customer, or a shifting Microsoft default. With one click you pull it back to your baseline version, instead of an engineer redoing the whole policy by hand.

Rename to baseline — the policy is functionally correct but the naming convention doesn't match. It's one thing for the JSON underneath to work the same; it's another to have policies standardized across tenants. How can your level-one engineers understand what's going on in one tenant versus another if the naming conventions differ? Standardization matters, and our platform prioritizes it in alignment scoring and lets you standardize automatically when pushing policies.

That's the whole pattern: four actions applied across the entire configuration surface, with ongoing drift detection so you can review it over time.

Three capabilities to call out

Three capabilities map directly to the framework we've discussed.

First, compliance-framework-aligned baselines. You can start from CIS and work up. The heavy lifting of mapping a framework to actual M365 settings is already done, because CIS works both as a foundation for customers with no specific compliance requirement (its recommendations are consensus-based) and for customers who do have one, since CIS maps to about 30 different frameworks. It's pre-built and maintained, available in both policy format and assessment format.

Second — one of my favourite features, especially for people leading M365 conversations without a deep M365 background — AI policy impact analysis. You click a button, it digests the policy's JSON, and gives you a neat summary of exactly what that policy is doing. It's also great for experienced engineers picking up a new tenant who don't want to read through an entire JSON blob to understand an unfamiliar policy.

Third, tenant drift alerting. When something changes in a tenant, we let you know — inside the inforcer platform or in the tenant itself — so you're aware and can come back in to adjust. (And thanks, Nathan, for answering a question for me in the chat.)

Custom baselines and modern tenant alignment

On custom baselines: the most common feedback we used to get was that one baseline doesn't fit every customer — and that's correct. So we added the ability to create custom baselines from one tenant. You can have as many baselines as you want from a single source tenant.

The idea — and this answers a question in the chat about how we pull policies — is to keep one demo, sandbox, or dev tenant internally as a repository of policies. You onboard it into inforcer and use that library to push to all your customers, creating as many baselines from it as you want. That means you don't have to maintain many tenants' worth of policies in different places. You can split the alignment journey into phases, split it by product type, and create variations by licensing and by compliance.

On the alignment side, we handle assignments on policies, not just the policy content — sometimes the policy is fine but assigned to the wrong group. You can accept deviations and align the rest. We also recently introduced time-bound deviations: you can accept something as a deviation for 90 days, and it auto-resurfaces after that for review.

Onboarding and GDAP

Our partner onboarding was also just updated. For Microsoft CSP partners specifically, GDAP relationships are a constant source of pain. You can now onboard using Partner Center, and we only onboard tenants with the correct GDAP setup. You can also set up GDAP and fix anything that's missing within the platform itself — you can see exactly what needs fixing in terms of security grouping and roles. This alone is worth a conversation if you're running a large CSP book, because it saves a lot of time.

Tenant assessments

Then there's tenant assessments — the thing I'm most excited about. It runs a full security and compliance assessment against a customer tenant in a few seconds, not days or weeks. Out of the box, we ship assessments for the Microsoft 365 Foundations Benchmark version 6. Version 7 is currently in consensus with CIS, which means they're finalizing it — I won't quote timing since I don't work there anymore, but typically that takes about a month. When CIS updated the benchmark from version 5 to 6, it took our team about a week to update our checks. We also have the Windows 11 Intune benchmark and Essential 8.

That's just the start — you can create custom assessments too, taking any of those checks and building your own. That's really useful because you can send a customer exactly what's going on in their tenant against a CIS expectation, rather than a generic vendor deck, and use it to prioritize your project. (Cody, yes — CIS is broken up into implementation groups for the controls. I also hosted a whole webinar on CIS two weeks ago; if you're interested, it's on our main website.)

User and group management

Entra user and group management inside the platform sounds boring but solves a real problem: when you're running 50 customers, finding users with issues across the estate is a multi-hour exercise, so having it in one pane of glass is genuinely valuable. We just updated this section — you can add available licensing directly in inforcer now, and view multi-factor authentication methods within the platform too.

Tenant standardization in five steps

Tenant standardization in five simple steps, done manually without a platform: define your best practice; document it somewhere (a Word doc someone owns and updates occasionally); onboard new customers; periodically check and update those customers; and deploy new settings and policies based on the updated best practice — which almost never happens.

If you laugh at that, it's because you've lived it. Every MSP we work with has some version of this story. The five steps are the correct process — the process isn't broken. The problem is executing all of it manually at scale.

That's where a platform comes in — whether built or bought — to close the gap created by the tenant being the new server. We built an entire industry of tooling around server operations because the manual approach didn't scale; tenants now need the same thing, and that industry is still in its early innings. It's exciting to see where it's going: what it was before with servers, how it's paralleled now, and how you still need to find a way to automate this process going forward. That's what today's focus was tailored to, so hopefully you got some foundational knowledge to fill any gap in your own coverage.

Wrap-up and Q&A

That's everything I had for today. I appreciate all of your time, and I'll open up for any questions.

If you'd like to book a demo, there's a QR code — I know it's a little wild to ask you to scan a QR code during a cybersecurity talk, but marketing provided it. There's also a resources link with the webinars, and a "book a demo" option on the left-hand side that connects you with someone from our M365 team.

On the questions: Nathan, hopefully I answered your first Q&A question — if not, happy to set up a demo and chat further. On how fast policies are pushed out: almost instantly, and there's an alert on the platform (a little bell at the top right) that tells you when a policy is deployed. Tenants are backed up daily and automatically, and you can also run manual backups; we pull everything in real time through the Graph API. I'll drop the link to our past webinars in the chat as well.

Thank you all for joining. I hope you'll join the next part of the series in June — I'm really looking forward to finishing it out. Have a great rest of your week, and thanks for interacting with me so it didn't feel like I was talking to myself for almost an hour. Thanks, everyone.