Orphaned, dormant, and shared accounts

Accounts without a person

In December, Harbor Clinic's pharmacy manager works through a review of every account in the pharmacy system. Most rows carry a name the manager recognizes. One does not. The account jsmith2 can order controlled medication, last signed in during May, and matches no identity by employee number, email address, or name. Identities, accounts, and entitlements called this an uncorrelated account and said it needed investigating. Now someone has to do it.

An orphaned account is an account in an application that is not linked to any current identity. The person it belonged to may have left, it may never have belonged to anyone the identity system knows about, or the link to its real owner may have broken.

Orphans matter because every process in identity governance starts from an identity. The leaver process disables a person's accounts. A manager's review lists a person's access. An account linked to nobody is invisible to all of them. If someone still knows the password for jsmith2, they can order controlled medication, and no departure will ever disable the account and no manager will ever see it in a review.

Finding orphans

Harbor found jsmith2 because a person happened to look closely. Finding orphans reliably means reconciling each application's accounts against the authoritative identities they should belong to. As in Keeping systems in sync, reconciliation compares intended state with actual state, but here it starts from the application's side: take every account that exists and ask whose it is.

For each account, the identity system looks for a stable identifier stored on it, such as an employee number, a contractor register ID, or the identity ID, and tries to match it to a current person in the HR system or the contractor register. Where an older system holds only a login name and a display name, as the pharmacy system did, a match is a candidate until someone confirms it. The results fall into three groups. Matched accounts belong to a current person. Orphaned accounts exist in the application but match no current identity. Missing accounts are the reverse: a person the rules say should have an account, in an application that has none, which usually points to a provisioning step that failed.

Orphans have a few common causes. The first is a missed leaver: the leaver process disabled the person's other accounts but never reached this application, perhaps because a ticket was missed or a nightly file import failed. The second is an account created by hand: an administrator set it up directly in the application for a temporary worker, a test, or a supplier's engineer. Nothing links it to an identity, so nothing will ever remove it. The third is failed correlation: the account belongs to a current person, but the identifier on it is missing or wrong, so the match fails. Matching on names or email addresses makes this more likely, because both change.

That third cause is why a list of orphans is a list of questions, not a list of accounts to delete. For jsmith2, the answer came from the pharmacy's own rota and the account's creation date. In February 2026, the pharmacy hired an agency pharmacist to cover a vacancy for three months, and a pharmacy administrator created the account by hand, adding a 2 because jsmith was already taken. The agency pharmacist was never entered in the contractor register, so no identity or end date ever existed for that person. When the cover ended in May, there was no leaver event to send. An account made by hand, for a person no source knew about, could only ever be found by a reconciliation or by luck.

Accounts nobody uses

The same review turned up a different kind of problem. The account pmorales belongs to Pat Morales, a pharmacy technician who still works at Harbor, and it can receive controlled medication. It has not been used since July.

A dormant account belongs to a known person or purpose but has not been used for a long time. It is not orphaned, because someone is accountable for it. It is still a risk: access nobody uses is probably access nobody needs, and nobody would notice someone else using it.

The usual measure is the last sign-in, and a threshold turns it into an action. The threshold should follow risk. Harbor treats 45 days without use as dormant for accounts that can order or receive controlled medication, 90 days for most clinical systems, and longer for email and files. Thresholds need judgment as well: a relief nurse who covers two shifts a month can look dormant against a short threshold and still need the account.

When an account crosses its threshold, Harbor disables it rather than deleting it. Pat's manager confirms that Pat moved in July to the outpatient pharmacy at another site, which uses a different system, so pmorales is disabled. If Pat needs it again, re-enabling it takes minutes and the account's history is intact. Deletion comes later, if the account stays unused and nobody claims it.

Last sign-in can also mislead. The pharmacy's dispensing cabinets receive orders through an integration that uses the account svc-dispense. Nobody has signed in to it interactively since it was set up in June 2025, so a dormancy rule based on sign-ins flags it as unused for well over a year. In fact it calls the pharmacy system's API every few minutes with a token, and disabling it would stop the cabinets from receiving new orders. Accounts used through tokens, API keys, or long-lived sessions may rarely or never sign in. Before disabling an account as dormant, check its token and API activity as well as its sign-ins.

Shared and service accounts

Some accounts match no person and are not orphans either. Night staff in the pharmacy use an account called relief-pharm, sharing its password so whoever is on shift can sign in quickly. At the main site's reception desk, the scheduling login frontdesk stays open all day, with its password on a card in a drawer. A shared account is one used by more than one person.

The problem is accountability. When relief-pharm orders controlled medication at 03:10, the record says relief-pharm did it, not which pharmacist. One person's access cannot be removed on its own: when a night pharmacist leaves, the password they know still works until someone changes it for everyone. And the checks described in Separation of duties cannot tell whether the same person ordered and received a delivery when both actions came from the same account.

Governing a shared account starts with giving it an owner: a named person, here the night pharmacy lead, who answers for who knows the password, what the account can do, and whether it is still needed. Then, wherever possible, it should be replaced with individual accounts. People share logins because sharing is quick, and individual sign-in can be made quick too, for example with a badge tap or fast switching between users on a shared workstation. Where a shared login has to stay, as it might at reception, it should be able to do as little as possible and be reviewed regularly like any other account.

A service account is used by software rather than a person. svc-dispense is one. So is the account that connects pharmacy to patient records. These accounts are often essential, and they drift easily. The engineer who set one up moves on, the integration is replaced, and the account stays with all its access. Each service account needs an owner, a recorded purpose, and a regular review of whether it still needs what it holds. The pharmacy review found svc-labfeed, which carried results from a laboratory system Harbor retired in the spring. Its token was last used in March, and nobody is listed as its owner.

Built-in administrator accounts belong in the same category. The pharmacy system's administrator account, created at installation, belongs to no person and can do more than any other account in the system. It needs a named owner too, with its credentials stored securely and used only through the emergency process described in Temporary, privileged, and emergency access.

How service accounts should authenticate, and how their credentials are issued, stored, and replaced, is a question about workload identity rather than governance. The governance question comes first and is simpler: who answers for this account, and does it still need to exist?

What to do with what you find

A reconciliation produces findings, not deletions. The orphan might be a current person whose link failed. The dormant account might be an integration that runs on tokens. The shared login might be the only way the night shift can work this week. Deleting first and asking later turns a cleanup into an outage, and it destroys history that an investigation might need.

Harbor works through each finding in the same order.

1. Investigate who the account belonged to and what it does, using its creation date, its sign-in and API activity, and what the application owner knows.
2. Disable it, which stops its use without losing anything.
3. Notify the owner: the application owner and, where known, the person's former manager or sponsor.
4. Wait a defined period, such as 30 days, for anyone to claim it.
5. Delete it according to the clinic's retention rules.

The order bends when the risk is high. An account like jsmith2, which matches nobody, shows no API activity, and can order controlled medication, is disabled first and investigated afterwards, because disabling is easy to undo. What does not bend is that deletion waits until the investigation is finished. Every decision along the way is recorded with who made it, why, and when, including decisions to keep an account, so the next reconciliation does not raise the same question again.

Here are eight accounts from the pharmacy reconciliation, compared with the HR system and the contractor register.

Each finding also points to a cause worth fixing. lwong shows that the leaver process failed to reach the pharmacy system for at least one departure in August. jsmith2 shows that accounts could be created outside the identity system, so Harbor now requires every new pharmacy account to carry an employee number or a contractor register ID.

Every one of these decisions, like every review decision, leaves a record. Continue to Evidence and governance metrics to see what makes those records convincing to an auditor, and how to tell whether the whole process is working.