Why MSPs Should Stop Using Shared Admin Accounts for Client M365 Tenants

Walk into any MSP shop with more than five client tenants and you'll find the same pattern: a shared admin account on each tenant, with credentials in a shared password manager, used by whichever tech is on shift for that client.

It's the path of least resistance. It works. And it's a compliance failure, an attribution nightmare, and an audit liability — none of which usually matter until they suddenly do.

Here's why the pattern persists, what it actually costs, and the architecturally-clean replacement.

How shared admin accounts happen

The pattern emerges naturally from MSP economics. You onboard a new client. They have an M365 tenant. They give you Global Admin access — typically through a helpdesk@client.com or msp-admin@client.com account they create specifically for you.

Your shop puts the credentials in 1Password (or LastPass, or Bitwarden, or — sometimes — a shared spreadsheet). The senior tech, the on-call tech, the L1 helpdesk staff who handle Tuesday morning password resets — they all use it. The audit log on the client's tenant shows every action coming from helpdesk@client.com, regardless of which of your six techs actually performed it.

For the first dozen clients, this is fine. By client #25, problems are showing up:

• A compliance audit asks the client "who reset the CFO's password on March 14?" — and the audit log says helpdesk@client.com, which is nobody specifically.
• A tech leaves your shop, and rotating the credentials for the 30+ tenants they had access to is a multi-day operation that some clients won't process until weeks later.
• A phishing email targets helpdesk@client.com (the address is often discoverable). One compromised inbox compromises every client tenant simultaneously.
• The client's CTO asks for a "show me everything your team has done in our tenant this quarter" report and you cannot produce it accurately.

None of these are urgent until they happen. Then they're all urgent at once.

The four specific risks

Risk 1: Attribution

The audit log on the client's tenant doesn't say which of your techs took which action. From the client's compliance perspective, every action was taken by an opaque service account. When something goes wrong — a deleted user, a misconfigured policy, a leaked document — the investigation can't get past "an MSP tech did it."

For SOC 2 / ISO 27001 environments, this is a documented finding. Non-attributable admin actions are explicitly flagged by every modern audit framework.

Risk 2: Off-boarding

When a tech leaves your shop, you have to revoke their access to every client tenant they touched. With shared credentials, that means rotating the password on every tenant — and informing every other tech, and updating the shared password manager.

Most MSPs don't do this promptly. In a 2024 industry survey of MSPs with 10+ clients, 41% reported that ex-employees still had access to at least one client tenant 30 days after departure. The shared-credentials model makes this the default failure mode.

Risk 3: Phishing blast radius

A phishing campaign targeting helpdesk@client.com (or whatever your shared account convention is) has a multiplicative payoff. One successful compromise = full Global Admin access to every client tenant where that account exists. Attackers know this and target MSP-shaped infrastructure specifically.

The CISA advisories on MSP-related compromises (the LAPSUS$ attacks, the ConnectWise compromises, the Kaseya VSA incident) repeatedly highlight shared credentials as a key amplification factor. One credential, many tenants, massive blast radius.

Risk 4: Compliance audit burden

When the client moves to a regulated industry — healthcare, financial services, government contracting — your shared admin account becomes their audit problem. Their auditor asks for evidence that admin actions are individually attributable. You can't produce it. The audit timeline slips, the client gets nervous, and the conversation shifts from "you're our MSP" to "we're evaluating alternatives."

This isn't hypothetical. It's the single most common reason regulated SMBs migrate from generalist MSPs to security-specialist firms or in-house IT teams.

The replacement pattern: GDAP + per-tech delegation

The architecturally-clean answer comes in two layers:

Layer 1: Granular Delegated Admin Privileges (GDAP)

GDAP is Microsoft's modern replacement for the legacy "Delegated Admin Privileges" model that allowed CSP partners blanket Global Admin access to client tenants. With GDAP, you assign specific Entra ID roles to specific Entra ID security groups in your tenant. Members of those groups get the assigned roles in the client's tenant, scoped to the time window you specify.

The mechanics:

• Each of your techs has their own user account in your MSP's Entra ID tenant
• You create security groups by function (e.g., "L1 Helpdesk," "L2 Operations," "Senior Engineers")
• For each client, you accept a GDAP relationship that grants specific Entra ID roles (User Administrator, Helpdesk Administrator, etc.) to those specific groups
• Each tech signs into the client's tenant as themselves, using their MSP-tenant credentials
• The client's audit log records actions with the actual tech's identity, not a shared service account

The time-window scoping means delegated admin access expires automatically if not renewed, which prevents the "ex-employee still has access" problem from compounding.

The downside: GDAP scoping is at the Entra ID role level (User Administrator, Helpdesk Administrator), not the operation level. A tech with GDAP User Administrator access can do anything User Administrator allows, which — as we covered in Why the User Administrator role is the wrong answer for HR delegation — is still quite broad.

Layer 2: Delegation portal for client-facing operations

The operations you want to give to the client's staff (HR resetting passwords, office managers onboarding new hires, team leads managing Teams memberships) are a different problem. GDAP isn't designed for client-side delegation — it's for partner-side admin access.

For client-side operations, a delegation portal that wraps Graph and exposes role-tier-constrained operations is the cleaner answer. UserDesk for M365 is built for exactly this multi-tenant pattern:

• Each client tenant connects with its own admin consent — no shared credentials
• Per-tenant subscription and audit log isolation
• Your MSP can be an Admin in each client's portal (with full visibility and management) while the client's HR or office staff get Member or Viewer roles
• Tokens are per-user, OAuth-based — when a tech leaves your shop and their MSP-tenant account is disabled, their access to all client portals vanishes automatically

Combined, the two layers give you:

• Tech-attributable audit logs on every client tenant (via GDAP, signing in as themselves)
• Auto-revoked access when techs leave (via Entra ID group membership in your MSP tenant)
• Client staff doing routine work themselves without needing your queue
• Per-client billing and isolation that scales linearly with your client base

The off-ramp from shared credentials

If you're operating shared credentials today, the migration looks like this:

1. Audit your current state. List every client tenant. For each, what's the shared account, who has the credentials, when were they last rotated?
2. Set up GDAP for new client onboardings. Establish the security groups in your MSP tenant. New clients get GDAP from day one.
3. Migrate existing clients in priority order. Start with regulated clients (healthcare, financial services). Move to GDAP. Disable the old shared account. Document.
4. For client-staff operations, layer the delegation portal on top. The client's HR doesn't need GDAP — they need a portal account in the Member role.
5. Update your offboarding checklist so disabled MSP-tenant accounts automatically cut off all client access via group membership.

The work front-loads: setting up GDAP relationships with existing clients takes about 30 minutes per client, plus the documentation. The ongoing maintenance afterward is significantly lower than what you're doing today with shared credentials and quarterly rotation.

The financial case is straightforward: one shared-credential compromise costs $80K-$250K (per IBM's Cost of a Data Breach data on MSP-related incidents). Migrating 30 clients to GDAP costs you ~15 hours of senior tech time. The expected-value math is not subtle.

For the broader MSP positioning question — why some clients now require their MSP to use individual-credential models as a contract precondition — we covered the multi-tenant security architecture in the MSP positioning page.

See the multi-tenant delegation pattern: interactive demo at /demo. Sample tenant, no signup. Shows the per-tenant role model an MSP would use to onboard a new client.