Service Accounts

Human privileged access is the visible problem. Service accounts are the larger one and the reason PAM programmes take years.

Why they are worse

More numerous. Frequently by a wide margin.

Broader rights, because it was easier to grant domain administrator than to work out the minimum.

Static credentials, unchanged since creation, because rotating them breaks things.

No owner. The person who created it left.

Unknown dependencies. Nobody can say what will fail if the password changes.

Excluded from reviews, because access review processes are designed around people.

No attribution, by definition.

Finding them

Windows services running as a domain account rather than as a system identity.

Scheduled tasks with stored credentials.

Application configuration files and connection strings.

Pipeline and automation variables.

Accounts with old creation dates and no interactive logon history, which is a useful heuristic against the directory.

Accounts whose name follows a service naming convention, and the ones that do not, which are harder.

Ask the teams, which finds the ones no scan does.

Mapping dependencies

The blocking problem for rotation, and it has a method.

Enable authentication logging for the account.

Run for a period long enough to catch monthly and quarterly jobs — a full quarter is not excessive.

Collect the source hosts and processes that authenticate.

Build the dependency list, and expect it to be incomplete anyway.

Then rotate in a maintenance window, with the list to hand and a rollback ready.

This is the work. There is no shortcut and no product removes it.

Reducing the rights

Frequently more valuable than rotating.

Determine what the account actually needs, by observing rather than by reading documentation.

Remove domain administrative rights from anything that does not require them, which is most of them.

Scope to specific hosts where the platform allows.

Deny interactive logon, which is a cheap and effective control that almost no service account needs and almost all of them have.

Deny network logon from workstations, so a captured credential cannot be used from a compromised endpoint.

The better end state

Managed service accounts where the platform provides them, with automatic password management.

Workload identity in cloud environments, where the platform issues short-lived credentials to a running workload with no stored secret at all.

Certificate authentication rather than passwords.

Dynamic secrets from a secrets manager, issued per use with a short lifetime.

Each of these removes the static credential entirely, which is a better outcome than rotating one.

The realistic programme

Inventory, which takes weeks.

Classify by tier, and address tier zero first.

Reduce rights, which is lower risk than rotating and delivers more.

Assign owners, which is what makes the rest possible.

Deny interactive logon across the population, which is a single sweeping change with a real effect.

Then rotate, account by account, with dependency mapping, over a long period.

Then migrate to managed or dynamic identities as systems are touched for other reasons.

Expect years, and sequence it so that value arrives early.

Denying interactive logon

A single sweeping change with a real effect and low risk.

Service accounts should never log on interactively. Almost none need to and almost all can.

Apply the restriction across the population, by policy rather than per account.

Also deny network logon from workstations, so a credential captured on an endpoint cannot be used from there.

Alert on any service account authenticating interactively, which is then a strong signal rather than noise.

Test on a subset first, because a small number will turn out to have a legitimate interactive use that needs a different arrangement.

Assigning owners

The field that makes every subsequent review possible, and the hardest to populate.

Start from what authenticates. The dependency log names the source hosts, and the hosts have owners.

Start from the creator, where the directory records it.

Start from the naming convention, where one exists.

Where no owner can be found, publish the list and give teams a period to claim. Unclaimed accounts are then candidates for disablement, which produces owners quickly.

Record ownership transfer in offboarding, or the field decays within two years.