Service account

Service accounts take very different forms by platform. On Windows, the legacy pattern is an ordinary domain user whose password is typed into the service configuration and then never changed. Managed Service Accounts, and from Windows Server 2012 group Managed Service Accounts (gMSA), let Active Directory generate a long random password and rotate it automatically, every 30 days by default, with authorised hosts retrieving it from the directory. On Linux, daemons run as system users with a nologin shell. In Kubernetes, every pod runs as a ServiceAccount; since version 1.24 long-lived token Secrets are no longer generated automatically, and pods receive projected, audience-bound, time-limited tokens through the TokenRequest API. In the cloud, the preferred forms are AWS IAM roles assumed through STS, Azure managed identities and Google Cloud service accounts used without downloaded keys, plus workload identity federation, where an external OIDC token, for example from a CI pipeline, is exchanged for short-lived cloud credentials.

The classic weaknesses are static secrets and missing ownership. Passwords set to never expire, keys embedded in scripts or configuration files, one account shared by several applications, interactive logon still permitted, and exemptions from MFA and conditional access because "a service can't do MFA" all make these accounts ideal persistence for attackers. In Active Directory, Kerberoasting (MITRE ATT&CK T1558.003) exploits any account with a service principal name: any authenticated user can request a service ticket encrypted with a key derived from that account's password and crack it offline, especially when RC4 is still allowed. Long random gMSA passwords and AES-only encryption defeat it.

Governance is spelled out in control catalogues. CIS Controls v8.1 Safeguard 5.5 requires an inventory of service accounts recording at least the department owner, review date and purpose, with reviews at least quarterly; NIST SP 800-53 Rev. 5 AC-2 covers account management generally. Practical hardening means one account per application and environment, denying interactive and remote-desktop logon, restricting where the account may authenticate from, storing any unavoidable secret in a vault with rotation, alerting when a service account signs in interactively or from a new location, and disabling accounts whose application has been retired.

A service account is one implementation of a non-human identity. The broader trend replaces stored secrets with platform-attested workload identities, such as SPIFFE IDs, cloud managed identities or Kubernetes projected tokens, whose credentials are short-lived and never handled by a person. AI agents and automation tools increasingly receive service accounts too, which makes least privilege and a named human owner more important, since the software acting through the account may be steered by untrusted input.