# Service Accounts: The Accounts Nobody Notices Until Something Breaks Managing Service Accounts Not every account belongs to a human. Applications need identities too. Services need to authenticate. Scheduled jobs need access. Automation needs permissions. Databases need connections. Those identities are often called service accounts. They quietly keep systems running. And because humans do not log into them every morning, they are easy to forget. Until something breaks. Or until someone discovers the account has far more access than anyone realized. What Is a Service Account? A service account is an account used by software, a service, automation, or another non-human process. For example: backup-service webapp-prod monitoring-agent database-sync A service account might: Read files Connect to a database Run scheduled tasks Start an application Access an API Write logs Perform backups It needs permissions because the software needs to do something. Service Accounts Are Still Accounts This sounds obvious. But service accounts sometimes receive less attention than human accounts. NIST SP 800-171 Rev. 3 explicitly includes service accounts among the account types organizations may need to manage. Its account-management requirements cover creating, enabling, modifying, monitoring, disabling, and removing accounts according to policy and need. The important lesson is: Non-human does not mean unmanaged. The "Do Not Touch It" Problem Imagine an old application uses: svc_app01 Nobody knows exactly what the account does. The password has not changed in four years. The original administrator left. The application still works. So nobody touches it. That may feel safe. But now you have an identity with: Unknown ownership Unknown dependencies Old credentials Possibly excessive permissions The account is invisible only because nothing has forced anyone to look at it yet. Service Accounts Often Accumulate Privileges An application needs to read one directory. Permission denied. Someone grants more access. The application needs another database. More access. A migration happens. More access. Years later the account may have: Read files Write files Database admin Local administrator Network access Backup access Some of those permissions may no longer be necessary. This is privilege creep. Least Privilege Applies to Processes Too Least privilege is not only for humans. NIST SP 800-171 Rev. 3 applies least privilege to users and processes acting on behalf of users, requiring only the access necessary to perform assigned tasks. That is directly relevant to service accounts. If a backup service only needs read access to a directory, it should not automatically receive full administrative access to the server. If an application only needs one database, it should not necessarily receive access to every database. Ownership Matters Every important service account should have an answer to: Who owns this? That might mean: Application team Infrastructure team Database team Security team Named system owner Ownership does not mean one person personally logs in as the service account. It means someone is responsible for understanding why it exists. Without ownership, cleanup becomes difficult. Nobody wants to disable the mysterious account that might break production. Credentials Need a Lifecycle Service accounts often authenticate using: Passwords API keys Certificates Tokens Cryptographic keys Managed identities These credentials need to be protected. If a service password is hard-coded inside a script, anyone who reads the script may obtain it. If an API token never expires, a leaked copy may remain useful for a long time. If nobody knows where a certificate is used, rotation can become dangerous. Authentication does not stop being a security issue because software is performing it. Hard-Coded Secrets Create Problems Consider: password = "SuperSecret123!" inside application source code. Now the credential may exist in: Git history Backups Developer laptops Build pipelines Logs Code copies Changing it becomes more complicated. Better designs use appropriate secret-management mechanisms so credentials are not casually embedded into source code. Service Accounts Should Be Observable If a service account authenticates from one application server every day, that is useful context. If the same account suddenly logs in interactively from a workstation, that may deserve attention. Monitoring can help answer: Where does the account normally authenticate? What actions does it perform? Is it being used interactively? Did its privileges change? Is it still active? NIST's account-management requirements include monitoring the use of system accounts. Interactive Login May Be Unnecessary Many service accounts exist only so software can run. A human may never need to log in using that identity. Where supported, restricting unnecessary interactive logins can reduce risk. Again, the exact implementation depends on the platform. The principle is: Allow only the behavior required for the service to function. What Happens When the Service Is Retired? Applications get decommissioned. Servers disappear. Projects end. What happens to the service account? Ideally: Application retired ↓ Dependencies reviewed ↓ Service account disabled ↓ Credentials revoked ↓ Account removed when appropriate What often happens: Application retired ↓ Everyone forgets the account That creates another stale identity. Build a Service Account Inventory For each important non-human account, record: Account: backup-service Purpose: Runs nightly backup job Owner: Infrastructure Team Systems: server01, server02 Privileges: Read backup directories Credential type: Managed secret Interactive login: Disabled Review date: Quarterly This does not need to be complicated. You simply need enough information to understand the identity. Key Takeaway Service accounts are not background decoration. They are identities. They authenticate. They receive privileges. They access systems. They use credentials. And they need owners. Manage service accounts with the same seriousness you apply to human identities. Because the account nobody notices can still have access to everything. Verified References NIST SP 800-171 Rev. 3 explicitly includes service accounts in its account-management discussion and requires organizations within scope to define, manage, monitor, disable, and remove system accounts according to need.