Service Accounts Are the Keys Nobody Rotates

The quarterly access review for non-human identities usually follows a predictable script. The identity team pulls a report of four thousand service accounts from Active Directory. They review the top fifty by privilege. The rest get attested with a click. The same fifty come back next quarter. The report has been running since the report existed, and the actual security posture of the estate has not moved an inch.

The inventory is the easy part. You can query Active Directory for accounts with passwords set to never expire in an afternoon. Getting a name next to every account takes a quarter and a change management process. The directory gives you a list of names. It does not give you a dependency map, and the dependency map is the only thing that matters.

Enterprises spend heavily on enterprise vaults to solve this. They take a password that has not been changed since 2018, put it inside a highly available, encrypted vault, and call the problem solved. Putting a stagnant password in a cyber vault is just moving the plaintext from a shell script to an API call. It improves custody. It does not rotate the credential, and it certainly does not tell you what breaks if you change it.

When faced with a thousand orphaned accounts, the instinct is to disable the ones that look unused. This fails because unused is a measurement artifact, not a fact. A last logon timestamp replicates lazily and can be weeks stale. More importantly, a batch job that runs on the last business day of the quarter looks idle for eighty-nine days. The annual financial close looks idle for three hundred and sixty-four days. If you disable an account based on a ninety-day inactivity report, you will eventually kill the regional invoicing pipeline.

An identity engineer might move a suspected dead account into a disabled organizational unit to test the theory. Forty-eight hours later, a P1 incident is opened because the HR system stopped syncing employee terminations to the badge reader database.

Consider an account named svc_edifact. It last set its password in 2016. The owner field in the directory is blank. The description field says EDI. It runs a scheduled task that posts invoices to three customers, one of which is the largest revenue source in the region. You cannot decommission what you cannot name, and half of these accounts are named after a project that ended four years ago.

Service accounts are the fossil record of every integration built under pressure. They map the organizational history of the enterprise. You can trace acquisitions, failed modernization initiatives, and departed contractors by looking at the naming conventions and creation dates. A service account is a decision someone made at two in the morning during a go-live, preserved in amber. The temporary SAP profile granted to unblock a cutover in 2019 is still sitting there with full administrative privileges. The CI/CD service connection is still using a personal access token tied to a developer who left the company two years ago. The pipeline has been green the whole time. The vendor remote support account has been enabled since 2017, with the password sitting in an old implementation ticket, because the support contract demands admin access to troubleshoot.

When you finally identify an owner and decide to rotate the credential, you discover that rotation is a change management problem wearing a security costume. Changing the password is one command. Finding every process that uses the old one, scheduling the test window, planning the rollback, and getting the right people on the bridge is the actual job.

A database password rotation might go perfectly. The vault is updated, the web servers are restarted, the logs are clean. Three weeks later, the month-end batch fails at two in the morning because a secondary process on a different server used the old connection string. The error is a login failure, not a name. A successful password change proves less than a successful run of every dependent job.

Safe rotation requires the target system to support a dual-secret window. You generate a second password, update the downstream consumers one by one, monitor the logs to ensure the first password drops off, and then revoke it. If the platform does not support dual passwords, rotation requires a coordinated maintenance window. You have to update the consumer first, restart, verify, and then rotate the credential. This requires the consumer to read its configuration at startup, not bake it into a compiled artifact. You also have to schedule the rotation around the business cycle, because the month-end job cannot be tested on a Tuesday.

The industry answer to static credentials is managed identity. Group managed service accounts in Windows, workload identity federation in Kubernetes, and IAM roles in the cloud remove the password entirely. The application requests a short-lived token from the metadata service. There is no secret to store, rotate, or leak in a Git repository.

Managed identity removes the password, but it does not remove the owner. A group managed service account still belongs to a service, a host, and a team. The question of what breaks if the identity goes away survives the migration. Furthermore, managed identity stops at the edge of the modern platform. It does not reach the mainframe batch userids in RACF, the legacy commercial off-the-shelf software that only speaks SQL authentication, the network gear, or the backup appliances with local accounts. That is where the work stays manual, annual, and coordinated with a disaster recovery test.

The fundamental control is not the vault, the rotation script, or the managed identity. The control is ownership. The owner field in Active Directory often says IT or a generic distribution list. That is not an owner. That is a zip code. An owner is a team that has a queue, a manager, and a change process. The owner field should lead to a person who can authorize a restart at three in the morning.

You do not own a service account until you know exactly what will break when you turn it off.