Stop Sharing Your Microsoft 365 Global Admin Account (Before It Costs You a Client)

Picture this. A technician opens the team password manager, copies the login for admin365@company.com, and signs into a client’s Microsoft 365 tenant. The MFA code is sitting right there in the vault for anyone on the team to grab.

It’s fast. It’s easy. And it’s one of the biggest security risks in the MSP world today.

A lot of teams run like this to avoid the hassle of setting up individual accounts. The thinking goes: “We’ve got a password manager and MFA, so we’re covered.” You’re not. A shared global admin account is a single point of failure that can take down every client you look after.

Here’s why it fails, and what to do instead.

Why shared global admin accounts are a problem

Global admin is the most powerful role in a Microsoft 365 tenant. It can read any mailbox, delete any file, and change any security setting. The moment you hand that power to a shared login, you lose all control over who’s actually doing what.

You lose accountability. When five people use the same login, the audit log only ever shows “Admin.” If a critical folder gets deleted or MFA gets switched off, you can’t tell whether it was Jason, Dave, or the new starter.

Now imagine a client finds out sensitive payroll data was accessed by someone who shouldn’t have seen it. You check the logs and see the global admin account signed in at 2 AM. But the whole team knows that password — so you have no way of proving who was behind the keyboard. Internal investigations become impossible, and insider threats become invisible.

Shared MFA isn’t real MFA. Most teams feel safe because there’s MFA on the account. But if the one-time passcode lives in a shared vault, it’s just a second password that everyone knows. If an attacker gets into that vault, they get the password and the code — and total control over every tenant you manage.

Admin accounts need phishing-resistant MFA. Standard codes can be stolen through a convincing phishing page or a quick phone call.

Building an identity setup you can actually trust

The fix is simple in principle: tie every identity to a real person, and get rid of shared secrets.

Give every engineer their own admin account. Each engineer gets a unique, cloud-only admin account that lives in your MSP tenant, not the client’s. It’s a dedicated identity used only for admin work.

This instantly restores your audit trail. Change a setting and the log shows your name. Someone leaves the company? You revoke their access in seconds — no scrambling to reset a password the whole team relies on.

Use phishing-resistant MFA. For high-privilege accounts, standard MFA no longer cuts it. Use FIDO2 security keys or passkeys. These bind the login to real hardware and the specific website, so nobody can be tricked into handing over access down the phone. The physical key has to be present — full stop.

Manage client tenants with GDAP. Stop dropping direct credentials into client tenants. Use Granular Delegated Admin Privileges (GDAP) instead. Your engineers use their own identities to manage client environments, with scoped permissions only the access they need for the job in front of them. Everything is audited through your MSP identity, and the “admin365” account disappears entirely.

Keep tenant credentials off client devices

There’s another dangerous habit worth calling out: remoting into a client’s machine and signing in as global admin. It’s quick, but every time those credentials touch a workstation, they’re at risk.

If that device is compromised, an attacker can scrape the credentials straight from memory. Suddenly they don’t just have one laptop, they have the keys to the entire tenant. One malware infection becomes a full company breach.

Use Windows LAPS. Windows Local Administrator Password Solution creates a dedicated local admin account on every device, each with its own unique, complex password. Those passwords rotate automatically and sit securely in Entra ID. When an engineer needs local admin rights, they pull the LAPS password from Intune or their RMM tool, do the job, and the password rotates. Your global admin account never touches the machine.

Lock down local admin groups with Intune. Pair LAPS with an account protection policy in Intune. Set it so only the LAPS-managed account sits in the local administrators group, no standard user, no shared admin, no global admin. That way, no high-level credentials ever live on the endpoint, and attackers have nothing to escalate to.

Where to start

Changing how you manage accounts feels like a big job. But sticking with shared logins is the bigger gamble. Start by auditing what you’ve got. Ask yourself:

• How many people use the shared global admin account?
• Where are the OTP codes stored?
• Who has global admin rights across all clients?
• Do those people actually need that access every day?

The answers might make you wince. That’s the point.

Then roll it out in phases: set up named accounts for your team first, move clients onto GDAP, and finally deploy LAPS and Intune policies to clean up your endpoints.

Final thought

Your clients trust you with the keys to their entire business. Leaving those keys in a shared vault is like leaving them in a hallway under a sign that says “Passwords.” It’s a gamble that eventually fails.

Named identities, phishing-resistant MFA, and GDAP protect your clients and your own business. Add Windows LAPS on top, and a single compromised laptop no longer turns into a full tenant takeover.

Audit your setup today. Build it around security, not convenience.