How should MSPs keep Microsoft security configurations aligned across many customer tenants?

Why This Matters for Security Teams

For MSPs, Microsoft tenant configuration is not a single hardening project. It is a living control plane that can drift through admin changes, vendor onboarding, emergency exceptions, and customer-specific overrides. Once drift accumulates across dozens or hundreds of tenants, small setting changes can create inconsistent exposure, especially for identity, email, endpoint, and app governance controls. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces that configuration management is an operational discipline, not a checkbox.

This matters even more in Microsoft ecosystems because attackers routinely benefit from weak tenant hygiene and stale permissions. NHIMG’s research on the Microsoft Midnight Blizzard breach and the Microsoft Entra ID Flaw shows how tenant-level identity and configuration weaknesses can have outsized impact when privilege, trust, and defaults are not tightly controlled. In practice, many MSPs discover drift only after a customer audit, an incident, or a failed containment effort, rather than through intentional baseline enforcement.

How It Works in Practice

The practical model is to define one approved baseline per Microsoft workload, then continuously compare each customer tenant against that baseline. That baseline should cover Entra ID, Conditional Access, Defender settings, Intune policies, Exchange protections, and any delegated administration permissions. MSPs should treat the baseline as policy-as-code where possible, with change approval, version control, and clear exception handling. Current guidance suggests that baselines work best when they are measurable, reproducible, and tied to business impact rather than broad security intent.

Operationally, the workflow usually looks like this:

• Capture the intended tenant state for each customer segment.
• Monitor for configuration deltas through Microsoft APIs, CSPM tooling, or native audit logs.
• Classify changes by risk, such as weakened MFA, relaxed admin consent, or disabled security defaults.
• Alert, ticket, or auto-remediate based on severity and customer approval model.
• Track exceptions with expiry dates so temporary changes do not become permanent drift.

For identity-related settings, this should include delegated admin privileges, conditional access exclusions, and privileged role assignments. The attack pattern behind Stryker Microsoft Intune Wiper Attack shows why endpoint and management-plane drift can become an enterprise-scale issue quickly. Pairing that with the control discipline described in NHI Mgmt Group guidance on non-human identities helps MSPs recognize that service principals, automation accounts, and API permissions are part of the tenant baseline too. These controls tend to break down when customers insist on bespoke exceptions per tenant because the exception set becomes larger than the standard itself.

Common Variations and Edge Cases

Tighter tenant baselines often increase operational overhead, requiring MSPs to balance uniform security against customer-specific business needs. That tradeoff is most visible when a customer requires legacy authentication, unusual mail routing, or admin roles that do not fit the standard policy pack. Current guidance suggests documenting those deviations as explicit exceptions rather than silently absorbing them into the baseline.

Multi-tenant environments also create a real distinction between configuration drift and delegated risk. A configuration may be intentional for one tenant but dangerous if copied elsewhere without review. MSPs should therefore segment baselines by customer tier, regulatory profile, and Microsoft workload, then review changes in context instead of assuming all tenants should be identical. The stat from The State of Non-Human Identity Security is relevant here: 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, which reinforces that configuration management and identity lifecycle controls are tightly linked. Best practice is evolving, but there is no universal standard for how much tenant variation is acceptable. The safest approach is to make drift visible first, then decide whether each change is a controlled exception or an unmanaged exception.

Related resources from NHI Mgmt Group

• How should MSPs implement credential security controls across multi-tenant customer environments?
• How should MSPs govern Microsoft 365 security across multiple tenants?
• How should security teams make NHI best practices usable across the business?
• How can teams keep remote access auditable across many customer sites?