Service account hygiene: inventory, ownership, and rotation

Reference article · 7 min read

Every agency network runs on a set of accounts that exist so software can talk to software. A backup agent signs in to copy files off a file server. A scheduled task pulls a nightly extract from the financial system and drops it on an SFTP server. A multifunction copier binds to the directory so scan-to-email works. A permitting application connects to its database. None of these accounts belong to a person, so none of them show up when HR sends the separation notice, and none of them get touched during the annual access review.

That is the problem. Service accounts tend to have passwords set once during an implementation and never changed, privileges granted generously because the installer asked for them, and credentials written in a runbook, a config file, or a spreadsheet that several people can open. An attacker who lands on one workstation looks for exactly this: a credential with broad rights that will not trigger a password-change prompt and that no one is watching. Cleaning this up is unglamorous work, but it closes one of the most reliable paths from a single compromised endpoint to the servers that matter.

Decide what counts as a service account

Before you inventory anything, agree on scope in writing. A narrow definition misses the accounts that hurt most. Include at least:

• Windows service logon accounts. Anything a service runs as other than LocalSystem, LocalService, or NetworkService.
• Scheduled task accounts. Often the least documented category and frequently the one running finance and reporting jobs.
• Application pool identities and application accounts. IIS pools, middleware, integration jobs.
• Database logins. SQL Server logins used by applications, including ones that predate the current system owner.
• Directory bind accounts. LDAP binds used by VPN concentrators, copiers, badge systems, and appliances.
• Cloud and SaaS integration identities. API keys, tokens, and connector accounts that behave like service accounts even when the vendor calls them something else.

Build the inventory with fields you will actually use

An inventory that lists only account names is not useful during an incident. For each account, capture what it runs, where it runs, and who decides. Useful fields include: account name, purpose in one sentence, application or system, hosts and services that use it, privilege level and group memberships, authentication method, credential storage location, named owner and backup owner, last credential change, rotation method, and the condition under which the account can be retired.

Gather the data from the systems rather than from memory. On a Windows estate, the practical starting points are a directory query for accounts flagged as password-never-expires or carrying service principal names, a per-server pull of service logon identities, a per-server enumeration of scheduled tasks and their run-as accounts, a list of IIS application pool identities, and a list of SQL logins with their roles. Reconcile the two directions: accounts that exist in the directory but run nothing, and running services whose account is not in your list. Both findings are valuable.

Give every account a named human owner

Ownership is the control that keeps the inventory alive. Assign a specific person, not a team mailbox, and record a backup. The owner is accountable for confirming the account is still needed, approving privilege changes, scheduling and validating rotation, and responding when the account is locked out or shows unusual logons. Build ownership review into the same recertification cycle you use for user access, and into the offboarding and role-change process so an account does not become orphaned when its owner moves on. Accounts with no owner after a defined grace period should be disabled first and deleted later, not left running.

Move off shared passwords

The goal is that no human knows the password to an account that runs production work. On domain-joined Windows systems, group managed service accounts let Active Directory generate and rotate the password automatically, with no password for anyone to share. They fit many Windows services and scheduled tasks, though they require supported operating systems, an initial directory configuration step, and application support, so test before committing. Where a managed service account will not work, put the credential in a privileged access vault with checkout, automatic rotation, and logging.

Pair this with least privilege. Give each application its own account rather than reusing one across systems, remove membership in high-privilege groups that were granted during installation, deny interactive and remote desktop logon where the account does not need it, and restrict the account to the hosts it actually runs on.

Rotate without breaking the nightly job

Most rotation failures are dependency failures. The password changes in one place and stays stale in three others.

1. Map every place the credential lives before touching it: service configuration, scheduled tasks, connection strings, scripts, appliance configuration, vendor-hosted integrations.
2. Rotate in a lower environment first when one exists, and rotate one account at a time in production.
3. Pick the window by the job calendar, not the maintenance calendar. Rotate after a nightly batch completes, not in the hour before it starts, and avoid payroll, month-end, and year-end closes.
4. Have a documented rollback and a person on call who can execute it.
5. Watch authentication failures and lockouts by account through at least one full business cycle, since some jobs run weekly or monthly.

Set rotation intervals per account based on privilege and exposure rather than applying one number everywhere, and note that any interval written into a policy or a state security standard should be confirmed against the current official text, since those requirements change.

Handle vendor-supplied accounts deliberately

Software implementations create accounts, and those accounts often outlive the project team. Common findings include install-time elevation that was never removed, passwords stored in plain text in a configuration file, a standing vendor remote-support account, and a credential the vendor considers theirs to manage.

Questions worth asking before go-live and during renewal:

• What accounts does your product create or require, on which systems, with what privileges, and why?
• Does the product support group managed service accounts, or credentials retrieved from a vault?
• What is the documented procedure for rotating each credential, and what breaks if we rotate it?
• Are any credentials stored unencrypted on disk or embedded in configuration?
• Is any account shared across your other customers, and can a default account be disabled?
• How is your support access granted, logged, and revoked, and can it be approved per session rather than left open?

Put the answers in the contract where you can: a required account list delivered at go-live and kept current, least privilege as a deliverable, cooperation with agency-defined rotation, and vendor access granted per request rather than standing. Add a closeout task to the implementation plan that removes elevated install-time rights.

Where to start

Pick the highest-privilege accounts first. Identify service accounts that are members of privileged directory groups, confirm which ones are genuinely required, assign owners to those, and vault or convert them before working down the list. A short list of well-governed privileged accounts is worth more than a complete spreadsheet nobody maintains.

HQT works with state and local agencies on enterprise IT and security engineering, including identity and privileged access practices.

Frequently asked questions