The Accounts Nobody Uses Are the Ones Attackers Want: Cleaning Up Dormant Identities in Entra ID

Open any client tenant, sort users by last sign-in, and you will find people who have not touched Microsoft 365 in months. Some of them still hold licenses. A few of them still hold admin roles. Every one of them is a working credential that nobody is watching.

That is how a real incident played out earlier in 2026. A former MSP employee's partner account was still enabled, and still privileged, inside a client tenant long after that person left. Attackers got hold of the credentials, used the account to move through the environment, and the client ended up with a data breach and ransomware.

The business relationship changed. The access did not. Dormant accounts are a security problem first, and a cost problem right behind it, because you are usually paying for licenses on identities nobody uses. Below we cover what counts as dormant, which accounts actually matter, how to find them in Microsoft Entra ID, and how to stop them from piling up again.

Where do dormant accounts come from?#

A dormant account is an identity that still exists in your environment but has not been used for a meaningful period of time. We use 45 days without a sign-in as the point to start investigating. Nearly all of them trace back to one of four sources:

1. Former employees. The person leaves, and the account never gets disabled or cleaned up.
2. Contractors. Project access is granted, the engagement ends, and nobody owns the cleanup.
3. Guests and partners. A vendor or outside collaborator is invited into Teams or SharePoint, and the guest identity remains after the engagement is over.
4. Legacy service identities. An old app, script, or scheduled task still relies on a user-based account, so it stays in place.

In each case the business moved on and the identity did not. That is why we treat dormant account reviews as identity lifecycle checks, not one-off cleanup projects.

Forgotten access keeps showing up in real breaches#

This is not a hypothetical risk. Four recent cases follow the same pattern:

1. Former employee admin account (CISA, 2024). A former employee's account stayed active and was later compromised. The vector was a dormant privileged user. The result was initial access, privilege abuse, and broader compromise.
2. MSP partner account (Kudelski Security, INC Ransomware, 2026). A former MSP employee's partner account stayed active for more than two years and was used in an attack. The vector was a trusted external account plus VPN access. The result was lateral movement, 410 GB of data exfiltrated, and ransomware.
3. Former engineer signing key (Coupang). A former engineer kept a signing key after leaving and used it to generate authentication tokens. The result was unauthorized access and customer data exposure.
4. Former employee repository access (Apple allegation). A former employee allegedly kept or regained access to an internal repository and downloaded confidential files. The exposure was intellectual property theft and confidential file exfiltration.

In Microsoft 365 the same risk shows up as stale guests, dormant admins, legacy service accounts, lingering mailbox or app access, and licenses nobody needs.

Sources:

• CISA advisory AA24-046A: threat actor leverages compromised account of former employee (opens in new tab)
• Kudelski Security: No zero days needed, how five hygiene failures handed ransomware operators the keys (opens in new tab)
• Coupang: response to the JIT report on the November 2025 data incident (opens in new tab)
• TechCrunch: Apple says former employee exploited rare bug to download confidential files (opens in new tab)

Which inactive accounts are actually fine?#

Some inactivity is expected. The job is to separate legitimate, controlled inactivity from the accounts nobody can explain.

• Break-glass accounts. Emergency admin accounts should rarely be used, so low activity is normal. They should still be documented and monitored.
• Service accounts. Some legacy apps, scripts, and scheduled tasks still run on user-based identities. Find out what owns the account and whether it should still exist.
• Shared mailboxes. These have an underlying user object, but direct sign-in should generally be disabled. Inactive and disabled is often the correct state.
• Already disabled users. Accounts that were properly offboarded and blocked from sign-in will look dormant, but they are lower priority.

A simple rule covers most of it. Dormant, expected, and controlled is probably fine. Dormant, enabled, and unexplained gets investigated.

How do you find dormant users in Microsoft Entra ID?#

For a single tenant, the Microsoft Entra admin center gets you there with no scripts:

1. Check one user. Go to Entra ID > Users, select the user, and review the sign-in activity on their Overview page.
2. Filter the whole list. Back on All users, select Add filter and choose Last interactive sign-in time. Set it to on or before a date 45 days ago.
3. Limit it to enabled accounts. Add a second filter for Account enabled == Yes. Switch it to No to see which accounts are already blocked and lower priority.
4. Watch the licenses. Keep the Assigned licenses column visible so dormant accounts that are still costing money stand out.
5. Export for review. Use Download users to pull the filtered results into a CSV.
6. Repeat for non-interactive sign-ins. Run the same process with Last non-interactive sign-in time, so you do not miss accounts that apps or tokens are still using behind the scenes.

Classify every account before you delete it#

Do not delete everything older than 90 days. Put each dormant account through four questions first:

1. Is the account already disabled? If yes, it is lower priority. Confirm whether it needs to remain for retention, an investigation, or another business reason. If no, keep investigating.
2. Is the inactivity expected? Break-glass accounts, service identities, and extended leave are the usual examples. If yes, document and monitor it with a record of the reason, the owner, and a review date. If no, continue.
3. Does the person or account still need access? Consider the account type: former employee, contractor, guest, or partner. If yes, keep it documented, confirm ownership, and set a future review date. If no, disable sign-in first, then follow your normal offboarding, retention, mailbox, and data-transfer process before deleting anything.
4. Why did this happen? Fix the lifecycle process that created the dormant account, whether that is employee offboarding, guest access reviews, contractor ownership, or service account modernization.

The full loop is find, classify, disable or remediate, then fix the lifecycle. Then keep monitoring, because new dormant accounts will show up. For the guest side of that lifecycle, see our guide to locking down guest access in Microsoft 365.

Doing this across every client tenant#

The Entra admin center works one tenant at a time. For an MSP managing dozens of clients, that does not scale, and it is why most tenants carry more dormant accounts than anyone realizes. This is what we built CloudCapsule to handle.

Dormant users per tenant. Every tenant flags accounts with no sign-in for more than 45 days, along with role, user type, and licenses, so a dormant Global Administrator stands out immediately.

Approved exclusions. Mark accounts like conference rooms and break-glass users as approved exclusions so they stop cluttering the list.

License optimization. Total users, unused licenses, and licensed shared mailboxes sit in one view, so cleanup ties directly to cost savings.

Cross-tenant search. Search for a metric like dormant users and see the count for every client at once.

Scheduled digests. Daily, weekly, or monthly digests alert you when dormant users, new global admins, or break-glass changes appear.

Two costs, one fix#

Dormant accounts are an identity lifecycle problem that costs you twice, once in security exposure and again in wasted licenses. Find them, classify them before you delete anything, disable what is not needed, and fix the process that created them in the first place.