Skip to content
Start with Identity
Join free
SWI-T015 · Identity lifecycle

Orphaned account abuse

An account left active after its owner departed or its purpose ended draws no attention from anyone, because no one owns it, no one expects a login from it, and no one is watching for one.

WidespreadHard to detect
First observed: 2010ATT&CK T1078 ↗

How it works

An orphaned account is an active account, credential or grant with no valid owner. It is left behind when an employee departs, a contractor's engagement ends, a project finishes, or a system is retired but its login is not. The account does not need to be a user in the directory. The most dangerous orphans are often one layer down: a VPN profile, a local admin on an appliance, a test tenant, a SaaS account bought on a corporate card, a service account created by hand for a migration, or a personal access token or OAuth grant that outlives the person who created it.

The gap comes from how deprovisioning is wired. A typical joiner-mover-leaver process fires off an HR termination event, which disables the identity provider account and, through SCIM, the applications connected to it. That works for accounts inside single sign-on. It does not reach:

  • applications with local logins that were never connected to the identity provider;
  • tokens the user already minted, such as GitHub personal access tokens, OAuth refresh tokens held by integrations, and API keys, which often keep working after the directory account is disabled;
  • non-human accounts, which have no HR record and therefore no termination event;
  • deliberate exceptions, such as "keep his access for two weeks so he can finish the handover", that nobody closes.

An attacker who obtains credentials for one of these accounts, through a prior breach, an infostealer log, a password spray, or an insider who still remembers their own password, logs in as an account nobody is checking on. There is no owner to notice unfamiliar activity, no scheduled access review that would catch it because the account may not be in the population that review covers, and frequently no MFA enrollment because the account was set up before MFA was mandatory and never revisited.

Why it works

Identity governance assumes every active account has an accountable human or a documented business owner who would notice anomalous use. The control assumption that fails is coverage: deprovisioning automation only reaches the systems and credential types it is wired into, and any account outside that wiring persists exactly as it was left. The account is not weak in any technical sense. It is simply unobserved, and every detection built on "the owner would notice" or "the manager would reject it in review" has nobody to ask.

There is also a perverse incentive. Disabling an account that turns out to be in use breaks something visible, while leaving an unused account active costs nothing until the day it is abused. Without an explicit rule that unowned means disabled, cleanup loses that trade every time. Attackers do not need a sophisticated technique here; they need patience to find the accounts that fell outside the reconciliation process, because those accounts inherit none of the monitoring built around the accounts that did not.

How to detect it

  • Reconcile against an authoritative source. Match every active account in every system against HR records for people and an owned inventory for service accounts, and flag anything with no match. This is a recurring job, not a one-time cleanup.
  • Last-use data, per system. In Microsoft Entra ID, the user signInActivity property exposes lastSignInDateTime, lastNonInteractiveSignInDateTime and lastSuccessfulSignInDateTime, which is how Microsoft documents finding inactive accounts. In AWS, the IAM credential report lists password_enabled, password_last_used, mfa_active and access_key_1_last_used_date per IAM user, and IAM Access Analyzer can generate unused access findings across an organization. Google Workspace exposes lastLoginTime on the Directory API user resource, and Okta exposes lastLogin on the user object.
  • Dormant accounts that wake up. A successful sign-in from an account with no activity in the preceding several months, especially from an unfamiliar IP or ASN. In AWS CloudTrail, a ConsoleLogin success for a user whose credential report shows months of inactivity; in Entra, a sign-in for a user whose previous lastSuccessfulSignInDateTime was long ago.
  • Activity after termination. Any authentication or API call by an identity after its owner's HR termination date, including token use in systems the IdP does not control. Okta's user.lifecycle.deactivate and user.lifecycle.suspend events give the offboarding timestamp to correlate against.
  • MFA exclusions. Accounts excluded from MFA policy correlate strongly with accounts that predate current identity standards. Review the exclusion list, not only the policy.

Be honest about the limits: a full reconciliation catches only what it is pointed at, and systems outside SSO are precisely the ones least likely to be in scope. Last-sign-in fields measure interactive or directory-level use, not use of a personal access token or an integration's refresh token, so an account can look dormant while its token is busy. Service accounts used once a quarter look orphaned and are not. This is a coverage problem before it is a detection problem; the account has to be discoverable before it can be flagged.

How to stop it

  • Revoke tokens and grants on the last day, not just the account. Offboarding must remove organization membership, personal access tokens, OAuth grants and API keys, not only disable the directory user. The secure offboarding checklist covers the sequence.
  • Time-box every exception. Access kept open for a leaver gets an expiry date and a named approver, with monitoring until it closes.
  • Extend deprovisioning beyond SSO to appliances, VPN profiles, local admin accounts, and any application procured outside central IT. Connect what you can with SCIM; inventory the rest.
  • Give every non-human account an owner and an expiry. Set expiration on service and project accounts by default, so an account created for a purpose does not silently outlive it. See what is a non-human identity.
  • Include every system in access certification, not only applications integrated with the identity provider, and disable accounts with no confirmed owner rather than queueing them. The access review checklist and the user lifecycle management guide cover the process.
  • Enforce MFA on every login path, so an orphan found by an attacker still needs a second factor nobody has.

Seen in the wild

The Identity Breach Report 2026 found 13 of 123 incidents in which the abused credential should already have been revoked, rotated or expired, steady across periods at 3, 5 and 5. Its fourth-ranked control, killing credentials on departure, retirement and every upstream breach, addresses 18 incidents. The clearest test-account case is Data Cymru: the UK ICO found ransomware entered in November 2024 through "Test2", a test account created in 2012 with the password "Password1" that nobody had reviewed or removed. The TeamFiltration spray shows the adjacent case: the seven accounts it compromised were unowned functional and service accounts on default passwords.

Sources

Related identity CVEs and breaches

Last reviewed By SWI Community TeamSuggest a correctionHow we research

In the Identity Breach Database

Real incidents in our sourced breach database where this technique was used.

Browse the full database

Seeing this technique used differently, or have a detection rule that works better? Email community@startwithidentity.com. See all briefs in the technique catalog, or volunteer as a CVE Analyst.
Mapped to MITRE ATT&CK where a technique ID exists. Independent, community-driven analysis, not a substitute for the ATT&CK knowledge base. See the disclaimer.