Orphaned Accounts in Entra ID: Finding Accounts Nobody Owns
The account from 2022
You're doing a quarterly review. You spot an account. "[email protected]." Created in 2022. Last sign-in: never. Owner field: empty. Description field: blank.
Nobody on your team recognizes it. The person who probably created it left the company two managers ago.
That's an orphaned account. The account exists. The credentials exist. The permissions exist. But there's no human who can answer "should this still be here."
Orphaned accounts are not the same as access creep. Access creep is when a real user has too much access. Orphaned is when an account has no real user behind it at all.
Where they come from
Three common origins.
Service accounts. Somebody set up an integration, created a "user" account for it (because the tool didn't support service principals), and moved on. The integration may still be running. It may not. The account is still there either way.
Test accounts. Someone needed to test a Conditional Access policy. Created "[email protected]." Forgot to delete it. Multiply by every IT engineer who's been at the company.
Contractor accounts. External user (or full Entra account, depending on how it was set up) for a consultant. The project ended. The contractor left. Nobody disabled the account.
Each of these has a slightly different cleanup story, but they all leave the same residue. A credential nobody is monitoring, attached to permissions nobody remembers granting.
Why they matter
Orphaned accounts are an attacker's favorite target. Three reasons.
No one will notice when they're compromised. A real user account that gets phished triggers behavioral signals. Login from an unusual location. New device. The user themselves notices weird emails being sent. None of that happens with an orphaned account. The "user" never logs in normally, so anomalous activity doesn't look anomalous.
They often have stale credentials. Password rotation policies don't apply if there's no human reading the policy. Service accounts especially tend to have long-lived passwords that haven't changed since 2022.
They sometimes have privileged access. The integration that needed Global Admin three years ago still has Global Admin. The contractor who needed contributor access on a subscription still has it.
NIS2 and ISO 27001 both treat orphaned accounts as a control failure. SOC 2 will flag them in a sample.
How to find them in Entra ID
Three queries that find most orphaned accounts:
Accounts with no sign-in for 180+ days. In the Entra ID portal, go to Users, then All users, and add filters for sign-in activity. Microsoft Graph PowerShell makes this faster. Anything that hasn't signed in for half a year is suspect.
Accounts with no manager attribute. Real employees have managers (assuming HR data is decent). Accounts with no manager attribute set are usually service accounts, test accounts, or stragglers.
Accounts that match no dynamic group rule. If your dynamic groups are based on department or job title, watch for accounts that match no rule. Those are usually not real employees.
Cross-reference the three lists. Anything that shows up on all three is almost certainly orphaned. Anything on two of three deserves a closer look.
What to do with what you find
Three buckets.
Confirmed orphaned, low-risk. Disable the account. Wait 30 days. If nothing breaks, delete it.
Confirmed orphaned, possibly active integration. Don't just disable. First, check whether anything is calling into it. Audit logs in Entra ID show recent sign-ins, even if the user-facing data says "never." If there's traffic, find the integration, migrate it to a proper service principal, then disable the user account.
Unclear. Assign an owner. Pick a human. Put their name in the description field. Make them responsible for confirming whether the account stays or goes within 30 days. If nobody volunteers to own it, that's your answer.
The temptation is to clean up everything aggressively in one Friday afternoon. Don't. Disable in batches. Watch for breakage. Production-critical integrations sometimes live behind orphaned-looking accounts.
Prevent the next round
Three rules that stop the orphan problem from recreating itself.
Service accounts go to service principals or managed identities, not user accounts. Microsoft's Graph API supports service principals for almost everything modern. The "create a user account because it's easier" habit is a major source of future orphans.
Every account has an owner attribute. Manually set if needed. An empty owner field means the account doesn't exist as far as your hygiene process is concerned.
Quarterly orphan scan. Add it to the same cadence as your access reviews. Fifteen minutes once a quarter prevents the slow build that takes a week to clean up later.
Where Adcyma fits
Full transparency: this is our product. Adcyma flags accounts that look orphaned based on sign-in history, group memberships, and ownership data. We don't do anything drastic, just surface them so you can make a call. Free for up to 25 users.