Service Accounts: The Privileged Users Nobody Owns

Every organisation has users who never appear in the HR system. They run the overnight backup, move files between the ERP and the bank, sync the directory with the cloud, scan the network for vulnerabilities and call APIs between applications. They are service accounts: identities used by software rather than people.

In most environments they outnumber human administrators, and many hold more power. A single account used by the backup platform can often read every file on every server. An integration account may be able to create payments. And because no person logs in with them day to day, they quietly fall outside the controls built for people.

Attackers know this. A stolen service account password rarely triggers an alert, rarely expires and rarely belongs to anyone who would notice it being misused.

Why they escape control

No owner

A service account is usually created by an engineer during a project. The project ends, the engineer moves on, and the account stays. Ask who owns it and the answer is often a team name, a vendor, or silence. Without an owner, nobody can say whether the access is still needed.

Passwords that never change

Rotating a service account password can break the application that uses it, so it is set to never expire and left alone for years. The same password is often written in configuration files, scripts and runbooks, and known by people who left long ago.

Far more rights than needed

When an installation fails, the quickest fix is to make the account an administrator. It works, the project goes live, and the rights are never reduced. Domain administrator rights for a reporting tool are more common than anyone would like to admit.

Humans borrowing them

Because these accounts are powerful and shared, people use them to log in interactively when something urgent needs doing. Every action then appears under the service account's name, and accountability disappears.

Invisible to the access review

Quarterly access reviews ask managers to confirm their staff's access. Service accounts have no manager, so they are left off the list or approved without a second thought.

An account nobody owns is an account nobody will notice being misused.

Bringing them under management

1. Build the inventory

Find service accounts in the directory, on servers, in databases, in cloud platforms and in SaaS integrations, including API keys and tokens. Agree a naming convention so new ones are recognisable at a glance.

2. Give every account a named owner and a purpose

Each account should have a person accountable for it and a one line description of what it does and which system uses it. Accounts nobody claims should be disabled, watched for a few weeks to see what breaks, and then removed.

3. Cut the rights down

Grant only what the job needs. Separate accounts for separate applications, so one compromise does not open everything. Remove membership of administrator groups unless there is a documented reason.

4. Stop humans logging in with them

Deny interactive and remote logon wherever the platform allows it, and alert when it happens anyway. People who need elevated access should use their own named privileged accounts.

5. Manage the secrets

Use platform features that rotate passwords automatically, such as group managed service accounts in Windows environments, or managed identities in the cloud. Where that is not possible, store credentials in a password vault, rotate them on a schedule and take them out of scripts.

6. Watch their behaviour

A service account should behave predictably: the same servers, the same times, the same actions. Logins from a new machine, at an unusual hour or interactively are worth an alert.

What auditors should test

Completeness. Compare the inventory with accounts extracted from the directory and key systems. Look for accounts set to never expire.
Ownership. Pick a sample and ask the named owner what the account does. Hesitation is a finding.
Privilege. List service accounts in administrator groups and ask for the justification.
Password age. Report the last password change date. Years old is common, and telling.
Interactive use. Check logon events for service accounts used from people's workstations.
Leavers. Find accounts whose creator or owner has left the organisation.

Four questions for leadership

How many service accounts do we have, and how many have administrator rights?
Does every one of them have a named owner who could explain it today?
When was the oldest service account password last changed?
Would we notice if one of them logged in from somewhere new tonight?

Service accounts are not a niche technical issue. They are privileged users with no manager, no leave and no exit date, and that combination makes them one of the easiest ways into an organisation. Give each one an owner, cut it down to what it needs and keep its secrets out of scripts, and one of the quietest risks in the environment becomes one of the best controlled.