What Is Service Account?

A service account is a non-human identity used by an application, script or system to authenticate. They typically outnumber human accounts substantially and are governed far less rigorously, which makes them one of the largest quiet exposures in most estates.

They have no manager, no onboarding process, no departure date and frequently no owner. Nobody notices when one stops being needed, because nothing breaks when an unused account remains active.

Why they accumulate privilege

Service accounts are created under deployment pressure. The installation guide says the account needs certain rights, narrowing them requires testing nobody has time for, and granting broad permissions makes the deployment work.

That decision persists for the life of the system. Years later the account still holds domain administrator rights it was granted because the installer suggested it, and nobody is certain what would break if they were removed.

The credential problems

Passwords that never change, because rotation requires knowing every system that uses the credential and coordinating a change across all of them. Credentials stored in configuration files, scripts and scheduled tasks where many people can read them. And the same credential shared across several integrations, so it cannot be rotated without breaking something unknown.

The inability to rotate is the real finding. A credential that cannot be changed cannot be responded to when it is exposed.

What good practice looks like

An owner, recorded, who is accountable for whether the account is still needed and correctly scoped. Narrow permissions, reviewed against actual use rather than what an installer requested. Managed credentials, ideally through platform identity or a secrets manager rather than a password in a file.

Restricted use — service accounts should not be able to log in interactively, and should be restricted to the systems they legitimately run on. Monitoring, because a service account behaving unusually is a strong signal precisely because its normal behaviour is so predictable.

When people use them, accountability disappears

Service accounts are frequently used interactively by administrators, either because the credential is convenient or because it holds rights their own account does not. At that point every action is attributed to the account rather than to a person, and the audit trail stops answering the only question that matters during an investigation.

It also means the credential is known to several people, cannot be rotated without telling all of them, and survives their departure. Blocking interactive logon for service accounts is the technical fix; the organisational fix is giving administrators appropriately privileged named accounts so there is no reason to reach for the shared one.

Where to start

List your service accounts with domain or cloud administrative rights and identify an owner for each. The ones with no identifiable owner are the priority.

See secrets management. GuardsArm runs security risk assessments.