Key points
- Identifies an app or service, not a person
- Historically uses long-lived credentials — major attack surface
- Modern best practice: workload identity, OIDC, or IAM roles
- Should follow least privilege and be inventoried like users
- A subset of the broader 'non-human identity' (NHI) category
What it is
A service account is a non-human identity an application uses to call APIs, write to databases, or integrate with other systems. They're how a CI/CD pipeline pushes to a cloud account, how an ETL job reads from Salesforce, and how a microservice calls another microservice.
Why they're risky
Legacy service accounts have long-lived credentials, broad standing privilege, no MFA, no clear owner, and rarely show up in access reviews — making them a top target. The SolarWinds, Okta, and CircleCI breaches all involved abused machine identities.
Modern alternatives
- Workload identity (AWS IAM Roles, GCP Workload Identity Federation, Azure Managed Identities) — no static credential at all
- OIDC for CI/CD (GitHub Actions, GitLab) — short-lived tokens minted per job
- SPIFFE / SPIRE — cross-platform workload identity
- Secrets managers (HashiCorp Vault, AWS Secrets Manager, 1Password Service Accounts) when static credentials are unavoidable
When buyers care
- Cloud migrations
- Post-incident reviews uncovering shadow service accounts
- Compliance audits asking about machine identity governance
- Rolling out NHI security tooling (Astrix, Oasis, Entro, Token Security)
FAQ
Service account vs non-human identity?
NHI is the broader umbrella (service accounts, API keys, OAuth apps, workload identities, AI agents). Service account is the classic, narrower term.