Orphaned Account: Definition, Risks, and How to Detect It

An orphaned account can give attackers and former employees a way into a company’s systems. Every time an employee leaves or a project ends, the chance of leaving another one behind grows.

In February 2024, cybersecurity agencies from five countries reported that hackers from Russia’s Foreign Intelligence Service (SVR) were targeting the accounts of former employees that remained on victims’ systems. The advisory also recommended disabling accounts that are no longer required and regularly reviewing inactive accounts.

This article explains what an orphaned account is and how it differs from a dormant account, then covers the types, causes, risks, and detection of these accounts.

What Is an Orphaned Account?

An orphaned account, also called an orphan account, is a user account that is still active in a system but no longer has a legitimate owner. The legitimate owner is the person or team responsible for the account, such as the employee who uses it or the manager who approved its access.

Accounts used by applications or vendors also need an owner inside the company, just like employee accounts.

Orphaned Account vs. Dormant Account

An orphaned account is judged by whether it has a legitimate owner, while a dormant account is judged by how long it has gone unused. A dormant account is one that has not been used to log in for a long time, whether or not its owner is still around.

Account ownership	Used regularly	Unused for a long time
Has a legitimate owner	Normal account	Dormant account only, such as the account of an employee on extended leave
Has no legitimate owner	Orphaned account only, such as an account that applications use to connect to each other, but whose creator has left and has no replacement	Both orphaned and dormant, such as the account of a former employee that nobody uses anymore

Ownership, not how often an account is used, decides whether it is orphaned. For that reason, last-login data alone is not enough to find orphaned accounts, because an account used every day can still have no owner.

Read also: Zombie Accounts in IAM: Threats and How to Prevent Them

Types of Orphaned Accounts and Examples

Orphaned accounts fall into five types by origin, namely former employee accounts, third-party accounts, service accounts, local accounts in non-SSO applications, and legacy project accounts. A non-SSO application is one that is not connected to a central login (single sign-on, or SSO), so it keeps its own list of users.

Type	Example	Why it is often missed
Former employee account	Email, remote access, and application accounts of employees who have resigned or retired	HR’s notice of the departure does not reach every team that manages an application
Third-party account	Accounts of vendors, contractors, or interns whose contracts have ended	Accounts are created without an end date and are not recorded in the employee data
Service account	Accounts that applications, scripts, or integrations use to connect to each other	No specific person owns it, and its creator has moved to another role or left
Local account in a non-SSO application	Accounts in SaaS (subscription-based software) applications or legacy systems that keep their own user lists	Offboarding (the process for departing employees) only reaches core systems such as email and the user directory
Legacy project account	Test accounts, migration accounts, or accounts inherited from an acquired company	Nobody feels responsible once the project is over

Former employee accounts are the easiest to trace because you can match them against HR data. Service accounts, third-party accounts, and legacy accounts are harder to trace because they do not appear in employee records, so an employee list alone is not enough.

Causes of Orphaned Accounts in a Company

Orphaned accounts appear when a change in someone’s status or in a project is not matched by a change to the related accounts in every system. Three conditions trigger this.

1. Manual and Delayed Offboarding

When offboarding is still manual, HR notifies the IT team by email or ticket. The IT team then often disables only the accounts in email and in the user directory, the central database that stores employee accounts.

Without a checklist that confirms everything has been revoked, accounts in other applications are left behind. A late notice from HR extends the time an account stays active, because the IT team acts only after it receives that notice.

2. Scattered Applications and Accounts

Departments often subscribe to their own SaaS applications, and each application keeps its list of users separately. When an employee leaves, accounts in applications that are not connected to a central login are not deactivated automatically.

The more applications departments buy without the IT team’s knowledge, the harder it is to confirm that a departing employee’s accounts are removed from all of them.

3. No Owner and No End Date

Service accounts and third-party accounts are often created in a hurry for a project, without recording who is responsible or when they should expire. When the creator changes roles or the project ends, the account stays active with nobody looking after it.

Mergers and system migrations add to the problem, because old user lists are often combined without being cleaned up first.

Risks of Orphaned Accounts for Security and the Business

Orphaned accounts are risky because someone can use them without an owner noticing unusual activity. The impact includes system breaches, excess access, audit findings, and wasted license costs.

An Entry Point for Attackers and Former Employees

In April 2021, hackers breached Colonial Pipeline, a US fuel pipeline operator, through a remote access (VPN) account that was unused but still active, said Mandiant’s Charles Carmakal. The account had no multi-factor authentication (MFA, a check beyond the password), so one compromised password was enough to get in.

An account with no owner is in the same position, still active and with nobody watching it. A former employee who still has an old password could use the account to download a customer list or delete data.

Excess Access and Outdated Security Policies

The last access rights a user held stay attached to an account with no owner, including administrator access for a former system manager. That access can pile up through privilege creep, which is old access that carries over when an employee changes roles.

Accounts created years ago can also miss new policies, such as a requirement to use MFA. Once attackers get in through such an account, they can move to other systems and raise their access rights for as long as nobody monitors the account.

Audit Findings and Legal Risk

In an access audit, auditors ask who owns an account and why its access is still needed. An account with no owner has no answer to those questions, so it is hard to justify.

If the account can reach personal data, the company risks violating Article 39(1) of Indonesia’s Personal Data Protection Law (UU PDP, Law Number 27 of 2022). That provision requires a personal data controller, meaning the party that determines the purposes of data processing and controls it, to prevent unauthorized access to personal data.

Violations can bring administrative sanctions, including a fine of up to 2 percent of annual income or revenue, based on the violation variable (Article 57 of UU PDP).

Wasted License Costs

SaaS applications billed per user usually keep counting an account for as long as it is active, even if nobody uses it. Leftover accounts raise the subscription bill and give the company nothing in return.

How to Detect Orphaned Accounts

You detect orphaned accounts by matching each system’s account list against the people who should own accounts, namely active employees and contractors, along with whoever owns each service account. An account with no match becomes a candidate for further review.

At the start, you can run these five steps without any special tool:

1. Export the list of active employees and contractors from the HR system, including contract end dates.
2. Export the account lists from the user directory, email, the VPN, and any application that stores customer or financial data.
3. Match the two lists, then mark accounts that have no owner in the HR data as candidates.
4. Add last-login data to tell long-unused accounts apart from accounts that are still in use but have no owner, such as service accounts.
5. Ask managers or application owners to verify each candidate, then record the decision (keep, deactivate, or assign a new owner).

Prioritize accounts with administrator rights and applications that hold customer or financial data, because misuse there causes the most damage.

If there are too many applications to match by hand, use an identity and access management (IAM) platform. An IAM platform manages user identities and access rights, including comparing HR data with the accounts in each application.

Read also: What is a User Access Review? Definition and Why It’s Important

Conclusion

An orphaned account is an active account with no legitimate owner, and it is risky because someone can use it to get in without being detected. The main causes are manual offboarding, scattered applications, and accounts created without a responsible person.

You can start this week by matching your list of active employees and contractors against the accounts in email, the VPN, and your most sensitive applications. The result shows which accounts need a new owner or should be deactivated.

FAQ