Accounts that belong to no one in particular
Most accounts are easy to reason about: a person signs in with their own identity and what they do is traced back to them. Two common kinds of accounts break that pattern.
A shared account is used by several people with the same credentials, such as a generic “reception” login or a shared mailbox password written on a sticky note. A service account is used by software rather than a person, for example by a backup tool that signs in each night, or an application that connects to a database.
Both are common, both are useful, and both are frequent sources of trouble because nobody feels personally responsible for them.
Why they are risky
Accountability disappears. If five people use one login and something is deleted, the logs show only the shared name. That makes investigation and, just as importantly, honest self-correction harder.
Departures leave a gap. When a person leaves, their own account can be switched off. A shared password they know stays valid unless someone remembers to change it. Because of this, shared accounts are one of the typical ways former staff retain access.
Passwords stay the same for years. Changing a service account password may break an application, so teams often avoid doing it. Old, unchanging passwords that appear in scripts and documentation are an attractive target.
Permissions tend to be too broad. Setting up a service account with administrator rights is the fast way to make something work, and the broad rights are rarely trimmed afterward.
No one notices unusual use. A person’s account that suddenly signs in from another country may be questioned. A service account doing odd things attracts less attention, partly because no one is watching it and partly because nobody knows what normal looks like. Recognizing compromised accounts is harder when a login has no clear owner to ask.
Start with an inventory
You cannot control what you have not listed. A practical first step is a simple register of every shared and service account, recording:
- what the account is for and which system it belongs to
- who is the named owner, a real person or team responsible for it
- who is permitted to use it
- what permissions it holds
- where its credentials are stored
- when its password or key was last changed
- when it was last reviewed
Finding them takes some detective work. Look at scheduled tasks, application configuration, database connections, and accounts with names like “admin,” “backup” or “svc.” Accounts that nobody can explain deserve particular attention. If an account’s purpose is unknown, a careful approach is to restrict or disable it in a controlled way and watch for complaints, rather than deleting it outright.
Reduce the need for sharing
For shared accounts, the strongest improvement is often to stop sharing. Give each person an individual account with the access they need. Many systems allow several people to access a shared mailbox or team resource using their own logins, which keeps accountability intact.
Where a shared login truly cannot be avoided, because a legacy system supports only one, compensate in other ways:
- store the credential in a password manager or similar secure vault rather than in a document
- record who checks it out and when, if the tool allows it
- change it whenever someone with knowledge of it leaves the team
- restrict where it can be used from
- add extra verification where the system supports it
Controlling service accounts
Give each service its own account. If one account runs ten applications, a compromise of one exposes all ten, and you cannot tell them apart in logs.
Apply least privilege. Work out the minimum the software needs and grant only that. A backup tool might need to read files but not change them. A reporting tool may need read access to one database, not to all of them.
Prevent interactive sign-in where possible. If a service account is only meant for software, configure it so a person cannot simply log in at a keyboard with it.
Protect and rotate credentials. Keep secrets in a managed secret store instead of plain text inside scripts or configuration files. Plan rotation on a schedule that you can actually carry out, and test it in a non-critical setting first, since changing a password may interrupt a dependent service.
Prefer stronger mechanisms. Where available, certificates, keys or short-lived tokens issued automatically are generally safer than a fixed password that sits unchanged for years.
Monitor behavior. Decide what normal looks like, such as which servers it connects to and what times it runs, and alert on departures from that. Reviewing system logs for these accounts occasionally often reveals forgotten activity.
Give every account an owner
An owner is a person or team who answers for the account: confirms it is still needed, approves any permission changes, and takes action when its password must be rotated. When an owner leaves or changes role, ownership must be reassigned as part of account offboarding, otherwise accounts gradually become orphaned.
Include these accounts in regular access reviews too. Ask whether each one is still used, whether its permissions are still needed, and whether the owner is still correct. Dormant ones are strong candidates for disabling.
A realistic approach
You will rarely clean everything at once. A sensible order is to list the accounts, fix the highest-risk ones first (those with administrator rights or access to sensitive data), assign owners, move credentials into a secure store, and then work through the rest. Document your decisions in your IT policies so that new accounts follow the same rules from the start.
Perfect control is not realistic, but moving from unknown accounts with unknown owners to a known list with named owners and limited permissions is a meaningful reduction in risk.