The ghost admin: seven roles, zero MFA.
A forgotten .onmicrosoft.com account became the highest-blast-radius credential in a Microsoft 365 tenant nobody watched, holding seven roles and zero MFA.
Every M365 tenant starts the same way: a .onmicrosoft.com domain and exactly one account that owns everything. The tenant’s first Global Admin. Microsoft uses this account to set things up, and then — in theory — the customer creates real, named, MFA-protected admin accounts and either disables this one or restricts it to break-glass duty.
In theory.
In practice, our risk assessment found a customer where that initial .onmicrosoft.com account still existed, still had its original credentials, and held seven directory roles. It had zero MFA factors registered. It had been used to sign in within the last 30 days.
Nobody on the IT team knew the account existed.
How it got there
The original IT consultant who set up the tenant six years ago had used the .onmicrosoft.com admin for the initial configuration — which is exactly what Microsoft’s setup wizard tells you to do. Then they created two named admins for the customer, transferred the relevant roles, and moved on.
What they didn’t do: disable or de-privilege the original .onmicrosoft.com account. They left it as a “backup,” logged out, and the next consultant inherited a tenant they assumed was clean.
Over the next six years:
- The two named admins came and went (three different IT shops total)
- Each shop added their own roles to “make troubleshooting easier”
- The
.onmicrosoft.comcredentials got passed forward — sometimes verbally, sometimes in a shared password vault, sometimes just left in the original setup notes - Nobody enforced MFA on it because nobody remembered it was there
By the time we ran our assessment, the account held:
- Global Administrator
- User Administrator
- Helpdesk Administrator
- Exchange Administrator
- Application Administrator
- SharePoint Administrator
- Password Administrator
A single credential compromise = full tenant access. No MFA challenge. No second factor. The phishing page just needs the password.
How we surfaced it
The check is mechanical. Pull every account from Microsoft Graph:
GET /users?$filter=endsWith(userPrincipalName, '.onmicrosoft.com')
Cross-reference each result against:
GET /directoryRoles?$expand=members
Any .onmicrosoft.com account with role memberships is a finding. Add the MFA registration check via /reports/authenticationMethods/userRegistrationDetails and any of those that come back with isMfaRegistered: false is a critical finding.
Total time to scan a tenant for this pattern: about 4 seconds.
Why this matters
The .onmicrosoft.com admin is the single most common “ghost admin” we find. Reasons:
- It’s there at tenant creation. Nobody actively creates it — Microsoft does.
- The IT team that inherits the tenant later didn’t make it, so they’re not sure if disabling it will break anything.
- Its UPN doesn’t match the company’s domain, so it doesn’t show up in casual reviews — admins scan the user list for
@company.com, not@company.onmicrosoft.com. - It often has the same display name as the original setup admin who left years ago, so nobody recognizes it.
What you can check in your own tenant today
- List every account on your
.onmicrosoft.comdomain. (Entra portal → Users → filter by domain) - Check role memberships on each one.
- Check MFA registration state on each one.
- For any with role memberships: - Either disable the account entirely (recommended), or - Strip the roles, register a FIDO2 key, and document it as break-glass
If you’re going to keep one .onmicrosoft.com account as break-glass:
- One per tenant, not seven
- FIDO2 security key (hardware) — not SMS, not Authenticator
- Conditional Access exclusion that’s audit-logged on every use
- Password stored in a physical safe, not a password manager
- Tested quarterly, used annually at most
The broader lesson
Tenant hygiene drifts over time. The IT team that’s running your tenant today is rarely the team that set it up. Every transition (vendor, consultant, internal hire) is an opportunity for ghost accounts, orphan roles, and forgotten exclusions to accumulate.
A privileged-access review is cheap to run and surfaces problems nobody is looking for. Our assessment does it automatically in under a minute. Yours doesn’t have to come from us — but it should come from somewhere.
The account with the most power in your tenant is the one nobody remembers exists.
Anonymized per our marketing policy. No identifying organization details retained.
Run the free Envyously Risk Score → — see every privileged role assignment in your tenant + which ones aren’t MFA-protected, in about six minutes via OAuth.