Home / Knowledge hub / Service account
Knowledge hub
Service account
A non-human identity that software uses to sign in and call other systems.
What it means
A service account is an identity created for software, not a person. A scheduled job, a deployment pipeline or a background worker uses it to sign in to a database, a cloud service or another application and do its work.
It usually has no one at the keyboard, so there is no second step and no one to notice an odd prompt. Its credential is often a key, a token or a password stored in configuration, which anyone who finds it can use as the account itself.
Why it matters
These accounts tend to be powerful and forgotten. They are created in a hurry with broad permissions, shared between systems, and left in place after the project ends. Nobody reviews them, because nobody owns them.
When one is exposed, through a leaked key in a repository or a log, the attacker gets that standing access with no sign-in alerts and no person to challenge. Cloud breaches have often started with a key of exactly this kind.
How it shows up
You meet them in cloud consoles as roles and keys, in databases as application users, in CI/CD as deploy tokens, and in integrations as API keys. Each shows up in audit logs as an account with no human attached.
The mistakes repeat. One account is shared by many services. Permissions are far wider than the task. Keys never expire and are never rotated. No one is named as owner. Prefer short-lived credentials from the platform, give each workload its own account, and review the list on a schedule against least privilege.
Questions people ask
Service account, answered
Is a service account the same as an API key?
Not quite. The service account is the identity. An API key or token is one way it proves itself. The same account may hold several credentials.
Controlling the identity means controlling all of them.
Why are service accounts risky?
They often hold broad, standing permissions, their credentials are long-lived, and no person is watching their sign-ins. A leaked key can be used from anywhere until someone notices.
They are also easy to forget.
Can a service account use MFA?
Not in the usual sense, because there is no person to approve. Protection comes from short-lived credentials, tying the account to a specific workload or network, narrow permissions and monitoring.
Cloud platforms offer workload identity for this.
How often should the credentials change?
As often as you can automate safely, and straight away when a person with access leaves or a leak is suspected. Short-lived credentials issued on demand avoid the problem.
See key rotation and secrets management.
How do we find the ones we have?
List them in each cloud account, database, repository and pipeline, then record an owner, purpose and last-used date for each. Remove the ones with no owner or no recent use.
Do it again on a regular schedule.
Sources
Where this comes from
Related
Terms that sit next to this one
Secrets management
Keeping keys, passwords and tokens out of code and in a vault.
Least privilege
Giving every person and service the minimum access the job requires.
IAM role
A set of cloud permissions that a person or service can temporarily assume.
API key rotation
Issuing new API keys on a schedule and retiring the old ones.
Hardcoded secret
A password, API key or token written straight into source code.
Who owns each machine account?
Over-permissive and leaked machine credentials are what real attackers reach for. We find vulnerabilities in web apps and APIs and prove each by exploiting it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.