Multi-Tenant MSP Architecture

MSP Architecture

Governing Microsoft at Scale Across Many Tenants

What 25 tenants actually teaches you

Managing a single Microsoft tenant well is one skill. Managing 25 simultaneously, each with different owners, expectations, and starting conditions, is a different discipline entirely. This document covers what I learned doing it.

25

The Core Challenge

"Every tenant is different. The job is building standards flexible enough to apply everywhere but specific enough to actually mean something."

Daniel Lepel · Principal Microsoft Cloud Architect

Reality Check

The Scale Problem

Why multi-tenant is harder than it looks

Across 25 tenants, no two environments are the same. Different industries, different sizes, different levels of technical maturity, and wildly different expectations about what IT is supposed to do for them.

The challenge isn't just technical. It's managing consistency across organizations that don't think about consistency the same way you do.

What Makes It Hard

›Expectations vary as widely as the environments themselves

In Practice
One client understands security architecture and wants detailed rationale for every policy decision. The next doesn't know what a global admin is but wants one anyway, on their daily driver account. Both are your responsibility. The approach has to flex without the standards flexing.
›Each tenant inherited different decisions made by someone else

In Practice
You almost never build from scratch. You inherit configurations that made sense to whoever set them up, or didn't make sense at all. Before touching anything, I map what's actually there. Assumptions about what should exist and what does exist are consistently different things.
›Fixing one tenant's problems doesn't fix them in the others

In Practice
Every improvement has to be deliberately propagated. There's no global policy push across unrelated tenants. What you build in tenant one has to be deliberately replicated across the others, which is why having a documented standard matters - it's the reference for every subsequent deployment.
›Staying current across all tenants simultaneously is its own workload

In Practice
Microsoft changes fast. A new Conditional Access template, a deprecation notice, a security default change - each one needs to be evaluated against all 25 environments. Building automation and using Microsoft 365 Lighthouse for visibility across the portfolio is how you manage that without drowning in it.

What Goes Wrong

Common Failure Patterns

The same problems appear in almost every tenant

After enough tenants, the failure patterns become predictable. They're not random. They cluster around a few areas where small organizations consistently make the same decisions for the same reasons.

Knowing the patterns in advance means you can assess a new tenant quickly and know where to look first.

The Usual Suspects

›Global Admin accounts on daily driver credentials

In Practice
This is the most common and most serious finding. Small organizations often have one or two people who "own" the IT and want maximum access. What they don't understand is that a compromised daily driver account with Global Admin is a compromised tenant. Getting them off standing Global Admin and onto PIM
Privileged Identity Management
Grants admin access only when needed, for a defined time window, with optional approval - then removes it automatically. Eliminates standing privileged access.
is usually the first conversation I have.
›No groups - permissions assigned directly to users

In Practice
In almost every small tenant I've inherited, permissions are assigned directly to individual users rather than through groups. It makes onboarding slower, offboarding riskier, and auditing nearly impossible. Rebuilding the permissions model around groups is foundational work that pays dividends in every subsequent change.
›SharePoint sites configured incorrectly or not at all

In Practice
SharePoint is consistently the most misconfigured workload in small tenants. Overly permissive sharing settings, no external sharing governance, site collections created ad-hoc without naming standards, and Teams-created sites nobody is managing. It's usually not malicious - it's just that nobody was ever shown how to set it up correctly.
›MFA not enforced or enforced inconsistently

In Practice
Security defaults enforce MFA but Conditional Access gives you control over how and when. Many small tenants have MFA "enabled" but not required - meaning users can skip it or it only triggers in some scenarios. A properly built Conditional Access policy set closes that gap and removes the ambiguity.

The Baseline

Building a Common Standard

What I apply to every Business Premium tenant

Consistency at scale requires a documented standard that can be applied to any new tenant and used as the benchmark for assessing existing ones. My Business Premium standard is the result of building and inheriting enough small tenants to know what a well-run one looks like.

It isn't a rigid template. It's a baseline that gets adjusted for each organization's specific requirements while maintaining the security and operational fundamentals.

What the Standard Covers

›MFA enforced for all users via Conditional Access
Conditional Access
Policy engine in Entra ID that evaluates user, device, location, and risk signals to decide whether to allow, block, or step up authentication for each sign-in.

In Practice
Not security defaults - a proper Conditional Access policy set that enforces MFA where it matters, allows for compliant device exceptions, and gives the admin team visibility into what's triggering. Security defaults are a starting point, not an architecture.
›All machines enrolled in Microsoft Intune
Microsoft Intune
Cloud-based endpoint management included in Business Premium. Handles device enrollment, compliance policy, application deployment, and configuration management.

