MSPs should use one control framework, one prioritisation model, and one closure workflow across all tenants. That prevents service drift and makes findings comparable from customer to customer. The goal is not just to detect issues, but to prove that remediation and revalidation happen in the same operating loop across the estate.
Why This Matters for Security Teams
MSPs managing Microsoft 365 across multiple tenants are not just running repeated assessments. They are governing a shared operational model where one missed remediation step, one inconsistent severity label, or one tenant-specific exception can create drift across the estate. A workable program needs comparable findings, consistent closure criteria, and evidence that revalidation happened after the fix, not simply that a ticket was opened.
This is especially important because Microsoft 365 security issues often involve identity, OAuth apps, mailbox rules, conditional access, and over-permissioned service accounts, all of which behave differently from one tenant to the next. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs notes that 71% of NHIs are not rotated within recommended time frames and 97% carry excessive privileges, which is a useful reminder that weak identity hygiene scales quickly across managed estates. A consistent control framework also aligns with the NIST Cybersecurity Framework 2.0 expectation that organisations define repeatable governance and improvement loops rather than ad hoc remediation.
In practice, many MSPs discover tenant-to-tenant inconsistency only after the same control failure has already repeated across multiple customer environments.
How It Works in Practice
The practical answer is to standardise the operating model, not just the tooling. Each tenant should be assessed against the same control catalogue, the same severity logic, and the same closure workflow, while still allowing tenant-specific exceptions where business constraints are documented and approved. For Microsoft 365, that usually means mapping findings to identity, device, mail, collaboration, and application controls, then enforcing the same remediation evidence requirements everywhere.
A strong MSP process usually includes:
- One baseline policy set for all tenants, with explicit deviation handling.
- One prioritisation model that weighs exposure, blast radius, and exploitability the same way across customers.
- One closure loop that requires fix, validation, and timestamped evidence before a finding is marked complete.
- One reporting structure that shows trend lines across tenants, not isolated ticket queues.
This is where NHI governance becomes operationally useful. Microsoft 365 tenants commonly expose high-risk non-human identities through app registrations, delegated permissions, and long-lived secrets. The State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which mirrors the blind spots MSPs face when tenant controls are monitored inconsistently. Pairing that visibility with control discipline from NIST SP 800-53 Rev. 5 Security and Privacy Controls helps keep remediation tied to a defensible control objective instead of a one-off fix.
In practice, these controls tend to break down when tenants have different exception policies, because remediation evidence stops being comparable and closure becomes a judgment call rather than a repeatable workflow.
Common Variations and Edge Cases
Tighter standardisation often increases administrative overhead, requiring MSPs to balance consistency against customer-specific configuration differences. That tradeoff is real, especially in environments with regulated clients, mergers, or tenants that use different licensing tiers and admin roles. Best practice is evolving, but there is no universal standard for this yet, so MSPs need a policy structure that is strict on process and flexible on documented exceptions.
Edge cases usually appear in three places: delegated administration, tenant-specific security baselines, and customer-owned remediation. Some customers will insist on unique approval chains or slower change windows, but that should not change the MSP’s severity model or validation criteria. If a tenant cannot support the standard workflow, the exception should be explicit and time-bound, not informal. The same principle applies to Microsoft 365 identity issues surfaced through compromised service principals or OAuth apps, where common attack patterns can cross tenants if monitoring and rollback are not uniform. NHI-focused guidance in Top 10 NHI Issues and the audit perspective in Ultimate Guide to NHIs — Regulatory and Audit Perspectives both reinforce the need for evidence, ownership, and repeatability across the full lifecycle.
The hardest environments are those where each tenant has its own tooling, approval chain, and remediation expectations, because the MSP then loses the ability to compare risk or prove closure consistently.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Multi-tenant MSP governance needs a consistent operating model and accountability. |
| NIST SP 800-53 Rev 5 | CA-7 | Continuous monitoring and revalidation are central to closure workflow discipline. |
| OWASP Non-Human Identity Top 10 | NHI-01 | OAuth apps, service principals, and secrets are core non-human identities in M365. |
Define one cross-tenant governance model with clear ownership, metrics, and review cadence.
