How should MSPs centralise identity governance across users, devices, and SaaS apps?

MSPs should establish one identity control plane that owns authentication, access policy, and lifecycle state, then integrate device and SaaS systems back to it. The goal is not total tool replacement, but consistent decision-making. Where separate consoles can still grant or preserve access independently, governance drift is already present and should be reduced.

Why This Matters for Security Teams

For MSPs, centralising identity governance is not just an efficiency project. It is the control that determines whether one policy engine can consistently govern humans, endpoints, and SaaS entitlements, or whether separate systems quietly reintroduce shadow access. Once authentication, lifecycle state, and authorisation are split across consoles, drift becomes inevitable, especially when administrators can grant access in one place and preserve it in another. The governance problem is often amplified by NHI sprawl; NHIMG research shows organisations still struggle with visibility and lifecycle control across identities, and the Ultimate Guide to NHIs highlights how quickly that risk scales when access is not centrally owned.

The practical goal is to create a single source of truth for identity state, then federate it to the systems MSPs manage on behalf of customers. That means central policy, central auditability, and central offboarding, even if the operational actions happen in different tools. Current guidance from NIST Cybersecurity Framework 2.0 supports this direction through governance, access control, and continuous monitoring outcomes. In practice, many MSPs discover access drift only after a customer review, incident, or failed offboarding rather than through intentional governance design.

How It Works in Practice

The most effective model is a hub-and-spoke identity architecture. The hub owns identity proofing, authentication policy, role assignment, conditional access, and joiner-mover-leaver lifecycle state. The spokes are the connected systems: customer directories, device management platforms, SaaS applications, and privileged access tooling. Each spoke should consume policy and lifecycle events from the hub, not maintain independent entitlement logic that can outlive the source record.

For MSPs, this usually means integrating directory services with MDM, SaaS provisioning, and PAM so that access is granted from the same authoritative record and revoked from the same workflow. Centralisation also requires explicit handling of exceptions. If a SaaS app supports its own local admin model, that control must be mapped back to the central identity system and reviewed as an exception, not accepted as a parallel authority. NHIMG’s Lifecycle Processes for Managing NHIs is useful here because the same lifecycle discipline that applies to service accounts applies to human admin and delegated access patterns as well.

• Define one authoritative identity source per tenant or customer boundary.
• Use SCIM, SSO, and directory sync to push lifecycle changes to SaaS and device platforms.
• Enforce conditional access and step-up controls centrally, not inside each app.
• Record all grants, revocations, and exceptions in one audit trail.
• Review orphaned local admins, cached access, and manual break-glass paths on a fixed cadence.

This approach aligns with the operating model implied by the Top 10 NHI Issues, because central governance only works when lifecycle and revocation are actually enforced across every connected platform. These controls tend to break down in multi-tenant MSP environments where customer-specific exceptions, shared admin tooling, and disconnected SaaS ownership models allow access to persist after the central record has changed.

Common Variations and Edge Cases

Tighter identity centralisation often increases integration overhead, so MSPs must balance consistency against the realities of legacy tools, customer contract boundaries, and delegated administration. There is no universal standard for every SaaS app’s role model, so best practice is evolving toward policy harmonisation rather than identical configuration everywhere. The key question is whether a local control can override the central source of truth without detection.

One common edge case is break-glass access. Emergency accounts should remain centrally governed even if they are not used day to day, because unmanaged exceptions are where governance fails first. Another is endpoint autonomy: device trust signals may originate in MDM or EDR, but access decisions should still flow through the central policy plane. For MSPs managing sensitive customers, the 52 NHI Breaches Analysis reinforces the broader lesson that disconnected identity controls turn administrative convenience into persistent exposure. Where vendors do not support federated lifecycle enforcement, those applications should be treated as governance gaps until compensated controls are in place.

Related resources from NHI Mgmt Group

• Why do shadow SaaS apps create a governance problem, not just an IT inventory problem?
• Why do SaaS management tools matter to identity governance programmes?
• How should teams govern asset lifecycle workflows across users and devices?
• How do SaaS operations tools affect non-human identity governance?