How should MSPs support both Google Workspace and Microsoft 365 without losing control?

MSPs should build a single identity and policy layer that governs authentication, device posture, provisioning, and deprovisioning across both suites. The goal is to keep lifecycle actions, security enforcement, and audit evidence consistent even when client preferences differ. Without that control plane, support becomes fragmented and governance degrades quickly.

Why This Matters for Security Teams

MSPs are often asked to support both Google Workspace and Microsoft 365 because clients want flexibility, existing licences, or regional preference. The risk is that a split-tool model usually becomes a split-control model: different identity rules, inconsistent device checks, uneven provisioning, and fragmented audit trails. That is where governance fails first, not in the mailbox or document layer, but in the identity and lifecycle layer that should stay consistent across tenants and suites. Current guidance from the NIST Cybersecurity Framework 2.0 reinforces that identity, access, and monitoring need coordinated control ownership rather than ad hoc administration. NHIMG research shows why this matters: in the Ultimate Guide to NHIs, 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that lifecycle gaps quickly become compromise paths. In practice, many MSPs discover the control problem only after offboarding, privilege drift, or audit failure has already exposed the inconsistency.

How It Works in Practice

A workable MSP model starts by separating the management plane from the product plane. Google Workspace and Microsoft 365 can remain the client-facing suites, but the MSP should centralise identity policy, approval, and evidence collection. That means one source of truth for joiner, mover, and leaver actions; one policy baseline for MFA, conditional access, and device posture; and one audit process for provisioning and deprovisioning.

Operationally, that usually includes:

• Federated authentication through a central IdP, so access decisions are not defined twice.
• Role templates and approval workflows that map to client-specific exceptions without changing the core standard.
• Automated offboarding for both human and non-human identities, including tokens, app registrations, and delegated access.
• Central logging that preserves who approved, who changed, and when revocation occurred.
• Policy checks at the identity layer before users or service accounts inherit suite-specific permissions.

This approach aligns with the control logic behind the Ultimate Guide to NHIs, especially where lifecycle governance and visibility matter more than the brand of the productivity suite. For implementation discipline, the NIST Cybersecurity Framework 2.0 is useful because it treats identity and monitoring as enterprise functions, not application-by-application tasks. MSPs also need to watch real-world failure cases such as the Microsoft Midnight Blizzard breach and the Google Firebase misconfiguration breach, both of which highlight how identity and configuration drift can turn into broad exposure. These controls tend to break down when each client insists on unmanaged exceptions because the MSP then inherits multiple policy dialects that cannot be enforced consistently.

Common Variations and Edge Cases

Tighter identity centralisation often increases change-management overhead, requiring MSPs to balance standardisation against client autonomy. Some clients will demand native controls in one suite or the other, and best practice is evolving on how much local variance is acceptable before governance becomes fragmented. In those cases, the MSP should preserve the same control objectives even if the enforcement mechanism differs. For example, Google and Microsoft may use different admin paths, but the baseline requirements for MFA strength, admin separation, and deprovisioning speed should not diverge.

The hardest edge cases usually involve shared admin accounts, delegated tenant access, and service accounts that span both ecosystems. Those identities need stricter ownership, shorter-lived credentials, and clearer evidence than ordinary user accounts. NHIMG data shows only 20% of organisations have formal offboarding and revocation processes for API keys, which is a warning sign for MSPs that support automation-heavy clients. The Schneider Electric credentials breach is a useful reminder that credential exposure often becomes a lateral movement problem once lifecycle control is weak. MSPs that cannot unify those edge cases across both suites usually end up with service desk convenience replacing security governance.

Related resources from NHI Mgmt Group

• How should security teams govern BYOD without losing control of access?
• How should IAM teams reduce tool sprawl without losing control?
• How should security teams compare Microsoft 365 admin tools with broader identity governance platforms?
• How should MSPs explain security work without sounding like tool installers?