In Practice
Intune enrollment is the foundation for device compliance in Conditional Access. Without it, you can't enforce "managed device" as a condition. I enroll everything - Windows, Mac, mobile - and configure compliance policies that feed directly into access decisions.
›Permissions model built on groups, not direct user assignments

In Practice
Every permission assignment goes through a group. New user onboarding means adding them to the right groups, not hunting down every individual permission. Offboarding means removing group memberships, not hoping you found everything.
›SharePoint external sharing governance and site standards

In Practice
Tenant-level sharing settings locked down to known domains or disabled externally where the business doesn't need it. Site naming conventions and ownership requirements set from the start. Teams-provisioned sites audited and brought under management.
›Defender for Business active with baseline policies deployed

In Practice
Defender for Business is included in Business Premium and covers endpoint threat protection, vulnerability management, and attack surface reduction. Getting it actually active and configured - not just licensed - is step one. Most small tenants have it licensed and untouched.

The Hard Part

Governing Security at Scale

What nobody tells you until you break something

The biggest risk in MSP security work isn't leaving gaps. It's fixing gaps and breaking something in the process - something that was set up incorrectly by a previous administrator, held together with workarounds, and silently depended on by users who never mentioned it.

This is the reality of inheriting environments. You're not building on a clean foundation. You're working around the archaeology of every decision that came before you.

How I Handle It

›Map what exists before changing anything

In Practice
Before any configuration change in an inherited tenant, I run through a structured assessment: what Conditional Access policies exist and what do they actually cover, what accounts have elevated roles, what legacy authentication is still active, where are the SharePoint permissions actually set. Changes made without this context break things you didn't know were there.
›Implement security changes in report-only mode before enforcing

In Practice
Conditional Access has a report-only mode that shows you who would have been blocked by a policy before you turn it on. I use it on every new policy in an inherited environment. It's how you find the service account that authenticates with legacy protocols before you lock it out of production.
›Expect that implementing best practices will break non-best-practice dependencies

In Practice
When you block legacy authentication, the application that was quietly using basic auth stops working. When you enforce MFA, the shared mailbox that was being accessed directly stops working. These aren't surprises - they're predictable consequences of fixing the environment. The mitigation is finding them before enforcement, not avoiding the fix.
›Document every non-standard configuration and the reason it exists

In Practice
Every exception to the standard - every policy exclusion, every legacy authentication allowance, every overly permissive sharing setting left in place for a business reason - gets documented with context. If I get hit by a bus, the next person needs to know why the exception exists, not just that it does.

The Other Challenge

The Human Factor

Security only works if people will use it

Technical governance is only half the problem. The other half is people. Small organizations in particular have users who are not technically sophisticated and who experience any change to how they work as a disruption, regardless of what it fixes.

Latham Pool Products was the exception - a more mature organization where users accepted new security requirements because they understood the context. Most tenants aren't Latham.

Managing the People Side

›Explain the why before the what

In Practice
Users who understand why MFA exists are significantly more accepting of the friction it adds. "We're requiring this because your account is the key to everything in the organization, and it needs to be protected" lands better than "IT is making you do this." Context converts resistors into participants.
›Anticipate what will feel like a disruption and prepare for it

In Practice
Quarantined email, MFA prompts, new sign-in experiences - all of these generate support tickets the first week they're active. I prepare communications in advance, write simple one-page guides for the most common user questions, and make sure whoever handles first-line support knows what's changing before it changes.
›Set expectations with the business owner before touching the environment

In Practice
The conversation about what security governance will change needs to happen before any changes are made. If the business owner is surprised by what MFA does to their workflow, you've already lost the relationship. Agreement in advance on what will change and when turns implementation into execution, not a fire drill.
›Recognize when a technically correct decision is the wrong call right now

In Practice
There are tenants where the right security posture, implemented all at once, would break the organization's trust in IT entirely. In those cases, phasing the changes over time - securing the highest-risk exposures first and building confidence before the next change - produces better outcomes than technically correct all at once. Architecture serves the business. Not the other way around.

Closing Thought

"Managing 25 tenants didn't teach me 25 times as much as managing one. It taught me things you can only learn from the variation."

Daniel Lepel · Principal Microsoft Cloud Architect

What It Comes Down To

Standards matter because they're what you fall back on when every environment is different. Build them deliberately, document the exceptions, and apply them consistently.

The technical problems in small tenants are predictable: Global Admin on daily drivers, no groups, SharePoint misconfigured, MFA inconsistently enforced. Knowing the patterns means you can address them quickly and in the right order.

The harder problems are organizational. Security that breaks the organization's confidence in IT isn't security - it's a setback. Getting users and business owners on board with the changes is as much a part of the work as making them.

The goal is environments that run well without constant intervention. That takes longer to build than a quick fix. It's worth it.